AWS Bedrock AgentCore as Enterprise Attack Surface: AI Agent APIs and the Execution Boundary Problem

Cloud Security Alliance AI Safety Initiative | Research Note | March 9, 2026

Key Takeaways

• AWS Bedrock AgentCore’s Code Interpreter component contains a documented privilege escalation path that permits any IAM principal holding the bedrock-agentcore:InvokeCodeInterpreter permission to execute code under an agent’s IAM role, not the caller’s own role, without resource-based policy controls to restrict this behavior. AWS has classified this as an expected design behavior rather than a defect. [1, 2]

• The AgentCore Code Interpreter microVM exposes temporary execution-role credentials via an internal metadata service (MMDS). Researchers demonstrated a string-filter bypass enabling credential exfiltration outside the sandbox boundary. Actions taken with those credentials are logged to CloudTrail under the Code Interpreter’s identity, not the attacker’s, creating a forensic attribution gap. [2]

• Indirect prompt injection attacks against AgentCore can silently write adversary-controlled instructions into the agent’s persistent long-term memory, causing those instructions to propagate across future sessions without requiring the attacker to maintain active access. No memory integrity verification mechanism is documented for the current AgentCore memory service. [3, 4]

• AgentCore’s Cedar-based Policy layer (generally available as of March 3, 2026) provides the primary runtime enforcement mechanism at the Gateway boundary for tool-invocation control, but it operates at the gateway boundary and does not intercept in-context prompt manipulation occurring within the agent’s reasoning process prior to tool invocation. [5, 6]

• Enterprise deployments integrating third-party Model Context Protocol (MCP) servers via AgentCore Gateway face supply chain risk of tool poisoning, analogous to malicious npm packages but targeting AI tool invocation rather than software build pipelines. [7]

Background

Amazon Web Services introduced Amazon Bedrock AgentCore in July 2025 as a managed platform for building, deploying, and operating AI agents at enterprise scale [8]. AgentCore is not a single service but a tightly integrated suite of components: a serverless Runtime that executes agents in per-session microVMs; a Gateway that proxies all agent-to-tool API calls; an Identity layer managing agent IAM roles, OAuth flows, and multi-tenant custom claims; a Memory service providing both short-term conversational context and long-term cross-session episodic storage; a Code Interpreter offering sandboxed Python, JavaScript, and TypeScript execution; a Policy engine using the Cedar policy language to enforce tool-invocation rules at the Gateway boundary; and an Evaluations framework for agent quality testing [8, 9]. By December 2025, the AgentCore preview SDK had accumulated over two million downloads [9], suggesting significant developer interest across the enterprise ecosystem. The Policy component reached general availability on March 3, 2026. [5]

The architecture reflects deliberate attention to the structural security problems that accompany autonomous AI agents in enterprise environments. Unlike traditional application services, AI agents are LLM-driven orchestrators that invoke real-world tools — databases, APIs, cloud services, external data sources — through natural-language reasoning rather than deterministic code paths. This combination of real-world capability and non-deterministic control flow creates what security researchers have begun calling the execution boundary problem: the surface at which an AI agent’s unbounded reasoning meets bounded, consequential action in an enterprise system.

The execution boundary problem has three interlocking dimensions. First, trust is transitive in agent systems: a principal that can influence the agent’s reasoning can effectively exercise the agent’s tool-invocation rights, regardless of whether that principal holds those rights directly. Second, the runtime behavior of an agent cannot be fully specified at configuration time, making static access controls insufficient as a complete defense. Third, multi-agent architectures in which orchestrator agents spawn and delegate to subagents multiply each of these problems proportionally to graph complexity. AgentCore’s component architecture — particularly its Gateway and Policy layers — reflects an attempt to address these dimensions through runtime enforcement rather than configuration-time policy alone.

Security research published throughout 2025 and into 2026 has identified specific gaps and attack paths in the platform, several of which are examined in detail below. This research note synthesizes published findings to provide enterprise security teams with actionable guidance for deployments that are already underway or under evaluation.

