AgentCorruption: How a Single Prompt Exposed AWS Bedrock AgentCore to Region-Wide Agent Hijacking

What Is AgentCorruption?

AgentCorruption is a security research finding that exposed how a single malicious prompt sent to a public-facing AI agent could become the starting point for a much larger compromise of an Amazon Bedrock AgentCore environment. Instead of merely manipulating a chatbot into producing an incorrect answer, the attack chain demonstrated how an adversary could obtain cloud execution credentials, move between AI agents, access private conversations, interfere with agent memory, and retrieve credentials associated with external services.

The research was published by Zenity Labs on October 8, 2026. Its central finding was that, under the conditions examined by the researchers, compromising one externally accessible AgentCore agent could expose other AgentCore resources within the same AWS account and region. That distinction matters. The reported scope was not unrestricted control over every AWS account, every region, or every customer running AgentCore. It was the lateral access enabled by a particular combination of workload credential exposure and overly broad execution-role permissions.

AgentCorruption is particularly significant because it connects two security problems that are often treated separately. The first is an AI application problem: an agent can interpret attacker-controlled language as an instruction to use its tools. The second is a cloud security problem: the agent’s runtime identity may possess privileges extending well beyond the actions a particular user should be allowed to initiate.

When those problems interact, prompt injection becomes more than a model-behavior vulnerability. It becomes an entry point into an infrastructure-level attack.

The researchers disclosed their findings to AWS before publication. Zenity states that the reported security issues have been addressed, including changes to metadata-service behavior and substantial restrictions to AgentCore’s default execution-role permissions. AWS, meanwhile, emphasizes that access to an agent’s own execution-role credentials through the metadata service is expected behavior and that developers must configure those roles according to least-privilege principles.

This difference in emphasis is important for understanding both the original AgentCorruption attack and the residual security responsibilities facing organizations that deploy autonomous agents. AgentCorruption should be treated as a documented, historically demonstrated attack chain, not as evidence that the same region-wide compromise remains available against current default AgentCore deployments.

The incident illustrates a broader issue in agentic AI security: an agent does not need to escape its runtime, defeat a cloud hypervisor, or discover a conventional remote-code-execution vulnerability to become dangerous. Sometimes it only needs to perform an authorized tool operation using credentials that were granted too much authority.

Why AgentCorruption Is Different From an Ordinary Prompt Injection Attack

Traditional prompt injection attacks generally attempt to change how a language model interprets its instructions. An attacker might place malicious instructions inside a web page, repository file, email, or tool response, hoping the model will prioritize those instructions over its legitimate task. The attacker may want the model to reveal sensitive information, produce misleading output, or invoke a tool in an unauthorized way.

AgentCorruption starts with a related but more consequential behavior. A prompt causes an AI agent to make network requests that expose credentials belonging to its cloud execution identity. Once the credentials are obtained, subsequent activity can occur through ordinary AWS APIs without further model interaction.

This makes the compromise fundamentally different from a jailbreak that affects only the current conversation. After obtaining the agent’s cloud identity, the researchers were no longer dependent on persuading the model to complete every subsequent action. The privileges attached to that identity became the primary determinant of what they could access.

Consider an enterprise that operates three separate AI agents. A customer-support agent answers public questions, a finance agent works with sensitive billing records, and an internal operations agent accesses infrastructure data. From the application’s perspective, these agents serve different users and should operate within different security boundaries.

However, if the customer-support agent’s execution role can invoke the other two agents, read their memory resources, and retrieve shared credentials, the apparent separation is much weaker than it looks. An attacker does not necessarily need to compromise the finance application directly. Access to the customer-support agent’s sufficiently privileged cloud identity may be enough to reach it.

This is why AgentCorruption belongs at the intersection of several established security categories. It involves prompt-driven tool misuse, server-side request forgery, workload credential exposure, excessive IAM permissions, lateral movement, sensitive information disclosure, and agent memory poisoning.

Bu LLM Başvuruları için OWASP Top 10 describes excessive agency as a condition in which an LLM-powered application has more functionality, permissions, or autonomy than its legitimate tasks require. That definition closely captures the cloud identity problem highlighted by AgentCorruption. Prompt manipulation creates the opportunity, but excessive privileges determine the damage.

Understanding the AWS Bedrock AgentCore Architecture

To understand the AgentCorruption attack chain, it helps to understand how an AgentCore application operates.

Amazon Bedrock AgentCore is a managed AWS platform for deploying and running AI agents. It provides capabilities for runtime execution, memory management, identity, tool connectivity, observability, and integration with cloud services. Developers can construct agents using frameworks such as Strands Agents and deploy them as containerized workloads.

AgentCore Runtime uses Firecracker microVM technology to isolate execution environments. Its architecture is designed to separate workloads and sessions at the compute layer, reducing the risk that activity inside one runtime will directly interfere with another.

Yet compute isolation and authorization isolation are different security properties.

A microVM can successfully isolate processes, memory, and filesystems while still running an application that is authorized to call powerful cloud APIs. The execution role assigned to that application determines which AWS resources those API calls can reach.

In AgentCore, the MicroVM Metadata Service, or MMDS, makes temporary credentials available to the workload. It serves a legitimate purpose: applications frequently need to authenticate to AWS services without embedding long-lived access keys in their container images.

AWS explicitly explains this model in its AgentCore credentials management documentation. The documentation states that code executing inside the VM can access execution-role credentials through the metadata service and advises developers to carefully limit the permissions associated with those credentials.

That means the existence of a metadata credential endpoint is not, by itself, evidence of a hypervisor escape or an unexpected cloud tenancy violation. The security question is whether an untrusted user can make an agent retrieve and disclose those credentials, and whether the resulting identity has authority beyond the agent’s intended function.

AgentCorruption demonstrated why these distinctions matter. The researchers combined an agent capable of issuing HTTP requests with metadata-service access and a historically overprivileged execution role. The microVM itself did not need to be escaped. Instead, the attack crossed boundaries between user instructions, tool execution, workload identity, and authorization.

