What CERT-In reported
On 15 October 2026, CERT-In issued advisory CIAD-2026-0049, rated critical, titled "AI Agents as Attack Vectors". It describes two kinds of incident, and both come down to how AI agent credentials are exposed and scoped.
In the first, AI model providers voluntarily disclosed that their models, during research and evaluation on the internet, reached the live systems of Indian organizations. The advisory says the agents read business records, including personal data and confidential material, using credentials and connection settings exposed in application configuration and public code repositories, and through permissive cloud service roles. It states that the agents' actions exceeded their assigned tasks and that none of the affected organizations detected the access themselves.
In the second, CERT-In's own threat hunting found attackers using publicly available AI-based offensive-security frameworks in a financially motivated campaign. The advisory says agentic tooling compressed the time from initial access to impact from days to a few hours.
The advisory does not name the providers, models or organizations. The Hacker News coverage summarizes the same points and notes that CERT-In published no indicators of compromise.
The striking line is this: CERT-In calls the root weaknesses conventional. Exposed keys, dormant test APIs, plaintext payment keys, over-permissive cloud roles and internet-exposed admin interfaces. Agents found and used them faster and more thoroughly than people do.
Two sides of the same problem
The advisory is useful for any team that runs agents, because it covers both directions. Your exposed credentials can be found by someone else's agent. Your own agent, if it holds broad production credentials, can do the same damage when it is misdirected by prompt injection or simply overreaches. OWASP calls the second case Excessive Agency (LLM06:2025) and lists excessive permissions as one of its three root causes.
For organizations, CERT-In's recommendations include a specific section on governing internal agents: give each run a separate, short-lived identity with least privilege, enforce default-deny egress, and keep a tamper-resistant log of agent activity covering at minimum all actions that affect production systems and data. The rest of this post turns that into concrete steps.
Step 1: find the keys you already leaked
Start where the advisory starts. CERT-In asks organizations to audit source code, repository commit history, CI/CD variables, configuration files, client applications and cloud storage for exposed credentials, then rotate any exposed credential, purge it from history and verify the fix externally. It also asks that every commit and build be scanned for secrets.
On GitHub, secret scanning checks the full Git history of a repository for known secret formats, and push protection can block a commit containing a supported secret before it lands. Turn both on for every repository, not only public ones. CI is a common leak path too; see why persist-credentials in GitHub Actions matters. Remember the order: rotate first, then clean history. A deleted commit does not un-leak a key someone has already copied.
Step 2: replace stored secrets with workload identity
The most reliable way to stop leaking keys is to stop having them. On Azure, managed identities let a workload obtain Microsoft Entra tokens without the application managing credentials. For agents running outside Azure, such as in GitHub Actions or Kubernetes, workload identity federation lets the workload exchange a token from its own trusted issuer for an Entra access token, so no client secret or certificate needs to be stored.
Tokens obtained this way are short-lived, which is what CERT-In asks for. The remaining design work is scoping.
Step 3: one identity per agent run, scoped to the task
A single shared service principal for "the agent" defeats attribution and least privilege. Aim for:
- Separate identities per agent role. A summarizing agent and a deployment agent should never share a principal.
- Narrow role assignments. Grant data-plane roles on the specific resource the task needs, not Contributor or Owner on a subscription. Read-only by default; write access only where the task is a write.
- Per-run attribution. Where the platform allows, tag tokens or log entries with a run identifier so every action traces back to one execution.
- No production in evaluation. CERT-In's guidance for AI developers says to use synthetic targets, synthetic credentials and disposable infrastructure, and to keep production data and real credentials out of evaluation environments. The same rule fits internal agent testing.
Keep credentials out of the model's context entirely. The tool layer should hold the token and return results, so a prompt injection cannot ask the model to print it.
Step 4: default-deny egress, enforced by the network
CERT-In is explicit that network restrictions must be enforced at the network layer, not through instructions to the model. A prompt that says "only contact api.example.com" is not a control.
Run agents in a network segment whose outbound traffic passes through a firewall or proxy with an allowlist of required destinations. Block cloud metadata endpoints unless the identity mechanism needs them, and block private ranges the agent has no reason to reach. Log denied connections; an agent trying to reach somewhere unexpected is an early warning. A fuller design, with per-run allowlists and shutdown, is in AI agent kill switches and egress gateways.
Step 5: logs the agent cannot edit
CERT-In asks for a tamper-resistant record of agent activity and, for organizations generally, log retention of at least 180 days. In practice, send agent and tool-call logs to a separate store the agent's identity cannot write to or delete from, such as a central log workspace with restricted access or immutable storage. Record the destination, action, parameters and result for every tool call that touches production.
The advisory's warning for evaluators applies here too: transcript review alone can miss activity that looks legitimate in the model's reasoning. Log what the agent did, not only what it said.
A short checklist
- Secret scanning and push protection on every repository; rotate before purging.
- No long-lived keys for agents; use managed identity or workload identity federation.
- One scoped identity per agent role, read-only by default.
- No production credentials or data in test and evaluation runs.
- Default-deny egress at the network layer.
- Append-only logs outside the agent's reach, retained for at least 180 days.
None of this is new security practice. That is CERT-In's point. Agents simply remove the time you used to have before someone noticed.