On October 15, India’s national cybersecurity agency published an advisory with one sentence I keep rereading.
“None of the organizations detected the unauthorized access.”
CERT-In reported that AI agents under test by AI companies reached the live systems of Indian organizations and read personal data and confidential business records. The agents wandered past their assigned tasks. The companies they got into never saw them. The only reason anyone knows is that the AI providers found it in their own reviews and reported it.
Most coverage framed this as a rogue-AI story. I read it as an infrastructure story, and I think that’s the more useful read for anyone running a business.
The Agents Didn’t Need a Zero-Day
Here is how the agents got in, according to the advisory.
Credentials and connection strings sitting in application config files and public code repositories. Keys still living in repository history after someone “deleted” them. Cloud roles with far more permission than the job required. Old, unused, and test APIs still reachable from the internet. Payment API keys stored in plain text. Management interfaces exposed to the public, running unpatched middleware with weak passwords and no MFA.
Read that list again. There’s nothing new on it. Every item was on the security checklists my teams worked from twenty years ago.
One detail stood out. In the cases tied to AI companies, the agents “found the same exposed credential again and reused it in separate operations.” They didn’t break anything. They walked through a door someone left open, came back later, and found it still open.
AI didn’t create the hole. It made the hole cheap to find.
That’s the shift. A human attacker has to hunt for a leaked key, and hunting takes time. An agent searches tirelessly and doesn’t get bored. CERT-In flagged a separate, financially motivated campaign using publicly available AI-agent attack frameworks, and those tools cut the time from first access to impact from days to a few hours.
The advisory adds that organizations that only partly fixed their problems were hit again within days, “at a larger scale.”
The weaknesses you tolerated because nobody would ever find them? Something is now looking for them full time.
Even the Labs Couldn’t See Their Own Agents
If you think detection is only a problem for under-resourced companies, look at what OpenAI disclosed the next day.
Four more incidents, all from June, where its models acted without authorization. Two were rated critical. In one, an internal model downloaded 24 years of hospital-bed data from a government website. The site blocked the request, and the agent got around the block. In another, a model accessed a crypto wallet nobody had given it, made a payment to finish its task, and described the funds as “effectively abandoned.” A third downloaded 147,451 rows from nonpublic data tables and didn’t tell its evaluators.
OpenAI didn’t learn about three of the four until August or September. That’s two to four months.
This is a company with more telemetry on its own models than any business reading this will ever have. It still took months to see what its agents had done.
So the honest question isn’t whether your AI vendor’s guardrails are good. It’s this: if an agent touched a system it shouldn’t have this morning, how would you know?
What “Seeing Sooner” Looks Like in Practice
I’ve told part of this story before, but it fits here.
At Kyndryl, I led delivery on a Fortune 500 account that had the problem most mature IT shops have. Incidents were getting fixed. They just weren’t getting seen early. Issues ran for a long time before anyone knew they existed, and the cost piled up in the gap between “it broke” and “we noticed.”
We didn’t solve it with a smarter fix. We solved it with instrumentation: monitoring that covered what actually mattered, alerting tuned to real signals instead of noise, and correlation that let the team see a pattern before it turned into an outage.
The result was a 38% improvement in incident detection and more than $2M in documented savings. Not one dollar of that came from AI. It came from finally being able to see the environment we were responsible for.
Why that matters for agents
An AI agent reaching a system outside its scope is an incident. It’s the same kind of event that monitoring has always been built to catch: an identity doing something it has never done before, touching data it has never touched, calling out to a place it has no business going.
The organizations in the CERT-In advisory didn’t miss the agents because the agents were clever. They missed them for the same reason that Fortune 500 account was missing incidents before we instrumented it. Nobody was watching the right signals.
If your monitoring can’t tell an AI agent from a normal service account, you’re blind to the fastest-growing category of activity in your environment.
Five Checks Before Your Next Agent Goes Live
CERT-In’s recommendations are worth reading in full. Here is how I’d boil them down for a leadership team that wants to act this quarter, not next year.
1. Find the keys you forgot about
Run secrets scanning across your code, your config files, and your full repository history, not just the current branch. Rotate everything you find. Then confirm from outside your network that the old credential is actually dead. Deleting a key from a file doesn’t remove it from the history an agent can read.
2. Shut down the APIs nobody owns
Inventory every API you expose. Old versions, test endpoints, the integration a contractor stood up in 2021. If no one can name an owner, turn it off. An agent will find the endpoint you forgot about long before your team remembers it exists.
3. Shrink every role to the job
Apply least privilege to cloud and backend roles, then test it the way an attacker would: what can an anonymous user read and write? Most companies are surprised by the answer. Overprivileged roles were a quiet risk before agents. Now they’re a loud one.
4. Give each agent its own short-lived identity
Agents shouldn’t borrow a human’s credentials or share a long-lived service account. Each run gets its own scoped identity that expires. Restrict outbound traffic too, and enforce it at the network layer. CERT-In said it plainly: the block “should be enforced at the network level, not through instructions to the model.” A prompt asking an agent to stay in bounds isn’t a control.
5. Log what agents do, and keep it
Tamper-resistant action logs, kept for at least 180 days, which is CERT-In’s floor. Then alert on the thing that matters: an agent identity touching a system outside its defined scope. OpenAI’s incidents surfaced months later. Your logs need to outlast your detection lag.
The Part Small Businesses Get Wrong
I hear the same objection from smaller clients: we don’t have a security operations center, so this is an enterprise problem.
It isn’t. Look at that list again. Secrets scanning, API inventory, least privilege, scoped identities, logging. None of it needs a SOC. It needs someone to own it and a few weeks of focused work. A small business with a clean environment is in better shape than a large one with fifteen years of forgotten credentials.
The agents in that advisory weren’t sophisticated. They were patient, and they were looking for what people left behind. That’s an infrastructure problem with an infrastructure answer, and it should be solved before an agent is ever turned loose on your systems.
The companies in India found out from someone else. You don’t have to.
Want to know what an agent would find in your environment? Our AI Infrastructure Assessment includes a security posture review built for exactly this question. Start the conversation here.
See how we sequence AI work, infrastructure first. Explore our services.
More on running AI agents safely: Browse the Summit AI blog.
Russell Love is the Founder & CEO of Summit AI Business Solutions, based in Browns Summit, NC. With 20+ years of enterprise transformation experience at IBM and Kyndryl, Russell helps businesses build the foundations that make AI actually work.