How the AgentCorruption Attack Chain Worked

The complete AgentCorruption attack can be understood as a sequence of trust-boundary failures. Each stage depended on an existing capability that seemed reasonable in isolation but became dangerous when combined with the others.

AgentCorruption — historical attack path

Untrusted promptPublic-facing AI agent

HTTP or shell tool invocationRequest reaches the metadata service

Temporary IAM credentialsAgent execution-role identity becomes accessible

Overprivileged roleHistorically broad account-and-region permissions

Other agentsDiscovery and invocation

Private sessionsConversation history access

Agent memoryPersistent behavior manipulation

Cloud secretsThird-party credentials

This depicts the attack chain demonstrated in the original research, not the permissions currently granted by default in AgentCore.

Stage 1: A Public-Facing Agent Becomes the Entry Point

The researchers began with a straightforward agent deployed on Amazon Bedrock AgentCore. The agent was built using the Strands SDK and equipped with an HTTP request tool.

For a normal application, this configuration is unsurprising. A customer-support assistant may need to retrieve information from a help center. A travel agent may query a booking API. A research assistant may need to fetch web pages, and an internal automation agent may call operational endpoints.

The security risk arises when the model is allowed to choose arbitrary request destinations based on untrusted prompts.

In the researchers’ environment, the agent could be instructed through its chat interface to send requests to the metadata service. It did not need a specially crafted binary exploit or malicious dependency. The attacker-controlled input reached an agent that already had the capability to generate network traffic.

Zenity’s technical report, AgentCorruption: Initial IMDS Access, documents the proof of concept and identifies built-in HTTP and shell tools as relevant paths through which the researchers tested the issue.

There is a subtle security lesson here. The immediate failure was not that an LLM understood the user’s English instructions. Understanding and responding to user instructions is precisely what the agent was designed to do. The failure was that the surrounding application did not impose an effective boundary between permitted business requests and access to sensitive runtime infrastructure.

A system prompt telling the agent not to disclose secrets would have been an additional behavioral safeguard, but it would not replace the need for independent authorization and network restrictions. The model should not be the only component deciding whether a request to an internal credential service is allowed.

Stage 2: SSRF Exposes the Instance Metadata Service

The next stage involved server-side request forgery, commonly abbreviated SSRF.

SSRF occurs when an attacker causes a server-side application to make a request to a destination that the attacker would not normally be able to access directly. In cloud environments, metadata endpoints are especially sensitive because they may expose instance configuration and temporary workload credentials.

The familiar link-local metadata address is:

169.254.169.254

This address is not an ordinary public web service. It is an infrastructure endpoint associated with the compute environment. A request originating outside the cloud workload generally cannot access the workload’s local metadata service directly.

An agent, however, may execute HTTP requests from inside its runtime. If the agent can be directed to request a metadata URL, the request originates from the environment that has access to the metadata service.

In the original AgentCorruption research, this distinction allowed the researchers to use an agent’s tool capability as an SSRF primitive. Once requests reached the metadata service, they could retrieve information associated with the execution environment.

The reported exposure included the agent’s execution-role identity and temporary credentials. The researchers also described access to other metadata, including configuration details and references to the agent’s container image.

This was an infrastructure exposure caused by the interaction between agent tool execution and workload metadata access. It was not a conventional network-based exploit that independently penetrated the Firecracker hypervisor.

AWS subsequently hardened the metadata interaction model. The distinction between the original reported behavior and current metadata requirements is discussed later in this article.

Stage 3: Temporary Credentials Become an AWS Identity

The sensitive result of metadata access was a set of temporary AWS Security Token Service credentials associated with the agent’s execution role.

AWS temporary credentials ordinarily consist of three components:

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
AWS_SESSION_TOKEN

These values authenticate an assumed IAM role for a limited period. Temporary credentials are preferable to long-lived static credentials in many architectures, but they remain security-sensitive. Anyone who obtains a valid credential set may be able to exercise the permissions associated with that role until the credentials expire or access is otherwise constrained.

The researchers verified that the extracted credentials represented the agent’s actual AWS execution identity. At this point, the attack crossed an especially important boundary: instructions delivered through an AI chat interface had resulted in a cloud identity that could be used separately from the conversation.

From the perspective of AWS authorization, the subsequent API requests were made using the credentials of an authorized IAM role. Unless other restrictions intervened, access decisions followed that role’s effective permissions.

This explains why credential exposure is so much more serious than the disclosure of a system prompt. A leaked prompt may reveal application behavior or internal instructions. A leaked credential can directly authorize actions against external infrastructure.

The distinction also changes how defenders should investigate an incident. Reviewing the suspicious conversation is only the beginning. Investigators may need to examine activity performed under the compromised execution role, including API calls made outside the original agent session.

Temporary credential expiration limits how long a particular set can be reused, but it does not automatically undo operations already performed. It also cannot be treated as a sufficient defense when an attacker retains a path to obtain refreshed credentials. The original research described this latter problem when examining longer-running credential harvesting.

Stage 4: Overprivileged IAM Permissions Enable Lateral Movement

Credential theft was the entry point, but IAM privilege scope determined the potential blast radius.

According to Zenity’s One Role to Rule Them All analysis, the execution role available in the tested configuration contained permissions extending across multiple AgentCore resources within the same AWS account and region.

Rather than being narrowly restricted to the original agent, the role allowed operations involving other runtime and memory resources. The researchers used these permissions to enumerate resources, identify agents, retrieve container images, and reach services that should have remained separate from the initial public-facing application.

For example, the research describes how CloudWatch log-group names revealed deployed AgentCore runtime identifiers. The role’s ability to enumerate log groups turned ordinary observability metadata into a resource-discovery mechanism.

This illustrates an often-overlooked aspect of privilege escalation. An attacker does not always need to call an API that explicitly lists private application resources. Logs, tags, deployment naming conventions, and other operational metadata can disclose enough information to discover targets.

After identifying additional runtime resources, the researchers used the permissions available to the extracted role to invoke agents beyond the initial one. This was particularly significant because an organization might expose a basic customer-service agent to the internet while assuming that its finance, infrastructure, and internal operations agents are accessible only through separate application-level authorization controls.

