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.
Why runtime credentials become a lateral access problem
Runtime credentials are dangerous in code interpreters because they are usually valid outside the interpreter boundary. The interpreter may be isolated from the wider environment, but the credential is not: if it can be copied, the permissions travel with it. That means a single local execution path can become a bridge into storage, APIs, or administrative functions the sandbox was never meant to reach.
The core issue is authority reuse. A token, key, or session secret does not remember where it was issued, only what it is allowed to do. If the runtime can export it through logs, environment variables, files, or outbound calls, the credential can be replayed elsewhere until it expires or is revoked. For teams managing secrets, the practical problem is identical to the one described in Secrets Management Guide: once a secret leaves the intended boundary, containment depends on scope, lifetime, and revocation speed.
In practice, this is why code interpreter sessions are not just computation environments. They can become credential handling environments, and that changes the trust model. A runtime credential may have broad API reach, inherited group permissions, or access to resources unrelated to the task the interpreter was asked to perform. If the interpreter can call one service and then leak the credential to another context, the result is lateral access rather than simple session abuse.
Where the lateral movement path opens up
The risk increases when the same credential can access multiple systems, especially when those systems are not equally constrained by network segmentation or application guards. An interpreter that was supposed to read a file, call a model, or transform data may end up with a credential that can write objects, list buckets, start jobs, or query internal endpoints. That is why overbroad runtime permissions are so often the real issue, not the interpreter itself.
Short-lived credentials reduce exposure, but they do not eliminate the problem if they are exported before expiry. The most useful control distinction is whether the credential is bound to the interpreter context or can be reused elsewhere. Guidance on this boundary is explored in Guide to NHI Rotation Challenges and in Ultimate Guide to NHIs, Static vs Dynamic Secrets, both of which show why rotation alone is weaker than preventing reuse across contexts.
Runtime credentials also create risk when they are shared across environments or roles. If the same secret works in dev, staging, and production, or if one token can touch several services, an attacker or accidental script can move far beyond the original task. For that reason, the key question is not simply whether the credential is present in the interpreter, but whether its audience and blast radius were narrowed enough to make reuse unhelpful.
What good control looks like for interpreter-issued credentials
Good control starts with limiting what the runtime receives in the first place. If the task can be completed with a narrow, audience-restricted token, use that rather than a broad session credential. Where possible, the credential should be bound to the specific service, operation, or resource set the interpreter needs, and it should expire quickly enough that extraction has limited value. External standards such as RFC 8707: Resource Indicators for OAuth 2.0 and RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens reinforce the same principle: token usefulness should be constrained to the intended audience and client.
It also helps to treat the interpreter as an execution zone with explicit secret hygiene rules. Do not inject credentials that the task does not need, and do not assume a sandbox prevents exfiltration on its own. Containers and isolated runtimes reduce some exposure paths, but they do not remove the need to scope, bind, and revoke credentials carefully, as reflected in NIST SP 800-190 Container Security. A protected runtime is still only one layer in the control stack.
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 OWASP API Security Top 10 address the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | Runtime tokens that can be reused outside the interpreter create the exact long-lived secret risk. |
| NHI-05 — Overprivileged NHI | Interpreter credentials become a lateral risk when they carry broader access than the task needs. | |
| NHI-02 — Secret Leakage | The question centers on exported runtime credentials that can escape the sandbox boundary. | |
| Recommendation — Shorten credential lifetime and revoke any secret that can outlive the interpreter session. Reduce scope and entitlements so runtime credentials cannot reach unrelated services or roles. Prevent secret export paths and monitor for leakage from interpreter logs, files, and outputs. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifetime, rotation, and revocation are central when runtime secrets can be reused elsewhere. |
| AC-6 — Least Privilege | Lateral access risk is materially driven by excessive permissions on interpreter credentials. | |
| IA-9 — Service Identification and Authentication | Interpreter-issued machine credentials are a service authentication problem, not a human login problem. | |
| Recommendation — Manage runtime authenticators with short lifetimes, rotation, and prompt revocation. Limit interpreter credentials to the minimum permissions needed for the task. Bind non-human credentials to the intended service context and restrict reuse. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Replayed runtime tokens can authenticate outside the intended interpreter context. |
| API5 — Broken Function Level Authorization | A reused runtime credential can reach functions the interpreter should not invoke. | |
| Recommendation — Harden token issuance and reject credentials that can be replayed from unintended contexts. Enforce function-level authorization so exported credentials cannot invoke broader operations. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The issue is fundamentally about constraining where runtime credentials can be used. |
| Recommendation — Apply access control rules that narrow interpreter credential reach to approved resources. | ||
Practitioner Guidance
What to verify: Check whether the interpreter-issued credential can be replayed outside the session, whether it is audience-bound, and whether it grants more than the task actually needs. If the answer to any of those is yes, treat it as a lateral access vector, not a harmless runtime convenience.
Decision rule: If a credential would still be valid after export, assume the sandbox is not the real boundary. Prefer credentials that are narrow in scope, short in lifetime, and unusable from unrelated services or roles.
What good looks like: The interpreter can complete its job without receiving a broadly reusable secret, and any credential it does receive has limited blast radius if copied, logged, or leaked.
Practitioner takeaway: Runtime credentials are risky not because they exist in code interpreters, but because they often inherit real authority that outlives the session and can be reused wherever the permissions still apply.
Related resources from NHI Mgmt Group
- Why do ephemeral credentials still leave risk in machine access models?
- Why do AI runtime credentials increase the risk of lateral movement?
- Why do standing credentials increase the risk of lateral movement in cloud environments?
- Why do machine credentials in repositories increase lateral movement risk?