Topic starter
06/01/2026 4:33 pm
TL;DR: Sandboxed Amazon Bedrock AgentCore code interpreters can still expose execution-role credentials through the MicroVM Metadata Service, allowing non-agentic identities to exfiltrate role session tokens and reuse them outside the interpreter, according to Sonrai Security. The finding reinforces that network isolation alone does not remove privilege abuse risk when runtime credentials remain accessible.
Editorial analysis by NHI Mgmt Group, based on content published by Sonrai Security: “Sandboxed to Compromised: New Research Exposes Credential Exfiltration Paths in AWS Code Interpreters”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Sandboxed code interpreters can still leak runtime credentials, so isolation alone does not prove that privilege is contained.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
11/10/2026 3:57 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Sandboxed code interpreters expose runtime credential risk in AWS