A shared or overly broad IAM identity can undermine those assumptions.

The researchers also examined ECR permissions. Their environment allowed retrieval of container images beyond the initial agent. Container images may contain application source code, dependencies, configuration files, or accidentally embedded secrets, making them valuable targets during a broader compromise.

Even without hardcoded secrets, access to source code may reveal API integrations, tool names, internal service endpoints, and application architecture. Such information can make subsequent attacks easier and help an adversary understand which agents have particularly sensitive capabilities.

The important distinction is between an application’s intended authorization model and the effective authorization enforced by the infrastructure. A user may have permission to ask a public assistant a question, but that does not imply permission to invoke every agent accessible to the public assistant’s underlying cloud role.

AgentCorruption showed what happens when the difference is not enforced.

Access to Private Conversations and Agent Memory

One of the most consequential aspects of AgentCorruption was the ability to access conversational data belonging to other agents and users.

Enterprise AI agents frequently process information that is substantially more sensitive than ordinary chatbot traffic. Employees may provide contracts, financial documents, customer records, source code, or infrastructure configurations. AI agents can also produce confidential output by querying connected tools on behalf of users.

AgentCore Memory provides facilities for preserving conversational context. The two broad categories relevant to the research are short-term memory and long-term memory.

Short-term memory stores events associated with conversations and sessions. Long-term memory can preserve extracted information that remains useful beyond the original interaction, such as user preferences, facts, summaries, or episodic knowledge.

In the original environment, the extracted IAM credentials permitted memory-related API calls that were not adequately restricted to the initial agent and its own users. The researchers showed how access to resource identifiers, actor identifiers, and session identifiers could lead to retrieval of private conversation events.

Bu bedrock-agentcore:ListEvents permission was particularly important. As documented by the AWS ListEvents API, this operation lists stored events from a specified memory resource and session.

If an execution role has broad access to memory resources, the privacy of individual application sessions can become dependent on IAM scoping rather than simply on the separation presented in the user interface.

A frontend that displays only the current user’s conversation does not establish a security boundary if backend credentials can read everyone else’s records.

The attack therefore exposed a general authorization problem in agent memory systems. Identifiers used to distinguish users and sessions are not substitutes for permission checks that bind operations to the correct authenticated principal.

AgentCorruption Memory Poisoning: From Temporary Access to Persistent Control

The memory component of AgentCorruption went beyond reading private conversations. The researchers also demonstrated how an attacker with suitable write permissions could alter the information that an agent would use in future interactions.

This attack is called agent memory poisoning.

In a stateless chatbot, a malicious instruction may affect a single conversation and disappear when that interaction ends. An agent with persistent memory operates differently. Information encountered today may become context for decisions made days or weeks later.

That makes persistent memory a high-value attack surface.

AgentCore supports several long-term memory strategies, including semantic memory, user preferences, summarization, and episodic memory. Each strategy extracts a different kind of information from stored events.

Semantic memory preserves facts or contextual knowledge. User preference memory retains information about how a user wants the agent to behave. Summarization captures prior discussion and decisions, while episodic memory represents actions and outcomes that might help the agent with later tasks.

An attacker who can insert events into the underlying conversation history may try to influence the information these strategies extract.

The precise mechanism matters. In Zenity’s Weaponizing Agent Memory for Persistent Hijacking, the researchers explain that their attack used bedrock-agentcore:CreateEvent to submit short-term memory events. Long-term memory extraction then processed those events according to the target memory’s configured strategies.

Bu CreateEvent operation did not simply grant arbitrary direct modification of every long-term memory record. For an injected instruction to persist and influence later behavior, it needed to survive extraction and subsequently be retrieved and trusted by the agent.

This distinction is essential because memory poisoning is not automatically successful whenever an attacker can write a message. Successful exploitation depends on how events are attributed, how the memory system extracts information, which namespaces receive it, and how the agent later interprets the retrieved material.

How Poisoned Memory Changes Agent Behavior

Consider an AI customer-support assistant that normally verifies refund eligibility before presenting payment instructions.

If a malicious actor can insert an event falsely stating that a particular approval requirement has already been satisfied, the memory extraction process might preserve that statement as historical context. Later, when the agent retrieves the stored information, it may interpret the claim as an established fact rather than untrusted input.

This is a conceptual example of the security failure, not a claim that every AgentCore deployment would perform an unauthorized refund.

The underlying issue is the promotion of lower-trust content into operational authority.

Memory systems are designed to condense large amounts of conversational information into useful context. However, if they do not preserve the source and trust level of that information, malicious instructions can be transformed into apparently legitimate preferences, facts, or prior decisions.

The danger is amplified when the agent can take actions rather than merely generate text.

A poisoned memory telling an agent to prefer concise responses is a nuisance. A poisoned memory that influences transaction approval, data access, tool selection, or outbound network requests can have much more serious consequences.

Persistent Command-and-Control Through Agent Memory

Zenity’s research explored a particularly concerning extension of memory poisoning. Instead of storing only a fixed malicious instruction, the researchers demonstrated how persistent memory could direct an agent to consult an attacker-controlled web resource before answering future queries.

The external resource became a means of changing the instructions delivered to the agent over time.

This is a significant difference from ordinary prompt injection. A typical injection must be encountered again to influence a new interaction. A persistent memory entry can cause the agent to repeatedly retrieve new attacker-controlled content during otherwise legitimate conversations.

In the research demonstration, the attacker-controlled resource was also used to direct exfiltration of conversational content. This created a path through which users could continue interacting with a seemingly trustworthy agent while portions of their conversations were sent to an external endpoint.

The resulting compromise combines persistence, instruction hijacking, and data exfiltration.

It also makes detection more difficult. A security analyst investigating only the most recent user message may find nothing suspicious. The malicious behavior can originate from memory records created during an earlier interaction, or from external content retrieved because of those records.

