On 8 October 2026 Zenity Labs published AgentCorruption, research on Amazon Bedrock AgentCore. The short version: researchers who could only chat with one public-facing agent sent it a single prompt, and from there reached every other AgentCore agent in the same AWS account and region. They read private conversations, pulled agents' container images, planted memories that changed how agents behaved later, and pulled secrets from AWS Secrets Manager.
AWS has since narrowed the default permissions, and Zenity says the reported issues are patched. So this is not a "patch tonight" story. It is a design lesson, and it applies to any team putting an AI agent in front of users, whatever cloud or framework they use.
How one prompt turned into a regional compromise
Nothing in the chain needed a memory-corruption bug. It needed an agent with a tool that could make web requests, and a role with too much in it. Per Zenity's write-up:
- The prompt asked the agent to fetch the link-local metadata address, 169.254.169.254, from inside its Firecracker microVM. That is a server-side request forgery, driven by text instead of code.
- The metadata service answered with temporary credentials for the agent's default execution role.
- That role could list log groups, which revealed the IDs of other agents in the region. Container repositories were named after those IDs, so the images could be pulled too.
- With
bedrock-agentcore:InvokeAgentRuntimethe attacker could call other agents. WithListEventsthey could read conversations across agents, users and sessions. WithCreateEventthey could write fake memories that steered future sessions. bedrock-agentcore:GetResourceApiKeyandsecretsmanager:GetSecretValueexposed credentials for connected services.
The memory part is the one I would underline. A stolen session ends. A poisoned memory keeps working on every user who talks to that agent afterwards, and nobody sees a new login.
AWS's view, and why both sides are partly right
The disclosure ran for most of a year. Zenity reported the metadata access on 25 December 2025 and the over-broad default role on 12 January 2026. AgentCore moved to IMDSv2-only on 14 February. By 29 September, during Zenity's final review, the default role had been substantially cut back. AWS's own statement calls the metadata behaviour documented and expected.
It is documented. The AgentCore credentials page says that "any code or actor running inside the VM can access these credentials by calling the metadata endpoint", and tells you to follow least privilege, especially with LLMs "that can generate arbitrary code". The trouble is that defaults win. Plenty of teams ship whatever role the service creates for them, and here the default role was wide.
What to check in your own agent setup this week
- Treat the prompt box as a network client. If an agent can fetch URLs, it can fetch internal ones. Block link-local and private ranges at the egress layer, not in the system prompt.
- One role per agent, scoped to its own resources. A public chatbot should not hold permissions that name other agents, other memories or the whole secrets store. Wildcards in resource ARNs are the first thing to remove.
- Keep secrets away from the agent's own credentials. If the agent needs an API key, fetch it in a separate service the model cannot talk to directly.
- Split public and internal agents into different accounts, or at least different roles that cannot invoke each other.
- Make memory writes visible. Log every memory event with its source session, and review new long-term memories the way you would review a config change.
- Watch the boring API calls. A chatbot role calling log-group listing or secrets reads at 3 a.m. is a strong signal. Alert on it.
We went through the tool side of the same problem in our audit checklist for malicious MCP servers: whatever an agent can call, an attacker who can talk to it can call too.
Where FanMind stands
FanMind is a document assistant, so its exposure is narrower than a general agent with a shell. The rule we hold it to is the same one AgentCorruption breaks: the model never holds more access than the person asking. Retrieval is filtered by that user's permissions before anything reaches the model, answers have to cite a document and page, and web search is scoped rather than on for every question. We explained the access-control side in why a general AI assistant can't just read your organization's documents. The model can still be tricked by a prompt. What matters is how little that trick can reach.
To find out afterwards which agent called which tool, you need call-level logs; see MCP server audit logging.
Frequently asked questions
Is AgentCorruption still exploitable?
Zenity says the reported issues have been patched by AWS, and that by 29 September 2026 the default AgentCore role had been substantially changed. Agents you deployed earlier with your own wide custom role are a separate question; check those roles yourself.
Do I need to be on AWS for this to matter?
No. The chain is prompt injection plus a web-request tool plus an over-privileged identity. The same pattern works against any agent platform where the agent's runtime can reach a metadata service or holds broad credentials.
What is the single most useful fix?
Scope the execution role to the one agent and the exact resources it needs, and block outbound requests to link-local and private addresses. Together those turn a stolen credential into something close to useless.
Why are poisoned memories worse than stolen chats?
Stolen chats are a one-time leak. A planted memory changes what the agent does for every later user, and it looks like normal agent behaviour, so it can persist until someone reviews the memory store.
