Zenity AgentCorruption Exposed an AWS AgentCore Account-Wide Hijack Path

Zenity AgentCorruption researchers found that one malicious prompt could expose temporary AWS credentials from a publicly reachable Amazon Bedrock AgentCore agent. Those credentials reportedly opened paths into every AgentCore runtime sharing the vulnerable account, region, and broadly scoped default role. The finding turned a familiar prompt injection problem into an account-wide cloud security failure.

The attack did not depend on breaking a foundation model, escaping into an unrelated AWS customer, or stealing an administrator password. It combined an agent’s ability to make HTTP requests with metadata credentials and excessive Identity and Access Management permissions. Zenity says the chain reached private agents, source code, conversation histories, stored secrets, and long-term memory.

That combination matters more than the headline number of one prompt. AWS marketed AgentCore as managed infrastructure for securely operating production agents, including identity, memory, tools, observability, and isolated runtimes. AgentCorruption showed how those connected services could amplify one compromised agent when their authorization boundaries were too broad.

There is also an important qualification. Zenity disclosed the issues months before publishing its research on October 8, 2026. The researchers reported that AWS restricted the default execution role before publication, while AWS documentation now mandates stronger metadata controls and warns against production use of broad CLI-generated policies.

The result is not evidence that every current AgentCore deployment remains open to the complete chain. It is evidence that teams cannot treat managed agent infrastructure as a substitute for least privilege. Agent security now has to cover language-model behavior, runtime credentials, cloud permissions, memory integrity, and lateral movement together.

How Zenity AgentCorruption Turned One Prompt Into AWS Credentials

The first failure crossed the boundary between untrusted language input and a trusted cloud identity.

According to Zenity’s AgentCorruption research, an exposed AgentCore agent accepted a prompt that instructed it to request a local metadata endpoint. The request targeted 169.254.169.254, a link-local address used by AWS compute environments to provide workload metadata and temporary role credentials.

The relevant service is the Instance Metadata Service, commonly shortened to IMDS. AgentCore’s Firecracker microVM environment uses a related MicroVM Metadata Service, or MMDS, to make execution-role credentials available inside the workload.

That credential delivery mechanism has a legitimate purpose. An agent may need temporary authorization to read an approved S3 object, call another AWS service, or perform a business task. Temporary credentials also avoid embedding permanent access keys inside code or container images.

The problem appears when an untrusted prompt can cause a tool to contact the metadata endpoint. Zenity says an HTTP-capable tool sent the request from inside the microVM, so the metadata service treated it as a local workload request. The response exposed the agent runtime’s temporary access key, secret key, and session token.

This is a server-side request forgery pattern, usually called SSRF. An attacker induces a server-side component to request a destination that the attacker cannot reach directly. Here, the agent reportedly became the requesting component because its tools could make outbound HTTP calls.

Prompt injection supplied the intent, while the HTTP tool supplied the capability. The metadata service then supplied a cloud identity. None of those elements alone would have produced the reported blast radius.

A model that merely generated unsafe text would not have stolen credentials. A metadata endpoint protected from the agent’s tools would have stopped the path. A narrowly scoped execution role would have contained the consequences even after credential theft.

AWS now explicitly documents this credential exposure property. Its credential guidance says code or actors inside a microVM can call the metadata endpoint and access the available credentials. AWS therefore tells customers to limit execution roles to only the permissions their workloads require.

Zenity initially reported the metadata issue to AWS on December 25, 2025. The researchers say AWS closed that report as informative on April 12, 2026. AWS told them that newly deployed agents had used IMDSv2 since February 14.

IMDSv2 requires a session token before a client can retrieve metadata. That design blocks many conventional SSRF attacks because the attacker cannot always control the preliminary token request and its headers.

An autonomous agent changes that assumption. If the agent can make sufficiently flexible requests, it may obtain the token and then retrieve credentials. Zenity argues that requiring IMDSv2 increased friction but did not remove the underlying trust problem.

AWS later moved beyond optional adoption. Current runtime guidance says AgentCore runtimes without MMDSv2 enabled have been rejected since June 30, 2026. That control improves the baseline, although it does not excuse excessive permissions attached to credentials that legitimate runtime code can still access.

The essential lesson is architectural. Prompt injection becomes a cloud compromise when an agent can translate natural-language instructions into privileged network and identity operations. Filtering the malicious sentence addresses only one layer of that path.

The Default Role Made One Agent Everyone’s Problem

Stolen credentials became account-wide leverage because the tested execution role trusted one agent with region-wide access to other agents.

Zenity submitted a second report on January 12, 2026, focusing on the permissions behind the initial compromise. The researchers said the default role was not limited to the runtime that assumed it. Several permissions applied to AgentCore resources throughout the same AWS account and region.