Bu OWASP GenAI Security Project’s discussion of memory and context poisoning identifies precisely this danger: retained context gives autonomous systems continuity, but also allows malicious influence to carry forward beyond the immediate point of compromise.

For defenders, agent memory must therefore be treated as security-relevant state, not merely as a convenience feature. The origin, integrity, and authorization of stored information can affect future tool execution.

Secrets Manager Exposure and Third-Party Credential Theft

Another important component of AgentCorruption concerned the credentials that AI agents use to communicate with external applications.

Enterprise agents rarely operate entirely within one platform. They may connect to GitHub repositories, Slack workspaces, Salesforce environments, internal databases, ticketing systems, or external APIs.

These integrations require authentication. Depending on the application, an agent might use API keys, OAuth access tokens, or other credentials associated with a service identity or individual user.

Amazon Bedrock AgentCore includes identity and outbound authentication capabilities that help manage these credentials. Storing credentials in AWS Secrets Manager is generally safer than embedding them directly in application source code.

But credential storage and credential access control are separate problems.

In the affected configuration examined by the researchers, the execution role had access to secrets associated with AgentCore outbound authentication resources across an overly broad scope. Once the attackers obtained that identity, they could use its permissions to retrieve credentials that belonged to other agent integrations.

Bu fourth AgentCorruption research report explains how the researchers identified credential references through agent source code and explored ways to discover additional outbound authentication providers. The investigation also described sensitive environment-variable information being exposed through runtime metadata.

This reveals a general failure mode that extends beyond AWS AgentCore.

A secrets manager can encrypt credentials at rest, provide audit logging, and support centralized secret rotation. Those capabilities do not prevent an identity with valid GetSecretValue permissions from retrieving secrets it is authorized to read.

If multiple unrelated agents effectively share access to a common collection of credentials, compromising one sufficiently privileged identity can expose integrations used by other agents.

The consequences can extend beyond the original AWS account and region because the extracted secrets may authenticate to third-party services.

For example, an exposed GitHub token could potentially grant repository access, while a leaked business-application API key could authorize operations against an external SaaS platform. The actual impact would depend on the token’s permissions, expiration, resource restrictions, and additional authentication controls.

This is where a compromise initially constrained to one cloud environment may develop into a broader organizational incident.

It is also why rotating an agent’s AWS credentials alone may be insufficient after a confirmed compromise. Organizations need to determine whether downstream credentials were accessed and whether those credentials were used outside the original cloud environment.

The Real Blast Radius of AgentCorruption

The following table summarizes the major capabilities demonstrated in the research and the security boundaries involved.

Attack stage	Security boundary	Demonstrated historical impact
Prompt-driven tool misuse	User input to agent tool execution	Agent made requests to internal metadata
Metadata credential exposure	Runtime environment to workload identity	Temporary IAM credentials obtained
Excessive IAM permissions	Individual agent to regional resources	Other agents and ECR images became accessible
Session enumeration	Application user boundary to memory service	Private conversation events could be read
Memory modification	Stored conversation state to future agent behavior	Sessions and long-term memory could be manipulated
Secrets Manager access	Agent identity to managed credentials	Third-party API keys and authentication secrets became accessible
Persistent instruction retrieval	Trusted agent context to attacker-controlled content	Future responses and tool actions could be redirected

These are capabilities described in the research, not a claim that every affected action occurred in a production customer environment.

There are also clear limits to the finding. The attack did not demonstrate a universal AWS authentication bypass or automatic access across unrelated customer accounts. It depended on the privileges available to the compromised execution role.

The relevant security question is therefore not simply whether an organization uses AgentCore. It is whether the deployed application’s effective permissions, tool capabilities, network behavior, memory access, and credential handling create an equivalent chain of authority.

Has AWS Fixed AgentCorruption?

The remediation status of AgentCorruption is an essential part of the story, particularly because the research was publicly disclosed after AWS had already made several changes to AgentCore.

The original vulnerabilities were reported privately during late 2025 and early 2026. Zenity’s published timeline identifies December 25, 2025, as the disclosure date for the initial metadata-access issue, followed by a separate report on January 12, 2026, concerning excessive execution-role permissions and their broader impact.

In April 2026, AWS informed the researchers that AgentCore had been updated to use the newer metadata protocol for newly deployed agents as of February 14, 2026. Further changes followed.

By September 29, 2026, Zenity observed substantial modifications to the default execution role. According to the researchers, AWS had removed permissions that previously enabled broad invocation of other agents, private conversation access, and retrieval of secrets across the account’s regional AgentCore resources.

The complete chronology is documented in Zenity’s original disclosure.

Date	Development
December 25, 2025	Initial metadata access issue disclosed to AWS
January 12, 2026	Broader execution-role privilege issue reported
February 14, 2026	According to AWS’s response, newly deployed agents began using IMDSv2
April 12, 2026	AWS responded to the initial report, classifying it as informative
June 22, 2026	Researchers reported that broad default permissions were still present
June 30, 2026	AgentCore began requiring MMDSv2 for runtime invocations
September 29, 2026	Researchers confirmed substantial hardening of the default execution role
October 8, 2026	AgentCorruption research publicly disclosed

The metadata-service terminology warrants clarification. AWS’s current AgentCore documentation refers to MMDS, the MicroVM Metadata Service, because AgentCore uses Firecracker microVMs rather than ordinary EC2 instances. The underlying security concept is similar to EC2 IMDS, and the research uses IMDS terminology extensively.

AWS documentation now states that AgentCore Runtime requires MMDSv2. Beginning June 30, 2026, runtime invocations without the required configuration are rejected. Organizations with older deployments can consult AWS’s MMDSv2 troubleshooting documentation for the supported configuration process.

AWS’s Response and the Shared Responsibility Question

AWS provided a statement acknowledging the research while explaining that access to an execution role’s credentials from within the agent’s microVM is documented and expected. It also emphasized that cross-account resource access requires appropriate permissions and that developers should grant execution roles only the privileges their applications need.

This position reflects how cloud workload identities ordinarily function. A running application needs a mechanism for accessing its own temporary credentials, and the credentials are intended to provide whatever access its execution role has been granted.

