An access model in which each tool call carries the initiating user’s identity and authorization context rather than a shared backend credential. For MCP, this is what preserves attribution and reduces the blast radius of server compromise.
Expanded Definition
Per-request identity is an access pattern where every tool invocation carries the caller’s identity, scope, and authorization context at the moment of use, rather than relying on a shared backend credential. In NHI and agentic AI environments, that distinction matters because execution authority must remain attributable even when an AI agent chains multiple tools or services together.
Definitions vary across vendors on how much context must be propagated, but the security objective is consistent: the backend should be able to verify who initiated the action, what it may do, and whether the request still fits policy at that exact moment. This aligns closely with the intent of NIST Cybersecurity Framework 2.0, especially around identity, least privilege, and continuous authorization. In MCP contexts, per-request identity helps preserve auditability while reducing the risk that one compromised service account can act broadly across every downstream call. It also complements the governance themes in Ultimate Guide to NHIs, where visibility and credential discipline are central to control.
The most common misapplication is treating a single long-lived backend token as equivalent to per-request identity, which occurs when teams forward authentication once at session start and stop propagating caller context on subsequent tool calls.
Examples and Use Cases
Implementing per-request identity rigorously often introduces routing and token-handling overhead, requiring organisations to weigh stronger attribution against added orchestration complexity and latency.
- An AI assistant calls an internal ticketing tool using the end user’s identity so approval history remains tied to the individual, not to a shared agent account.
- An MCP server receives each request with a scoped delegation token, allowing it to enforce exactly which files, records, or actions that user can touch.
- A workflow engine passes the initiating analyst’s role and session context into a risk-scoring API so every decision can be traced back to a specific operator.
- A SaaS integration uses per-request identity for write actions but not for read-only enrichment, limiting exposure if the integration host is compromised.
- Incident teams reviewing patterns similar to the 52 NHI Breaches Analysis often find that shared credentials made attribution impossible; by contrast, request-level identity gives each call a defensible trail.
For implementation detail, teams often borrow concepts from federated identity and workload identity models described by SPIFFE and related standards work, especially when a tool chain spans multiple trust zones and the calling principal must remain intact across hops.
Why It Matters in NHI Security
Per-request identity is what keeps an autonomous system from becoming a black box with broad access. Without it, a compromised agent, plugin, or orchestration layer can reuse the same credential for every downstream action, which destroys attribution and makes containment far harder. This is especially relevant in NHI security because service accounts, API keys, and secrets already face severe governance gaps: NHI Mgmt Group reports that only 5.7% of organisations have full visibility into their service accounts, and 97% of NHIs carry excessive privileges in the broader NHI population. Those conditions make request-level attribution more than a design preference; it becomes a control boundary.
The practical security value is strongest when paired with least privilege, short-lived credentials, and strong audit logging. Guidance in the Ultimate Guide to NHIs and the Top 10 NHI Issues shows how secret sprawl and over-privilege compound each other when identity context is flattened. Organisations typically encounter the need for per-request identity only after a shared credential is abused, at which point the control becomes operationally unavoidable to restore attribution and limit blast radius.
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 | Per-request identity reduces shared-secret exposure and preserves request-level attribution. |
| OWASP Agentic AI Top 10 | A-03 | Agentic tool use requires explicit authorization context for each autonomous action. |
| NIST CSF 2.0 | PR.AC-1 | Identity proofing and access control depend on knowing the initiating principal for each request. |
| NIST Zero Trust (SP 800-207) | JIT access | Zero Trust requires continuous verification instead of trust from an initial session token. |
| CSA MAESTRO | IAM-1 | Agentic governance depends on explicit identity binding across delegated tool invocations. |
Propagate caller identity on every tool call and avoid shared backend credentials wherever possible.
Related resources from NHI Mgmt Group
- What is the difference between network trust and request-level identity trust?
- How should teams reduce repeated database reads in a single request without risking stale identity data?
- What do teams get wrong when they treat self-service request portals as identity governance?
- Why do service request systems matter to identity governance?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
