A borrowed credential is a human token or account used by an AI or workload to access systems it should not inherit directly. It obscures ownership, complicates revocation, and turns machine activity into a false human identity record.
Expanded Definition
A borrowed credential is not simply a shared account. It is a human token, password, API key, or session used by an AI agent or workload to perform actions outside its intended identity boundary. In NHI security, the problem is less about access alone and more about attribution collapse: the system records machine activity as if a person had acted, which weakens auditability, incident response, and revocation logic.
Definitions vary across vendors when borrowed credentials are discussed alongside delegated access, service accounts, or secret injection. NHI Management Group treats the term narrowly: the credential belongs to a human identity, but operational use is transferred to software that should have its own machine identity. For that reason, borrowed credentials are a control failure as much as an access pattern. They conflict with guidance in the OWASP Non-Human Identity Top 10 and blur the assurance expectations described in NIST SP 800-63 Digital Identity Guidelines.
The most common misapplication is treating a borrowed human login as acceptable “temporary automation” when an AI agent or script has no separate machine identity or revocation path.
Examples and Use Cases
Implementing borrowed-credential prohibitions rigorously often introduces migration friction, requiring organisations to weigh short-term operational speed against better attribution, expiry, and least-privilege enforcement.
- An AI coding assistant uses a developer’s cloud console session to deploy infrastructure, leaving the platform to log the developer as the actor even though the action was machine generated.
- A build pipeline reads a personal VPN token from a vault because the team has not issued a dedicated workload identity, creating a hidden dependency on one employee’s access lifecycle.
- A customer-support chatbot invokes internal APIs with a human service desk account, making it impossible to distinguish approved human use from autonomous workflow activity.
- An operations script runs under a borrowed admin password during an emergency and is never reworked, so the account remains the audit trail for every later automated action.
These patterns are frequently visible in breach write-ups such as the CI/CD pipeline exploitation case study and the 230M AWS environment compromise, where identity misuse and secret reuse magnify impact. They also align with the access-risk patterns discussed in the OWASP Non-Human Identity Top 10.
Why It Matters in NHI Security
Borrowed credentials create a false sense of control. When an AI agent or workload is operating under a human account, access reviews become misleading, revocation becomes partial, and forensic timelines become unreliable. That is especially dangerous in environments that already struggle with secret sprawl, ephemeral workloads, and hybrid cloud sprawl. In the 2024 Non-Human Identity Security Report, only 19.6% of security professionals expressed strong confidence in their organisation’s ability to securely manage non-human workload identities, a signal that many environments are already over-reliant on fragile identity shortcuts.
Borrowed credentials also undermine zero trust expectations because they conceal whether a request came from a human, an agent, or an automated service. They can survive long after the original business need has changed, especially when teams copy a working credential into a pipeline, prompt workflow, or integration and never replace it with a dedicated machine identity. The right response is usually to replace borrowed access with service-specific identity, short-lived authorization, and explicit ownership mapping, as reinforced by NHIMG guidance on Ultimate Guide to NHIs — Static vs Dynamic Secrets and the Guide to the Secret Sprawl Challenge.
Organisations typically encounter the real cost of borrowed credentials only after an account is abused, at which point ownership ambiguity makes containment and attribution 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 SP 800-63 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-02 | Borrowed credentials are a core secret-management and ownership failure in NHI systems. |
| NIST SP 800-63 | Digital identity assurance helps distinguish human authenticator use from machine access patterns. | |
| NIST CSF 2.0 | PR.AA-01 | Identity verification and access control are weakened when software borrows human credentials. |
Replace borrowed human secrets with dedicated workload identities and enforce secret rotation and ownership.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