Security Analysis

The Code Interpreter Privilege Escalation Path

AgentCore’s Code Interpreter is its most powerful and most heavily scrutinized component. Each Code Interpreter invocation runs Python, JavaScript, or TypeScript inside an isolated container within a dedicated microVM provisioned on a Spot EC2 instance [20]. Memory is sanitized at session termination to prevent cross-session data residue [20]. From a tenant-isolation perspective, no cross-tenant data residue vulnerabilities have been publicly documented in the current Code Interpreter design [1, 2]. The privilege escalation problem is not a cross-tenant issue but an intra-organization IAM design gap identified by Sonrai Security in July 2025 and expanded in September 2025. [1, 2]

The first vector is non-agent invocation. The bedrock-agentcore:InvokeCodeInterpreter IAM action permits any principal holding that permission to invoke a Code Interpreter — not only agent runtimes that have been explicitly granted tool access. When a Code Interpreter is invoked, it executes code under the agent’s IAM role, not the caller’s. This means a low-privilege IAM principal that would not ordinarily be permitted to call AWS services accessible to the agent role can effectively gain those permissions by creating and invoking a Code Interpreter that runs under the agent role. At the time of initial disclosure, AWS did not provide resource-based policies for Code Interpreter resources, making Service Control Policies (SCPs) the only centralized prevention mechanism available at the organization level. Enterprise security teams should treat SCP configuration for bedrock-agentcore:CreateCodeInterpreter and bedrock-agentcore:InvokeCodeInterpreter as a mandatory hardening step, not an optional configuration. [1, 10]

The second vector involves the microVM Metadata Service (MMDS), an internal endpoint analogous to the EC2 Instance Metadata Service (IMDS) that exposes the execution role’s temporary credentials to code running inside the microVM. Sonrai demonstrated a string-filter bypass in the MMDS access path that allowed exfiltration of those temporary credentials outside the sandbox boundary [2]. Once exfiltrated, the credentials can be used to call AWS APIs with the full permissions of the agent’s execution role. The forensic problem compounds the security problem: actions taken with the exfiltrated credentials are logged in CloudTrail under the Code Interpreter’s identity, not the attacker’s. Incident responders examining a CloudTrail stream will see what appears to be normal agent activity, with no signal that the session was under adversary control. AWS reviewed this behavior and characterized it as within the expected design of the service, publishing hardening guidance for execution role configuration rather than modifying the underlying architecture. This is a consequential determination: it places the mitigation burden entirely on enterprise configuration rather than platform controls, in a domain where configuration errors are common and detection is difficult. [2]

In practice, proof-of-concept deployments often begin with broad agent role permissions; organizations that have not reviewed these roles prior to production promotion should treat this as an urgent remediation priority. AgentCore Code Interpreter execution roles should be scoped to the narrowest possible set of permissions for each specific workflow, and any roles with broad AWS service access should be revised before production use.

Prompt Injection and Persistent Memory Poisoning

Prompt injection against agentic systems has four attack surfaces in the AgentCore context: direct user input passed to the agent, input that the agent constructs for tool calls, tool output that the agent incorporates into its reasoning, and the final agent response. The first surface, user input, has received the most attention in traditional Bedrock Guardrails guidance, but it is the second and third surfaces — tool input and tool output — that present the most structurally intractable risk. An agent that has been configured to retrieve content from the web, summarize documents, or process email should be assumed to encounter adversarially crafted content in those channels, and no filtering layer applied at the user-input boundary will protect against that content once it enters the agent’s reasoning context. [4]

Indirect prompt injection exploits this gap by embedding adversarial instructions in content that the agent retrieves as part of a legitimate task. AWS’s own guidance acknowledges this limitation and recommends tagging dynamically retrieved content as “user input” so that Guardrails evaluates it for adversarial instructions, though this approach shifts the problem to filter evasion rather than eliminating it structurally [4]. In March 2026, Palo Alto Networks Unit 42 reported observing adversarially crafted web content designed to redirect AI-based ad review systems — a case documenting real-world deployment of indirect prompt injection techniques in the wild, though Unit 42 noted they were not aware of any confirmed successful exploitation of a deployed production system [18]. This finding may indicate maturing adversary capability in this technique.