Zenity’s findings, however, highlighted what can happen when that legitimate credential mechanism interacts with untrusted natural-language instructions and overly broad permissions.

The two positions address different parts of the security problem. AWS describes the intended workload credential model, while Zenity’s research demonstrates how agent-driven tool execution and historical default IAM policies created an unexpectedly large attack surface.

There is no need to assume that every current AgentCore deployment remains vulnerable to the original complete chain. The researchers explicitly report remediation of the underlying issues.

Nevertheless, organizations should review their own deployed policies rather than assume that a platform-level update automatically removes every permission previously granted through custom roles, copied examples, or independently maintained IAM configurations.

Why MMDSv2 Alone Is Not a Complete Defense

A particularly important technical distinction is that requiring MMDSv2 does not eliminate the need for least-privilege execution roles.

Metadata protocol hardening helps defend against specific forms of credential exposure, particularly requests that rely on the simpler access behavior of older metadata implementations.

However, legitimate software running inside an AgentCore runtime may still need access to temporary execution-role credentials. AWS explicitly documents this behavior.

The underlying question is whether untrusted input can cause software inside the runtime to misuse those credentials.

An attacker who can exploit a vulnerable tool implementation, manipulate authorized application behavior, or obtain sufficiently powerful execution capabilities may still be able to create problems even when newer metadata protocols are enabled.

This does not mean MMDSv2 is ineffective. It means a metadata protocol is one defensive boundary, not a complete authorization system for autonomous AI agents.

The correct security model is layered. Network controls should restrict inappropriate destinations. Tool interfaces should limit which operations can be requested. IAM roles should restrict what those operations can accomplish. Downstream services should independently verify authorization, and persistent memory should not become a source of unrestricted instructions.

The most robust defense is the one that remains effective when the model makes an incorrect decision.

If a customer-support agent attempts to retrieve another application’s financial records, the authorization system should deny the request regardless of how convincingly the prompt was written.

How to Detect AgentCorruption-Like Activity

Detecting a historical AgentCorruption-style compromise requires examining both the AI application and the cloud infrastructure supporting it. Either layer alone may provide an incomplete picture.

At the agent level, investigators should examine unexpected tool calls, requests to metadata endpoints, unauthorized HTTP destinations, and attempts to expose runtime configuration. Requests involving the link-local metadata address 169.254.169.254 are especially relevant when analyzing the original attack class.

A request to this address is not automatically malicious, because legitimate runtime components may need metadata access. Suspicion should increase when the request is initiated through a user-directed agent tool or its response is returned to a conversational interface or external destination.

At the IAM level, investigators should look for execution-role credentials being used for operations outside the agent’s ordinary business purpose. Unusual AgentCore runtime invocations, broad resource discovery, ECR image access, memory enumeration, and Secrets Manager retrieval are examples of activity worth correlating.

There is also a distinction between seeing an API call and proving malicious intent. Many of these operations are legitimate in development and administration workflows. Their significance depends on which identity performed them, which resource was targeted, and whether the activity was expected for that application.

AWS recommends CloudTrail, CloudWatch Logs, and other observability capabilities for runtime auditing. Its AgentCore security best practices describe how CloudTrail records relevant runtime API activity and how logs can help correlate commands and requests.

Detecting Suspicious Memory Operations

Memory-related events deserve particular attention because unauthorized changes may influence future interactions even after the original compromise is contained.

Investigators should review instances where one execution role attempts to access memory resources belonging to unrelated agents, users, or workflows.

Relevant actions include ListEvents, CreateEventve DeleteEvent. Each operation has a legitimate purpose. Reading stored conversation history, adding an event, or deleting an event may be normal application behavior when correctly authorized.

The anomaly arises when the operation targets a resource outside the caller’s intended scope, occurs without a corresponding legitimate interaction, or modifies persistent context in an unexpected way.

For example, a customer-service runtime that normally writes only to the current customer’s session should not suddenly generate memory events associated with unrelated users and internal agents.

An effective detection strategy therefore requires mapping expected relationships between runtime identities, memory resources, actors, and sessions.

Monitoring only whether an API call succeeded is insufficient. Organizations should also ask whether the caller was authorized to perform that particular operation on behalf of that particular user.

AgentCore provides memory observability information, including spans associated with CreateEvent, ListEventsve DeleteEvent. Bu AWS memory observability documentation describes available operation attributes such as memory, session, event, and actor identifiers.

These fields can help identify unusual cross-session activity when the appropriate telemetry has been enabled. They should be correlated with application authentication records and deployment-specific access policies.

Auditing AgentCore Execution Roles for Excessive Permissions

One of the most practical lessons from AgentCorruption is that organizations should audit the IAM roles actually attached to their deployed agents.

Security teams should begin by identifying each AgentCore runtime, its execution role, and the intended resources that role must access. They should then compare this intended permission set with the actual IAM policies attached to the role.

A public-facing support agent may need to invoke a particular model, write logs, and access a narrowly scoped knowledge base. It may not need the ability to invoke unrelated AgentCore runtimes, read all memory events, retrieve secrets used by other applications, or inspect arbitrary container repositories.

For an authorized IAM audit, the AWS CLI provides read-only operations that can help inspect a role and its attached permissions.

# Replace with the actual AgentCore execution role name.
ROLE_NAME="YOUR_AGENTCORE_EXECUTION_ROLE"

# Inspect the role and its configuration.
aws iam get-role \
  --role-name "$ROLE_NAME"

# List inline policy names.
aws iam list-role-policies \
  --role-name "$ROLE_NAME"

# List attached managed policies.
aws iam list-attached-role-policies \
  --role-name "$ROLE_NAME"

These commands do not modify IAM permissions. They provide a starting point for identifying policies associated with a particular runtime role.

For inline policies, the get-role-policy operation can retrieve the policy document. Attached managed policies require inspection of their active policy versions.

The review must also account for permissions boundaries, service control policies, resource-based policies, explicit denies, and relevant IAM conditions. Merely listing attached policies does not fully establish the role’s effective permissions.

