Runtime evidence

Cryptographic proof collected from the environment a workload is using, such as image hashes, cloud-signed metadata, boot measurements or code signatures. It is the material a verifier checks to decide whether an identity should be trusted.

Expanded Definition

Runtime evidence is the cryptographic material a verifier uses to decide whether a workload, agent, or service identity is operating in a trusted environment. It is gathered after execution starts, so it complements static assertions such as provisioned identities, signed binaries, or predeployment attestations. In NHI operations, runtime evidence can include image hashes, cloud-signed metadata, boot measurements, code signatures, and other signals that prove what is actually running rather than what was intended to run.

Definitions vary across vendors when runtime evidence is bundled with attestation, telemetry, or policy enforcement, so the term should be used carefully. The closest standards discussion sits in zero trust and identity assurance work, including NIST Cybersecurity Framework 2.0, which emphasizes continuous risk-informed verification. For agentic systems, runtime evidence is especially important because an AI Agent may inherit tool access long after deployment, making the trust decision dependent on the environment at the moment of use. The most common misapplication is treating a signed build artifact as runtime proof, which occurs when teams verify release provenance but do not verify the live instance, enclave, or node that is actually executing.

Examples and Use Cases

Implementing runtime evidence rigorously often introduces latency and operational overhead, requiring organisations to weigh stronger trust decisions against slower deployments and more complex verification flows.

• A service account presents a signed workload identity, and the verifier checks boot measurements before allowing secrets access.
• An AI Agent requests a tool action, and the platform validates the container image hash plus cloud metadata before issuing privileges.
• A CI/CD job claims to be running approved code, but runtime evidence shows the node image has drifted from the trusted baseline.
• During incident response, investigators compare live code signatures with known-good measurements to confirm whether tampering occurred.
• In a supply-chain review, teams correlate runtime evidence with the exposure pattern described in the JetBrains GitHub plugin token exposure case to determine whether stolen credentials were used from an unexpected execution context.

Operationally, runtime evidence matters most where the runtime environment is the trust boundary, not just the identity store. That is why practitioners often pair it with NIST Cybersecurity Framework 2.0 control mapping and workload verification patterns used in modern zero trust designs. When the evidence is strong, access can be granted with higher confidence; when it is incomplete, the safer choice is to restrict the request until the environment is revalidated.

Why It Matters in NHI Security

Runtime evidence closes the gap between identity issuance and identity use. Without it, a valid token, certificate, or service principal can be replayed from a compromised node, a tampered container, or an untrusted agent runtime. That risk is especially acute in NHI environments because identities outlive sessions, automation runs continuously, and secrets often move through pipelines faster than humans can review them. NHI Mgmt Group research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is why runtime checks cannot be treated as optional hardening.

This issue also surfaces in governance. A team may believe it has strong access controls, yet the live workload may be running outside approved policy, with mismatched signatures or stale boot state. Runtime evidence gives operators a way to prove that the identity is still being exercised in the expected context. It also supports Zero Trust Architecture by making verification continuous rather than one-time, aligning with NIST Cybersecurity Framework 2.0 and the broader logic of NIST Cybersecurity Framework 2.0 aligned assurance. Organisations typically encounter the need for runtime evidence only after a token is abused from a compromised workload, at which point proof of execution becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What is the difference between compliance evidence and runtime access control?
• What is the difference between runtime protection and NHI lifecycle management?
• What is the difference between code scanning and runtime identity monitoring?
• What evidence is needed to understand the impact of shadow AI agents?