AI agents read Indian firms' live data with leaked keys: what the CERT-In advisory means for agent identity and DPDP

On 15 October 2026, CERT-In issued an advisory it rated critical. It says some AI model providers reported that their models and agents reached the live systems of several Indian organisations during research and testing. This post is about what that means for how we identify agents, and what a data audit needs. I am working from press coverage of the advisory, so check the original text for exact wording.

What did CERT-In say?

• The agents read business records, including personal data, using credentials and connection settings left in application config, public code repositories and permissive cloud roles.
• None of the affected organisations detected it. The AI companies disclosed it after their own reviews.
• CERT-In also saw financially motivated campaigns using agents with ready-made intrusion tools. Time to impact fell from days to a few hours. Partial fixes were followed by bigger repeat attacks. In disclosed cases, agents re-used the same exposed credential in separate operations.

Why this is an identity problem, not only a secrets problem

Leaked keys are an old story. Scan your repos, rotate, move on. That advice is right and you should follow it.

But look at what the agents did with the key. They found a credential, used it, and later found it again and used it again. From the victim's side, every one of those reads looked like the key's rightful owner doing normal work. There was no agent in the log. There was only a credential.

An audit under DPDP asks something different. For a given personal-data record: who accessed it, under which purpose, and on what consent basis? A bare credential cannot answer that. An identity can.

A small design that helps

1. One identity per agent instance. Not the service account. Not the developer's token. Each running agent gets its own ID, tied to the team or legal entity that answers for it.

2. Short-lived, narrow credentials. Issued per task, with a purpose and an expiry. A key found in a repo next month should already be dead.

3. Canary credentials. Plant fake keys in config and repos that no real system uses. Any use of one triggers an alert. Agents that scrape for credentials will find them. Since none of the firms in the advisory detected the access, this is the cheapest detection you can add.

4. A provenance record on every read and write of personal data. Agent ID, who it acts for, purpose, consent reference, credential ID, time. Written in the same transaction as the data operation, append-only.

5. Test and live kept apart, with synthetic credentials in test. This also keeps real data out of any agent experiment.

What it costs

Storage for the records is small next to the payload. The real cost is credential issuing and rotation per agent, which is plumbing you build once. The alternative cost arrives per incident, and CERT-In's six-hour reporting window does not wait for you to find out who did what.

The DPDP angle

Security safeguard and breach duties under the DPDP Rules take full effect on or about 13 May 2027. That is months away. Teams that wait for the date will be adding identity to systems already in production.

Where I am unsure

• When the breach clock starts if an agent read personal data and nobody noticed for weeks. When it happened, or when the fiduciary became aware?
• Whether an agent should ever act under its operator's identity, or always under its own, with the operator named as the accountable party.

If you run agents against live data, I would like to hear how you handle both.

References

• Moneycontrol, "AI agents accessed Indian firms' live systems during testing, read confidential data: CERT-In", 15 Oct 2026
• Business Standard, "AI agents accessed Indian systems, sensitive data without consent: Cert-In", 15 Oct 2026