The first expansion step used CloudWatch Logs. Zenity says logs:DescribeLogGroups allowed the compromised identity to list regional log-group names. AgentCore naming conventions exposed identifiers for runtimes and memory resources in those names.

The attackers did not need an existing inventory of private agents. They could reportedly derive runtime identifiers from operational metadata already visible to the role. Discovery converted a stolen identity from a local foothold into a map of neighboring resources.

The role also contained regional permissions for Amazon Elastic Container Registry. Zenity says predictable repository naming let the researchers associate AgentCore runtimes with container images. Pulling those images exposed application code and potentially sensitive configuration embedded in the deployed artifacts.

That finding challenges a common assumption about managed runtimes. A microVM can isolate one running session from another while IAM still authorizes the session to retrieve unrelated resources. Compute isolation and authorization isolation solve different problems.

Next came bedrock-agentcore:InvokeAgentRuntime. Zenity’s role analysis shows that the tested policy covered wildcard runtime resources in the region. The stolen credentials could therefore invoke private agents that an external user was never meant to reach.

A public support bot might have limited tools and carefully filtered data. A private billing agent could have access to financial files, internal APIs, or transaction systems. Region-wide invocation connected the exposed entry point to the more sensitive agent.

Zenity demonstrated this path against a test billing agent. The researchers enumerated its tools, identified a file named billing.json, and instructed the agent to return its contents. That scenario illustrated lateral movement through legitimate AgentCore APIs rather than a second software exploit.

Conversation memory expanded the damage again. AgentCore Memory stores short-term events by memory resource, actor, and session. Long-term strategies can preserve extracted facts, preferences, summaries, and lessons for future interactions.

Zenity says the compromised role could list actors and sessions, then call ListEvents to retrieve conversation content. Because those permissions covered wildcard memory resources, the researchers reportedly accessed conversations belonging to other agents and users.

The exposed material could include personal information, source code, internal plans, customer records, or credentials pasted during troubleshooting. The platform cannot determine whether a secret entered into a conversation should have been there. Authorization must prevent unrelated workloads from reading the session at all.

Write permissions created a separate integrity threat. Zenity found that the role could create and delete memory events. An attacker could inject false context into an active session, remove tool results, or influence what the agent believed had happened.

This risk differs from ordinary data theft. A manipulated agent can continue presenting itself as a trusted company service while acting on attacker-supplied context. Users may not see the hostile instruction because it sits inside stored session state rather than their visible prompt.

AWS told Zenity on February 25 that its team was addressing the underlying problem. The researchers checked again on June 22 and reported that the default role remained unchanged. That timeline left the broad role at the center of the unresolved chain for several months.

During a final review on September 29, Zenity found substantial restrictions. The researchers said AWS had removed permissions enabling cross-runtime invocation, private conversation access, and Secrets Manager retrieval. Other permissions had also been narrowed.

That remediation sharply changes the current risk assessment. The published chain documents what the researchers achieved against earlier defaults, not proof that the identical permissions remain attached today. Existing customer-created roles, copied policies, and older deployments still deserve direct review.

Managed Isolation Met an Overprivileged Reality

AgentCorruption exposed a conflict between AgentCore’s isolation promise and the shared authorization paths surrounding each isolated runtime.

AWS launched AgentCore for general availability in October 2025, describing it as infrastructure for running agents securely at scale. The platform combined runtime isolation with identity, memory, gateways, browser automation, code execution, and observability.

Each capability answers a real deployment problem. Agents need state across conversations, credentials for connected services, governed tool access, and tracing for unpredictable actions. Building all those components independently raises cost and complexity.

However, integration also creates security dependencies. A runtime may be computationally isolated while its execution role can invoke another runtime. A token vault may keep secrets out of application code while an overly broad identity can request those secrets.

This is the central reversal in Zenity AgentCorruption. The managed platform’s connected controls were intended to support secure production use. Under the tested defaults, those same connections reportedly carried the compromise across service boundaries.

AWS’s current runtime security practices acknowledge this distinction more directly. The documentation warns customers not to use CLI-generated development policies in production. It recommends specific runtime ARNs instead of wildcard resource statements.

The guidance also says an execution role should have equal or fewer privileges than the principals allowed to invoke it. That rule provides a useful way to evaluate public agents. If an anonymous user can invoke a runtime, the runtime should not inherit authority unavailable to anonymous users.

Public reachability does not automatically make an agent unsafe. It changes the trust level of every instruction reaching the model. The execution role must assume that some accepted input will be malicious, misleading, or designed to manipulate tools.

Authentication helps identify callers, but it does not eliminate prompt injection. A legitimate customer account can submit hostile instructions. Compromised documents and web pages can also deliver indirect prompt injection after the user asks an agent to summarize them.

