An execution environment that cannot be assumed to keep secrets safely because it reads untrusted input, logs its own actions, persists state, or makes autonomous tool calls. In identity and agent design, this is the place where durable credentials should be removed whenever possible.
Expanded Definition
An untrusted runtime is any execution context that should be treated as hostile to durable secrets, even if it is owned or orchestrated by the organisation. The key distinction is not whether the system is legitimate, but whether the environment can be relied on to preserve confidentiality, integrity, and precise execution boundaries. That distinction matters in cloud workloads, browser-based sessions, containers, serverless functions, and AI agent runners that handle prompts, plugins, or tool outputs.
In security practice, the term is often used to describe places where a secret can be observed, copied, replayed, or indirectly exposed through logs, crash dumps, state files, debugging hooks, or outbound network calls. This is why guidance increasingly favours short-lived credentials, scoped tokens, and external secret retrieval over embedding long-lived keys inside the runtime itself. NIST’s NIST Cybersecurity Framework 2.0 is relevant here because its governance and protection outcomes support reducing exposure of sensitive assets across operational environments.
The most common misapplication is assuming a runtime is trusted because it is containerised or internal, which occurs when teams ignore logging, persistence, and tool access paths that still expose secrets.
Examples and Use Cases
Implementing untrusted runtime handling rigorously often introduces integration friction, requiring organisations to weigh developer convenience against tighter secret handling and shorter session lifetimes.
- An AI agent workflow that must call external tools receives only ephemeral tokens, not the long-lived API key used by the control plane.
- A serverless function processes customer input, but secret material is fetched just in time from a vault and discarded before the function exits.
- A browser automation session is treated as untrusted because page content, extensions, and telemetry can expose in-memory values or copied tokens.
- A container that writes verbose logs is prevented from seeing durable credentials, because debug output can unintentionally capture request headers or environment variables.
- A multi-step workflow uses signed, narrowly scoped delegation rather than static secrets, so a compromised step cannot impersonate the whole process.
For identity-heavy systems, this concept also intersects with non-human identity design: if an agent or workload must operate in an untrusted runtime, its permissions should be limited to the smallest viable scope and duration. That aligns with modern guidance on reducing credential dwell time and avoiding broad reuse across execution contexts.
Why It Matters for Security Teams
Security teams need this concept because most secret leaks do not come from obvious theft, but from routine system behaviour such as logging, retries, telemetry, inspection, or post-execution persistence. Once a runtime is treated as untrusted, architecture decisions change: secrets move out of the process, access becomes time-bound, and tool calls are mediated through stronger policy checks.
This is especially important for AI agents and automation because their autonomy expands the number of places where credentials can be exposed or misused. A runtime that can read prompts, invoke tools, or serialize state should not be assumed to protect high-value secrets just because it was provisioned by a trusted platform. The practical response is to minimise what the runtime can ever see, not to hope it will keep a secret after execution.
Teams usually realise the importance of untrusted runtime handling only after a token appears in logs, a workflow is replayed, or an agent exceeds its intended permissions, at which point the concept becomes operationally unavoidable.
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 Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS | Protecting data in transit and at rest applies when runtimes may expose secrets. |
| OWASP Non-Human Identity Top 10 | NHI guidance covers secret handling for non-human identities in exposed execution contexts. | |
| OWASP Agentic AI Top 10 | Agentic AI guidance addresses tool-enabled execution where secrets can be leaked or reused. | |
| NIST AI RMF | AI RMF governance supports risk treatment for execution environments that handle sensitive data. | |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero trust emphasises not assuming trust based on network or platform location alone. |
Keep durable secrets out of runtimes and reduce exposure through storage and transmission controls.
Related resources from NHI Mgmt Group
- Why do sandboxed runtime environments increase risk when they share a host process with untrusted code?
- What breaks when AI agents are allowed to act on untrusted prompts without runtime guardrails?
- What is the difference between runtime protection and NHI lifecycle management?
- What is the difference between code scanning and runtime identity monitoring?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
