TL;DR: AWS Bedrock AgentCore Code Interpreters can be invoked with IAM permissions and, when custom interpreters carry privileged execution roles, that access can be used to pivot into those roles and perform control plane actions, according to Sonrai Security. Existing cloud IAM patterns do not yet control this AI-centric privilege path cleanly, so organisational-level guardrails matter now.
At a glance
What this is: This is an analysis of how AWS Bedrock AgentCore Code Interpreters can become a privilege escalation path when invocation access and execution roles are not tightly separated.
Why it matters: It matters because IAM teams may be granting tool invocation while underestimating that the tool itself can execute privileged actions on behalf of the caller, expanding blast radius for AI workloads.
Context
AWS AgentCore code interpreters expose a cloud IAM problem that sits between tool access and role authority. When a caller can invoke an interpreter that runs code in the context of a privileged execution role, the tool boundary becomes an authorisation boundary.
The issue is not generic automation risk. It is the mismatch between existing IAM patterns, which were built for stable principals and explicit resource access, and AI tooling that can turn code execution into role-enabled control plane action.
For IAM, PAM, and cloud security teams, the key question is who can invoke the interpreter, which role the interpreter runs under, and whether that combination lets the caller act beyond their intended scope.
Key questions
Q: What breaks when a code interpreter can run with a privileged AWS role?
A: The separation between tool use and authority breaks down. A caller may only be authorised to invoke the interpreter, but if that interpreter runs with a powerful execution role, the caller can cause actions that would otherwise be denied. The failure is not code execution alone. It is code execution inside an identity context with broader AWS permissions than the caller should hold.
Q: Why do privileged AI tools create a different risk than ordinary cloud automation?
A: Because the tool can become the acting principal for the session, not just the mechanism that carries out a fixed workflow. Ordinary automation usually has a known path and bounded permissions. A code interpreter that accepts arbitrary code and executes under a configured role can turn those permissions into a pivot point, especially when the runtime is reachable through IAM.
Q: How should teams detect misuse of privileged AI tool sessions?
A: Monitor both invocation and creation activity for code interpreters, and correlate those events with role assignment and sensitive resource access. If `InvokeCodeInterpreter` is not logged as a data event, use that gap as a signal that the control surface is incomplete. Detection should focus on who can start the tool, which role it uses, and what AWS actions follow.
Q: Who should control access to custom code interpreters in AWS?
A: Platform or org security teams should control access centrally when interpreter permissions can reach sensitive roles or data. The practical reason is that local application teams may not have resource-policy support to express the needed restriction. In that case, the governance model must move up to SCPs and shared audit coverage, because the blast radius is organisational, not project-specific.
Technical breakdown
How AgentCore invocation becomes an authorisation boundary
AgentCore Code Interpreters are separate resources that can be started and invoked with IAM permissions such as `bedrock-agentcore:InvokeCodeInterpreter`. That means the security decision is not only whether a person or workload can use the agent runtime, but whether it can reach the interpreter itself. If the interpreter accepts arbitrary code and runs with a configured execution role, the interpreter inherits the permissions of that role for the duration of the session. In practical terms, the access check happens before code runs, but the impact occurs inside the interpreter’s role context.
Practical implication: Treat interpreter invocation as privileged access, not as routine tool use.
Why custom execution roles create a role pivot path
The escalation path emerges when a custom code interpreter is assigned a role that can access sensitive AWS resources. A caller with permission to invoke that interpreter can supply code that performs control plane actions in the interpreter’s identity context, effectively borrowing the role’s authority for the task. Public mode broadens this exposure because the tool can act against AWS services more directly, while Sandbox mode reduces but does not eliminate AWS reach. The architectural problem is that the code runner is not just a sandbox; it is an identity-bearing execution surface.
Practical implication: Separate interpreter permissions from the permissions needed by the interpreter’s execution role.
Why monitoring and policy controls are harder than they should be
Sonrai Security notes two control gaps. First, resource policies are not available for AgentCore resources, so fine-grained resource-level denial is missing. Second, CloudTrail does not log Code Interpreter data events by default, which means invocation evidence is absent unless teams explicitly enable it and accept the storage cost. That pushes enforcement toward organization-wide Service Control Policies, which are harder for developers to manage locally. The result is that the most effective controls sit above the resource level and outside normal application-team workflows.
Practical implication: Use org-level guardrails and explicit logging coverage to close the visibility gap around interpreter use.
Threat narrative
Attacker objective: Use interpreter invocation to pivot into a higher-privilege AWS role and act with that role’s permissions.
- Entry occurs when an identity with `bedrock-agentcore:InvokeCodeInterpreter` reaches a custom code interpreter that is bound to a privileged execution role.
- Credential access is not the issue here; the problem is role inheritance, because the interpreter executes supplied code in the context of the assigned AWS role.
- Escalation follows when that code performs control plane or permitted S3 actions beyond what the original invoker should have been able to do directly.
- Impact is unauthorized use of the interpreter’s execution role, including access to sensitive AWS resources and unintended control plane actions.
Breaches seen in the wild
- Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Code interpreters are becoming identity-bearing control surfaces: The security boundary is no longer just the runtime that hosts the agent, but the tool that executes code on its behalf. When that tool carries a privileged execution role, IAM policy is silently being asked to govern both invocation and authority at once. Practitioners should treat agent tools as first-class principals in access design.
Existing cloud IAM assumptions do not map cleanly onto agentic tool use: Traditional IAM assumes a caller requests a resource and the resource responds within a known permission boundary. AgentCore breaks that model because the tool can execute arbitrary actions in the context of a configured role. The implication is that least privilege must be expressed for the tool’s authority, not only for the caller’s identity.
Interpreter invocation without resource-level policy creates centralised blast radius: Without resource policies on the interpreter itself, control shifts upward to SCPs and logging discipline. That is a governance burden, not merely a configuration inconvenience, because it moves enforcement away from the team closest to the tool. Security teams should recognise this as a platform-level privilege aggregation problem, not an isolated application issue.
CloudTrail blind spots turn approval into speculation: If interpreter data events are not logged by default, then unauthorized use can exist without an evidentiary trail. This is a classic identity governance failure mode in a new form: the organisation cannot confidently prove who invoked what, under which role, and for what outcome. The practitioner takeaway is that controls without default auditability are not sufficient for privileged agent tooling.
Privilege path governance now needs a named concept: tool-to-role escalation: This article exposes a pattern where the act of using an AI tool becomes the path into a different AWS role. That is not just overprivilege, it is a distinct escalation route created by the coupling of interpreter execution and IAM role assignment. Teams should catalogue it separately in their cloud identity risk model.
From our research library:
- 91% of organisations say at least half of their privileged access is always-on, and only 1% have fully implemented just-in-time privileged access, according to a CyberArk study.
- Read next: AI Agent Authorisation Guide
What this signals
Tool-to-role escalation is now an identity pattern that cloud teams need to name explicitly: The risky unit is not just the interpreter or the role in isolation, but the coupling between invocation permission and execution authority. Once that coupling exists, least privilege must be designed around the tool boundary as well as the human or workload caller.
Existing IAM models work best when the actor’s permissions are static and the resource’s authority is obvious. Agentic code interpreters blur that line, so teams should review where their cloud programme still assumes tool use is harmless compared with direct role possession.
For practitioners
- Classify interpreter access as privileged Treat `bedrock-agentcore:InvokeCodeInterpreter` and related start permissions as high-risk access that requires explicit approval, not broad developer convenience.
- Bind execution roles to the minimum task scope Review every custom interpreter role for the exact AWS actions it can perform, especially control plane actions and sensitive S3 operations.
- Move enforcement to organization-level guardrails Use Service Control Policies to deny unintended invocation of privileged interpreters when resource policies are unavailable.
- Enable and monitor CloudTrail data events Turn on logging for `InvokeCodeInterpreter` and watch for `CreateCodeInterpreter` activity that pairs `iam:PassRole` with privileged execution roles.
Key takeaways
- AWS AgentCore code interpreters can become a privilege escalation path when invocation rights and execution roles are not separated cleanly.
- The article shows that custom interpreters with privileged roles can be used to perform AWS control plane actions beyond the caller’s normal permissions.
- The control gap is governance as much as technology. Teams need org-level denial, logging coverage, and tight role scoping to contain the path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Custom interpreters inherit execution roles that can exceed the caller's intended authority. |
| NHI-04 — Insecure Authentication | Invocation permissions become the gate to a privileged execution surface in this pattern. | |
| Recommendation — Scope interpreter execution roles to the minimum AWS actions required for the task. Restrict who can invoke privileged interpreters and treat that permission as sensitive access. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article centres on controlling and governing the credentials and permissions that enable the role pivot. |
| Recommendation — Manage interpreter-related credentials and role bindings so they cannot be reused beyond their intended scope. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The core issue is entitlement sprawl between invoker and interpreter execution role. |
| Recommendation — Review access permissions for code interpreters and remove unnecessary entitlements that enable escalation. | ||
| MITRE ATT&CK | TA0004;TA0008 — Privilege Escalation; Lateral Movement | The attack path pivots from interpreter access into broader AWS role authority. |
| Recommendation — Map interpreter abuse to privilege escalation and lateral movement detections in your cloud threat model. | ||
Key terms
- Agentic Code Interpreter: A code execution tool that an AI system can call during task completion, often with access to cloud resources or APIs. In this article’s context, the key risk is not the interpreter itself but the identity and permissions attached to it, which can turn tool use into privileged action.
- Execution Role: The IAM role an AI agent assumes to call cloud services on behalf of a workflow. It is the main control point for what the agent can do, so poor scoping turns an ordinary agent into a high-blast-radius identity with access that can outlive the original use case.
- Service Control Policy: An AWS Service Control Policy is an organisation-level guardrail that caps the maximum permissions available to accounts and identities in scope. It does not grant access on its own, but it shapes the outer boundary of what IAM policies can ever allow, which makes it central to org-wide least privilege.
- Tool-to-Role Escalation: A privilege path where the act of using a tool provides access to the permissions of a separate role bound to that tool. This pattern matters in agentic environments because the caller may be allowed to invoke the tool without being allowed to perform the resulting actions directly.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 24, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org