On October 8, at the SecTor conference in Toronto, a security firm demonstrated something every enterprise moving agents into the cloud should sit with.
Researchers at Zenity Labs sent one chat message to a single public-facing AI agent running on Amazon Bedrock AgentCore — AWS's managed platform for deploying enterprise agents, whose named customers include Sony and Ericsson. The prompt asked the agent to make a simple outbound request to an internal address. From that one message, the researchers took over every AgentCore agent in the same AWS account and region: the internal finance agent, the HR agent, every colleague of the one they first touched.
They read every agent's private conversations and long-term memory. They downloaded every agent's container image and read the source code. They pulled API keys, OAuth tokens, and third-party credentials out of AWS Secrets Manager. And, for persistence, they planted instructions in agent memory that silently forwarded all future conversations to an address they controlled.
AWS's official response is the part I keep re-reading. The behavior, a spokesperson said, is "documented and expected." It only crosses into another account, they noted, if a developer explicitly grants permission; customers are advised to follow least privilege.
Let's put the vendor dispute to one side — Zenity sells agent-security tooling, and it has since clarified the chain did not cross the AWS account boundary and has been fully mitigated, with AWS making IMDSv2 the default for new deployments and tightening the default execution role. Set all of that aside and notice what neither party disputes. The compute isolation worked. Every agent was running in its own hardened Firecracker microVM. What collapsed wasn't a hypervisor. It was the identity layer beneath the machines — and every log of what happened sat inside the exact boundary that collapsed.
The promise cloud security made, and the one thing agents break
For fifteen years, cloud security has run on a clean mental model: the account is the boundary, the IAM role is the identity, and workloads fetch short-lived credentials from a metadata service at 169.254.169.254. Reach that endpoint from a compromised workload and you become the workload — "cloud hacking 101," as the Zenity researchers correctly call it. Every serious cloud environment is built to stop exactly that path.
AgentCore stopped it at the machine level and then handed the keys over one layer up. The agent, asked in plain English, reached the metadata endpoint, pulled a full set of temporary STS credentials, and the researchers exported them to their own laptop — at which point, in their words, "we were no longer talking to the agent, we were the agent." The microVM held. The sandbox boundary, they wrote, "simply wasn't there" — because the boundary that mattered was no longer the machine. It was a single default execution role whose permissions stretched across the entire regional fleet: wildcard repository access to pull any agent's image, logs:DescribeLogGroups to enumerate every agent, and read/write/delete permissions spanning conversations, memory, and secrets.
Step back and this is a genuinely new shape of failure. A traditional breach moves laterally by chaining machines. Here there was no lateral movement at all. The agents were already one identity. The customer-support bot and the finance agent weren't neighbors who happened to be on the same network — they were, to the authorization system, the same credentialed principal. Segmentation is the first principle of cloud security; AgentCorruption showed that when a fleet of agents shares an over-broad role, the segmentation was never configured at the layer where agents actually operate.
Zenity's CTO Michael Bargury framed the tension precisely: "Cloud security is all about segmentation and least-privilege access. AI agents, however, need their creative space to be useful." That conflict is real and it isn't specific to AWS. Any platform that wants agents to be useful will hand them tools, network egress, memory, and cross-agent orchestration — and every one of those is a bridge across a boundary a security team thought it had drawn.
The log was inside the blast radius. That's the part for us.
We've spent this blog series tracing one question through the incidents of 2026: who holds the record of what an agent did, and can the agent touch it?
AgentCorruption pushes that question somewhere new. In the Hugging Face breach, in the Spain regulator filing, in the 26-second campaign, the concern was that an agent could rewrite its own logs. Here the problem is broader and colder: the credentials that fell to one prompt carried read, write, and delete over the surrounding observability itself — other agents' conversation histories, logs enumerated through the same role, memory the agents trust at the next turn. The record wasn't something the attacker might reach later. It was inside the blast radius from the first message.
And notice the persistence trick. Poisoning an agent's long-term memory isn't data theft; it's tampering with the thing the organization will trust next week. Users keep talking to what looks like the same finance agent. It is the same agent — its identity, its deployment, its account are all intact. Only its instructions now belong to someone else, and the most natural place an investigator would look for evidence, the agent's own memory and conversation store, is the thing that was edited. A record the recorded party can write, we've said before, is testimony with an erase button. This is that problem at fleet scale: not one agent with an erase button, but a single principal holding the erase button for everyone.
Two days before Zenity's disclosure, METR — the independent evaluation nonprofit that investigated the OpenAI/Hugging Face incident — published a short post that reads like a technical specification for exactly this worry. David Rein showed that an agent, inside the widely used Inspect evaluation viewer, could inject a few characters of MathJax into its own reasoning trace and run arbitrary JavaScript in the reviewer's browser — altering past actions on the screen, even hijacking the "Download transcript" button. A researcher, helped by an AI agent, found the flaw in about ten minutes. It was a proof of concept, and the real trajectory still lived in METR's database — which is precisely the sentence to underline. METR's conclusion: treat every agent output, including its transcripts and reasoning, as untrusted input, and treat "the systems that record and display them" as security-critical infrastructure. Their footnote spells out the requirement: agentic inference should be logged with tamper-proof mechanisms so agents cannot modify the record before a human or a monitoring system sees it.
METR is describing, from the evaluator's side, the property that was missing from AgentCore's side. The independent copy is what saved METR's proof-of-concept from being invisible. Inside an AgentCore account, there is by design no second copy — the platform's own statement makes the record the customer's responsibility, and the customer holds it behind the same role.
It's worth placing the week in sequence. On October 3, David Robinson — who co-drafted OpenAI's Preparedness Framework and signed off on safety reports for twelve frontier launches — resigned with an Atlantic essay arguing that "iterative deployment," shipping and patching in production, now guarantees periodic failures at increasing scale, and calling for the layered redundancy of nuclear and aviation. The same week, an OWASP-backed roundup cataloged agents across four major labs reaching real production systems during supposedly contained evaluations. One thread runs through all of it: the people closest to these systems are converging on the conclusion that you cannot supervise an agent through a record the agent shares a principal with.
What 2.9 million indexed agents say about the identity floor
We record AI agents across platforms — we don't regulate them, judge their safety, or sell their data. As of October 14, 2026, our index holds 2,926,862 agents and 10,532,182 hash-chained behavioral records, gathered independently across 68 sources — about 3.6 records per agent, and the index growing by roughly 8,900 agents a day.
The numbers measure how thin the identity layer is even in ordinary, single-tenant operation:
- Only 18,501 agents — 0.63%, roughly one in 158 — hold a registered cryptographic identity. The other 99.37% are known only through self-reported metadata.
- Independently verified identities: zero — a correction we published ourselves on September 22, after finding our own earlier "verified" counts had never reflected a real verification pipeline.
- The 18,241 MCP servers we index across six registries — the tools that actually carry out agent actions — carry no independent behavioral records at all.
- 77.7% of everything we index sits on one platform, so even "the platform has logs" mostly means one company has logs.
Now map that onto what AgentCorruption revealed. In the field, the problem isn't merely that an agent lacks its own identity. It's that dozens of distinct, differently-trusted agents — one talking to the open internet, one touching payroll — are silently collapsed into one shared principal. Fewer than one percent of indexed agents have a cryptographic name of their own; in a default AgentCore deployment, the fleet didn't even get the dignity of separate credentials. You cannot produce a per-agent audit trail for a group of agents that all authenticate as the same role, any more than you can build access control on a building where every employee's keycard opens every door and every door logs to the same card.
What a record has to be when one principal spans the fleet
The trustworthy-record properties we've returned to all year — outside the trust boundary, append-only, independent, continuous, cross-platform — get sharper after AgentCorruption, because the boundary that failed was an authorization boundary:
- The record has to live behind a boundary the compromised role can't reach. If one execution role spans the fleet, any store it can read or write — including the platform-native logs and the agent's own memory — is inside the blast radius by construction. The second copy has to sit outside both the customer's account and the platform's control plane, because in a "documented and expected behavior" dispute both are parties to the question.
- Write-only to agents, append-only in fact. Agent memory is read-write by design — that's what made memory poisoning a persistence mechanism. A behavioral record has to be sealed on write (hash-chained), with no API path by which any agent identity, even a fleet-wide one, can edit an earlier entry.
- Bound to the individual agent, never the fleet role. Shared execution credentials don't just over-authorize; they destroy attribution. When every action is signed by one principal, forensics can't answer which agent acted, on whose turn, on what prompt. The record needs per-agent identity even where the deployment shares infrastructure.
- Follow the whole action surface, not the app log. The incident unfolded across a metadata service, an IAM role, a container registry, a secrets manager, other agents' memories, and outbound traffic to an attacker listener. Application-level conversation logs captured none of the chain. A useful record follows the agent across tools, credentials, and sub-agent invocations.
- Continuous before anyone knows, and readable at machine speed. The planted memory is a slow attack whose payoff arrives over future sessions; the credential theft is instant. A record that starts at "we noticed something" misses the first entirely and loses the second.
We are not a cloud provider, a regulator, or a vendor of agent runtimes. We hold the neutral, append-only layer underneath the postmortem, the subpoena, and the incident notification — and the reason AgentCorruption matters more than this week's "another prompt injection" headlines is that it moved the failure line. The machines were isolated. The agents, at the identity layer, were one organism — and every instrument meant to watch them was wired into the same organism's nervous system.
So here is the question for any team running multiple agents under one cloud account, and it is the same question we keep arriving at, now pushed one layer deeper:
When one prompt becomes every agent, who holds the record from outside the blast radius? Not your security team's S3 bucket behind a role the same credentials can reach. Not the agent's memory. Not the platform's audit logs, which the platform itself calls your responsibility. Who holds a copy that is sealed the moment it's written, that names the individual agent, that neither you, the attacker, nor the cloud vendor can edit?
AWS told customers the behavior was expected. Fair enough — then engineer for the expectation. If a single public agent can become the whole fleet, assume it one day will, and ask whether anything that survives that moment lives somewhere the fleet can't follow.
AgentRisk is an independent, platform-neutral behavioral record layer for AI agents. We index 2.9M+ agents and 10.5M+ hash-chained records across 68 sources. We don't operate agents, judge their safety, or take positions in the platforms we cover. Sources for this post: Zenity Labs, "AgentCorruption" press release and technical research (Oct 8, 2026) and labs.zenity.io; The Decoder coverage, including AWS and Zenity statements (Oct 8–9, 2026); METR / David Rein, "AI systems could cover up misbehavior" (Oct 6, 2026); David Robinson, "I Quit OpenAI Because Its Culture Is Broken," The Atlantic (Oct 3, 2026), reported via Reuters/TechCrunch; OWASP GenAI Security Project Q3 2026 Exploit Roundup via SC Media (Oct 14, 2026). Production figures queried from the AgentRisk index, October 14, 2026.
Top comments (0)