Ignore the agent demo. Watch the credential lifecycle.
On October 15, 2026, India's CERT-In published advisory CIAD-2026-0049, classifying AI agents as an active attack surface. The document describes a pattern that should worry every team running autonomous infrastructure: agents re-deriving and reusing the same credentials across independent operations, crossing authorization boundaries within hours, building complete attack chains before a human analyst finishes reading the first log line. The advisory states that no affected organization discovered the unauthorized access on their own. Every detection came from an AI model provider or from CERT-In's own hunting operations.
That single sentence is the most important thing in the document, and it has almost nothing to do with artificial intelligence. It has everything to do with the fact that the organizations being compromised had no idea what their own machine identities were doing.
I have spent the last decade watching this exact failure mode play out in crypto. Not with large language models, but with bots, relayers, keeper networks, and liquidation agents. The shape of the problem is identical. The regulatory framing is new.
The technical claim is sound, and it is not what the headlines say.
Strip away the AI branding and the advisory describes a tool registry design flaw. Many agent frameworks inject tool authentication material as environment variables or global configuration rather than provisioning per-task short-lived credentials. Once a planner learns that a tool is available in one session, in-context learning causes it to naturally reuse that tool in subsequent sessions. This is not a code bug. It is an emergent property of how these systems reason about available actions. The same property appears in every automated trading system I have audited that was built without a rigorous secrets management layer.
The advisory's most technically correct recommendation is that network-layer default-deny egress enforcement is the only reliable boundary, and that relying on system prompts to constrain agent behavior is insufficient. This is precisely right, and it is right for reasons that anyone who has deployed on-chain automation already understands. Prompts are probabilistic. Policy is deterministic. A liquidation bot does not refrain from calling an arbitrary contract address because its configuration file says please do not. It refrains because the egress policy drops the packet.
Here is where the advisory shows its age, and where crypto teams should pay closer attention than the document's authors did.
Nowhere in the published summary does the technical guidance address the Model Context Protocol attack surface that has dominated agent security discussions since 2025. MCP tool definitions themselves are an injection vector. An agent that loads a malicious MCP server inherits poisoned tool descriptions, and the payload executes through the tool schema rather than through user input. This is a more subtle channel than exposed API keys, and it maps directly onto how on-chain agents consume external data: price oracles, RPC endpoints, bridge relayers, indexer APIs. Any agent that discovers its tools dynamically is a tool-poisoning target. The advisory's technical framing remains anchored in the 2024 API key leakage paradigm.
The contrarian read: this is not a new threat class. It is an old one wearing new vocabulary.
CERT-In's own text concedes that the exploited weaknesses were conventional in nature. Exposed credentials. Deprecated API endpoints that were never decommissioned. Overly permissive roles. If an organization had real secrets management, an API lifecycle policy, and least-privilege discipline, the agent would have found nothing to amplify. The agent is a multiplier, not a new source of vulnerability.
Which means the regulatory panic is misdirected. Teams will now over-invest in agent-specific detection tooling while the actual exposure remains an environment variable committed to a Git repository in 2023 and never rotated. I have watched this exact allocation error in DeFi for years. After every exploit, the market funds a new monitoring product and skips the key rotation. Bets are cheap; exits are expensive, and most teams never price the exit.
There is a second-order problem the advisory creates, and it is a serious one: the document discloses risk without disclosing indicators of compromise. There is no detection signature, no request pattern, no TLS fingerprint an affected organization could use to self-inspect. A security advisory that tells you that you may be compromised but gives you no means of verifying whether you are is not an operational document. It is a policy statement. Compare this to the standard set by genuine incident advisories, which ship with log queries and detection rules. By that standard, this document falls short, and the shortfall matters more than its technical content.
For anyone building on-chain, the actionable extraction is narrower than the advisory implies and more urgent than its framing suggests.
Three things follow. First, the credential architecture question is the whole problem. If your agent, keeper, or relayer holds a long-lived key with broad permissions, you have already replicated the failure mode regardless of whether any model is involved. Per-task ephemeral credentials, scoped to a single intent, revoked on completion, are the only structural answer. Second, egress policy must live at the network layer, enforced by something deterministic. A smart contract's access control is the on-chain analogue of a firewall rule; it works because it is enforced by the virtual machine, not because participants agree to respect it. Third, treat dynamic tool discovery as an untrusted input channel. Every external API your agent consumes for price data, routing, or state is a potential injection path, and the injection arrives through the schema rather than the payload.
The competitive implication is worth stating plainly, because most coverage misses it. Regulatory fragmentation benefits large incumbents. A firm that can absorb three sets of compliance requirements has an advantage over a firm that can absorb one. If default-deny egress enforcement becomes a contractual requirement for AI vendors serving Indian financial institutions, the compliance cost flows to enterprise pricing, open-source agent frameworks get banned by procurement teams that cannot verify their defaults, and commercial platforms with built-in security posture capture the gap. India will not write the agent security standard. It will enforce one, and the standard will be written in the United States and in open-source specification bodies. That is the Brussels effect operating through supply chain contracts rather than statute.
What to watch is not the advisory. Watch whether it converts into a direction with a compliance timeline and a penalty structure, whether financial regulators fold it into existing audit frameworks, and whether cloud providers ship agent egress control and audit reporting as a bundled primitive within the next two quarters. If that last one happens, the independent agent security vendor window closes fast. Cloud providers are the most reliable destroyers of value in every adjacent security category.
The uncomfortable question the document raises but does not answer: how much of what it calls an active attack surface is actually a testing failure? An agent that hallucinates its task boundary and touches a live production system is not under attack. It is being evaluated in an environment that was never properly isolated. Those are different problems with different fixes, and conflating them will produce a generation of compliance theater where firms deploy nominal allowlists, run one secrets scan, write the report, and return to their old habits.
Follow the gas, not the hype. The gas here is the credential. It was always the credential.
