A request-scoped cache stores computed results only for the duration of one application request. It reduces repeated work inside that path while preserving isolation between users and sessions. In identity-heavy services, it is useful only when invalidation on writes is immediate and the cached data cannot outlive the request.
Expanded Definition
A request-scoped cache is a short-lived in-memory lookup layer that exists only for the lifecycle of a single application request. It is used to avoid recomputing the same value multiple times inside one call path, such as repeated policy checks, token parsing, or identity enrichment. In NHI-heavy systems, it differs from session, process, or distributed caching because its lifetime ends when the request completes, which limits cross-request leakage and reduces stale identity state.
Definitions vary across vendors on whether request-scoped caching is treated as a performance pattern, a security boundary, or both. In practice, it is safest to view it as a containment mechanism that supports deterministic processing, not as a substitute for authorization checks or secret handling. The guidance in the OWASP Non-Human Identity Top 10 aligns with this view: caching should never preserve access decisions beyond the request that produced them. The most common misapplication is treating request-scoped cache entries like session state, which occurs when developers let identity assertions or secret lookups persist beyond the request boundary.
Examples and Use Cases
Implementing request-scoped caching rigorously often introduces coordination overhead, requiring organisations to weigh lower latency against the cost of strict invalidation and limited reuse.
- A service validates an API token once per request, then reuses the parsed claims for downstream authorization decisions without re-reading the token multiple times.
- An agentic workflow fetches a service account’s policy context once and reuses it across several tool calls in the same request, then discards it immediately.
- A gateway computes a tenant-specific entitlement set once per request and shares it across middleware layers, avoiding repeated directory calls.
- Identity enrichment logic caches a user-to-NHI relationship only within the request so logging, policy enforcement, and auditing see a consistent view.
For governance context, the Ultimate Guide to NHIs — Key Challenges and Risks highlights how quickly NHI exposures compound when identity data is reused too broadly. Request-scoped caching reduces redundant calls without creating a reusable identity artifact, and it fits cleanly with the OWASP guidance that secret and token handling should remain tightly bounded. It is most useful where a request fans out into multiple internal checks, but the cached value must not outlive that execution path.
Why It Matters in NHI Security
Request-scoped caching matters because many identity-heavy failures are not caused by the cache itself, but by cache scope that is too broad for the sensitivity of the data. If service account attributes, token claims, or authorization results are cached beyond the request, later decisions can be made on stale state after privilege changes, revocation, or rotation. That is especially dangerous in NHI systems where identities often outnumber humans by 25x to 50x, and control drift can spread quickly across automation paths.
The Ultimate Guide to NHIs — Key Challenges and Risks also notes that 97% of NHIs carry excessive privileges, which makes stale cached identity data particularly risky when it influences authorization. Request-scoped caching can support safer, faster processing, but only if writes invalidate immediately and the cache never becomes a hidden trust store. Organisations typically encounter the operational cost of poor cache scoping only after a token revocation, privilege reduction, or incident review exposes that old identity state was still being trusted.
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 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-04 | Request-scoped cache must not extend identity or secret lifetime beyond one request. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access depends on using fresh authorization data, not stale cached decisions. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust requires continuous evaluation, which request-scoped caching must not undermine. |
Recompute authorization from current entitlements and avoid reusing access decisions across requests.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
