Zenity’s October 8 AgentCorruption publication describes a historical path from one publicly reachable Amazon Bedrock AgentCore agent into neighboring runtimes and persistent memory. The decisive condition was a broadly scoped execution role in the same AWS account and region, not a break into unrelated AWS customers or theft of an administrator password.
A prompt-induced network request exposed temporary workload credentials; IAM permissions then amplified their reach. Before publication, researchers found AWS had substantially restricted the default role. The research therefore demonstrates a failure of earlier tested defaults, not that every current AgentCore deployment remains vulnerable to the complete chain.
A prompt crossed into a trusted workload identity
AgentCore, generally available since October 2025, combines isolated runtimes with identity, memory, gateways, browser automation, code execution and observability. Those services solve genuine operational problems, but their integration creates authorization dependencies beyond the microVM boundary.
In Zenity’s test, an HTTP-capable tool followed untrusted instructions and requested local workload metadata. AWS environments use a link-local metadata service; AgentCore’s Firecracker microVMs provide the related MicroVM Metadata Service, MMDS. Temporary execution-role credentials legitimately let code access approved resources without permanent keys embedded in images.
The reported request ran inside the microVM, where it appeared local, and returned temporary access, secret and session credentials. This is an SSRF pattern: an attacker induces a server-side component to contact something the attacker cannot reach directly. Prompt injection supplied intent, the tool supplied network capability and metadata supplied identity.
Unsafe generated text alone would not create that chain. Blocking unnecessary metadata access from tools would interrupt it; a narrowly scoped role would limit consequences even if credentials leaked. AWS credential guidance explicitly says code or actors inside a microVM can access available credentials and instructs customers to minimize permissions.
Zenity first reported metadata exposure on December 25, 2025; AWS closed it as informative on April 12, 2026, saying new deployments had used IMDSv2 since February 14. That token-based metadata scheme defeats many conventional SSRF assumptions, but flexible autonomous tools may make preliminary requests too. Zenity argues it added friction without resolving trust.
Current runtime guidance says runtimes without MMDSv2 have been rejected since June 30, 2026. Customers should verify deployed metadata configuration, including requireMMDSV2, rather than assume all historical configurations changed. Metadata hardening is a layer, not justification for oversized permissions available to legitimate runtime code.
Broad permissions made the foothold useful elsewhere
A second report, January 12, focused on role scope. Zenity says regional CloudWatch log-group listing exposed identifiers through AgentCore naming patterns, allowing discovery of runtimes and memories without a prior inventory. Regional ECR permissions and predictable repositories then linked runtimes to container images, potentially exposing code and embedded configuration.
The tested wildcard runtime-invocation permission reached private agents in that account and region. A public support bot could thereby reach a more sensitive billing agent. Zenity demonstrated access to a test billing agent’s tools and a billing.json file through legitimate APIs, not a second unrelated software exploit.
Memory permissions reportedly allowed listing actors and sessions and reading events from other agents and users. Conversations could contain personal information, code, plans, customer records or pasted credentials. Whether a secret should have entered a conversation is separate from whether unrelated workloads should read it.
Create and delete event permissions also changed integrity, not just confidentiality. False context could enter an active session, and genuine tool results could disappear. Compute isolation did not prevent an identity from invoking other resources or altering their state: authorization isolation is a distinct requirement.
AWS told Zenity on February 25 that it was addressing the underlying problem. Researchers said the default was unchanged on June 22, but found substantial restrictions on September 29: cross-runtime invocation, private conversation access and Secrets Manager retrieval permissions had been removed, with other permissions narrowed.
Those changes materially narrow present-day claims. Customer-created roles, copied policies and older deployments still require review, but historical demonstrations are not proof that today’s default role has identical authority. Researchers used controlled deployments; cited public evidence does not establish widespread customer exploitation, and AWS had not issued a dedicated bulletin covering the whole chain.
Memory could preserve influence after credentials expired
Short-term AgentCore memory holds session events; long-term strategies extract reusable facts, preferences, summaries and lessons. That helps an agent remember an unresolved case or formatting preferences, but makes stored history an input to future decisions rather than merely post-incident evidence.
Zenity reports discovering memory IDs through logs, enumerating actors, sessions and strategies, and adding hostile events. Extraction converted some content into long-term records that later sessions could retrieve as trusted context. A repeated initial injection was therefore unnecessary for every future interaction.
Researchers characterize this as persistent command and control in their test. Actual behavior depends on memory configuration, retrieval, model, tools and permissions. A false destination, fabricated approval or poisoned summary illustrates the integrity risk without establishing that every recalled statement will control every agent.
Inserted assistant history may look like an earlier decision; deleted results can remove contradictory evidence. Expiring or rotating the stolen credentials stops future API access but does not erase copied code, retrieved secrets or poisoned state. Recovery must identify touched sessions, events, summaries and extracted memories.
AWS memory guidance recommends validation, guardrails before persistence, regular injection testing and least privilege. Provenance should identify the creating user, agent, session and extraction process, with quarantine and review for affected records. Writing-style preferences differ in consequence from payment destinations or access grants, which warrant tighter creation, retention and review.
Recalled context must not itself authorize a high-risk action. Remembering a preferred bank account does not replace current independent approval. Monitoring writes and deletes alongside reads—including unusual volumes and cross-agent patterns—helps reveal integrity abuse through CloudTrail, application logs and AgentCore observability.
The authorization boundary belongs outside model judgment
AWS runtime guidance warns against production use of broad CLI-generated development policies and recommends specific runtime ARNs rather than wildcards. It says execution-role privileges should be equal to or less than those of the principals allowed to invoke the runtime. Public reachability therefore demands especially narrow authority.
That does not make every public agent unsafe. It means accepted language is untrusted, including authenticated customers’ hostile prompts or indirect instructions in retrieved pages and documents. Authentication identifies a caller; it does not make all caller-supplied meaning safe.
Gateways, guardrails and interceptors can validate or restrict requests, but their policies fail if another authorized route bypasses them. Where the gateway is intended as the entry, direct runtime invocation should be restricted to its execution role. User identity must come from verified principals, not model-generated or caller-asserted labels.
Resource-scoped IAM can prevent invoking unrelated agents, pulling unrelated images, enumerating regional logs or reading other memories. Public and internal workloads should not share roles merely because setup is convenient; account or region separation can create clearer boundaries for sensitive functions.
Tools are privileged interfaces, not permissions conferred by the model’s choice to call them. Authorization must consider authenticated user, resource and operation independently. Engineering knowledge records can connect runtime owners, policies, threat models and incident procedures, but cannot substitute for enforced denial.
Current deployment review needs historical and persistent state
A scoped review should inspect execution roles and metadata settings, public/IAM/JWT reachability, gateway bypasses, cross-runtime rights, ECR and logs, cross-user memory, event writes/deletes and token or Secrets Manager retrieval. Resource and identity policies should be tested together for the expected denial, not judged from a successful prototype.
Possible historical exposure requires the relevant CloudTrail period, runtime calls, metadata-related activity, image pulls, memory calls and secret access, not only current policy snapshots. Temporary credentials can leave enduring effects, so credential rotation and memory validation are complementary.
The next useful evidence would be a formal AWS advisory or migration guidance, stronger separation of agent-controlled tools from credential endpoints, and customer-visible memory provenance, scoped writes, alerts and bulk quarantine. These are evidence to seek, not features assumed delivered.
AgentCorruption’s broader question is what remains possible after a model follows a malicious instruction. Managed infrastructure reduces complexity but cannot safely turn tools, identity and persistent memory into one broadly trusted role. Deterministic scope should keep a manipulated response from becoming an account-wide incident, even when model-level defenses fail.
Sources and related reading
Zenity attack-chain research · AWS credential guidance · Zenity execution-role analysis · AWS runtime security guidance · Related reading: engineering knowledge bases · Zenity memory-poisoning study · AWS memory practices · AgentCorruption reporting