The preservation of origin and acting principal information as a request moves through multiple services. In MCP chains, this is what allows downstream systems to make a trustworthy authorization decision instead of relying on a stripped-down token with no task context.
Expanded Definition
Identity propagation is the end-to-end preservation of who initiated a request, which service is acting, and what authority was delegated as that request traverses APIs, queues, gateways, and microservices. In NHI environments, that context is what lets downstream systems distinguish a legitimate agent action from a forwarded token that has lost its original intent. It is closely related to delegation, token exchange, and identity federation, but no single standard governs this yet and usage in the industry is still evolving. The practical goal is to avoid collapsing every hop into a generic service account identity, because that destroys provenance and weakens authorization decisions.
For teams building MCP-enabled workflows, identity propagation often depends on how requests are encoded, whether claims survive translation, and whether the receiving service can evaluate context against policy. NIST’s NIST Cybersecurity Framework 2.0 supports this thinking through identity, access, and logging outcomes, even if it does not name the pattern directly. The most common misapplication is treating a passed token as sufficient proof of authority, which occurs when intermediaries strip actor context and downstream services authorize only the last hop.
Examples and Use Cases
Implementing identity propagation rigorously often introduces engineering overhead, because every service boundary must preserve, validate, and log context without creating excessive coupling between systems and policy engines.
- An AI agent calls a planning service, which then invokes a ticketing API. Propagation preserves the agent, the human approver, and the task so the ticketing system can apply the right Ultimate Guide to NHIs governance model instead of treating the call as a generic automation event.
- A payment workflow fans out across services. With propagated identity, each hop can evaluate whether the request came from a privileged service account, a delegated human session, or a short-lived NIST Cybersecurity Framework 2.0 aligned control plane.
- In a breach review, investigators correlate the original principal, the acting principal, and each downstream action. That kind of traceability is central to 52 NHI Breaches Analysis, where missing provenance turns incident response into guesswork.
- In federated service-to-service access, propagated claims can support JIT decisions and reduce standing authority, but only if the receiving platform understands how to interpret delegated context rather than flattening it into a single role.
- During CI/CD automation, the build system may act on behalf of a developer. Propagation allows the deployment gate to distinguish a pipeline credential from the human change owner, which is essential when policy or approval rules differ.
Definitions vary across vendors, especially when teams confuse propagation with simple logging or pass-through authentication. The operational difference is whether the receiving service can use the inherited context to make a better decision, not just record an event.
Why It Matters in NHI Security
Identity propagation matters because NHI risk is rarely confined to a single system boundary. Once context is lost, downstream services often overgrant access, misattribute actions, or fail to enforce delegation limits. That is especially dangerous in agentic workflows, where an AI Agent may chain multiple tools and services under a single request. NHI Management Group’s Top 10 NHI Issues shows how quickly weak identity handling becomes a governance problem rather than a technical inconvenience.
This also intersects with credential and secret exposure. The Ultimate Guide to NHIs — What are Non-Human Identities notes that 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface. If propagation fails, that excess privilege is harder to contain because downstream systems cannot tell whether a request is acting within its true delegated scope. Proper propagation also supports auditability, RBAC enforcement, ZTA policy checks, and incident reconstruction after abuse.
Organisations typically encounter the consequences only after a service compromise, token replay, or agent misuse reveals that downstream systems cannot prove who actually caused the action, at which point identity propagation 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 address the attack and risk surface, while NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Covers NHI identity context, delegation, and service-to-service trust boundaries. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero Trust relies on continuously evaluating identity and context at each request. |
| NIST CSF 2.0 | PR.AC-1 | Access control outcomes depend on knowing the true requesting principal. |
Preserve actor, origin, and delegation data across every hop before granting downstream access.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