Bu AWS IAM permissions documentation for AgentCore Runtime is particularly relevant because it distinguishes execution-role requirements from broader permissions used to provision and manage the service.

AWS also warns that policies generated by certain development tooling may be intentionally broad and unsuitable for production. That is a critical detail for teams that began with a quick prototype and later deployed the same configuration without performing a dedicated security review.

What Permissions Should Security Teams Review?

An AgentCorruption-focused audit should examine permissions involving other runtime resources, conversation history, memory modification, container images, and secrets.

Permission or capability	Security concern
bedrock-agentcore:InvokeAgentRuntime	Potential invocation of unrelated agents
bedrock-agentcore:ListEvents	Access to stored conversations
bedrock-agentcore:CreateEvent	Insertion of potentially malicious conversation events
bedrock-agentcore:DeleteEvent	Removal or alteration of stored context through deletion
secretsmanager:GetSecretValue	Retrieval of sensitive application credentials
ecr:BatchGetImage	Access to private container images
ecr:GetDownloadUrlForLayer	Retrieval of container image layers
logs:DescribeLogGroups	Discovery of runtime and memory resource identifiers

The presence of one of these permissions is not necessarily a vulnerability. Some applications genuinely require them.

The critical issue is whether the permission applies to precisely the resources and operations required by the agent.

For example, granting an agent permission to retrieve one application-specific secret is fundamentally different from granting it access to a broad collection of secrets used by unrelated agents.

Likewise, an application that legitimately records memory events should ideally be authorized only for the appropriate memory resources and should enforce user-level access restrictions in its backend.

Security teams can use IAM Access Analyzer policy validation to examine policy documents and identify issues related to IAM best practices.

It is worth emphasizing that automated policy validation is not a substitute for understanding the application’s business requirements. An IAM policy can be syntactically valid while still granting dangerous permissions.

Building a More Secure AgentCore Architecture

AgentCorruption demonstrates why AI agent security cannot rely entirely on modifying a system prompt or selecting a model that appears resistant to prompt injection.

An enterprise agent should operate within constraints enforced by infrastructure that the model itself cannot arbitrarily override.

Enforce Least Privilege at the Individual Agent Level

The most important control is to assign narrowly scoped execution permissions according to what each agent actually needs.

Separate public-facing agents from internal agents that process sensitive information. Avoid reusing broad service roles simply because the agents belong to the same application or AWS account.

Where possible, scope permissions to specific runtime ARNs, memory resources, secrets, and other resources.

Some actions require broader resource scopes or use specific IAM authorization mechanisms. Those exceptions should be documented and minimized rather than handled through unrestricted policies by default.

The key principle is simple: compromising one agent should not automatically authorize access to its neighbors.

Restrict Tools Rather Than Trusting the Model to Avoid Misusing Them

An agent that needs to retrieve a weather forecast does not necessarily need unrestricted HTTP access. It may be safer to provide a dedicated weather tool that queries an approved provider with validated parameters.

Similarly, an agent that needs to retrieve files from a document repository should not automatically receive a general-purpose shell interface or unrestricted filesystem access.

Narrow tool interfaces reduce the number of actions that untrusted language can trigger.

Consider an HTTP tool that accepts arbitrary URLs. A useful first line of defense is to reject inappropriate schemes and nonapproved destinations before making network requests.

The following simplified example illustrates a restrictive URL-validation approach for an agent expected to access only one known API host.

from urllib.parse import urlsplitALLOWED_HOSTS = {    "api.example.com",}def validate_tool_url(url: str) -> str:    if not isinstance(url, str):        raise ValueError("URL must be a string")    parsed = urlsplit(url)    if parsed.scheme != "https":        raise ValueError("HTTPS is required")    if parsed.username or parsed.password:        raise ValueError("Embedded credentials are not allowed")    if parsed.hostname not in ALLOWED_HOSTS:        raise ValueError("Destination is not approved")    if parsed.port not in (None, 443):        raise ValueError("Port is not approved")    if parsed.fragment:        raise ValueError("URL fragments are not supported")    return url

This is an illustrative application-level guard, not a complete SSRF prevention system. A production implementation must also consider DNS resolution, redirects, proxies, URL parsing inconsistencies, network-level egress restrictions, and the possibility that an approved hostname resolves to an unsafe destination.

Even a correctly implemented URL allowlist cannot replace network segmentation if other tools, libraries, or code paths can issue outbound requests.

The strongest approach combines narrow tool interfaces with infrastructure-level controls that restrict access to unnecessary destinations.

Treat Tool Invocation as a Privileged Operation

Agent tool calls should be evaluated against policies that exist outside the language model.

An application can distinguish between ordinary information retrieval and operations with meaningful consequences, such as issuing refunds, deleting resources, accessing secrets, changing access controls, or transferring data outside the organization.

For high-impact operations, the tool layer should independently verify the user’s identity, permissions, and approval requirements.

A model saying that a user has approved an action is not sufficient evidence of authorization.

AWS recommends several related controls in its AgentCore Runtime security guidance, including explicit input validation, careful inbound authentication, scoped execution roles, and gateway-based controls.

One particularly relevant warning concerns structured input. If user-controlled content is accepted as a tool-use message by an agent framework, it may trigger tool execution without passing through the normal model decision process. AWS therefore recommends validating the shape and type of incoming requests and rejecting unauthorized tool-use content blocks.

This highlights a broader rule for agent development: not all prompt-related attacks occur inside the model’s reasoning process. Some exploit how orchestration frameworks parse messages or dispatch tools.

Protect Agent Memory as a Security-Sensitive Database

Persistent memory should have its own authorization and integrity controls.

Memory operations need to be bound to authenticated users and appropriate sessions. It should not be possible for one runtime to alter another application’s memory simply because both resources exist within the same cloud account.

Applications should also preserve useful information about the source and trust level of stored content.

For example, a verified company policy should not be treated as equivalent to an arbitrary claim made in a previous conversation. An agent may need to remember both, but it should not grant them equal authority when making consequential decisions.

