Sandboxed code interpreters expose runtime credential risk in AWS

At a glance

What this is: This is an analysis of how sandboxed AWS code interpreters can still leak execution-role credentials at runtime, even without external network access.

Why it matters: It matters because IAM and PAM teams must treat interpreter sandboxing as an isolation control, not a privilege boundary, when runtime credentials remain accessible.

Context

Sandboxing is meant to constrain where code can reach, but it does not automatically constrain what credentials the runtime can expose. In AWS code interpreter environments, that distinction matters because the execution role may still be reachable through local metadata services even when public network access is blocked.

For identity teams, the governance problem is familiar: the control plane assumes the runtime can be trusted to use its privileges only inside the intended boundary. Once credentials can be extracted from the execution environment, the trust boundary shifts from network isolation to identity containment.

This is primarily an NHI governance issue because the exposed subject is a machine execution role, not a human session. The article’s core lesson is that runtime access design, privilege scope, and off-platform reuse determine exposure, not the sandbox label alone.

Key questions

Q: What breaks when sandboxed code interpreters can still access execution-role credentials?

A: Sandboxing breaks as a security boundary when the interpreter can still reach its own runtime credentials. The attacker no longer needs outbound network access to create impact. Once the role session is exposed, it can be reused outside the sandbox, so the real failure is excessive privilege attached to a reachable workload identity.

Q: Why do runtime credentials in code interpreters increase lateral access risk?

A: Because the token can be reused wherever its permissions apply, not only inside the interpreter session that issued it. Once exported, the credential may reach services or roles that the sandbox could not directly call. That turns a local execution identity into a broader access vector, especially when the role is over-privileged.

Q: How should teams know whether code interpreter logging is sufficient?

A: Logging is sufficient only if it lets defenders tie interpreter creation, invocation, and downstream cloud API activity together. If management events show ordinary workload behaviour but there is no invocation telemetry, credential theft can blend into normal use. The signal to watch is whether the same runtime identity appears to do more than its intended task scope.

Q: What should security teams do when AWS code interpreters are required?

A: They should limit access to the smallest set of approved workloads, constrain the execution role to task-specific actions, and route repeatable cloud operations through controlled functions rather than direct interpreter privilege. The goal is to reduce the value of any credential that can be extracted from the runtime and reused elsewhere.

Technical breakdown

Why sandbox network isolation does not hide execution-role credentials

Sandbox mode limits outbound connectivity, but it does not inherently remove access to local identity services that the runtime can reach. In Firecracker-based environments, a metadata endpoint can still expose temporary role credentials if the service is enabled and accessible. That means the sandbox can block direct control-plane calls while still leaving the credential source intact. The security boundary is therefore narrower than many teams assume: the interpreter is isolated from the internet, not necessarily from its own identity substrate.

Practical implication: Treat sandboxing as network containment, not credential containment, and verify whether the runtime can still query metadata services.

How MMDS-style credential exposure becomes a privilege problem

The MicroVM Metadata Service behaves like other metadata services that hand a workload its own credentials at runtime. If an attacker can read those credentials, they can export them and use them outside the interpreter boundary, where the original network restrictions no longer apply. This is classic NHI abuse: the identity is not stolen from a vault, it is harvested from the execution context that was supposed to consume it. The risk is amplified when the role is broad enough to perform actions that the interpreter itself could not directly reach.

Practical implication: Scope execution roles so stolen session tokens have little value outside the runtime that issued them.

Why observability weakens after credential extraction

Once credentials are exfiltrated, downstream API calls often look like legitimate activity from the interpreter’s identity because the session token is still valid. That creates attribution blur: the actor and the credential source no longer line up cleanly in logs. If invocations are not logged at the interpreter layer, defenders may only see ordinary management events performed by a trusted runtime identity. The detection problem is not just exfiltration, but the reuse path that makes malicious actions resemble expected workload behaviour.

Practical implication: Correlate interpreter invocation logs with downstream cloud API activity so credential reuse does not disappear into normal workload telemetry.

Threat narrative

Attacker objective: The attacker wants reusable AWS role credentials that extend interpreter access into broader control-plane actions outside the sandbox boundary.

