A failure pattern where a stolen identity is used to create more trusted identities or actions, causing compromise to spread through legitimate systems. In supply chains, this can mean a compromised build or publish path repeatedly issuing new valid artefacts.
Expanded Definition
Recursive trust abuse describes a compounding trust failure in which one compromised non-human identity is used to mint, approve, sign, or authorize additional identities, tokens, artefacts, or actions that are then trusted by downstream systems. In NHI security, the danger is not just initial compromise, but the way legitimate trust chains amplify it. This pattern appears in CI/CD pipelines, artifact signing, cloud federation, delegated automation, and service-to-service authorization.
Definitions vary across vendors, but the core idea is consistent: trust is recursively propagated through systems that assume previous trust decisions are still valid. That makes the issue closely related to least privilege, key lifecycle control, and provenance verification in NIST SP 800-53 Rev 5 Security and Privacy Controls. NHI Management Group treats this as an abuse pattern rather than a single control failure, because it often spans identity issuance, build integrity, and downstream authorization.
The most common misapplication is treating every newly issued token or signed artefact as trustworthy simply because it was created by an already trusted automation path.
Examples and Use Cases
Implementing controls against Recursive Trust Abuse rigorously often introduces friction in automation speed, requiring organisations to weigh delivery efficiency against stronger validation and provenance checks.
- A compromised build agent signs a release, and the signing key is trusted by deployment systems to issue more trusted artefacts without additional review.
- A stolen workload identity uses federation to request short-lived credentials for another service, which then inherits the original trust context without revalidation.
- A compromised package publisher injects a new dependency version that downstream pipelines automatically accept because the source repository is already allowlisted.
- An agentic workflow with tool access uses an approved credential to generate a new API token for a subordinate process, extending compromise across services.
- A CI/CD secret leak enables repeated issuance of valid artefacts, echoing the supply-chain and lifecycle weaknesses discussed in the Ultimate Guide to NHIs and the control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls.
These scenarios are especially dangerous when no one separately validates the provenance of what was created, only the identity of what created it.
Why It Matters in NHI Security
Recursive Trust Abuse turns one credential compromise into a cascading trust event, which is why it is so damaging in environments that rely on automated issuance, delegation, and signing. NHI Management Group’s research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, underscoring how often trust chains are the real blast-radius multiplier. The same research also reports that 92% of organisations expose NHIs to third parties, increasing the chance that a compromised upstream trust relationship can propagate inward through supply chains.
From a governance perspective, this pattern matters because it defeats surface-level controls. A team may rotate credentials, yet still leave the issuing workflow, signing path, or federation rule unchanged. It also weakens Zero Trust if downstream services continue to trust artefacts just because they came from an approved system path. For that reason, practitioners need provenance verification, narrow delegation, step-up approval for issuance, and strong offboarding of signing and publishing identities. The risk becomes visible only after a release pipeline, federation path, or automation chain has been abused, at which point recursive trust abuse is 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 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-08 | Covers trust-chain abuse where one NHI is used to obtain or empower another. |
| OWASP Agentic AI Top 10 | A-07 | Agent tool use can recursively extend authority through delegated actions and credentials. |
| NIST CSF 2.0 | PR.AC-1 | Access and trust should be managed through explicit authorization, not inherited trust chains. |
| NIST Zero Trust (SP 800-207) | SC-1 | Zero Trust rejects implicit trust propagation across systems and sessions. |
| NIST SP 800-63 | AAL2 | Assurance must be preserved when identities are delegated or derived from others. |
Break recursive issuance paths and verify each token, key, or artefact against its own provenance.
