What happened
Zenity Labs published a detailed walkthrough showing that the default execution role granted to Amazon Bedrock AgentCore agents includes broad permissions—such as logs:DescribeLogGroups, bedrock-agentcore:InvokeAgentRuntime, bedrock-agentcore:ListSessions, and bedrock-agentcore:ListEvents. Using these permissions, the researchers were able to list all agent log groups in a region, reconstruct each agent’s ECR repository name, pull the container images, and extract source code. They then invoked other agents, enumerated memory resources, and read private short‑term memory events, exposing user‑level conversations, PII, and confidential business data. The team also demonstrated write capabilities: creating events that could steer an agent’s decisions (e.g., issuing a fraudulent refund) and deleting events to erase evidence or corrupt the agent’s reasoning. All of this was achieved from a single set of temporary STS credentials obtained by compromising a public‑facing agent.
The Zenity team first compromised a public‑facing Bedrock agent and extracted its temporary STS credentials, confirming the role’s assumed identity via aws sts get-caller-identity.
Using the role’s logs:DescribeLogGroups permission, they enumerated every CloudWatch log group matching the Bedrock AgentCore naming pattern, thereby discovering all agent IDs and names in the region.
They derived each agent’s ECR repository name (bedrock-agentcore-<agent_name>) and pulled the container images, gaining full source‑code visibility for every agent.
With bedrock-agentcore:InvokeAgentRuntime, they invoked other agents, including internal ones that were never intended to be reachable from the compromised perimeter.
The role also granted bedrock-agentcore:ListSessions, ListActors, and ListEvents, allowing the researchers to enumerate memory IDs, actors, sessions, and finally read every event (conversation) stored in short‑term memory across all agents.
Write‑side permissions (CreateEvent, DeleteEvent) let them inject fraudulent assistant messages—such as a request to transfer funds to an attacker‑controlled account—and delete evidence of the injection, effectively hijacking the agent’s decision flow.
Source details: labs.zenity.io ↗
Why it matters
The findings reveal a systemic risk in the way Amazon Bedrock AgentCore provisions IAM roles. Because the role is attached by default to every deployed agent, a single compromised agent can become a pivot point for lateral movement across an entire organization’s AI‑agent fleet. This exposure threatens the confidentiality of user conversations, the integrity of automated decision‑making, and the availability of services that rely on agents for finance, customer support, or internal tooling. If attackers can inject malicious events, they could trigger unauthorized transactions, exfiltrate proprietary data, or sabotage business processes. The vulnerability also underscores broader concerns about AI‑agent governance, least‑privilege principle enforcement, and the need for robust monitoring of agent‑related IAM policies. Organizations using Bedrock agents must reassess role permissions, audit CloudWatch log groups, and consider isolation mechanisms to prevent a single point of compromise from cascading across their AI ecosystem.
Over‑privileged roles break the principle of least privilege, turning a single compromised component into a high‑impact attack vector.
Private conversations held in agent memory often contain sensitive personal data, credentials, or proprietary business information; exposure can lead to regulatory violations and reputational damage.
The ability to programmatically alter an agent’s short‑term memory means attackers can manipulate automated workflows, potentially causing financial loss, data corruption, or operational disruption.
Because Bedrock AgentCore is marketed as a managed service for enterprise automation, many organizations may have deployed agents without fully auditing the attached IAM policies, leaving a large attack surface.
The demonstration highlights a gap in AWS’s default security posture for AI agents, prompting a need for clearer guidance and possibly a redesign of default role permissions.
Interactive Mechanism: How It Actually Works
Explore the underlying technology behind this development interactively.
Why can ethical evaluation not be reduced to one model score?
What to watch next
AWS’s response—whether it issues a security advisory, patches the default role, or provides guidance on tightening permissions—will be critical. Customers should monitor AWS security bulletins, update IAM policies to restrict logs:DescribeLogGroups and Bedrock‑specific actions to only required agents, and consider employing execution containers or sandboxing solutions that limit agent capabilities. Future research may explore whether similar over‑privilege exists in other managed AI services, prompting industry‑wide reviews of AI‑agent security models.
AWS security advisories or patches that restrict the default execution role’s permissions, especially around CloudWatch log enumeration and Bedrock memory APIs.
Guidance from AWS on implementing least‑privilege IAM policies for AgentCore, including recommended custom roles and monitoring alerts for suspicious agent invocations.
Adoption of AWS Execution Containers or other sandboxing technologies that isolate agent runtimes and limit cross‑agent access.
Industry response: whether other cloud providers (Google, Microsoft, etc.) audit their AI‑agent IAM defaults for similar over‑privilege issues.
Potential regulatory scrutiny if exposed data includes protected health information (PHI) or personally identifiable information (PII) under GDPR, CCPA, or other privacy frameworks.