The intersection of indirect prompt injection with AgentCore’s long-term memory service creates a more serious and persistent threat variant. Unit 42’s research on persistent memory poisoning demonstrates that an indirect injection payload can be crafted to manipulate the session summarization process, causing the agent to write adversary-controlled instructions into its long-term memory store [3]. Because the agent incorporates long-term memory into the context of every subsequent session, the injected instructions persist across future sessions, are treated as trusted memory rather than untrusted input, and can direct the agent to exfiltrate conversation history or modify behavior in future sessions — all without the attacker maintaining any active access after the initial injection. Zenity Research published a complete attack scenario specific to AgentCore in December 2025, demonstrating the chain from initial memory poisoning through sustained tool abuse. [11]

AgentCore’s Memory service has no documented mechanism for memory integrity verification, anomaly detection on stored memory entries, or differential trust treatment between memory written by the system and memory that resulted from external content processing — a gap that should be reviewed against current AWS documentation as the service evolves [11]. The episodic memory capability added at AWS re:Invent 2025 increases the utility and the attack surface of persistent memory simultaneously [9]. Enterprise deployments using long-term memory should implement review workflows for memory contents, restrict which agent workflows have write access to long-term memory, and treat unexpected memory contents as a potential indicator of compromise. Organizations should also review any configurable memory retention settings, as bounded retention windows may themselves serve as a partial mitigation against persistent memory poisoning.

Multi-Agent Trust Delegation and Lateral Movement

Enterprise deployments of AgentCore increasingly involve orchestrator-subagent architectures in which a top-level agent manages a network of specialized subagents, each with narrower tool access. This architecture offers operational advantages — parallelism, specialization, scalability — but creates lateral movement opportunities that do not exist in single-agent deployments. A compromised or manipulated subagent can craft responses that cause the orchestrator to take actions on its behalf that the subagent could not take directly, effectively using the orchestrator as a proxy for capability escalation. [12]

AgentCore Identity’s support for custom claims in multi-tenant environments partially addresses this by enabling differentiated identity tokens at each tier of an agent hierarchy. However, the security properties of hierarchical trust chains in multi-agent systems remain an active research area, and there is currently no validated threat model for complex agent graphs of the kind that enterprise deployments are beginning to build. The CSA’s Agentic AI Red Teaming Guide addresses orchestration-layer attack surfaces at a framework level and represents the most relevant available reference for teams evaluating multi-agent deployment security. [12, 13]

Supply Chain Risk via MCP Tool Integration

AgentCore Gateway supports integration with remote Model Context Protocol (MCP) servers, which are transformed into agent-compatible tools available for invocation during agent sessions. MCP has matured rapidly as an interoperability standard, but the MCP ecosystem’s security posture has not kept pace with its growth. Security community scanning conducted in early 2026 has identified thousands of publicly accessible MCP servers with no authentication controls, and audits of MCP-compatible marketplaces have documented large volumes of malicious or unauthorized skills. Research into the MCP supply chain has also documented cases in which malicious npm packages impersonated legitimate MCP integration tools, exploiting agents’ dependency resolution to introduce unauthorized functionality into CI/CD pipelines and agent-connected workflows [17]. Penligent’s analysis of agentic AI security in production environments places these findings within a broader pattern of supply chain risk targeting the MCP ecosystem [7].

Enterprise organizations that connect third-party MCP servers to AgentCore Gateway should treat this integration with the same scrutiny applied to third-party software dependencies in traditional software supply chain security programs. This means vetting MCP server provenance, reviewing tool schemas and declared permissions before onboarding, restricting which agent workflows can invoke externally sourced tools, and monitoring tool-invocation telemetry for anomalous patterns. The AgentCore Policy layer can enforce tool-invocation restrictions at the Gateway boundary and represents the appropriate enforcement point for MCP allowlisting.

