AgentCorruption attack research shows how a single prompt sent to a public-facing Amazon Bedrock AgentCore agent could have exposed temporary AWS credentials and opened a path to other AI agents, private conversations, source code and secrets within the same AWS account and region.
Zenity Labs disclosed the attack chain on October 8, 2026 after testing Amazon Bedrock AgentCore, AWS’s managed platform for deploying and operating production AI agents.
The researchers found that an agent equipped with a web-request or shell-capable tool could be instructed to contact the local metadata service running inside its Firecracker microVM.
From there, Zenity obtained the temporary AWS credentials associated with the agent’s execution role and demonstrated how overly broad permissions could dramatically expand the blast radius.
AWS disputes part of the vulnerability framing and says access to an agent’s own execution-role credentials through the metadata service is expected behavior. The company has nevertheless hardened AgentCore metadata protections and significantly restricted default execution-role permissions since the original disclosure.
For broader coverage of autonomous-agent risk, prompt injection and AI security controls, see our AI-Era Threats and Agentic Security Guide.
Key takeaway: AgentCorruption demonstrates that an AI agent should be treated as a privileged cloud workload, not simply as a chatbot. A malicious prompt can become far more dangerous when the agent can access network services, tools and broadly scoped IAM permissions.
What Is the AgentCorruption Attack?
AgentCorruption is the name Zenity Labs gave to a chain of security weaknesses it found while testing Amazon Bedrock AgentCore.
The attack began with one public-facing AI agent.
The researchers did not need to compromise the agent’s web interface or exploit a traditional memory-corruption vulnerability.
Instead, they used the agent’s legitimate tooling to make a request to the local metadata service.
This effectively created a prompt-driven server-side request forgery path.
Why the Metadata Service Matters
Cloud workloads often receive temporary credentials through a local metadata service.
In AgentCore Runtime, AWS documents a MicroVM Metadata Service that provides execution-role credentials to code running inside the microVM.
AWS explicitly warns that any code or actor running inside the VM can access those credentials and recommends tightly scoping execution-role permissions.
The security problem therefore becomes much larger when an AI agent can be manipulated into making requests on behalf of an untrusted user.
One Prompt Reached the Agent’s Cloud Identity
Zenity showed that a prompt could instruct an exposed AgentCore agent to access the local metadata endpoint.
Because the request originated from inside the agent’s own microVM, the metadata service returned temporary AWS credentials associated with the runtime’s IAM execution role.
The researchers then exported those credentials into their own terminal and verified the identity using AWS STS.
At that point, the attack was no longer limited to manipulating chatbot output.
The stolen credentials represented a real AWS cloud identity.
The Default IAM Role Created the Bigger Problem
Zenity says the most serious impact came from the permissions attached to the agent’s default execution role at the time of testing.
The researchers found permissions that extended well beyond the initially compromised agent.
Those permissions enabled actions involving:
- Other AgentCore agents
- Amazon ECR container images
- Agent conversations and events
- Agent memory
- AWS Secrets Manager
- Connected service credentials
This turned one compromised public-facing agent into an entry point for a much larger AgentCore environment.
Researchers Could Discover Other Agents
After obtaining the execution-role credentials, Zenity researchers used AWS APIs to identify other AgentCore resources in the same environment.
They were able to enumerate agent-related resources and locate container repositories associated with additional agents.
According to Zenity, AgentCore repository naming made it possible to map discovered agent names to corresponding Amazon ECR repositories.
The researchers then demonstrated that the compromised role could pull additional agent container images.
Source Code Could Be Exposed Through ECR
Agent container images can contain application code, configuration and other implementation details.
Zenity reported that the role available during its testing had permissions that allowed it to retrieve other agents’ container images from Amazon ECR.
This meant an attacker could potentially inspect:
- Agent source code
- Prompt logic
- Tool implementations
- Runtime configuration
- Application dependencies
Source-code access can provide additional information for lateral movement or targeted exploitation.
Private AI Conversations Were Also Reachable
Zenity’s research found that the same execution role could access AgentCore APIs associated with conversations and session events.
Researchers demonstrated the ability to read private conversations belonging to users interacting with other agents.
This significantly increased the potential privacy impact because compromised access was no longer limited to the public agent that received the original prompt.
Depending on how organizations use AI agents, private conversations may contain business data, customer information, operational instructions or internal credentials.
Agent Memory Could Be Poisoned
One of the more unusual capabilities demonstrated by Zenity involved AgentCore memory.
The researchers said they could create or modify events associated with agent conversations.
This allowed them to inject attacker-controlled information into the agent’s short-term memory or conversation history.
Instead of influencing only the current session, a malicious instruction could potentially affect later interactions.
This creates a form of persistent agent hijacking where poisoned memory changes how the agent behaves over time.
Why Memory Poisoning Is Especially Dangerous
Traditional prompt injection often disappears when a session ends.
Memory-enabled agents are different.
If an attacker can modify persistent or semi-persistent context, malicious instructions can survive beyond the original conversation.
An attacker may attempt to:
- Alter future agent decisions
- Plant false instructions
- Manipulate future users
- Redirect tool usage
- Maintain persistence after the initial attack
This is why security teams need to treat agent memory as a protected application resource rather than ordinary chat history.
AWS Secrets Manager Was Within the Blast Radius
Zenity also identified permissions that could access AWS Secrets Manager.
During the research period, the execution role included capabilities such as secretsmanager:GetSecretValue.
This could expose credentials used by connected services.
Potentially sensitive material may include:
- API keys
- OAuth tokens
- Application secrets
- Database credentials
- Third-party service credentials
Once an attacker obtains credentials for external systems, the impact can extend beyond the AWS AgentCore environment.
AgentCore API Keys Could Also Be Exposed
Zenity reported access to AgentCore credential-related capabilities including bedrock-agentcore:GetResourceApiKey.
This added another path for an attacker to obtain credentials associated with services used by AI agents.
The broader lesson is that agents often sit at the intersection of cloud services, APIs and enterprise applications.
A compromised agent identity can therefore become a bridge into systems that were never directly exposed to the attacker.
The Attack Could Cross From Public Agents to Internal Agents
Organizations may deploy both public-facing and internal agents inside the same AWS account.
Public agents naturally receive untrusted input from customers or internet users.
Internal agents may have access to more sensitive business data and powerful tools.
Zenity demonstrated that overly broad shared permissions could collapse the intended security boundary between those environments.
A malicious user interacting only with a public agent could potentially reach internal agents that were never intended to be internet accessible.
Why Prompt Injection Was Only the Starting Point
The initial malicious prompt was important, but AgentCorruption was not simply another prompt-injection attack.
The dangerous chain resulted from several controls interacting together:
- Untrusted user input
- An agent capable of making HTTP requests
- Metadata credentials available inside the runtime
- Broad IAM execution-role permissions
- Access to other AgentCore resources
Prompt injection provided the initial instruction, while cloud permissions determined how far the compromise could spread.
AWS Says Metadata Credential Access Is Expected
AWS does not fully agree with Zenity’s characterization of the initial metadata behavior as a vulnerability.
AWS documentation states that AgentCore runtimes use a metadata service to provide execution-role credentials to workloads inside the microVM.
The company warns administrators that any code or actor executing inside the runtime can request those credentials.
AWS therefore emphasizes that customers should scope the execution role to the minimum permissions required by each agent.
AgentCore Now Requires Stronger Metadata Protection
AWS has changed AgentCore metadata behavior since Zenity’s original testing.
Zenity says that by February 14, 2026, newly deployed agents used the stronger IMDSv2-style metadata flow.
AWS’s current documentation states that AgentCore Runtime requires MMDSv2 protection.
As of June 30, 2026, runtimes without MMDSv2 enabled cannot be invoked.
The newer flow adds additional request protections compared with the earlier metadata behavior.
AWS Also Restricted AgentCore Default Permissions
The more important remediation involved the execution role’s blast radius.
Zenity says it continued reviewing the default execution role throughout 2026.
During a final review on September 29, researchers observed substantial permission changes.
Zenity says AWS removed permissions that previously allowed:
- Broad invocation of other agents
- Access to private conversations
- Access to Secrets Manager secrets
- Other region-wide AgentCore operations
The remaining role permissions were also significantly restricted.
Zenity Says the Reported Attack Chain Is Now Fixed
Cyber Security News reported that Zenity considers the specific broad AgentCorruption attack chain addressed following AWS’s changes.
This distinction is important.
The research describes what was possible under the permissions and runtime behavior observed during the testing period, not necessarily what a newly deployed AgentCore environment permits today.
However, organizations can still create risky configurations if they attach overly broad custom roles or expose powerful tools to untrusted input.
Current AWS Guidance Emphasizes Least Privilege
AWS currently recommends that each AgentCore execution role contain only the permissions required by that specific agent.
AWS documentation warns against treating a broad default or managed policy as a production security boundary.
Execution roles should be scoped to specific actions and resource ARNs wherever possible.
The principle becomes especially important when AI agents can generate code, make network requests or call external tools.
AgentCore Identity Can Reduce Secret Exposure
AWS recommends using AgentCore Identity for outbound authentication to external services.
The service can manage OAuth credentials and API keys without requiring those credentials to be directly embedded in application code or agent logs.
This can reduce the chance of long-lived secrets becoming exposed during prompt injection or tool misuse.
Public and Internal Agents Should Be Separated
Organizations should avoid treating all agents as equivalent workloads.
An internet-facing support agent and an internal administrative agent have dramatically different trust profiles.
Security teams should separate agents based on:
- Who can invoke them
- Which tools they can access
- Which IAM roles they use
- Which networks they can reach
- Which secrets they can access
Shared wildcard roles can turn a single compromised agent into a much larger cloud incident.
Restrict Outbound Network Access
The initial AgentCorruption path depended on the agent being able to make network requests from inside its runtime.
Agents that do not require unrestricted outbound access should not receive it.
Organizations can consider:
- Allowlisting required destinations
- Restricting direct runtime network access
- Routing tools through controlled gateways
- Blocking unnecessary metadata-style requests
- Monitoring unusual outbound connections
Use AgentCore Gateway and Policy Controls
AgentCore Gateway can provide a controlled boundary around tools exposed to agents.
AWS supports policy-based authorization that can determine which caller is allowed to invoke specific tools and under which conditions.
Security teams should ensure that an agent cannot bypass the controlled gateway by reaching sensitive runtime services directly.
Monitor CloudTrail and CloudWatch for Agent Abuse
AI-agent activity should be included in normal cloud monitoring.
Security teams should watch for unusual activity such as:
- One agent invoking unrelated agents
- Unexpected Secrets Manager access
- Unusual ECR image retrieval
- Large numbers of conversation-event reads
- Unexpected memory modifications
- Cross-resource activity from a public-facing agent
CloudTrail and CloudWatch logs can provide important evidence when investigating potentially compromised agent identities.
Treat AI Agents Like Cloud Workloads
The central lesson from AgentCorruption is that AI agents inherit the security consequences of the infrastructure around them.
An agent with an LLM, tools and an IAM role is not merely generating text.
It may be able to:
- Call APIs
- Read cloud resources
- Access credentials
- Modify memory
- Run code
- Interact with business applications
Security reviews therefore need to examine both AI-specific threats and ordinary cloud security controls.
For additional guidance on controlling autonomous agent permissions and runtime behavior, see our AI agent security and enforcement coverage.
Frequently Asked Questions
What is the AgentCorruption attack?
AgentCorruption is Zenity Labs’ name for a security research chain showing how a prompt to one exposed Amazon Bedrock AgentCore agent could lead to cloud credential access and compromise of other agent resources under the permissions available during testing.
Was Amazon Bedrock AgentCore hacked?
The research was conducted as controlled security testing. Zenity disclosed the findings to AWS, which subsequently changed metadata protections and execution-role permissions.
How did the attack start?
A public-facing agent with HTTP-capable tooling was instructed to request credentials from the metadata service available inside its microVM.
What could researchers access?
Zenity demonstrated access to other agents, private conversations, container images, memory, API keys and secrets under the broad permissions available during its testing.
Could attackers steal AWS Secrets Manager credentials?
Zenity says the execution role it tested included permissions capable of retrieving Secrets Manager values, expanding the attack beyond the initially compromised agent.
Does AWS consider metadata access a vulnerability?
No. AWS says access to execution-role credentials from within the runtime is expected and documented behavior, which is why least-privilege IAM permissions are critical.
Has AWS fixed the AgentCorruption issue?
Zenity says AWS hardened metadata protections and substantially restricted default AgentCore permissions. The specific broad attack chain described by the researchers is considered addressed.
What is MMDSv2?
MMDSv2 is the protected metadata access mode currently required by AgentCore Runtime. AWS says runtimes without it enabled cannot be invoked.
How should organizations protect AI agents?
Use least-privilege execution roles, separate public and internal agents, restrict outbound network access, use controlled gateways, protect credentials and monitor cloud activity for anomalous agent behavior.
Final Takeaway
The AgentCorruption attack demonstrates how AI-specific threats and traditional cloud-security weaknesses can combine into a much larger compromise.
A single prompt did not magically break AWS. The serious impact came from an agent capable of making network requests combined with metadata credentials and an execution role that, at the time of testing, had access to far more resources than the original agent required.
AWS has since hardened AgentCore metadata requirements and reduced the permissions responsible for the region-wide blast radius described by Zenity.
For enterprises deploying AI agents, the lasting lesson is clear: every agent should receive its own tightly scoped identity, limited network reach and only the tools and secrets it genuinely needs.
Stay Updated on AI Agent Security
AI agents increasingly operate with access to cloud services, enterprise applications, credentials and sensitive business data.
Follow CyberUpdates365 for verified AI security research, cloud vulnerabilities, prompt-injection threats and practical agent-security guidance.
Primary and Official Sources
Zenity Labs — AgentCorruption Overview:
AgentCorruption: How a Single Prompt Collapsed the Entire Cloud Security Model
Zenity Labs — Initial Metadata Access:
AgentCorruption: Initial IMDS Access
AWS AgentCore Credential Guidance:
Understanding Credentials Management in Amazon Bedrock AgentCore
AWS AgentCore Security Best Practices:
Security Best Practices for AgentCore Runtime
