Sandboxed code interpreters expose runtime credential risk in AWS

At a glance

What this is: This is Sonrai Security's analysis of how sandboxed AWS code interpreters can still leak execution-role credentials through metadata access.

Why it matters: It matters because cloud teams may assume sandboxing removes exposure, when the real control question is whether runtime credentials can be reached, reused, and over-privileged across NHI and agentic workflows.

By the numbers:

• 17 minutes.
• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.

👉 Read Sonrai Security's analysis of sandboxed AWS code interpreters and credential exfiltration

Context

Sandboxed execution environments are often treated as a boundary that prevents credential abuse, but that assumption only holds if the runtime cannot reach or expose the identity material it uses to operate. In AWS code interpreters, the relevant question is not just whether internet access is blocked, but whether execution-role credentials remain reachable inside the sandbox.

For identity teams, this is an NHI governance problem first and a cloud isolation problem second. A code interpreter that can read its own role session credentials can still become an access pivot, even when it cannot call external control plane endpoints directly.

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 sandboxed NHIs still create lateral movement risk in cloud environments?

A: Sandboxed NHIs create lateral movement risk when their credentials can be copied and reused in a different context. A temporary token with broad AWS permissions can become a pivot point if the session is exported from the original runtime. The issue is not persistence, but privilege scope and reusability.

Q: How do security teams know if interpreter credentials are actually contained?

A: They know containment is real only if the runtime cannot retrieve or export its own credentials and those credentials cannot be used outside the original execution path. Check metadata exposure, role scope, downstream API activity, and whether invocations are logged well enough to reconstruct who used the interpreter and when.

Q: Who is accountable when a sandboxed workload identity is abused?

A: Accountability sits with the team that defined the runtime identity, the platform team that exposed the credential path, and the governance owner who approved the scope. NIST Zero Trust and OWASP NHI both imply that workload identities need explicit ownership, because containment failures are governance failures as much as technical ones.

Technical breakdown

Why sandbox isolation does not equal credential isolation

Sandbox mode restricts external network reachability, but it does not automatically remove the execution identity assigned to the runtime. In this pattern, the code interpreter still has a role session that can be queried through metadata services or adjacent runtime channels. That means the security boundary is narrower than many teams assume: the sandbox blocks outbound paths, yet the workload identity still exists and can be harvested if exposed by the platform. The architectural mistake is treating network containment as proof of privilege containment.

Practical implication: validate whether runtime identities are reachable from inside the workload, not only whether the workload can reach the public internet.

How metadata services turn runtime identity into a theft target

Metadata services are designed to help workloads discover credentials at runtime, which is useful when the environment is trusted and tightly constrained. In a hostile or misuse scenario, that same mechanism becomes a credential distribution path. If an attacker can execute code inside the interpreter, they may be able to query the metadata endpoint, retrieve temporary role credentials, and reuse them outside the original sandbox. The critical issue is that the credential source is local to the execution environment, so network isolation alone does not stop abuse once code execution is achieved.

Practical implication: treat metadata access as a privileged path and restrict it where the runtime does not genuinely need direct AWS control-plane access.

Why temporary role sessions still create standing privilege risk

Temporary credentials are safer than long-lived keys only when the scope is tightly bounded and the session cannot be repurposed. In this article's pattern, the interpreter's role session can be extracted and then used from elsewhere, which converts a supposedly short-lived runtime grant into reusable privilege. The underlying failure mode is over-broad execution-role design, not credential format. Even short-lived tokens can become standing privilege if the role they represent can do too much once copied out of the original execution context.

Practical implication: design execution roles for minimal blast radius, because session duration does not matter if the privilege scope is already excessive.

Threat narrative

Attacker objective: The attacker wants to convert restricted interpreter access into reusable AWS privilege that can be exercised outside the sandbox.

1. Entry occurs when a non-agentic identity gains code execution inside an AWS code interpreter session with sandboxed network mode.
2. Credential harvesting occurs when the attacker queries the metadata service and extracts the interpreter's temporary execution-role session credentials.
3. Impact occurs when the stolen credentials are reused outside the sandbox to call AWS control plane APIs and pivot into higher privilege.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

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

NHI Mgmt Group analysis

Sandbox isolation is not a credential boundary: The article shows that network containment can fail to protect the identity material attached to a runtime. That matters because cloud security programmes often equate no internet access with no practical exposure. In reality, the execution role remains present inside the sandbox and can still be harvested if metadata paths are reachable. The practitioner conclusion is that runtime identity, not just network placement, must be governed as an attack surface.