Gateway controls can reduce exposure by validating requests before they reach a runtime. Guardrails may detect known attack patterns, while interceptors can restrict operations based on identity and context. These controls work only when callers cannot bypass the gateway and invoke the runtime directly.

AgentCore’s security guidance now recommends restricting runtime invocation to the gateway’s execution role when a gateway is the intended entry point. This approach moves authorization outside the model’s decision loop. The agent cannot talk its way around an IAM denial.

IAM resource scoping remains the stronger containment boundary. A customer-support agent should not receive wildcard permission to invoke every runtime. A memory-writing permission should name the specific memory resource, actor scope, and business need wherever the service supports that precision.

The same reasoning applies to container repositories and logs. Operational metadata often looks less sensitive than application data. Yet names, identifiers, endpoints, and repository patterns can become a discovery system for lateral movement.

Organizations also need separation by trust level. Public agents and internal agents should not share execution roles merely because a setup tool makes that configuration convenient. Sensitive functions can be split across AWS accounts or regions when account-level controls offer clearer isolation.

No prompt filter can guarantee that a model will reject every malicious variation. Models interpret meaning rather than enforcing a finite command grammar. Attackers can rephrase requests, hide instructions inside retrieved data, or exploit conflicts between system and user context.

That limitation does not make agent deployment impractical. It changes where defenders should place confidence. Model-level defenses can reduce successful manipulation, while deterministic cloud controls limit what a manipulated model can do.

Teams should treat prompts as untrusted input and tools as privileged interfaces. Every tool call needs an authorization decision based on the authenticated user, requested resource, and permitted operation. The model’s choice to call a tool should never serve as authorization by itself.

For organizations documenting these decisions, a searchable set of engineering knowledge bases can help connect runtime ownership, IAM policies, threat models, and incident procedures. That record becomes important when multiple teams deploy agents through shared cloud accounts.

Memory Poisoning Turned a Breach Into Persistent Control

The most consequential part of the chain was not credential theft, but the ability to corrupt what trusted agents remembered later.

AgentCore Memory supports short-term and long-term state. Short-term memory records turn-by-turn events in a session. Long-term memory extracts reusable information so an agent can recall preferences, facts, summaries, or prior lessons.

That persistence improves usability. A support agent can remember an unresolved case, while a workplace assistant can preserve formatting preferences. It also creates a durable input channel that may influence future decisions.

Zenity’s memory poisoning study says the stolen role could discover memory identifiers through CloudWatch logs. It could then list actors, sessions, and configured memory strategies.

The researchers used CreateEvent to add hostile content to other agents’ conversations. Memory extraction processed those events and converted their contents into long-term records. Future sessions could retrieve those records as trusted context.

An attacker therefore did not need to repeat the original prompt injection for every interaction. A planted instruction could survive beyond the compromised session and affect later conversations. The visible interface would still appear to be the organization’s official agent.

Zenity describes this as persistent command and control. That phrase should be read as the researchers’ characterization of their test environment. The exact behavioral outcome depends on memory configuration, retrieval logic, model behavior, tools, and authorization controls.

The demonstrated primitive is still serious. A false preference might tell an agent to send data to an attacker-controlled address. A fabricated fact could redirect a workflow, while a poisoned summary could misrepresent a customer’s prior approval.

Short-term history manipulation adds immediate risks. An inserted assistant event can appear to the model as something it previously decided. A deleted tool result can remove evidence that would otherwise stop an unsafe action.

Traditional application security often treats logs and history as evidence after an incident. Agent systems may actively feed stored history back into future decisions. Integrity failures in that data can therefore change execution, not merely hinder investigation.

Memory also complicates recovery. Rotating stolen credentials stops continued API access, but it does not automatically remove every poisoned record. Responders must identify which sessions, events, summaries, and extracted memories the compromised identity touched.

AWS’s current memory guidance recommends input validation, guardrails before persistence, and regular prompt-injection testing. It also emphasizes least-privilege policies for memory resources.

Those controls should be paired with provenance. A long-term record should retain enough metadata to show which user, agent, session, and extraction process created it. Security teams need an efficient way to quarantine memories associated with a compromised identity.

High-risk actions should not rely on recalled context as proof of authorization. An agent might remember that a user prefers a particular bank account, but a transfer still requires current, independently verified approval. Memory can guide a workflow without authorizing it.

Organizations should also separate data types by consequence. Preferences about writing style present less risk than payment instructions, access grants, or destination addresses. Sensitive memories need stricter creation rules, shorter retention, and stronger review.

Monitoring must cover writes as well as reads. Unusual bursts of CreateEvent, cross-agent memory access, or changes affecting many actors can signal abuse. CloudTrail, application logs, and AgentCore observability data should feed alerts tied to expected workload behavior.