1. Entry occurs when a user can invoke a sandboxed AWS code interpreter that still has an execution role attached to it.
2. Credential access follows when the interpreter queries the MicroVM Metadata Service and retrieves temporary role session credentials from the runtime.
3. Escalation happens when those credentials are exported outside the interpreter and used against AWS services that the sandbox itself could not directly reach.
4. Impact is reached when the reused session token enables broader cloud control-plane actions and potential pivoting into additional roles or resources.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.

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

Sandboxing is not a privilege boundary when the runtime still owns the credential source: The governance assumption behind many code-interpreter designs is that network isolation meaningfully contains what the runtime can do. That assumption fails when the interpreter can still read its own execution-role credentials from a local metadata service. The implication is that runtime identity, not just network reachability, must be treated as the real control boundary.

Runtime credential reuse creates identity blast radius: A session token harvested from an interpreter is not limited to the interpreter’s visible network path once it is extracted. It can be reused wherever the underlying permissions allow, which turns a constrained execution context into an off-platform access channel. Practitioners should recognise this as identity amplification, not merely sandbox escape.

Access review processes assume privilege survives long enough to be reviewed: Autonomous or runtime-mediated access patterns break that assumption when credentials can be issued, used, and exported within one execution cycle. In this case, the problem is not standing privilege alone but ephemeral privilege with reusable transport. Teams need to rethink what they certify when the identity is created for a task and then detached from it.

Cloud PAM for interpreters must focus on issuance path control, not just session containment: When a code interpreter can obtain its own role credentials at runtime, the high-value question is who can invoke it, what role it receives, and whether those privileges are meaningful outside the intended task. That is a lifecycle and authorisation problem, not a sandboxing problem. Practitioners should align the execution role model with the actual authority the runtime can export.

Ephemeral credential trust debt: The article exposes a growing gap between temporary credentials and temporary trust. Even short-lived session credentials become durable risk when they can be extracted and reused beyond the original execution environment. Practitioners should treat that gap as a governance debt that accumulates whenever runtime identity is more powerful than the boundary that hosts it.

From our research library:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• 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

Ephemeral credential trust debt: Temporary credentials are not low-risk credentials when the runtime can export them beyond the sandbox. That is the real control failure exposed here, and it shifts governance from network containment to issuance-path control.

Code interpreters sit at the intersection of NHI governance and cloud PAM. If the interpreter can read its own role session from a metadata service, then least privilege has to be evaluated on the credential’s reuse value, not just on the actions visible inside the session.

For practitioners

• Restrict interpreter invocation to approved agent runtimes Use organisation-wide policy controls to prevent non-agentic identities from creating or invoking code interpreters except where a workload is explicitly approved to use them.
• Re-scope execution roles for export risk Assume any credential exposed to the runtime can be reused outside the sandbox and keep the role limited to the smallest feasible cloud actions.
• Shift sensitive cloud operations into parameterised functions When an agent needs repeatable AWS access, move those operations into parameterised Lambda functions behind gateways so the interpreter never receives broad direct control-plane privilege.
• Enable interpreter-level and data-event logging Capture both creation and invocation events for code interpreters so credential theft attempts and suspicious reuse patterns can be correlated with downstream API activity.
• Block metadata-service abuse paths where possible Review whether local metadata access is exposed to the runtime and remove unnecessary paths that let the interpreter read its own temporary credentials.

Key takeaways

• Sandboxed code interpreters can still leak runtime credentials, so isolation alone does not prove that privilege is contained.
• The article shows that temporary role session tokens can be extracted from the interpreter and reused outside the original execution boundary.
• The practical control point is the execution role and its invocation path, not the sandbox label by itself.

Key terms

• 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.
• MicroVM Metadata Service: A local metadata endpoint that supplies a micro virtual machine with identity and environment information, including temporary credentials when enabled. For sandboxed runtimes, access to this service can become a credential exposure path if the workload can read its own session tokens.
• Sandboxed Isolation: Sandboxed isolation is the practice of containing execution in a restricted environment that limits network access, data reach, and resource usage. For AI agents, it reduces blast radius by preventing a model or script from freely touching systems outside its approved scope.
• Credential Reuse: Credential reuse happens when the same password, token, or secret can unlock multiple systems or sessions. It increases breach impact because one stolen credential can become a wide-ranging access path. The control problem is not only theft, but the amount of trust packed into each reusable secret.

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.