AgentCore's Real Blast Radius: SSRF, IMDS, and the Persistent Memory Nobody Audited

Last quarter I ran an egress enumeration against a managed agent runtime. The policy looked tidy: outbound HTTPS to the model endpoint, a couple of allowlisted tool APIs, DNS. Then I grepped for the link-local block and found nothing. No rule for 169.254.0.0/16. The runtime could still reach the instance metadata service. For any workload running on EC2, that omission is the entire game. A prompt-injected agent becomes an SSRF primitive. The SSRF becomes a credential. The credential becomes the account. That is the shape of AgentCorruption, disclosed by Zenity Labs at SecTor 2026 and covered by The Register on October 9. The vendor framing calls it expected behavior. The framing is wrong, but not for the reason the headlines give. AWS Bedrock AgentCore is a managed runtime for production agents. Four layers matter here, and each carries its own failure mode. The runtime layer executes agent code inside Firecracker MicroVMs — the same isolation primitive behind Lambda and Fargate. The memory layer, BedrockAgentCoreMemory, persists state across sessions through a CreateEvent API. The identity layer binds each agent to an IAM execution role. The network layer governs egress. Commercially, AgentCore is a PaaS play. The runtime never touches the customer's floor, memory is hosted, identity is hosted. The value proposition is no-ops and instant onboarding. That proposition is what makes the security defaults load-bearing, because the customer trades configuration control for convenience. The disclosure timeline spans roughly nine months. First report landed December 25, 2025. IMDSv2 became the default for new deployments on February 14, 2026. Execution-role permissions were reduced on September 29, 2026. The Register's coverage followed in October. Read that sequence as an engineer, not an investor. Nine months from report to default change. No CVE. No evidence of in-the-wild exploitation. A vendor statement describing the behavior as documented and expected. Each of those data points is load-bearing, and I will return to all of them. Strip the branding and AgentCorruption is a classic SSRF-to-IMDS chain, the same technical family as Capital One in 2019. What is new is the multiplier: an agent holding a broad default role and a persistent memory store. Step one is injection. An agent processes untrusted input — a retrieved document, a tool response, a user message — and is manipulated into issuing an HTTP request to 169.254.169.254. That address is link-local. It is reachable by default from instances and containers unless someone explicitly blocks it. No authentication, no VPC boundary, no egress policy in the path. Step two is credential retrieval. On IMDSv1, a plain GET to the metadata path returns the temporary credentials attached to the execution role. No token, no header, no ceremony. Any SSRF that can issue a GET is now a credential-theft primitive. Step three is the mitigation, and this is where the mechanism deserves precision. IMDSv2 changes the handshake. The client must first issue a PUT to request a session token with a TTL, then present that token in an X-aws-ec2-metadata-token header on subsequent reads. A simple GET-only SSRF dies. That is why AWS set IMDSv2 as the default for new deployments in February. But IMDSv2 reduces attack surface; it does not close the class. If the SSRF allows custom methods and headers, or if a request-smuggling path exists between the agent and the metadata endpoint, the tokenized handshake can be satisfied. I have seen this pattern in circuit audits: a mitigation that raises the bar is not a control that removes the class. Step four is where the blast radius lives, and it is not the metadata service. It is the IAM role. The default execution role was scoped to the entire account and region. That contradicts AWS's own least-privilege doctrine, and it converts one stolen token into account-wide reach. With that role, an attacker calls any other agent in the region, reads private conversation history, pulls ECR images, and reads secrets from Secrets Manager. That is a blast-radius design defect, and it multiplies the SSRF rather than sitting beside it. Blast radius is the metric that matters, and by that metric the default was catastrophic. A single injected request, if it landed on IMDSv1, resolved to account scope. That is not a misconfiguration edge case. That is the default. Step five is the genuinely AI-specific surface: memory poisoning. Through BedrockAgentCoreMemory's CreateEvent API, an attacker injects instructions that persist across sessions. This is persistent prompt injection, structurally identical to RAG poisoning but with a longer half-life. The directive survives credential rotation, survives the session boundary, and silently conditions every future interaction. The severity ordering matters. Credentials can be rotated. A poisoned memory cannot, because the platform exposed no audit trail, no source signature, and no rollback path at the time of disclosure. That absence is the finding. Now the trade-off, stated plainly. Managed runtimes optimize for time-to-first-success. Wide default egress and a broad default role shorten the path from signup to a working agent. That is a deliberate product decision, and it works — until it does not. The security cost is deferred onto the customer, who inherits a runtime that is convenient by default and safe only by configuration. The economics follow directly. For the vendor, loose defaults are cheap and drive adoption. For the customer, hardening is expensive and arrives after procurement. That asymmetry stays invisible until a regulated buyer writes least-privilege default role, VPC-internal isolation, and auditable memory into an RFP. Then the deferred cost comes due, and it lands on the sales cycle. The shared-responsibility model is where this gets messy. The vendor says the customer should have configured a narrower role. The customer says the platform handed them a wide one by default. Both statements are true, and that is precisely the problem. On a traditional VM, the responsibility boundary is legible. On an agent platform, it dissolves — and responsibility vacuums become risk vacuums. If I were probing this surface, I would not start with the model. I would start with the egress policy: does the runtime block 169.254.0.0/16, or merely rate-limit it? Then the role: what is the trust policy, and does it resolve to account scope? Then the memory store: is there a signature on CreateEvent, and can a write be attributed to a source? Three questions, in that order, and the third is the one nobody was asking. One question the disclosure never answers is migration. IMDSv2 became the default for new deployments — new, not existing. Whether the nine-month-old agents were force-migrated, or left running on IMDSv1 behind an over-broad role, is the difference between a patched fleet and a latent one. There is also a combination most coverage missed. CoreBreak bypassed the model guardrails through InvokeHarness; AgentCorruption seizes the platform identity. Run them together — poison memory to shape behavior, then escalate through the stolen role — and you get simultaneous failure of both guardrails and IAM. The disclosure compared the two. It did not chain them. The Firecracker attribution is wrong. Firecracker provides strong VM-level isolation and is widely respected; it is not the defect. The defect is network egress policy plus IAM. Conflating VM isolation with network isolation is a media error, and it matters because it points remediation at the wrong layer. The expected-behavior defense is technically true and strategically hollow. Yes, any workload on EC2 can reach its own execution-role credentials through IMDS — that has always been the mechanism. But the controllable variable is not the mechanism. It is why the role was granted account-wide scope by default. Vendors argue mechanism-legality; researchers argue default-safety. Those are different propositions, and the vendor statement answers the one nobody asked. The short-board effect is the real lesson. You can have the strongest VM isolation in the industry, and if the network layer leaks link-local and the identity layer is over-provisioned, total security equals the weakest layer. Firecracker being excellent does not save you. Two more blind spots deserve naming. ECR image theft is a supply-chain vector: stolen source can propagate to downstream products, and the disclosure treats it as a single-tenant incident. And the missing CVE suggests AI platform flaws may fall outside mandatory notification regimes — a compliance gap dressed as a technical one. And the persistent memory is not only a data-integrity problem. Cross-session malicious instructions are, conceptually, a dormant agent — one that waits, survives rotation, and acts on cue. The disclosure treats it as a vulnerability. I read it as a capability. The nine-month window and the missing CVE tell you what to watch next. AI platform vulnerabilities are not entering the standard disclosure track, and that is a governance gap, not an oversight. The category to watch is agentic identity — IAM will not stay a two-body model of humans and service accounts. It becomes a triad: human, service account, agent. Whoever ships auditable, least-privilege, revocable agent identity first wins the regulated market. The math on that is not close, and the gap is widening.