AWS AgentCore code interpreters expose an AI role escalation path

At a glance

What this is: This is an analysis of how AWS Bedrock AgentCore Code Interpreters can become a privilege escalation path when agent tools inherit powerful execution roles.

Why it matters: It matters because IAM teams must govern AI-centric identities and tool execution paths with the same discipline they already apply to privileged workload and service identities.

By the numbers:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.

👉 Read Sonrai Security's analysis of AWS AgentCore privilege escalation

Context

AWS AgentCore code interpreters sit in the growing gap between AI orchestration and identity governance. The core problem is not that the interpreter can run code, but that the code runs under an execution role that may be broader than the task requires.

For IAM and cloud security teams, this is a familiar least-privilege problem with a new actor type. Once a tool can be invoked directly and can act on behalf of a privileged role, access control, logging, and organizational policy all need to treat that tool as part of the identity surface.

The article argues that existing cloud controls are awkward here because the resource itself has no resource policy support and default logging is incomplete. That makes this a practical governance problem, not just a theoretical agentic AI concern.

Key questions

Q: How should security teams govern AI tools that can act with privileged cloud roles?

A: Security teams should govern AI tools as privileged identity paths, not as harmless application components. That means binding each tool to a task-scoped execution role, tightly controlling who can invoke it, and logging invocation activity as a high-risk event. If a tool can execute actions in a role’s context, it belongs in IAM and PAM review cycles.

Q: When does an AI code interpreter become a privilege escalation risk?

A: An AI code interpreter becomes a privilege escalation risk when callers can reach it directly and the interpreter runs with permissions broader than the caller should have. At that point, the tool can proxy privileged actions on behalf of the invoker. The risk is not the code itself, but the combination of invocation access and over-privileged execution context.

Q: What do security teams get wrong about AI tool sandboxing in cloud environments?

A: Teams often assume that sandboxing alone prevents privilege abuse, but sandboxing does not remove the interpreter’s execution role or the permissions attached to it. If the tool can still reach cloud services through that role, the sandbox limits environment shape, not identity abuse. Governance must focus on invocation rights, execution scope, and auditability.

Q: Who is accountable when a privileged AI tool is invoked outside its intended scope?

A: Accountability sits with the teams that own IAM policy, platform guardrails, and the tool’s execution role, because those controls determine whether the invocation path exists. If logging is not enabled or resource-level controls are unavailable, the governance gap becomes organizational, not just technical. Frameworks such as Zero Trust and privileged access governance should cover the tool path itself.

Technical breakdown

How AgentCore code interpreter permissions create a privilege path

AgentCore Code Interpreters are invoked through IAM permissions such as bedrock-agentcore:InvokeCodeInterpreter, which means the interpreter itself becomes an addressable privileged resource. The article shows that invocation can happen through an agent runtime role or directly through the AWS control plane, so the interpreter is not just a private agent helper. If the interpreter runs with a custom execution role, the caller can instruct it to execute actions in that role’s security context. That changes the trust boundary from the agent to the tool execution environment.

Practical implication: treat invoke permissions on code interpreters as privileged access and scope them as tightly as you would a role assumption path.

Why custom execution roles widen the blast radius

The risk increases when a custom code interpreter is bound to an execution role with access to S3, STS, or other control plane actions. In that setup, the tool no longer only helps the agent compute, it can also act as a proxy for the role’s privileges. The article’s key point is that anyone who can invoke the interpreter can potentially cause those role permissions to be exercised on their behalf. That is a classic identity escalation pattern, even if it is packaged as an AI tool.

Practical implication: separate low-risk and high-risk tool roles, and do not attach privileged data or control plane permissions to interpreters that broader callers can reach.

Why resource policies and default logging matter here

The article highlights two control gaps. First, Bedrock AgentCore does not support resource policies, so access cannot be governed at the resource boundary in the way many teams expect for sensitive cloud assets. Second, Code Interpreter invocation events are data events and are not logged in CloudTrail by default, so misuse may not be visible unless teams explicitly enable the right logging. That combination creates a blind spot where a privileged tool can be both reachable and under-observed.

Practical implication: use organization-level controls and explicit audit logging for interpreter invocation, because the resource itself does not currently give you enough native control.

Threat narrative

Attacker objective: The attacker wants to pivot from interpreter invocation into the privileges of the interpreter’s execution role and use that access to reach sensitive cloud resources or control plane actions.

1. Entry occurs when a caller gains the ability to invoke a Bedrock AgentCore Code Interpreter through IAM permissions or an agent runtime role. Escalation begins when that interpreter is attached to a custom execution role with broader access than the caller should have.
2. Impact follows when the caller uses the interpreter to execute control plane actions in the context of the privileged execution role, effectively turning a tool invocation into role abuse. The result is unauthorized access to cloud resources and actions that the original caller should not have been able to perform.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI-centric tools become part of the identity plane the moment they can invoke privileged actions. This article shows that a code interpreter is not a neutral runtime helper once IAM permissions and execution roles are involved. The control boundary shifts from the agent to the tool, which means identity governance must cover the tool surface as well as the agent runtime. The practitioner conclusion is simple: if a tool can act with role privilege, it must be governed as privileged identity infrastructure.