The Cedar Policy Layer: Capability and Limits

The Cedar-based Policy component, generally available as of March 3, 2026, represents a qualitatively different category of security control from earlier AgentCore additions [5]. Cedar policies intercept all tool invocations at the Gateway boundary before execution, providing a deterministic enforcement layer that is external to the agent’s own code and reasoning. Policy rules can be authored in natural language and are automatically validated against tool schemas; an automated reasoning engine flags overly permissive or contradictory rules prior to deployment. This addresses a class of misconfiguration-driven privilege abuse that traditional IAM alone cannot prevent for agentic workloads.

The policy layer’s limitation is that it enforces boundaries on what tools the agent can call, not what reasoning leads the agent to call them. An adversarially injected instruction that manipulates the agent’s reasoning to invoke a permitted tool for an unintended purpose — exfiltrating data via a search tool, for example, or deleting records via a permitted database write — is not visible to the Cedar policy engine. The policy layer and Guardrails together provide defense-in-depth for distinct threat classes, but neither addresses in-context reasoning manipulation independently. Enterprise teams should not interpret Cedar Policy adoption as a comprehensive mitigation for prompt injection risk.

Recommendations

Immediate Actions

IAM scoping for Code Interpreters should be addressed before any other AgentCore hardening work. Every Code Interpreter execution role should be reviewed against the principle of least privilege with specific attention to which AWS service APIs are reachable from that role. Organizations should implement SCPs restricting bedrock-agentcore:CreateCodeInterpreter and bedrock-agentcore:InvokeCodeInterpreter to authorized agent principals only, and should audit existing IAM policies for overly permissive grants to these actions. AWS-managed policies for AgentCore may grant broader permissions than individual workloads require; organizations should author customer-managed policies scoped to specific workflow needs for any production environment [1, 10].

Organizations running AgentCore in environments where exfiltrated credential abuse would be difficult to detect should enable enhanced CloudTrail data event logging for AgentCore resources. The attribution gap described by Sonrai is a structural limitation of the current platform. Until AWS provides a mechanism for distinguishing attacker-exfiltrated credential usage from legitimate Code Interpreter activity, organizations should combine preventive controls — narrow execution role scoping, SCP restrictions on InvokeCodeInterpreter, and VPC endpoint restrictions [19] — with compensating detective controls built on CloudTrail data event logging that treats Code Interpreter identity as a potential proxy for attacker activity when anomalous API calls are observed. [2]

Short-Term Mitigations

Long-term memory should be treated as a high-value target requiring access controls commensurate with those applied to production databases. Write access to long-term memory stores should be restricted to the specific agent workflows that require it, and read access for memory incorporation into new sessions should be scoped to the owning agent identity. Organizations should implement periodic review of long-term memory contents, with particular attention to entries that result from workflows involving external content retrieval.

For indirect prompt injection specifically, AWS’s recommended pattern of tagging dynamically retrieved content as user input for Guardrails evaluation should be implemented consistently across all AgentCore workflows that process external content [4]. Teams should also adopt the AWS guidance on agent action group configuration to limit which tools are accessible in contexts where high-risk external content is processed.

Cedar Policy rules should be deployed for all production AgentCore Gateway configurations, with explicit allowlists for tool invocations rather than broad implicit permissions. Organizations integrating third-party MCP servers should implement explicit Policy rules restricting MCP tool invocations to known-good, reviewed servers, and should treat the introduction of any new MCP server as a change management event requiring security review.

Strategic Considerations

The execution boundary problem is architecturally inherent to any platform that combines LLM orchestration with real-world tool invocation; enterprise security teams should not assume that alternative cloud AI platforms are exempt from the structural issues described here. Enterprise security teams building agentic AI capabilities should treat the execution boundary as a first-class security domain requiring dedicated threat modeling, distinct from both traditional application security and data science risk management. The CSA Agentic AI Red Teaming Guide provides a structured methodology for this threat modeling that can be adapted to AgentCore-specific deployments. [13]

