Your AI agent should not borrow a human identity

The simplest way to give an AI agent access is also the most damaging to accountability: let it use a person's session, API token, or shared service account. The integration works. The audit trail does not.

When the agent and person appear as the same principal, a downstream system cannot answer whether the human clicked, the agent inferred, a scheduled workflow ran, or a compromised process replayed the credential. The access review sees one identity with one broad permission set. Incident response sees one stream of actions. Revoking the agent may also lock out the person, while disabling the person may leave an agent's copied credential alive elsewhere.

A shared service account changes the label but preserves the problem. It can identify a workload class, yet it rarely distinguishes one agent instance, owner, task, delegated user, or downstream subagent from another. Convenience at connection time becomes ambiguity at every control point after it.

An agent can act for a person without pretending to be that person. Identity answers who acted; delegation answers on whose authority and for what purpose.

A durable design starts with a first-class identity for the agent. Microsoft describes an agent identity as distinct from the human or workload identity that creates and manages it. Google Cloud has likewise introduced a dedicated agent principal rather than modeling every agent as a human or conventional service account.

That identity does not determine everything the agent may do. It gives policy, logs, ownership, and lifecycle controls a stable subject. Authority should arrive separately: from the agent's own narrow role for autonomous work, from a user delegation for a specific request, or from a system workflow that defines the mission.

Do not choose between an agent identity and a human identity. Carry both facts into the decision, then add the bounded grant that connects them.

Existing identity types remain useful, but none should be stretched until it hides the operating reality. Human identities assume a person can understand consent, perform multifactor authentication, and remain responsible for an interactive session. Service identities assume a relatively stable workload with predictable permissions. Agents are dynamic actors that can interpret instructions, select tools, retain context, and delegate parts of a task.

The difference matters most when context changes. A payroll agent may be allowed to read a specific employee's compensation data to answer an approved question. That does not mean the agent should inherit every payroll screen the employee or administrator can reach. It also does not mean a permanent service account should retain that access after the answer is delivered.

Consider an illustrative procurement agent asked by a department head to collect three quotes and prepare a comparison. The agent authenticates as itself. The request identifies the department head as the delegating principal. A policy engine issues a short-lived grant that allows this agent to read the approved vendor list, send quote requests from a designated channel, and write one draft comparison to the procurement workspace.

The grant does not copy the department head's full access. It excludes contract signature, vendor onboarding, payment changes, and access to unrelated departments. Every downstream action records the agent as the actor and the department head as the source of authority. If the task ends, the deadline passes, the agent version changes, or either identity is disabled, the grant stops working.

This is not a claim that every current enterprise system can enforce every field natively. It is the decision record to preserve at the control plane even when adapters must translate it into narrower credentials for legacy tools.

Agent

Which registered agent, version, runtime, owner, and policy profile is requesting access?

Principal

Which human, system, or workflow supplied the authority, and was that principal entitled to delegate it?

Mission

What outcome is the agent pursuing, and which request or case created the work?

Scope

Which resources and actions are allowed, denied, or subject to approval?

Constraints

What data boundaries, spend limits, recipients, environments, and policy conditions apply?

Lifetime

When does the grant expire, what renews it, and what events revoke it early?

Microsoft's agent authorization model distinguishes autonomous access from delegated user access. The distinction is useful, but both modes still need least privilege. An autonomous agent should receive only the application permissions required by its job. A user-directed agent should receive the intersection of the user's authority, the agent's policy, and the current task—not the union of everything either identity can reach.

Short-lived credentials make that intersection enforceable. SPIFFE, for example, defines cryptographically verifiable workload identity documents designed to be issued and rotated rather than treated as permanent shared secrets. The exact credential technology can vary. The operating principle should not: an agent's usable authority should be narrow, renewable, observable, and independently revocable.

