Borrowed Authority

Expanded Definition

Borrowed authority describes a delegation pattern in which an autonomous agent inherits usable permissions from a human user, service account, or connected application and can therefore perform actions without holding a separate identity of its own. In agentic AI environments, this becomes a security boundary issue rather than a convenience feature, because the agent can call tools, read data, or trigger workflows inside the scope of the original principal.

The concept is closely related to delegation, impersonation, and scoped token use, but it is not the same as permanent privilege assignment. In well-governed designs, borrowed authority should be narrowly bounded by task, time, and resource, with explicit revocation paths and strong logging. NIST control families for access enforcement and account management provide the closest formal security framing, even though the term itself is newer than most standards language. For a useful control reference, see NIST SP 800-53 Rev 5 Security and Privacy Controls.

The most common misapplication is treating borrowed authority as harmless proxy access, which occurs when teams let an agent inherit broad user permissions without task scoping or revocation discipline.

Examples and Use Cases

Implementing borrowed authority rigorously often introduces delegation overhead, requiring organisations to weigh agent autonomy against the cost of tighter authorisation, audit, and revocation controls.

• An AI scheduling agent uses a user’s mailbox access to read meeting invitations and send replies, but only within the mailbox scope originally granted to that user.
• A customer-support agent borrows a ticketing service account’s API token to update records, which is useful until the token also exposes administrative actions the agent does not need.
• A DevOps assistant inherits a CI/CD connector’s permissions to open pull requests or trigger builds, making the connector a high-value pathway if the agent is manipulated.
• A procurement workflow agent acts through a business user’s application session to approve routine requests, which becomes risky when the approval threshold is not enforced by the downstream system.
• In a zero trust design, borrowed authority is constrained by policy checks at each action point rather than assumed safe because the initiating user was authenticated earlier.

For teams building practical guardrails, identity and access guidance is often easiest to anchor in established control expectations, especially around least privilege, session control, and account lifecycle handling. The key question is not whether the agent can act, but whether every inherited permission is still justified for that specific action and moment.

Why It Matters for Security Teams

Borrowed authority matters because it changes the blast radius of a compromise. If an attacker can influence an agent through prompt injection, malicious data, or workflow manipulation, the agent may faithfully execute actions that a human would never intentionally approve in that context. This is why the issue sits at the intersection of AI security, identity governance, and privileged access management: the agent is not merely generating text, it is exercising permissions.

Security teams need to understand where borrowed authority begins and ends, who owns the underlying entitlement, and how the organisation proves that an agent’s action remained within policy. That includes narrowing token scope, separating read and write capabilities, logging delegated actions with enough fidelity for review, and ensuring revocation works immediately when a session or connector is compromised. NIST SP 800-53 Rev 5 Security and Privacy Controls is helpful here because it frames access control, auditability, and account management as enforceable responsibilities rather than informal expectations.

Organisations typically encounter the full risk only after an agent has already sent, approved, or exfiltrated something using legitimate permissions, at which point borrowed authority becomes operationally unavoidable to address.

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?