A mixed execution pattern where one workflow uses both autonomous machine credentials and human-delegated tokens. The problem is not just multiple identities, but the loss of clear attribution when actions travel across several trust contexts and logging systems at once.
Expanded Definition
Identity mashup describes a workflow pattern where a single business process combines autonomous machine credentials, such as service accounts or API keys, with human-delegated tokens, such as SSO sessions or OAuth grants. In NHI management, the key issue is not simply that multiple identities are present, but that attribution becomes fragmented when each step is logged under a different principal, context, or trust boundary.
Definitions vary across vendors, but the operational concern is consistent: once machine and human authority are interleaved, it becomes harder to prove who initiated a change, which identity actually executed it, and whether the resulting access path still respects least privilege. That is why NHI Management Group treats identity mashup as a governance and observability problem, not just an authentication pattern. The concept aligns closely with identity lifecycle and logging expectations discussed in the Ultimate Guide to NHIs, and it maps to the risk-based control logic reflected in the NIST Cybersecurity Framework 2.0.
The most common misapplication is assuming a workflow is attributable just because each component individually authenticates, which occurs when logs are not correlated across both human and machine trust contexts.
Examples and Use Cases
Implementing identity mashup safely often introduces correlation overhead, requiring organisations to balance workflow flexibility against the cost of unified audit trails and stricter token governance.
- A developer approves a CI/CD deployment with a human SSO session, while the pipeline later uses a service account to publish artifacts, leaving two separate principals in the logs.
- An AI agent receives a delegated user token to read data, then switches to an autonomous machine credential to call downstream APIs, making action ownership difficult to reconstruct.
- A support workflow uses a human-issued OAuth grant to open a ticket, but automation escalates privileges through a bot identity before the human sees the final state change.
- A federated SaaS integration chains a user token through multiple services, then persists a long-lived machine secret for retries, creating mixed attribution and secret sprawl risk.
- For breach analysis, NHI Mgmt Group recommends comparing the execution path against patterns seen in the 52 NHI Breaches Analysis and validating delegation behavior against OAuth 2.0 expectations.
These examples show why identity mashup is often introduced unintentionally, especially when teams optimise for speed by reusing human tokens inside automation paths without a clear delegation record.
Why It Matters in NHI Security
Identity mashup matters because it can hide privilege escalation, blur incident timelines, and break accountability during response. When a workflow spans multiple identities, security teams may see the final action but not the true decision chain, which weakens containment, forensics, and separation of duties. The risk is amplified when mixed flows rely on long-lived secrets or shared vault entries, a pattern that NHI Mgmt Group has identified repeatedly in its research, including the Top 10 NHI Issues.
NHI Mgmt Group reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, a reminder that mixed trust paths are not theoretical; they are a common breach amplifier. Identity mashup also complicates Zero Trust enforcement because policy engines need a stable principal to evaluate. Where delegation is real, the chain must be explicit, as reflected in NIST Cybersecurity Framework 2.0 and the broader visibility and lifecycle guidance in the Ultimate Guide to NHIs.
Organisations typically encounter the consequences only after an investigation cannot reconcile who approved an action and which identity executed it, at which point identity mashup 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 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-01 | Identity mashup creates attribution and lifecycle ambiguity across human and machine principals. |
| NIST CSF 2.0 | PR.AA-01 | Identity verification and authentication must remain traceable across blended execution paths. |
| NIST Zero Trust (SP 800-207) | PA | Zero Trust policy decisions depend on clear principal context, which mashups often obscure. |
Inventory mixed trust paths and require explicit delegation records for every identity transition.
