An access decision made at the moment a secret is requested, rather than when it is stored or provisioned. For workloads and AI agents, this is a key control because it ties disclosure to identity, context, and policy instead of static possession.
Expanded Definition
Request-time policy check is the control point where a workload, service account, or AI agent is evaluated at the moment it asks for a secret, token, or certificate. The decision is made using current identity, context, and policy rather than relying on a pre-granted standing entitlement. In NHI programs, this is one of the clearest ways to reduce secret exposure because the request is authorized only when the conditions are still valid.
Definitions vary across vendors on how much context a request-time decision should consume. Some implementations focus on basic identity and role membership, while stronger models also evaluate workload posture, time, source, environment, and policy intent. That distinction matters because a secret request can be legitimate in one runtime and risky in another. For a broader governance lens, the NIST Cybersecurity Framework 2.0 reinforces continuous risk management rather than one-time trust decisions.
The most common misapplication is treating request-time policy check as a front-end login control, which occurs when teams issue the secret once and then assume later reuse remains equally safe.
Examples and Use Cases
Implementing request-time policy check rigorously often introduces latency and policy complexity, requiring organisations to weigh stronger secret governance against additional evaluation overhead.
- A CI/CD job requests a deployment token only after its pipeline identity, repo source, and environment match approved policy.
- An AI agent asks for an API key to call a finance system, but access is denied unless the agent is running in an approved tenant and task scope.
- A service account requests a database credential through a broker that verifies device posture, time window, and workload attestation before releasing the secret.
- An emergency admin process uses short-lived approval logic so a privileged rotation token is only disclosed during an active incident window.
- Teams mapping policy-driven secret release to lifecycle discipline often pair this with the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and broader control reviews in the Top 10 NHI Issues.
For standards-oriented implementations, request-time checks are often paired with short-lived credentials and federation patterns described in SPIFFE-style workload identity models, where the secret itself is minimized rather than broadly reused.
Why It Matters in NHI Security
Request-time policy check matters because NHI compromise is rarely just about stolen storage, it is about whether stolen material can still be used. NHI Mgmt Group reports that 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage, which shows how quickly a leaked credential becomes an operational incident when access is not revalidated at use time. A request-time decision reduces the usefulness of copied secrets, cached tokens, and stale agent permissions.
This control also supports auditability and blast-radius reduction. If access is conditioned at the moment of use, security teams can link every disclosure to a current business reason, a specific workload, and an enforced policy state. That becomes especially important in AI agent systems, where tool access may be broad, transient, and difficult to review after the fact. The Ultimate Guide to NHIs — Regulatory and Audit Perspectives is useful here because it frames how evidence for authorization, rotation, and review should be preserved.
In practice, organisations typically encounter the need for request-time policy check only after a secret has been reused outside its intended context, at which point the control becomes operationally unavoidable to address.
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, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Request-time disclosure is a direct safeguard against improper secret handling. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions should be enforced dynamically, not assumed from prior possession. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification before granting access to protected resources. | |
| OWASP Agentic AI Top 10 | Agent tool access must be constrained at runtime to limit unauthorized actions. | |
| CSA MAESTRO | MAESTRO emphasizes runtime governance for autonomous agents and their privileges. |
Treat every secret request as a fresh trust decision based on identity and context.
Related resources from NHI Mgmt Group
- What is the difference between build-time scanning and deployment-time policy checks?
- What breaks when NHI provisioning happens without ownership and policy at creation time?
- What breaks when network controls are used instead of request-level policy for machine access?
- Why do real-time policy decisions still fail in identity governance programmes?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