Organizations should architect agent identity hierarchies with the assumption that any agent in a multi-agent graph may be compromised, and design delegated permissions accordingly. The principle of least privilege applies at each hop of an agent delegation chain, not only at the top-level orchestrator. Trust should not be implicit in the orchestrator-subagent relationship; responses from subagents should be treated as potentially adversarial inputs to the orchestrator’s reasoning.

As AgentCore continues to mature, organizations should monitor AWS announcements for resource-based policy support for Code Interpreter resources, memory integrity features, and enhanced CloudTrail attribution capabilities. Each of these would address a documented gap between the platform’s current security model and the threat landscape it faces.

CSA Resource Alignment

This research note connects directly to several active CSA frameworks and publications. The CSA MAESTRO (Model for AI Security Threat and Risk in Orchestration) framework provides the foundational threat taxonomy for the execution boundary and multi-agent trust delegation issues described above, mapping the agent-to-tool interface and the inter-agent communication surface as distinct threat layers. Enterprise teams should use MAESTRO to structure their AgentCore threat models, particularly for multi-agent deployment topologies.

The CSA AI Controls Matrix (AICM) provides control mappings for AI system deployments that apply to Code Interpreter IAM scoping, memory access controls, and Gateway policy enforcement. Specifically, controls in the AI Deployment and Runtime categories address the lifecycle management requirements for agentic workloads that the scenarios described in this note make concrete. [14]

The CSA Agentic AI Red Teaming Guide (2025), authored under the AI Organizational Responsibilities Working Group, provides procedural testing methodology for the attack surfaces discussed in this note, including prompt injection across all four agent surfaces, multi-agent lateral movement, and tool misuse scenarios. Organizations preparing to run red team exercises against AgentCore deployments should treat this guide as the primary CSA reference. [13]

The CSA AI Organizational Responsibilities: Core Security Responsibilities publication establishes the organizational ownership framework for AI system security, including the delineation between cloud provider responsibility and customer responsibility in shared-responsibility AI platforms. The AWS determination that MMDS credential exfiltration falls within expected customer-configured behavior rather than platform responsibility is exactly the kind of boundary question that this CSA framework is designed to help organizations evaluate and plan around. [15]

The CSA Zero Trust guidance, particularly on shadow access risks in AI deployments, applies directly to the multi-agent delegation scenarios described above, where implicit trust between orchestrators and subagents replicates the lateral movement risks that zero trust network architectures were designed to prevent. [16]

References

[1] Sonrai Security, “AWS AgentCore: The Overlooked Privilege Escalation Path,” Sonrai Security Blog, July 2025. https://sonraisecurity.com/blog/aws-agentcore-privilege-escalation-bedrock-scp-fix/

[2] Sonrai Security, “Sandboxed to Compromised: New Research Exposes Credential Exfiltration Paths in AWS Code Interpreters,” Sonrai Security Blog, September 2025. https://sonraisecurity.com/blog/sandboxed-to-compromised-new-research-exposes-credential-exfiltration-paths-in-aws-code-interpreters/

[3] Palo Alto Networks Unit 42, “When AI Remembers Too Much – Indirect Prompt Injection Poisons AI Long-Term Memory,” Unit 42 Threat Research, October 2025. https://unit42.paloaltonetworks.com/indirect-prompt-injection-poisons-ai-longterm-memory/

[4] AWS Machine Learning Blog, “Securing Amazon Bedrock Agents: A Guide to Safeguarding Against Indirect Prompt Injections,” Amazon Web Services, 2025. https://aws.amazon.com/blogs/machine-learning/securing-amazon-bedrock-agents-a-guide-to-safeguarding-against-indirect-prompt-injections/

[5] AWS What’s New, “Policy in Amazon Bedrock AgentCore is Now Generally Available,” Amazon Web Services, March 3, 2026. https://aws.amazon.com/about-aws/whats-new/2026/03/policy-amazon-bedrock-agentcore-generally-available/