This is where the incident reaches beyond AWS. Any agent platform that combines persistent memory with tools faces a similar integrity problem. The implementation details differ, but the trust question remains constant.

What information is the agent allowed to remember, who can write it, and what decisions can depend on it later? AgentCorruption shows that incomplete answers can turn a temporary foothold into continuing influence.

What AgentCore Customers Should Verify Now

The full historical chain was narrowed before publication, but customer-defined permissions and older configurations determine each deployment’s remaining exposure.

The first check is the execution role attached to every AgentCore runtime. Teams should list allowed actions and resources, then remove permissions unrelated to the runtime’s documented function. Wildcards deserve specific justification rather than routine acceptance.

Production roles should not inherit policies generated for prototypes. AWS now labels CLI-generated permissions as development conveniences and advises customers to create narrowly scoped alternatives. A successful test deployment is not evidence that its role belongs in production.

The second check is MMDSv2 enforcement. Current runtimes should set requireMMDSV2 to true in their metadata configuration. Teams should verify the deployed configuration rather than assuming a platform update changed every historical runtime correctly.

MMDSv2 should still be treated as one layer. If an agent legitimately controls a flexible HTTP client, shell, or code interpreter, it may perform requests that simplistic SSRF protections assumed attackers could not construct. Network policy should block unnecessary access to metadata endpoints.

The third check is inbound reachability. Teams should identify which runtimes accept direct public, IAM, or JWT-based invocation. Public agents need the smallest roles because their input comes from the least trusted audience.

Where AgentCore Gateway supplies policy enforcement, direct runtime invocation should be restricted. Otherwise, an attacker may bypass gateway guardrails and call the runtime endpoint through another authorized path. Authentication and user identifiers must derive from verified principals.

The fourth check covers lateral movement. A runtime should not invoke unrelated agents, list regional log groups, pull unrelated ECR images, or enumerate memory resources. Those permissions should be isolated by runtime ARN and business function.

The fifth check is conversation confidentiality. Security teams should test whether one runtime identity can list actors, sessions, or events belonging to another workload. They should also verify whether resource policies and identity policies produce the intended denial together.

The sixth check is memory integrity. Teams should inventory principals with CreateEvent, DeleteEvent, and long-term memory access. Alerts should distinguish normal user-session writes from cross-agent or high-volume changes.

The seventh check concerns stored credentials. AgentCore Identity can keep third-party tokens outside application code, but IAM still controls who may retrieve them. Runtime roles should not have broad access to API keys or Secrets Manager values.

Investigators reviewing possible historical exposure need more than current policy snapshots. They should examine CloudTrail events, runtime invocation logs, metadata-related activity, ECR image pulls, memory API calls, and Secrets Manager access during the relevant period.

Temporary credentials expire, but their effects may persist. An attacker could copy source code, retain a retrieved secret, modify session history, or plant long-term memory before expiration. Response plans should include credential rotation and state validation.

Two uncertainties remain central. Zenity’s findings come from researcher-controlled deployments, and no public evidence cited here establishes widespread exploitation in customer environments. AWS has not published a dedicated security bulletin describing the complete AgentCorruption chain.

That absence should prevent inflated claims, not dismiss the research. Zenity published detailed permission examples, exploitation paths, and disclosure dates. AWS’s updated documentation independently confirms that runtime code can access metadata credentials and that broad development policies are unsuitable for production.

The first signal to watch is whether AWS issues a formal advisory, retrospective, or additional policy migration guidance. Such documentation would clarify affected configurations and whether customers need to remediate older roles manually.

The second signal is further restriction of metadata access from agent-controlled tools. A control that blocks runtime workloads from reaching credential endpoints would reduce dependence on model behavior. Granular egress policy could also contain other SSRF paths.

The third signal is customer-visible memory protection. Better provenance, scoped write authorization, integrity alerts, and bulk quarantine tools would make memory poisoning easier to detect and reverse. Those capabilities matter as long-term memory moves into business-critical workflows.

Zenity AgentCorruption ultimately tests a broader claim behind enterprise agents. Managed infrastructure can reduce operational complexity, but it cannot safely collapse identity, memory, and tool access into one broadly trusted role.

Developers should now ask a concrete question of every deployed agent: what happens after the model follows the worst instruction it can receive? Trace the resulting tool calls, credentials, permissions, reachable agents, and writable memories.

If the answer extends beyond that agent’s narrow task, treat the scope as an active security defect. Review the role, isolate public runtimes, test memory boundaries, and confirm the current AWS defaults directly. The safest agent is not the one that always rejects manipulation. It is the one whose cloud permissions keep a manipulated response from becoming an account-wide incident.