Least privilege was designed for stable executors, not for callable tools that can be addressed directly. The governance assumption behind many cloud IAM models is that access is bound to a known workload or service identity with a fixed scope. That assumption weakens when the same tool can be invoked by different callers and then run under a privileged role. The implication is that teams must rethink how privilege is assigned to AI tooling, because the original access model no longer matches the execution model.

Agentic AI widens the classic workload identity problem into a control-plane problem. This is not just a secrets issue or a generic AI safety issue. It is an identity design problem where a tool’s execution context can become a lateral path into cloud permissions. That matters because the business pressure to ship agent workflows often outpaces the security work needed to constrain them. The practitioner conclusion is to align AI tool governance with privileged workload governance, not with experimental sandbox assumptions.

Cloud security teams need to treat interpreter invocation as a privileged event, not a developer convenience. The article makes clear that resource-level controls are missing and that logging is not automatic, so the path from access to misuse can stay too quiet. That means the governance model has to be deliberate, centralized, and reviewable. The practitioner conclusion is that access to agent tools should be approved, logged, and periodically reviewed like any other high-risk identity.

Tool privilege should be designed around the task, not around the machine that hosts the task. A custom code interpreter with broad control-plane access creates unnecessary identity blast radius because the tool can do far more than the workflow actually needs. The better framing for practitioners is not whether the agent is clever enough, but whether the execution role is narrow enough. The practitioner conclusion is to re-evaluate every agent tool through the lens of task-scoped privilege.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
• 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to The 2026 Infrastructure Identity Survey.
• For a broader control lens, review 52 NHI Breaches Analysis for the recurring patterns that turn over-privileged identities into breach paths.

What this signals

Tool-level identity governance is becoming the next control-plane requirement for AI operations. When an agentic tool can execute under a privileged role, the governance question is no longer whether the model is safe enough. The question is whether the platform has turned an AI helper into a privileged identity path that deserves the same scrutiny as workload credentials. Teams should expect these controls to move into cloud policy, IAM review, and platform engineering conversations together.

The pattern here aligns closely with the wider NHI problem: access tends to expand faster than governance catches up. With 70% of organisations already granting AI systems more access than they would give a human employee performing the exact same job, the pressure is not hypothetical. Practitioners should assume that any agent tool introduced without a scoped execution model will accumulate privilege faster than it is reviewed.

Identity blast radius: the real risk is not a single agent action but the spread of permissions behind the tool. Once a code interpreter can touch control plane actions, the platform must track who can invoke it, which role it runs under, and whether the environment can be observed after the fact. That means AI tooling should be folded into privileged access governance, not managed as a separate experiment.

For practitioners

• Inventory every callable AI tool as a privileged identity path Map Bedrock AgentCore Code Interpreters and similar agent tools to the IAM permissions that invoke them, then identify the execution roles they can act under. Treat each tool as an access path, not just a runtime component, and record who can invoke it directly versus through an agent runtime.
• Restrict interpreter execution roles to task-scoped permissions Remove broad control plane and data plane access from custom code interpreters unless the task explicitly requires it. Use separate roles for low-risk and high-risk workflows so that a tool invocation cannot be turned into a general role pivot.
• Enable and monitor CloudTrail data events for interpreter use Turn on logging for InvokeCodeInterpreter and review CreateCodeInterpreter activity so that unauthorized use and risky setup patterns are visible. Pair that monitoring with detection for unexpected role attachment and unusual invocation volume.
• Apply org-level denial controls where resource policies are unavailable Use Service Control Policies to block unintended invocation of privileged code interpreters when the service cannot enforce resource-level access boundaries. Centralize this control so developers cannot create a privileged interpreter that escapes local review.

Key takeaways

• AgentCore code interpreters create a privilege escalation path when invocation access and execution roles are broader than the task requires.
• The evidence point is structural, not isolated: direct invocation of privileged AI tools can turn a helper function into a role abuse channel.
• Practitioners should centralize control, narrow execution scope, and audit interpreter use as privileged identity activity.

Key terms

• Code Interpreter: A code interpreter is a runtime that executes supplied code in a managed environment. In an agentic cloud context, it becomes an identity-bound tool because the code runs under a specific execution role, so access control and monitoring matter as much as the code itself.
• Execution Role: An execution role is the IAM role under which a workload or tool performs actions. For AI tooling, it defines the real security boundary because any action the tool takes is limited or expanded by that role’s permissions, not by the caller’s intent.
• Privilege Escalation Path: A privilege escalation path is any route that lets a caller reach permissions they should not have. In agentic systems, that path can appear when a tool invocation is allowed to act under a more powerful identity than the invoker should control.
• Service Control Policy: A Service Control Policy is an organization-level AWS guardrail that limits what identities can do across accounts. It is especially relevant when a service lacks resource policies, because it can block dangerous invocations centrally even when local resource controls are missing.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance in your organisation, it is worth exploring.

This post draws on content published by Sonrai Security: AWS AgentCore, the overlooked privilege escalation path in Bedrock's AI tooling. Read the original.