[6] AWS Developer Guide, “Policy in Amazon Bedrock AgentCore,” Amazon Web Services, 2026. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/policy.html

[7] Penligent, “Agentic AI Security in Production: MCP Security, Memory Poisoning, Tool Misuse and the New Execution Boundary,” Penligent Security Research, March 2026. https://www.penligent.ai/hackinglabs/agentic-ai-security-in-production-mcp-security-memory-poisoning-tool-misuse-and-the-new-execution-boundary/

[8] AWS News Blog, “Introducing Amazon Bedrock AgentCore: Securely Deploy and Operate AI Agents at Any Scale,” Amazon Web Services, July 2025. https://aws.amazon.com/blogs/aws/introducing-amazon-bedrock-agentcore-securely-deploy-and-operate-ai-agents-at-any-scale/

[9] AWS News Blog, “Amazon Bedrock AgentCore Adds Quality Evaluations and Policy Controls for Deploying Trusted AI Agents,” Amazon Web Services, December 2025. https://aws.amazon.com/blogs/aws/amazon-bedrock-agentcore-adds-quality-evaluations-and-policy-controls-for-deploying-trusted-ai-agents/

[10] Software Secured, “AWS Privilege Escalation: IAM Risks and New AgentCore Vectors,” Software Secured Research Blog, 2025. https://www.softwaresecured.com/post/aws-privilege-escalation-iam-risks-service-based-attacks-and-new-ai-driven-bedrock-agentcore-vectors

[11] Zenity Research, “Inside the Agent Stack: Securing Agents in Amazon Bedrock AgentCore,” Zenity Security Research, December 2025. https://zenity.io/blog/research/inside-the-agent-stack-securing-agents-in-amazon-bedrock-agentcore

[12] AWS Security Blog, “Securing AI Agents with Amazon Bedrock AgentCore Identity,” Amazon Web Services, 2025. https://aws.amazon.com/blogs/security/securing-ai-agents-with-amazon-bedrock-agentcore-identity/

[13] Cloud Security Alliance, “Agentic AI Red Teaming Guide,” AI Organizational Responsibilities Working Group, 2025. https://cloudsecurityalliance.org/artifacts/agentic-ai-red-teaming-guide

[14] Cloud Security Alliance, “AI Controls Matrix (AICM),” AI Controls Framework Working Group, 2024. https://cloudsecurityalliance.org/research/working-groups/ai-controls

[15] Cloud Security Alliance, “AI Organizational Responsibilities: Core Security Responsibilities,” AI Organizational Responsibilities Working Group, 2024. https://cloudsecurityalliance.org/artifacts/ai-organizational-responsibilities-core-security-responsibilities

[16] Cloud Security Alliance, “Confronting Shadow Access Risks: Considerations for Zero Trust and Artificial Intelligence Deployments,” CSA, 2024. https://cloudsecurityalliance.org/artifacts/confronting-shadow-access-risks-considerations-for-zero-trust-and-artificial-intelligence-deployments

[17] Penligent, “AI Agents Hacking in 2026: Defending the New Execution Boundary,” Penligent Security Research, February 2026. https://www.penligent.ai/hackinglabs/ai-agents-hacking-in-2026-defending-the-new-execution-boundary/

[18] Palo Alto Networks Unit 42, “Fooling AI Agents: Web-Based Indirect Prompt Injection Observed in the Wild,” Unit 42 Threat Research, March 2026. https://unit42.paloaltonetworks.com/ai-agent-prompt-injection/

[19] AWS Developer Guide, “VPC Configuration for Amazon Bedrock AgentCore,” Amazon Web Services, 2025. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/agentcore-vpc.html

[20] AWS Machine Learning Blog, “Introducing the Amazon Bedrock AgentCore Code Interpreter,” Amazon Web Services, 2025. https://aws.amazon.com/blogs/machine-learning/introducing-the-amazon-bedrock-agentcore-code-interpreter/