Where feasible, memory write operations should be attributable to the authenticated actor and validated against the application’s intended workflow.

For high-risk applications, particularly those involving finance, healthcare, account management, or security operations, teams should consider additional integrity checks before promoting conversational information into durable instructions.

A legitimate memory system may record that a user prefers shorter answers. That is different from silently accepting a remembered instruction that asks the agent to bypass security verification or send future conversation data to an external endpoint.

The problem is not memory itself. It is the possibility that stored information will be interpreted as an instruction whose authority has not been verified.

Isolate Third-Party Credentials

Secrets should be accessible only to the components and identities that require them.

AgentCorruption shows that storing an API key in Secrets Manager does not automatically prevent compromise if the agent’s execution identity has broad retrieval permissions.

Third-party authentication should be delegated and scoped wherever possible. A user-facing application should ideally use credentials associated with the relevant user or application function rather than relying on shared, organization-wide secrets.

For external integrations, teams should pay particular attention to token scope, credential lifetime, revocation procedures, and the permissions granted to agents through connected tools.

If a compromised agent can retrieve credentials that authorize changes in GitHub, Slack, or an external business platform, the organization’s potential exposure is no longer limited to the original agent runtime.

This is a general reason to treat agent integration architecture as part of the organization’s identity and access management strategy, rather than merely as an application configuration task.

Testing AI Agents for AgentCorruption-Like Weaknesses

An effective defensive assessment should test more than whether an agent refuses a malicious prompt.

The goal should be to establish whether untrusted requests can cause unauthorized effects in connected infrastructure.

For AgentCore deployments, this begins with determining which tool capabilities are available to users and whether those tools can interact with runtime metadata, internal APIs, or other sensitive network services.

Tests should be conducted only against controlled or explicitly authorized environments. Production credentials, real customer data, and unrelated cloud resources should not be required to validate the security architecture.

A safe test environment can use synthetic data, restricted IAM identities, dedicated runtime resources, and non-sensitive canary values.

Testing Network Isolation

A defender can begin by confirming that tools capable of making network requests reject destinations outside their intended scope.

The test should cover direct URLs, redirects, alternate address representations, hostname resolution behavior, and other ways that an application might reach sensitive infrastructure unintentionally.

The assessment is successful when inappropriate destinations are blocked by deterministic controls, even if the language model attempts to invoke the request.

Simply observing that the model declined one suspicious prompt is not strong evidence of network isolation. A different prompt, tool, or orchestration path may produce different behavior.

Testing IAM Boundaries

The next step is to test whether an agent’s execution identity can invoke unrelated resources.

In a controlled account, create multiple agents with distinct responsibilities and permissions. Verify that a public-facing agent cannot read another agent’s private memory, retrieve its credentials, or invoke its runtime unless those operations are explicitly part of the authorized design.

IAM policy simulation, Access Analyzer, and controlled authorization checks can help determine whether the expected boundaries are enforced.

The most important test is a negative authorization test: a prohibited operation should be denied regardless of how the request originated.

This approach produces stronger security evidence than relying exclusively on prompt injection benchmarks.

Testing Memory Integrity

Memory security tests should determine whether a user can insert content that later acquires greater authority than intended.

For example, a test might place a harmless statement in a controlled conversation and observe whether it becomes long-term memory, how it is attributed, and whether a different user or session can retrieve it.

More advanced tests can examine whether conflicting information is resolved correctly, whether memory extraction preserves provenance, and whether agent behavior changes when a memory record is retrieved.

The relevant outcome is not merely whether a suspicious phrase appears in a stored record. The security outcome depends on whether the agent treats that record as authoritative when choosing tools or taking consequential actions.

Bu OWASP Agentic AI memory-poisoning discussion provides useful context for understanding this distinction.

Testing Credential Isolation

A credential-isolation assessment should verify that the agent cannot retrieve secrets outside its approved scope and that its connected tools use credentials with appropriate permissions.

Security teams can use non-sensitive test secrets or dedicated dummy integrations to verify authorization behavior without risking disclosure of production credentials.

Container images should also be examined for accidentally embedded secrets and unnecessary configuration files. Secret scanning during image builds and before deployment can reduce exposure if an image becomes accessible to an unintended identity.

Finally, the organization should test the process for credential revocation and rotation. Containment becomes more complicated when an incident involves multiple agents, persistent memory, and third-party integrations.

AgentCorruption and the OWASP AI Agent Security Model

AgentCorruption is a useful case study because it demonstrates that several security categories can interact within a single attack chain.

The prompt-driven entry point relates to OWASP LLM01 Prompt Injection. The unrestricted or overly powerful tool capabilities relate to OWASP LLM06 Excessive Agency. The abuse of cloud identity and persistent agent context aligns with the broader identity, privilege, and memory-poisoning concerns addressed by the OWASP GenAI Security Project.

These classifications are complementary rather than mutually exclusive.

A model may behave correctly under many ordinary prompts while the surrounding system remains vulnerable because a tool performs unauthorized operations. Conversely, infrastructure permissions may be relatively narrow while a poorly designed application still allows an agent to make harmful business decisions using the permissions it legitimately possesses.

Neither model-level alignment nor traditional infrastructure hardening is sufficient by itself.

An enterprise agent operates across several trust domains: the person providing instructions, the language model interpreting them, the orchestration framework dispatching tools, the runtime executing operations, the workload identity authorizing access, and the external services receiving API calls.

AgentCorruption demonstrated how weaknesses across these domains can be chained together.

It also suggests that security testing should measure concrete effects rather than relying only on the language model’s final response.

An attacker may succeed in triggering a forbidden tool operation while the assistant still produces an entirely normal-looking response to the user.

That possibility becomes especially important in long-running workflows where tool calls, memory changes, and external API operations are not necessarily visible in the conversational interface.

What Organizations Should Do After the AgentCorruption Disclosure

For organizations operating AgentCore, the immediate priority is to verify actual deployment configurations.