Temporary credentials do not solve privilege overreach: Short-lived role sessions are only safe when the session scope is narrowly contained and cannot be repurposed elsewhere. Here, the same credentials usable inside the interpreter can be lifted out and used against AWS APIs outside the interpreter. That makes session duration secondary to entitlement scope. Teams should read this as a blast-radius problem, not a token-format problem.

Runtime credential exfiltration is a control-path failure, not a sandbox failure: The exploited assumption is that a sandbox prevents the actor from reaching the credentials needed to act. That assumption was designed for workloads whose identity stays inside the execution boundary. It fails when the runtime can query its own credentials and export them for later use. The implication is that identity governance must treat execution paths and credential retrieval paths as part of the same control surface.

Cloud control planes still depend on NHI governance discipline: Code interpreters, gateways, and agentic tooling all inherit the same basic machine-identity questions: who can assume what role, from where, and with what blast radius. OWASP-NHI and Zero Trust guidance are relevant here because the failure mode is excessive privilege attached to a non-human execution context. Practitioners should evaluate these runtimes as governed identities, not just as compute objects.

The real boundary is between intended automation and unintended reuse: The article makes clear that a runtime granted a specific task can become a general-purpose access bridge once its credentials leave the original execution context. That is the governance gap. Access review cadences and sandbox labels do not help if the credential can be reused before the review cycle even starts. The practical conclusion is to reclassify these runtimes as privileged identities with explicit lifecycle ownership.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• From our research: DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records including chat histories, backend credentials, and API keys, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• From our research: Read 52 NHI Breaches Analysis for the control failures behind real-world identity abuse patterns and the governance gaps they expose.

What this signals

Runtime identity is now part of the attack surface, not just the workload configuration. Sonrai Security's finding shows that teams need to watch for whether an execution role can be discovered, exported, and reused, because sandbox labels alone do not contain the privilege. With 67% of organisations still relying heavily on static credentials despite the risks they pose to agentic AI deployments, the governance pattern is already behind the threat model.

The next control question is whether cloud teams can prove that a runtime identity cannot outlive or outgrow the task it was created for. That means tying interpreter access to explicit owners, logging the credential path, and treating metadata exposure as a policy issue rather than an infrastructure quirk.

Ephemeral privilege debt: credentials that are temporary in form but reusable in practice create a hidden governance liability. The programme signal is simple: if the identity can be copied out, the privilege was never fully contained.

For practitioners

• Inventory every runtime that can expose execution-role credentials Map all code interpreters, agent runtimes, and sandboxed workloads that can reach metadata services or similar credential sources. Record the exact role attached to each runtime, the services it can call, and whether the credentials can be reused outside the original execution context.
• Reduce execution roles to task-scoped minimums Remove broad AWS permissions from any role that can be retrieved from a sandboxed interpreter. If a runtime only needs repeatable operations, move those operations into a tightly parameterized Lambda or gateway pattern so the interpreter never receives direct control-plane privilege.
• Restrict who can invoke interpreters at all Use org-level controls to limit interpreter creation and invocation to the identities that genuinely require them. Where possible, block non-agentic identities from using interpreter resources and make the allowed callers explicit in policy.
• Monitor metadata access and interpreter invocations together Correlate interpreter invocation logs with access to credential endpoints and downstream AWS management events. Enable the data events needed to see who called which interpreter, because default logging may not capture the credential extraction step.

Key takeaways

• Sandboxed code interpreters can still expose the execution identity they rely on, which makes credential containment the real control problem.
• Temporary role sessions do not eliminate risk when their permissions are broad enough to be reused outside the original runtime.
• Teams should narrow execution roles, restrict interpreter invocation, and monitor metadata access as part of one identity control plane.

Key terms

• Execution Role: An execution role is the identity a workload assumes to perform its allowed actions in a cloud environment. In this case, it matters because the role can be more valuable than the sandbox around it if the credentials are reachable and reusable outside the intended runtime.
• Metadata Service: A metadata service is a local endpoint that provides runtime details and temporary credentials to cloud workloads. It is convenient for automation, but it becomes a theft path when an attacker can run code inside the workload and retrieve identity material directly.
• Runtime Identity: Runtime identity is the machine or workload identity active while code is executing. It is distinct from the host, the user, or the application because it can be granted privileges that persist for the life of a session and then be abused if that session is exported.
• Blast Radius: Blast radius is the amount of damage an identity can cause if it is misused or stolen. For workload identities, the size of the blast radius depends less on session length and more on the services, actions, and resources the role is allowed to reach.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Sonrai Security: Sandboxed to Compromised: New Research Exposes Credential Exfiltration Paths in AWS Code Interpreters. Read the original.