Process-scoped state is information that persists for the lifetime of an application process rather than for a tab, origin, or user session. In privacy-sensitive systems, this state can become an unintended identity signal if public APIs expose it directly or through deterministic behaviour.
Expanded Definition
Process-scoped state is the data a running application process keeps alive for its own lifetime, even when tabs, requests, or user interactions change. It may include cached configuration, counters, challenge outcomes, parser state, in-memory tokens, or feature flags that are not meant to act as an identity mechanism. In privacy-sensitive systems, the risk is not the state itself but the way stable, observable behaviour can reveal it.
This matters because process lifetime is different from browser scope, origin scope, or user session scope. A page reload, session refresh, or request boundary may not clear the state if the same backend worker, browser process, or service container remains active. That creates a subtle distinction between what the application believes is ephemeral and what an external observer can repeatedly detect. Guidance in the OWASP Non-Human Identity Top 10 is useful here because process-held secrets and machine context can become identity-like signals when they are reused deterministically.
The most common misapplication is treating process-scoped state as if it were user-scoped or request-scoped, which occurs when developers assume a restart, tab change, or API call boundary resets all relevant data.
Examples and Use Cases
Implementing process-scoped state rigorously often introduces operational friction, requiring teams to weigh performance and convenience against isolation and observability.
- A backend service keeps a per-process cache of authentication results, so repeated requests from the same worker are treated differently from requests handled by another worker.
- A browser-based application stores anti-abuse counters in memory, which survive route changes but disappear only when the page process is fully terminated.
- A machine-to-machine component retains an access token, client assertion, or handshake outcome for the duration of the process, making the process itself a reusable trust anchor. This is especially important in identity-heavy systems discussed by the OWASP Non-Human Identity Top 10.
- A privacy review finds that deterministic timing or error differences expose whether a process has seen a prior event, turning state persistence into an unintended fingerprint.
- A containerised agent maintains tool-selection memory for its runtime, which affects later actions even though the user believes each task starts fresh.
Why It Matters for Security Teams
Security teams need to understand process-scoped state because it can undermine assumptions about isolation, replay resistance, and data minimisation. When state survives longer than intended, it can create hidden coupling between requests, users, or autonomous components. That coupling becomes a problem in privacy reviews, in abuse detection, and in identity assurance, where stable behaviour may be enough to distinguish one process from another or one execution path from another.
For identity and NHI-adjacent systems, the danger is especially clear: a process that holds secrets, derived credentials, or internal trust decisions can begin to behave like a standing identity. That is why process lifetime, secret handling, and deterministic responses need to be reviewed together, not as separate concerns. Guidance from the OWASP Non-Human Identity Top 10 helps teams spot when machine-held state is drifting into identity territory, while broader software security practice should also consider NIST SP 800-53 for access control and NIST SP 800-63 for assurance boundaries.
Organisations typically encounter the consequences only after a privacy incident, abuse investigation, or inconsistent auth behaviour appears in production, at which point process-scoped state becomes operationally unavoidable to trace and constrain.
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, NIST SP 800-63, NIST AI RMF and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers machine-held secrets and process trust that can become identity-like. |
| NIST CSF 2.0 | PR.AC-4 | Access control guidance applies when process state influences authorization decisions. |
| NIST SP 800-63 | AAL2 | Assurance boundaries matter when process state is mistaken for user identity. |
| NIST AI RMF | AI RMF applies when process state shapes behaviour of autonomous or AI-enabled systems. | |
| NIST SP 800-53 Rev 5 | AC-6 | Least privilege is relevant when process-scoped state broadens effective permissions. |
Review process-held state as a potential machine identity and remove unnecessary standing trust.
Related resources from NHI Mgmt Group
- Why do NHI programmes need stronger process ownership than many human identity programmes?
- Why do AI agents increase the blast radius of over-scoped NHI tokens?
- What is the difference between role-based access and task-scoped access for AI agents?
- How should organisations govern API partner onboarding as a non-human identity process?