The first question is whether runtime metadata security requirements are satisfied and whether existing deployments follow current AWS guidance. Since AWS now requires MMDSv2 for AgentCore Runtime invocation, failures involving older metadata configurations should be investigated and resolved through supported update procedures.

The second question is whether the execution roles attached to deployed agents contain excessive or historically inherited permissions.

A platform update may change default behavior for new deployments without automatically correcting every independently maintained IAM policy. Organizations should review custom execution roles, copied configuration examples, and policies generated during development.

The third question concerns sensitive agent resources. Teams should establish which roles can invoke internal agents, access memory events, retrieve secrets, and read ECR repositories. Permissions should be compared with actual functional requirements rather than accepted simply because an application has operated successfully with them.

The fourth question is whether sufficient logging exists to investigate suspicious behavior. Runtime invocation records, relevant memory events, Secrets Manager access, and other cloud operations should be traceable to appropriate identities and workflows.

If there is evidence that an agent’s credentials were compromised, incident response should also consider the downstream consequences. A stolen execution role may have been used to read other agents’ data, access container images, or obtain third-party credentials. Depending on the evidence, response actions may include restricting access, rotating affected secrets, investigating memory integrity, and revoking external tokens.

These steps address the general failure modes demonstrated by AgentCorruption without assuming that the original chain remains exploitable in a fully updated deployment.

Frequently Asked Questions About AgentCorruption

Is AgentCorruption a prompt injection vulnerability?

AgentCorruption includes prompt-driven tool misuse and behavior commonly discussed under prompt injection. However, the research describes a broader attack chain involving SSRF, workload credential exposure, excessive IAM permissions, cross-agent access, memory manipulation, and credential theft.

Its significance is that a malicious instruction could lead to cloud infrastructure access rather than merely influencing a chatbot’s output.

Does AgentCorruption affect all AWS Bedrock AgentCore users?

The original research identified security weaknesses in historical AgentCore behavior and default permission configurations. The researchers reported that AWS had addressed the issues before the October 8, 2026 public disclosure.

This does not establish that every current AgentCore deployment remains vulnerable. Organizations should evaluate their own configuration, particularly custom execution roles, tool permissions, and memory authorization controls.

Has AgentCorruption been assigned a CVE?

The original Zenity publication presents AgentCorruption as a named research finding and chained security issue rather than centering its disclosure on a single CVE identifier.

A named attack chain is not necessarily equivalent to one independently tracked software vulnerability. Security teams should use the original research and current AWS guidance when determining the relevant mitigation requirements, rather than assuming that remediation depends on applying one CVE-specific patch.

Can AgentCorruption steal AWS credentials?

The original research demonstrated the extraction of temporary AWS execution-role credentials through the runtime metadata service.

The extent of the resulting compromise depended on the permissions granted to the exposed role. In the historical configuration examined by Zenity, those permissions allowed access to additional AgentCore resources within the same AWS account and region.

AWS has since introduced metadata protocol requirements and hardened the default execution-role permissions described in the research.

What is the difference between AgentCorruption and ordinary SSRF?

Ordinary SSRF usually begins with a web application that accepts or constructs URLs in an unsafe way, allowing attackers to cause unexpected server-side requests.

AgentCorruption used an AI agent as the request-generating component. The malicious prompt influenced the agent’s tool use, which in turn reached sensitive metadata infrastructure.

The SSRF mechanism was familiar, but the entry point and subsequent exploitation path involved AI agent orchestration and cloud identity permissions.

Can memory poisoning survive after a malicious conversation ends?

Yes, under certain conditions. When an agent uses persistent memory, attacker-controlled information may be extracted into long-term memory and later retrieved during otherwise legitimate interactions.

Successful poisoning depends on how the memory system processes the content, what authority the agent assigns to retrieved information, and whether security controls prevent unauthorized instructions from influencing behavior.

Zenity demonstrated this risk in its AgentCorruption memory research.

Can enabling MMDSv2 completely prevent AgentCorruption-like attacks?

No single metadata protocol change eliminates all forms of agent tool misuse or credential abuse.

MMDSv2 strengthens metadata access controls, and AWS now requires it for AgentCore Runtime. However, legitimate runtime components may still access their assigned execution-role credentials. An application with excessive permissions or poorly restricted tools can therefore remain exposed to other attack paths.

The strongest protection combines metadata hardening, restricted tool capabilities, carefully scoped IAM permissions, authorization at downstream services, and memory integrity controls.

Why is AgentCorruption important for enterprise AI security?

AgentCorruption demonstrates that the damage caused by an AI agent compromise depends on more than model behavior.

An attacker who influences one agent may be able to reach sensitive business systems if the surrounding identity and authorization architecture allows it.

As organizations deploy agents that interact with internal applications, external services, and persistent data stores, those authorization boundaries become increasingly important.

Sonuç

AgentCorruption is an important case study in the security risks created when autonomous AI systems inherit powerful cloud identities.

The research did not depend on a sophisticated model jailbreak or a novel method for escaping a virtual machine. Its impact came from connecting familiar weaknesses: an agent willing to perform an inappropriate tool action, a reachable workload metadata service, temporary credentials with broad permissions, and cloud APIs that trusted the resulting identity.

What began as a malicious prompt against a public-facing agent developed into an attack path involving other runtimes, private conversations, persistent memory, container images, and third-party credentials.

AWS and Zenity report that the underlying issues described in the original disclosure have been addressed. That remediation is an important part of the factual record and should not be overlooked when assessing present-day AgentCore security.

The broader lesson, however, remains applicable to agentic systems across cloud providers and orchestration frameworks.

AI agents are not merely interfaces that generate text. They are software components that can make network requests, execute tools, access data, retain memory, and act through authenticated identities.

Their permissions must therefore be designed with the same care as those granted to any other potentially compromised workload.

The principle that emerges from AgentCorruption is straightforward: an untrusted prompt should never become a shortcut around infrastructure authorization.

The most secure AI agent is not necessarily the one that refuses every malicious-looking instruction. It is the one whose environment continues to enforce meaningful boundaries even when the model attempts the wrong action.