Borrowed trust is the security condition where one system relies on another system, package, token, or automation path to act legitimately on its behalf. In practice, it creates hidden attack paths because the trusted component often inherits permissions broader than the original use case requires.
Expanded Definition
Borrowed trust describes a condition where legitimacy is inherited rather than proven. A service, agent, package, or token is allowed to act because another trusted component vouches for it, even when the downstream actor was never intended to hold that level of access.
In NHI operations, borrowed trust appears in delegated API access, CI/CD runners, workload identities, service meshes, and chained automation. The risk is not simply that one identity is trusted; it is that trust can propagate through hidden dependencies, making access review and blast-radius analysis much harder. Definitions vary across vendors when borrowed trust is discussed alongside delegation, impersonation, or token exchange, so the operational question is whether the acting component has direct proof of authority or is merely inheriting it. That distinction matters in NIST Cybersecurity Framework 2.0, where identity assurance and access control depend on knowing exactly who or what is acting.
The most common misapplication is treating inherited authorization as equivalent to original authorization, which occurs when teams reuse broad credentials across automation paths without validating the final actor.
Examples and Use Cases
Implementing controls against borrowed trust rigorously often introduces routing and authentication overhead, requiring organisations to weigh automation speed against tighter verification of each hop.
- A build pipeline signs artifacts with a shared token, and every downstream deployment job inherits the same privilege even though only one stage needs write access.
- An AI agent calls internal tools through a broker service, but the broker’s standing permissions let the agent reach systems outside its intended task scope.
- A SaaS integration uses a vendor-issued API key that is trusted by default, creating a path where the third party’s operational issues become the customer’s access risk. This pattern aligns with concerns discussed in the Ultimate Guide to NHIs.
- A service account is reused across multiple microservices, so one compromise can masquerade as normal east-west traffic and evade coarse RBAC reviews.
- An orchestrator exchanges a short-lived token for broader credentials, but the token exchange chain is not logged well enough to reconstruct the real authority path.
These examples show why borrowed trust is not just a design issue; it is a governance issue that becomes visible only when identity lineage, privilege scope, and delegation records are examined together. The NIST Cybersecurity Framework 2.0 is useful here because it encourages organizations to define, protect, and monitor identity-based access across the full control chain.
Why It Matters in NHI Security
Borrowed trust is dangerous because it hides the true security boundary. A token, workload, or agent may appear low risk at the point of issuance, yet still unlock privileged actions when it is accepted by a downstream system. That breaks assumptions behind least privilege, JIT access, and ZSP, especially when trust relationships are undocumented or long-lived. In practice, borrowed trust can turn a single compromised secret into a multi-system incident.
That is why governance must focus on both the credential and the path it travels. NHI programs that track inventory, lifecycle, rotation, and offboarding are better positioned to detect where trust has been implicitly extended; Ultimate Guide to NHIs is a useful baseline for that operational view. The same principle matters in zero trust programs, where trust is continuously evaluated rather than inherited by default. The NHI data is stark: Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges, which makes borrowed trust far more likely to become an escalation path than a convenience.
Organisations typically encounter borrowed-trust failures only after a service account abuse, pipeline compromise, or agent misuse exposes permissions that were never meant to be shared, at which point the concept 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-02 | Borrowed trust often stems from excessive secret and token reuse across NHI paths. |
| NIST CSF 2.0 | PR.AC-4 | Addresses access permissions and least-privilege enforcement for identity-based trust chains. |
| NIST Zero Trust (SP 800-207) | SC-NA | Zero Trust rejects implicit trust and requires continuous verification of the acting entity. |
Eliminate implicit inheritance by verifying every workload, token, and agent action.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
