One prompt shouldn't own your cloud: scoping AWS Bedrock AgentCore credentials

When using AWS Bedrock AgentCore, it is crucial to understand the scope of permissions your agent's execution role possesses. To determine this, run the following two commands: `aws iam list-attached-role-policies --role-name your-agentcore-exec-role` and `aws iam list-role-policies --role-name your-agentcore-exec-role`. If you are using the default AgentCore execution role, these commands will reveal permissions that may extend beyond your deployed agent.

In October 2026, security researchers demonstrated that a single chat prompt to an exposed agent was sufficient to take control of every Bedrock AgentCore agent within the same AWS account and region. This article explains the findings in simple terms and provides a checklist to help you assess your own role.

The research conducted by Zenity Labs, published on October 8, 2026, and presented at SecTor 2026 conference, identified two interrelated issues. First, an agent running within AgentCore could access the instance metadata service (IMDS) at the link-local address 169.254.169.254. Since AgentCore runs each agent in a lightweight microVM, it lacks network isolation.

Consequently, any agent tool capable of making an HTTP request can act as a server-side request forgery vulnerability. By crafting a specific prompt, an attacker can retrieve the agent's temporary IAM credentials using IMDS and hand them back.

Second, the default IAM role assigned to AgentCore workloads is overly permissive. It does not limit access to a single agent but grants extensive permissions across every AgentCore resource in the account's region. These permissions include invoking other agents, reading sessions, creating memories, and accessing secrets from AWS Secrets Manager.

When combined, these flaws create a massive blast radius that spans the entire region. With one exposed agent and one carefully crafted prompt, an attacker can: discover every other agent's ID due to the role's ability to describe log groups across the region; invoke any agent in the region using the `bedrock-agentcore:InvokeAgentRuntime` command, allowing lateral movement to internal agents; read all private conversations across all agents and users via the `bedrock-agentcore:ListEvents` command, compromising AgentCore's privacy boundary; plant memories that permanently alter another agent's behavior using the `bedrock-agentcore:CreateEvent on BedrockAgentCoreMemory` command, enabling an attacker to control enterprise agents; and retrieve the credentials intended to protect the agent, such as `secretsmanager:GetSecretValue` and `bedrock-agentcore:GetResourceApiKey`.

The timeline of disclosure is crucial for maintaining trust. The IMDS access was reported to AWS on December 25, 2025; however, AWS classified it as "informative" and resolved it in April 2026 after switching newly deployed agents to IMDSv2. The overprivileged-role report was filed on January 12, 2026; AWS acknowledged the need for role hardening and confirmed the changes on September 29, 2026.

AWS maintains that agents can access resources in other accounts only if developers explicitly grant those permissions on both sides. Their advice remains valid: assign execution roles only the permissions the agent requires. However, for teams with existing deployments, AWS's September 2026 hardening only applies to new roles created after that date.

If your agent was deployed before September 2026, it may still possess the original broad role. To determine this, use the commands mentioned earlier.

The primary concern for users is not Amazon's safety but rather the responsibility of teams to define and manage the credential scope for their agents. Agents are not simple web servers; they maintain sessions, call various tools, and can be redirected by the content they retrieve from the web, documents, or other agents. A malicious prompt can transform a seemingly harmless mistake into a widespread account-wide event.

Consider a practical scenario where a support agent utilizes a tool that queries an internal API. If this API resides within the same account as another agent capable of reading customer records and a third agent that can post to social channels, and all three agents share a single broad role, a compromised instruction from the support agent could extend beyond its initial scope.

It could pivot to the customer-records agent and eventually reach the posting agent, as the shared role permits all of these actions.

The solution does not rely on enhanced prompts but rather on assigning narrower roles. To reduce the blast radius effectively, follow these four steps: 1. Assign each agent its own execution role. Avoid sharing one execution role among multiple agents. Create distinct roles for each agent, attaching only the permissions necessary for the agent's tools to function.

If agent A should not have access to agent B's memory, its role should explicitly disallow `bedrock-agentcore:CreateEvent` on shared memory. 2. Apply the principle of least privilege rigorously. Begin with an empty policy and gradually add one permission per tool call your agent requires. Ensure that you can explicitly name the permission; if not, the agent should not possess that permission.

Begin by reviewing `DescribeLogGroups` and `secretsmanager:GetSecretValue`, as these two permissions are particularly dangerous due to their ability to facilitate a regional leak. 3. Keep third-party credentials outside the agent's execution role. Store such credentials in AWS Secrets Manager, allowing AWS Bedrock AgentCore Gateway to handle the authentication process.