Borrowed authority is the security condition where an agent can act with permissions that originated from a user, service account, or connected application. It is what makes prompt injection operationally dangerous. The attacker does not need new credentials if the agent can already exercise valid ones on their behalf.
How borrowed authority works
Borrowed authority describes a delegation pattern, not a credential type. The agent is not inventing access; it is exercising permissions that already exist on behalf of a person, service account, or connected application. That is why the condition matters in agentic systems: the action may look legitimate even when the instruction that triggered it is malicious.
This differs from direct compromise of credentials. In borrowed authority scenarios, the security boundary shifts from “who has the secret” to “what the agent is allowed to do with already-authorised access.”
Why borrowed authority is dangerous
The danger is that the attacker can use a trusted execution path instead of stealing new credentials. If the agent can read mail, query files, call APIs, or trigger workflows as the user or application, prompt injection can turn that existing trust into unauthorized action, data exposure, or privilege abuse.
Borrowed authority is especially risky when access is broad, poorly constrained, or reused across tools. A single malicious instruction can then cascade into multiple downstream systems that all treat the agent as an authorised actor.
Where borrowed authority appears in real systems
Borrowed authority most often appears in copilots, workflow automations, assistants, and integration agents that operate inside an existing trust context. The agent may inherit a user session, a service account token, delegated OAuth consent, or an application role and then act within that scope until the session or grant expires.
The pattern can also emerge when organisations centralise convenience over separation. If one agent is allowed to search, retrieve, summarise, and act across several systems, the authority that makes the tool useful also makes prompt injection more consequential.
How to recognise and reduce it
The practical question is not whether an agent has access, but whether its access is bounded tightly enough for the actions it can take. Stronger designs reduce the amount of authority exposed to a prompt-driven component, separate read from write paths, and keep high-impact actions behind explicit checks.
Borrowed authority should be treated as a governance issue as much as a technical one. Teams need to know which identity is acting, which permissions were inherited, which downstream systems trust that action, and whether the resulting behaviour is acceptable for the business function the agent serves.
Risk and Threat Considerations
Borrowed authority creates a high-value attack path because the attacker can operate through a legitimate access chain instead of defeating authentication directly. Prompt injection, malicious content, or poisoned context can cause the agent to use valid permissions in ways the original user never intended.
Failure mechanism: The agent inherits authority from a user, service account, or connected application and then performs actions that remain technically authorised but contextually unsafe, such as reading sensitive data, invoking APIs, or modifying records.
Impact: A compromise can produce data leakage, unauthorised transactions, lateral movement across connected systems, or persistent abuse until the delegated access is revoked or constrained.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Borrowed authority often depends on service and workload authentication paths. |
| AC-6 — Least Privilege | Borrowed authority becomes dangerous when delegated permissions exceed the task. | |
| Recommendation — Use IA-9 to authenticate non-human actors that an agent may act through or against. Apply AC-6 to limit what an agent can do with inherited access. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Borrowed authority is a core agent privilege-abuse pattern. |
| ASI02 — Tool Misuse | Agents can misuse approved tools when authority is borrowed through prompts. | |
| Recommendation — Constrain agent privileges so prompt-triggered actions cannot exceed intended authority. Restrict tool actions so trusted access cannot be repurposed by malicious instructions. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Borrowed authority is reduced by continuously verifying access context and minimizing implicit trust. |
| Recommendation — Adopt zero trust principles to continuously evaluate each delegated action and reduce implicit trust. | ||
Practitioner Guidance
Why practitioners should care: Borrowed authority is where many agent failures become real incidents, because the security model assumes the agent will use trusted access responsibly. Treat every delegated permission as part of the attack surface, not just the prompt channel.
Common misunderstanding: “The agent only uses existing permissions” is not a safety argument. Existing permissions are exactly what an attacker wants to steer, especially when the agent can chain actions across systems.
Practitioner takeaway: Design for least authority, explicit action boundaries, and clear ownership of every delegated permission the agent can exercise.
Related resources from NHI Mgmt Group
- What is the difference between identity governance and authority governance?
- What is the difference between access visibility and access authority?
- What is the difference between delegated user access and machine authority for AI agents?
- What is the difference between delegated access and agent authority?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org