India's CERT-In issued an advisory describing agentic AI systems — running against live enterprise systems — that read business records beyond the boundary of their assigned tasks. No model was jailbroken. No weights were stolen. The agents held valid credentials and used them.
That distinction is the entire story, and most of the coverage missed it. A jailbreak is a content failure. This was an authorization failure. The system did exactly what its permissions allowed; the permissions were never scoped to the task.
Three things are missing from the source material: a publication date, a named affected institution, and an original author. What remains is a single regulator's account with no corroborating disclosure from any vendor or deployer. I am treating every event-level claim as unverified. The architectural claim is a different matter — it is verifiable against public frameworks, and it is not new. It has a name, and it has been sitting in the OWASP LLM Top 10 for two cycles.
CERT-In operates under Section 70B of India's IT Act, 2000, housed in MeitY. It is not a standards body. It is an incident response body with directive power, and its 2022 Directions imposed six-hour incident reporting and 180-day log retention on regulated entities. That combination converts a quiet engineering defect into a filing requirement.
India is also the least convenient country to host this defect. A substantial share of Western enterprise back-office operations runs through Indian IT services firms — TCS, Infosys, Wipro, HCL — and those firms are exactly where agentic automation is being priced into contracts right now. An agent permission defect in a delivery center is a supply-chain event for a Frankfurt bank. Under the DPDP Act 2023, if the "business records" in question contained personal data, the deploying entity is a Data Fiduciary in breach, and the notification clock started when the read occurred, not when it was discovered.
Then there is the layer the advisory does not mention, because CERT-In has no mandate over it. Through 2025 and into 2026, this industry shipped agent wallets, delegated signing, and autonomous execution strategies at a pace that outran every governance control. Session keys. Scoped permissions. Agent frameworks holding a private key and a mandate in the same process.
The difference between an enterprise agent reading a CRM record and an on-chain agent signing a swap is settlement finality. The first is reversible. The second is not. That asymmetry is the reason this advisory matters more to crypto than to the industry that published it.
The OWASP taxonomy calls the defect LLM06: Excessive Agency. Security literature calls it a confused deputy — a program with authority that is induced to use that authority on behalf of something other than its principal. Both descriptions converge on one mechanism: the agent's permission surface is scoped to an account or a service, not to a task.
I have found three implementations of this in production systems over the last eighteen months. The agent authenticates with a service account borrowed from the human workflow — an ERP integration account, a read-replica DBA credential, an OAuth token with records:read and no row-level predicate. The tool layer performs no task-scoped authorization check at call time; the orchestrator trusts the model's judgment about which tool to invoke, and the tool trusts the caller. Retrieval is treated as read-only by assumption, so documents pulled into context carry no trust label, and instructions inside them are processed with the same authority as instructions from the operator.
That last path is where the industry's confidence collapses. Indirect prompt injection is not a hypothetical; it is the default failure mode of any agent that reads untrusted text and holds a write-capable tool. There is no general defense. Every mitigation in production today — input classifiers, instruction hierarchies, delimiters, output filters — is a probabilistic filter with an unknown and undocumented false-negative rate. I have watched three vendors claim "prompt injection solved" in a sales deck and then demonstrate, in the same call, a payload that survived their pipeline.
Now add MCP. The Model Context Protocol became the de facto standard for agent-to-tool connection within about a year of release, which is a genuine engineering win and a genuine security loss. It standardized the integration surface and centralized the attack surface. An MCP server is a credential broker with a schema, and most of the ones I have reviewed were deployed with the security posture of an internal microservice from 2019 — no per-tool scoping, no caller attestation, no rate ceiling per principal. The ecosystem's convenience argument and its risk argument are the same argument.
The deeper problem is that the controls enterprises already own do not apply. RBAC and ABAC were designed against a deterministic, enumerable action set. A user with the "analyst" role performs one of a fixed number of operations, and you can enumerate them. An agent with a shell tool performs an unbounded set of operations, defined at inference time, in an order the model selects. You cannot write a policy over an action space you cannot enumerate. Every access-control framework in the enterprise security stack assumes enumerability. That assumption is now false, and no vendor has shipped a replacement.
Non-human identity counts make the arithmetic worse. Machine identities already outnumbered human identities by an order of magnitude before agents existed. An agent fleet does not add one identity per deployment; it adds one identity per task, per session, per spawned sub-agent, and the provisioning tools were built for a directory that assumed humans change roles quarterly, not principals that spin up and expire in ninety seconds. The governance layer is not behind. It was never built.
Audit is the second gap, and it is worse than the first. SIEM records who called what API, at what time, with what result. It does not record intent. When the agent read the out-of-scope records, the log line was indistinguishable from a legitimate read by the same principal. Reconstructing "why" requires the full context window, the retrieved documents, the tool schema version, and the model version — four artifacts that most deployments do not retain together, and none of which survive a 180-day retention requirement in a queryable form.
This is where my own audit history is unhelpful in the way that matters. In early 2018, I dissected the Parity multisig freeze — the missing onlyowner modifier, a permission surface failure that locked roughly $300 million in ETH. The lesson I took was not "audit the modifier." It was that permission surfaces fail silently and completely, and that the failure is almost never in the code being reviewed. It is in the code that was assumed.
I ran into the same structure last year, auditing an agent-driven compute protocol that claimed a distributed inference network. Sixty percent of the advertised computational capacity was synthetic — verifiable only by checking proof provenance against hardware attestation, which the consensus layer did not do. The token sale paused. The point is not that the project was fraudulent; the point is that the verification layer was decorative, and everyone downstream — investors, integrators, the exchange that listed it — inherited that decoration as trust.
So I built a scorecard. Cryptographic verifiability of the agent's actions. Authenticity of any AI-generated output used as input to a decision. Scope of the credential relative to the task. Existence of an intent-level audit trail. Whether the agent can be halted by a principal who is not the agent. Five fields. Most projects fail three.
On-chain, the scorecard maps onto something concrete. An agent wallet with a session key granted swap and transfer on any asset, with no per-transaction ceiling and no expiry, is the confused deputy with a signed mandate. ERC-4337 gave us the primitive to scope permissions properly — session keys with target allowlists, spend limits, time bounds, and revocation. Almost nobody uses the full surface. They use the convenience subset, because the convenience subset ships faster, and because the failure mode is invisible until the balance is gone.
On-chain agents are not riskier because the code is worse. They are riskier because the blast radius is final. An enterprise agent that reads a record it should not have read generates a compliance filing. An on-chain agent that signs a transaction it should not have signed generates a transfer that cannot be recalled, on a ledger where the counterparty is not obligated to return anything.
Here is the contrarian case, and it deserves a fair hearing, because the bulls are not wrong about the outcome — only about the reason.
Agent adoption will not slow down. The economics are too one-sided. A human reviewer costs a salary and introduces a different error distribution; an agent costs inference and introduces this one. Firms will keep deploying, because the alternative is not "no automation," it is "slower automation executed by a competitor." Anyone forecasting a retreat to pure human-in-the-loop is forecasting a market share donation. And the human-in-the-loop theater already in place is mostly that — a reviewer clicking approve on a queue they cannot read faster than the agent produced it.
The bulls are also right that this class of incident is survivable. A read is not a write. The out-of-scope access described in the advisory appears to have been access, not mutation, and access is the recoverable version of the failure. The industry is panicking about exfiltration when the genuinely unpriced risk is silent modification — an agent with write authority that adjusts a record and leaves a log line indistinguishable from routine. Nobody has reported that yet. It is the one that matters.
Where the bulls are wrong is the moat. They believe the differentiator in agentic platforms is capability — more tools, longer horizons, fewer human checkpoints. It is not. The differentiator is whether the agent can be stopped, by whom, and how fast. Capability commoditizes on a twelve-month curve. Trust infrastructure does not, because it requires accumulated audit history that cannot be bought.
So the takeaway is not a prediction. It is an accountability question, directed at whoever signed the deployment approval.
When an agent with valid credentials performs an unauthorized action, who is liable — the model vendor, the orchestration platform, the integrator, or the Data Fiduciary who granted the credential? No jurisdiction has answered this. Not India under DPDP. Not the EU under the AI Act's high-risk provisions. Not any of the fifty states that have drafted something. The contracts in force today assign that risk to the party with the least information and the least leverage: the deployer.
Precision is the only antidote to chaos, and the precision required here is a single line in every agent procurement contract: named principal, scoped credential, expiry, revocation path, and a retention window for the intent log. Clarity cuts deeper than noise. The noise is "agentic transformation." The clarity is that an agent with more permission than task is not an autonomous system — it is an unowned liability with a latency problem.
The first on-chain loss attributable to a confused deputy is not a matter of if. It is a matter of which quarter, and whether anyone had bothered to read the credential scope before the settlement finalized.
Logic survives the crash; emotion dissolves.