Legacy systems sometimes require one account at the boundary. In that case, map the account one-to-one to the agent where possible, store the relationship in the agent record, mint task-specific sessions behind it, and preserve the human delegation separately. A compatibility constraint should not become the enterprise identity model.

Effective access should be the intersection of agent policy, delegating-principal authority, task scope, and current risk conditions.

Human approval is often inserted as a safety control: the agent proposes an action, and a person clicks approve. That can be valuable, but the click should create or satisfy a specific authorization condition. It should not cause the agent to inherit the approver's session or turn every later action into a human action in the logs.

An active IETF Internet-Draft on AI agent authorization makes the same distinction: user confirmation alone is not authorization unless it is bound to a verifiable authorization grant. Because this is draft standards work, its terminology and recommendations can change. The underlying control question is stable: what exactly did the person authorize, for which agent, action, resources, and time window?

Treat the approval as a signed decision record with an expiry and replay protection. If the agent changes the transaction, recipient, amount, data class, or tool after approval, require a new decision when the policy says the risk changed. A generic approval prompt cannot repair an over-broad identity model.

An agent rarely acts alone. It calls model endpoints, browsers, code runners, databases, SaaS APIs, and sometimes other agents. Each hop creates an opportunity to launder authority: a narrowly authorized parent calls a broadly privileged tool, or a subagent receives a credential without the task constraints that justified it.

Do not pass a reusable bearer token down the chain when a derived, audience-bound credential can represent the smaller downstream job. Record the parent agent, child agent or tool, original principal, derived scope, and result. The child must never gain more authority than the parent grant permits, and the parent should remain accountable for why the delegation occurred.

This chain belongs in the same operating record as the agent's governance controls and run-level observability. Identity without execution evidence proves who connected, not whether the resulting work stayed inside the mission.

Every delegation should reduce or preserve scope. If a downstream tool gains authority, the chain has become a privilege-escalation path.

NIST's AI Agent Standards Initiative includes agent identity and authorization among the infrastructure needed for secure human-agent and multi-agent interactions. Its related concept work highlights identification, authorization, auditing, and non-repudiation. The operational implication is that identity cannot be a token issued once at deployment; it needs an owned lifecycle.

Register the agent before it touches production. Name a business owner and technical sponsor. Record its model, harness, allowed environments, credential issuers, data classification, and delegation policy. Set an expiry or review date. Make disabling the agent separate from disabling an employee, and make revoking one task grant separate from retiring the agent completely.

Then connect identity changes to the rest of the control system. A new model, tool, permission, owner, or deployment environment should trigger re-evaluation. A suspicious run should support immediate containment. The agent's sandbox and credential boundaries should assume that a valid identity can still receive a malicious instruction or make a bad decision.

Register

Create a unique agent record, owner, sponsor, purpose, version, and approved environments.

Issue

Mint short-lived credentials only after agent policy, principal authority, and task scope agree.

Observe

Log the acting agent, authorizing principal, grant, tool chain, decision, and outcome.

Review

Re-evaluate access after material changes, incidents, inactivity, ownership changes, or scheduled expiry.

Revoke

Stop one grant, one credential, one agent version, or the entire identity without depending on a user's account.

NIST is organizing standards work, the IETF is developing an authorization architecture, SPIFFE provides established workload-identity building blocks, and major cloud identity platforms now model agents as distinct principals. These are meaningful signals of convergence around first-class agent identity, bounded delegation, and richer audit evidence.

They are not one completed standard. Product capabilities differ, protocols are still evolving, and many business applications cannot yet consume agent-aware claims. Teams should avoid waiting for a perfect universal identity layer, but they should also avoid hard-coding one vendor's current object model into every policy decision.

Keep the durable facts portable: the agent that acted, the principal that authorized it, the mission, the resources and actions allowed, the constraints, the delegation chain, the expiry, and the outcome. Credentials and enforcement adapters can change around that record.

The goal is not a more elaborate login. It is the ability to constrain, explain, and revoke agent work without confusing the agent with the person it represents.