AI agent identity in 2026: user delegation, service accounts, or agent principals?

If you are giving an AI agent access to a B2B product, the first identity question is not “which OAuth library should we use?” It is “who is honestly responsible for this action?”

That sounds obvious until an agent sits between a signed-in user, a queue, a model provider, an MCP server, three SaaS APIs, and a second agent. Then a single request can carry several identities, several tokens, and several ideas about who approved what.

My short recommendation: use delegated user access for an interactive action that genuinely belongs to a signed-in user. Use a workload or service identity for unattended, system-owned work. Add a distinct agent identity and short-lived task credential when you need to tell agents apart, revoke one agent without revoking its siblings, or preserve a delegation chain across tools and agents. Put downstream credentials in a controlled gateway or runtime when the model should never see them. Keep authorization in your application, where the exact actor, tenant, resource, action, and approval can be checked.

Do not copy a human’s long-lived token into a model context. Do not call a broad service account “the agent identity” and assume the naming solved the problem. Do not let the model provide an agent_id in a tool argument and treat that string as proof. Those shortcuts make a demo connect. They do not tell you who may do what, what the action was for, or how to stop one bad run.

The short answer: pick the honest principal

Most B2B teams do not need to invent a new identity system on day one. They need to stop hiding an important choice inside a token configuration file.

Start by putting the workflow into one of these lanes:

This is a recommendation, not a protocol requirement. There are legitimate hybrids. A user can start a job that runs asynchronously under a workload identity while carrying a verified reference to the user and approval. A gateway can hold a vendor credential while issuing a short-lived, task-specific token to an agent. An enterprise can give every agent a distinct identity and still require user delegation for particular records.

The important thing is to keep the layers visible. A human principal, an agent principal, a workload identity, a credential holder, and an authorization decision are related, but they are not interchangeable.

Identity, authentication, authorization, and delegation are different

Many agent security conversations become foggy because they use “auth” for four separate jobs. You can make the architecture easier to reason about by giving each job a plain-English question.

• Identity: what entity is this? It might be a person, an application, a workload, an agent, or a particular task instance.
• Authentication: how did the system verify that claim? A signed token, mTLS certificate, managed identity, session, or workload-attested credential may be involved.
• Authorization: may this authenticated entity perform this operation on this resource under the current policy?
• Delegation: did one principal grant a narrower authority to another principal, and can the system preserve that relationship?
• Credential custody: where is the secret, key, or token stored, and which component is allowed to use it?
• Audit: what evidence lets an operator reconstruct the actor, grant, target, action, result, and decision later?

A token can authenticate a caller without authorizing the action you care about. A service account can identify a workload without telling you which customer initiated a request. A user session can prove who is present without granting an agent permission to send a message to every contact in the company. A gateway can keep a refresh token out of the model while still forwarding an over-broad operation if the application policy is weak.

NIST’s current work on agent identity calls these concerns out separately. Its February 2026 concept paper asks how organizations should identify agents, manage key issuance and revocation, apply least privilege when actions are not fully predictable, handle “on behalf of” delegation, bind agent and human identities for human-in-the-loop decisions, and create verifiable logs. The companion NIST guidance published on August 27 warns that credential sharing creates accountability gaps and argues for unique agent identifiers, credentials, and entitlements bound to the operating user or system. Those documents describe a direction of travel, not a finished universal recipe.

That distinction gives you a useful debugging move. When a tool call is denied, ask which layer failed:

1. Was the caller not authenticated?
2. Was the token valid but intended for another resource?
3. Was the identity valid but outside the tenant or scope?
4. Was the action allowed in general but not under this task or approval?
5. Did the tool run under the wrong credential because a gateway confused custody with authority?
6. Did the system fail to record enough evidence to answer any of those questions?

If your design cannot answer these separately, it is too early to talk about “autonomous identity” as if it were a single feature.

Four questions that choose the identity shape

Before selecting a grant type or buying an agent IAM product, write down four answers. These answers are more durable than any current vendor dashboard.

1. Who owns the action?

If Alice asks an assistant to summarize her customer records, the action starts with Alice. That does not mean the agent should inherit every right Alice has. It means the system should be able to prove the relationship between Alice, the agent, the request, and the allowed record set.

If a nightly process checks for duplicate invoices, there may be no human owner in the moment. The system or finance operations team owns the action. A workload identity is more honest than pretending a person is logged in at 2:00 a.m.

If an orchestration agent asks a specialist agent to prepare a shipping exception, there are at least two software principals and perhaps a human or workflow owner above them. A stable agent identity plus a task grant can preserve the chain. If you collapse everything into one shared bearer token, the downstream service cannot tell whether the request came from the orchestrator, the specialist, or a different tenant using the same connector.

2. Is a human present when the permission matters?

A user can consent to an interactive connection, review a proposed message, or complete a step-up challenge. That is useful, but it has a time boundary. A consent screen is not a permanent license to act forever, and “the user once connected the app” is not proof that the user approved a particular destructive action.

When no human is present, design for a system-owned action with bounded authority. That usually means a job contract, explicit schedule, limited resource set, short-lived or automatically rotated credentials, and a way for an operator to pause or revoke the workload.

Some workflows start interactively and finish in the background. In that case, save the user’s verified identity and the exact approved task as application state. Do not keep the browser session alive as a substitute for a job identity. The BishopTech guide to AI agent background jobs covers why the request channel, job record, and workflow state should be separate.

3. Do you need per-agent or per-task revocation?

One shared credential is attractive because it is simple. It is also a problem when an organization needs to answer, “Which agent did this?” or “How do we stop only that agent?”

If the whole product has one assistant, one tenant, one narrow read-only tool, and one operator, an application principal with a small scope may be enough. If a tenant can create several assistants, a platform can hand tasks to third-party agents, or an orchestrator can spawn short-lived workers, the identity boundary becomes more valuable.

Per-agent identity does not require every token to be permanent. In fact, the better pattern is often a stable identity record for inventory and ownership plus short-lived credentials for each run or delegated task. The stable record answers “which agent is this?” The task credential answers “what may this instance do right now?”

4. What exact resource is being accessed?

“The CRM” is not a resource policy. The resource might be one tenant’s contacts, a single project, a read-only report endpoint, a specific mailbox, or one tool surface inside an MCP server. The more specific the target, the easier it is to issue a credential that cannot be replayed somewhere else.

RFC 8707 gives OAuth deployments a standard resource parameter for naming the target service and applying audience restrictions. It specifically discusses making a resource identifier specific enough to help prevent cross-tenant misuse and warns that tokens valid for multiple audiences require a high degree of trust between those resources. The practical lesson is simple: do not request one broad token because several downstream services happen to be convenient to call from the same agent.

Option one: delegated user access

Delegation is the right starting point when a signed-in user is asking an assistant to work with data or operations that belong to that user. Think of a support copilot locating an order, a sales assistant drafting a renewal brief, or an operations user asking for a report from the records that person is already allowed to see.

The clean mental model is not “the agent becomes the user.” It is “the user grants this client or agent a defined slice of authority, and the resource server can see enough context to enforce it.” The user remains the source of the grant. The agent remains a separate software component. The application still checks the operation.

Where delegation fits

• The request begins in an authenticated user session.
• The data belongs to the user’s tenant, workspace, or assigned role.
• The user can understand the connected surface and revoke it.
• The operation can be downscoped to the records and actions needed for the job.
• The system can re-check the user’s current role and resource policy before a consequential write.

Delegated access is especially useful for customer-facing products because it lets each customer connect their own account instead of handing your service a shared organization-wide secret. It also gives the resource server a better basis for tenant isolation than a free-form string in a prompt.

What delegation does not mean

Delegation does not mean the agent gets every permission the user could ever obtain. Ask for only the scopes and resources needed. It does not mean the agent should store the user’s refresh token in a conversation transcript. It does not mean approval from yesterday applies to a changed target today. It does not mean the agent may forward the user’s token to a downstream service that was not the intended audience.

The current MCP authorization specification is a useful concrete example. It describes an MCP server as an OAuth resource server and an MCP client as an OAuth client acting on behalf of a resource owner. It requires protected-resource metadata discovery, calls for resource indicators, and says servers must validate that tokens were issued for them. It also says an MCP server calling an upstream API must use a separate upstream token rather than pass through the token it received from the client. The protocol is doing important work at the transport boundary. Your product still has to decide which user, tenant, tool, record, and operation are allowed.

Delegation failure modes

Stale role: the user changes teams, loses access, or leaves the organization while a refresh token remains available. Re-check current authorization at the resource server; do not treat a previously issued grant as a timeless business entitlement.

Scope inflation: the first connection asks for read access, then a later feature quietly reuses the same grant for writes. Make permission changes visible and use a step-up path for new capabilities.

Token confusion: a connector token is accepted by both the MCP surface and normal account endpoints. Use separate audiences or token classes where practical, and reject tokens not intended for the receiving resource.

Unclear consent: a user clicks “Allow” without knowing whether the agent can read a whole workspace or only one project. Explain the actual resource and action surface in product language, not just provider scope names.

Background drift: an interactive task becomes an asynchronous job, but the system continues to rely on the user’s browser token. Persist a verified task grant and run the job through a controlled workload path with explicit expiry and revocation.

The best test is not “did OAuth complete?” It is “after the user changes role, tenant, scope, target, or approval, does the next tool call get the right answer?”

Option two: workload or service identity

A workload identity represents software acting for a system or organization rather than a person who is actively clicking through the workflow. It is the honest choice for scheduled processes, queue workers, internal data movement, reconciliation, indexing, and other bounded automation.

The phrase “service account” is familiar, but it can hide very different implementations. A static key in an environment variable, a cloud-managed identity, a SPIFFE workload identity, and a short-lived OAuth client-credentials token all express different security properties. The useful question is not whether the credential is called a service account. It is whether the runtime can prove which workload is running and obtain only the authority it needs.

Where workload identity fits

• The work should continue without a person present.
• The system owns the schedule, queue, or business process.
• The allowed data and operations can be bounded in advance.
• The workload can obtain credentials through its runtime or identity provider rather than receiving a copied long-lived secret.
• An operator can see, rotate, disable, and replace the workload independently of human accounts.

A service identity is not an excuse to erase user context. A customer-triggered export might run under a worker identity but still carry a verified customer, tenant, resource, and approval reference. The worker is the authenticated execution identity. The application can still enforce the user’s grant and record the relationship.

What current workload systems show

AWS’s current AgentCore documentation describes workload identities as a stable anchor for agents across deployment environments and authentication schemes, including IAM roles, OAuth2, and third-party API keys. Its token guidance shows a user-and-agent binding when an inbound JWT is available and explicitly warns that a caller-supplied user ID is an opaque string without identity-provider verification. That is a useful distinction even if you never use AgentCore: a label supplied by the calling workload is not the same as cryptographic proof of the user.

SPIFFE takes a different, provider-neutral route for workload authentication. Its documentation describes a workload API that can provide an identity document and private key without co-deploying application authentication secrets, and it describes short-lived credentials that rotate automatically. It also says deciding when a workload should assume which identity is site-specific. That last sentence matters. SPIFFE can help prove what workload is running; it does not decide whether that workload should export a tenant’s records today.

Microsoft’s Entra Agent ID documentation shows another direction: agent identities modeled as service principals with agent-specific behaviors, lifecycle management, sponsors, and separate permission/audit concepts. Its service-principal guidance notes that a blueprint may hold credentials while individual agent identities hold permissions and audit identity, making the blueprint count a security-boundary choice. That is Microsoft’s model, not a universal standard, but it demonstrates why “one service principal for all agents” can be too coarse.

The service-account traps

One account for every tenant: easy to deploy, difficult to reason about. A tenant bug becomes an organization-wide access problem, and audit logs cannot explain which customer the agent was acting for without trusting application metadata.

One account for every action: the opposite extreme can create a forest of identities nobody owns. Prefer a small number of deliberate boundaries tied to blast radius, lifecycle, and policy, not an identity per function name.

Static secret as identity: a shared API key proves possession of the key, not the origin, task, or instance that used it. If the key leaks, every caller looks the same until you rotate it.

Unbounded background autonomy: “the job runs without a user” does not imply “the job can do whatever the service account can do.” Give the job a state machine, step limit, target allowlist, expiry, and a failure path.

Human-shaped records: some systems require an account that looks like a user. If you must use one for compatibility, make the non-human nature visible in your inventory and audit trail. Do not hide an agent behind a departed employee’s account.

Option three: an agent principal plus a task grant

A distinct agent principal becomes useful when the agent itself is a meaningful unit of ownership. Maybe a customer can create several agents with different jobs. Maybe one orchestration system delegates to specialist agents. Maybe an enterprise needs to retire one agent, inspect its activity, or restrict it to a particular toolchain without changing the person or platform identity around it.

The design I prefer is a two-part identity:

1. Stable agent record: agent ID, owner or sponsor, tenant, version, declared purpose, lifecycle status, allowed capabilities, and links to policy.
2. Ephemeral task or run credential: agent ID, instance or run ID, initiating principal, parent actor when relevant, task or grant ID, audience, scopes, expiry, and a unique token identifier.

The stable record is for inventory, governance, and revocation. The short-lived credential is for execution. Combining both lets an operator say, “This is the Invoice Triage agent, instance 7c…, acting for Northwind’s finance team on task 94…, with read-only invoice access until 14:30.” It is far more useful than “some bearer token called the finance bot.”

Token exchange gives the chain a vocabulary

RFC 8693 defines OAuth token exchange for requesting a new security token from an authorization server and distinguishes impersonation from delegation. It also describes an act claim for identifying the actor to whom authority was delegated. You do not have to implement every part of RFC 8693 to adopt the underlying idea: a downstream token can be issued for a narrower audience and can retain information about who is acting.

For example, a signed-in user might start a job. An orchestrator authenticates the request and asks an authorization service for a token limited to the invoice-review agent. The agent then asks for a second token limited to the document store and one tool surface. The downstream service can validate the token’s audience and policy while the audit system records the user, orchestrator, agent, task, and tool.

That is delegation. Passing the original user token through every hop is not the same thing. It spreads one credential across components that may not be equally trusted, makes audience validation harder, and can create a confused-deputy path where a service uses a token it was never meant to receive.

When is a distinct agent worth the cost?

Use a separate agent principal when at least one of these is true:

• Customers or operators need to see which agent performed an action.
• One agent should be revoked without affecting other agents using the same user or platform.
• Different agents have meaningfully different scopes, tools, data boundaries, or owners.
• Agents delegate to other agents and the downstream service must validate the caller chain.
• A security, compliance, or operations workflow needs a non-human identity with its own lifecycle.
• The same user may start several simultaneous tasks that must not share a reusable authority.

Do not add a new principal merely because “agents are the future.” If your product has one narrow assistant that only drafts a report for the current user, a small application identity plus delegated user context may be simpler and clearer. The identity boundary should match the question an operator needs to answer, not the number of nouns in your architecture diagram.

Credential custody: the agent should not hold every key

There is another decision hiding inside identity architecture: which component actually holds a credential for a downstream system?

A model context is a poor place for a long-lived refresh token, API key, private certificate, or service-account key. The model may be exposed to retrieved documents, tool descriptions, logs, screenshots, prompt injection, and third-party content. Even when the model provider is trusted, a credential inside the reasoning context is harder to limit, rotate, inspect, and prevent from appearing in a trace.

A gateway, broker, or managed runtime can hold the downstream credential and expose a typed operation instead. The agent asks for get_invoice_status with a tenant-scoped invoice ID. The broker resolves the appropriate downstream token, checks the caller and policy, calls the service, redacts the result, and writes an audit event.

This pattern reduces credential exposure, but it does not magically authorize the request. A broker that accepts any caller-provided tenant ID or forwards any tool name is just a credential-holding confused deputy.

Custody is not authority

Ask two separate questions:

• Who holds the credential? The user device, agent runtime, MCP server, gateway, cloud workload, or identity vault?
• Who decides the operation is allowed? The resource server, application policy engine, tenant authorization layer, human approval service, or a combination?

The answer can be different. AWS documents AgentCore as a system that stores and retrieves external credentials through a workload identity. The MCP specification describes a server that may act as an OAuth client to an upstream API, but must not pass through the client’s token. Anthropic’s tunnel discussion has generated public interest because it moves credentials toward a customer-controlled perimeter rather than leaving them in the agent context. That discussion is a practitioner signal, not proof that a tunnel is right for every team. The durable principle is the separation: the model proposes a call, a controlled component uses the credential, and application policy decides whether the call is allowed.

A useful broker contract

A brokered tool should be able to show:

• The authenticated caller and any initiating user.
• The tenant, workspace, project, or resource boundary.
• The named operation and validated arguments.
• The downstream audience and credential class used.
• The policy version and approval or grant reference.
• The result status, redacted output reference, and retry or idempotency key.
• The reason the call was denied, paused, or escalated.

If the broker cannot provide that receipt, you may have improved secret storage while leaving the most important accountability question unanswered.

What MCP and A2A solve—and what they leave to you

Protocols matter because agents increasingly need to discover and call tools or other agents outside one codebase. But a protocol’s authentication flow is not the same as your product’s identity model.

MCP: an authorization transport, not your whole IAM system

The current MCP documentation is moving quickly. The July 28, 2026 release announcement says the protocol hardened authorization, bound client credentials to the issuer that minted them, and began formally moving from Dynamic Client Registration toward Client ID Metadata Documents. The detailed versioned authorization page describes protected-resource metadata, OAuth discovery, resource indicators, scope selection, PKCE, audience validation, and a prohibition on token passthrough.

Those are valuable guardrails for remote tool connections. They do not answer product questions such as:

• Which customer or tenant does this user belong to?
• Which records may this agent read?
• Does this specific tool call count as a write or an external commitment?
• Does the user’s approval cover this changed argument?
• How do we revoke one agent without disconnecting every customer?
• How do we reconcile a timeout after the downstream write may have happened?

A current research preprint on remote MCP authentication is a useful warning against treating conformance as completion. The study reports that 40.55% of the 7,973 live remote MCP servers it identified exposed tools without authentication. In a tested subset of 119 OAuth-enabled servers, it reports at least one flaw in every server and 325 flaws overall. Those figures belong to that study and methodology, not to every deployment on the internet, but they make the point: adding OAuth endpoints does not remove implementation risk.

Public builder discussions show the same friction from another angle. A recent r/mcp post compares clients that differ in their support for static bearer tokens, Dynamic Client Registration, and newer metadata flows. Another recent implementation report says separate connector tokens scoped to the MCP surface and live testing were necessary because client discovery and registration behavior differed. These are anecdotes, not compatibility standards. Use them as a reason to test the actual clients you promise to support.

A2A: declare the agent, authenticate the request, preserve the chain

The A2A specification treats agents as enterprise applications and keeps identity at the protocol/security layer. An Agent Card describes an agent’s identity, capabilities, skills, endpoint, and authentication requirements. The server must authenticate each request and apply its own authorization policy. For in-task authorization, the specification recommends secure out-of-band credential delivery; it warns that in-band credential exchange can expose credentials across a chain and recommends binding credentials to the originating agent when that pattern is used.

That is a sensible starting point. The downstream agent should not simply trust a sentence saying “the user approved this” in the message payload. It should validate the caller’s credential, the audience, the declared capability, the task reference, and its own resource policy.

The open A2A issue on authentication-scheme declaration shows that the ecosystem is still working through the practical edge: a client may see that an agent requires OAuth but not know how to acquire a usable token, which grant to use, or which authorization server is intended. That is an open issue, not a settled defect in every implementation. It does mean your rollout plan should include a real credential-acquisition walkthrough and a client/server compatibility matrix.

The protocol/product boundary

The ecosystem is converging on more identity-aware infrastructure. It has not converged on a universal answer to intent, behavioral trust, or accountability across every vendor boundary. Build your product boundary so that a protocol change does not silently rewrite your authorization policy.

The boundary that stops identity from becoming a costume

Identity is useful only when it connects to an enforceable boundary. In a multi-tenant B2B product, the minimum set usually includes actor, tenant, resource, action, audience, and time.

Tenant is not a prompt field

Do not ask the model to decide which tenant it is in from a natural-language conversation. Resolve tenant context from the authenticated principal and the server-side relationship between that principal and the resource. A user can mention another company in a prompt. That does not grant access to that company’s records.

Similarly, do not trust a model-supplied workspace_id, customer_id, or agent_id without checking it against the authenticated caller and policy. Tool arguments are data to validate. They are not proof of identity or authority.

Audience is not decoration

A bearer token is dangerous when it is accepted by more services than necessary. Use audience restrictions so a token issued for one tool surface is not automatically valid at another API. The MCP authorization documentation and RFC 8707 both emphasize this. An MCP server that calls an upstream service should obtain or exchange a separate credential intended for that upstream resource.

One broad multi-audience token may reduce round trips, but it also increases the trust relationship and the blast radius of theft or misrouting. Make that a conscious tradeoff, not an accidental result of reusing a token object across clients.

Scope is not the whole policy

Scopes are useful for coarse capability such as invoices:read or messages:draft. They rarely express the whole B2B policy. The application may still need record ownership, region, data classification, approval state, time window, rate limit, amount threshold, or a separation-of-duties rule.

Use scopes to narrow the surface, then use application policy to evaluate the exact request. A token with invoices:read can still be blocked from another tenant’s invoice. A token with messages:send can still be blocked when the recipient is outside an allowlist or when no current approval covers the content.

Task is the missing middle

A stable user or agent identity is often too broad for one high-impact operation. Add a task or grant record that says what this run is trying to do, who initiated it, which resource and arguments were approved, when the grant expires, and whether it has already been consumed.

This is the difference between “the agent may send email” and “the agent may send this approved draft to these three recipients before 4:00 p.m.” The latter is easier to review, expire, audit, and revoke.

Use an identity receipt

For each consequential tool call, keep a redacted receipt with fields such as:

Do not log raw tokens, secrets, full sensitive documents, or an unredacted prompt just to make the receipt detailed. The receipt should help an operator reconstruct the decision without creating a new credential or privacy leak.

Identity is a lifecycle, not a login screen

Teams often spend a week making the first token work and almost no time deciding how the identity will be retired. Agent systems need the whole lifecycle because they can be created quickly, copied across environments, delegated to, and forgotten after the person who configured them moves on.

Provision

Create an inventory record with a human or team owner, tenant, purpose, environment, capabilities, allowed protocols, and data classification. If the platform uses an agent blueprint, template, or application registration, decide which parts are inherited and which are instance-specific.

Give the agent a stable identity only when it earns one. A temporary experiment can use a development workload identity with isolated data. A production agent should not appear as an anonymous test client that was accidentally promoted.

Authenticate and issue

Prefer credentials that are short-lived, audience-bound, and issued for the current runtime or task. OAuth’s current security best practice recommends stronger code-flow protections and sender-constraining options where feasible. SPIFFE’s model uses short-lived workload credentials. Cloud providers increasingly expose managed identity and workload-token patterns. The exact mechanism differs; the direction is away from long-lived shared secrets.

At issuance time, include the context the resource server will need to enforce policy: subject, actor or agent, audience, scopes, tenant or resource, expiry, and a unique identifier. If the identity provider cannot carry a field, store the relationship in a server-side grant record rather than letting the model invent it.

Authorize and re-check

Authentication at the start of a run is not enough when the run can last minutes, call several services, or wait for approval. Re-check the important boundary at the point of action. Verify the token, audience, tenant, tool, arguments, current role, task state, approval, and expiry.

For a low-risk read, that can be lightweight. For a permission change, external message, financial operation, public publication, or destructive write, make the policy decision explicit and keep a human approval tied to the exact arguments when the risk requires it.

Rotate, revoke, and offboard

Design the stop path before the happy path. A useful stop path can:

• Disable one agent or workload without disabling the entire customer integration.
• Invalidate outstanding task grants or leases.
• Revoke or rotate downstream credentials held by a broker.
• Prevent new token issuance while allowing safe reconciliation of in-flight work.
• Show which records, messages, or external calls may have been affected.
• Preserve enough audit evidence to investigate without keeping unnecessary sensitive data forever.

Microsoft’s agent identity guidance emphasizes owners, sponsors, lifecycle governance, and retirement without orphaned credentials or permission assignments. That is enterprise product terminology, but the operational idea applies to a small SaaS too: someone owns the identity, someone can disable it, and the system can prove what happened after disablement.

Recover after partial failure

Suppose the agent submits a ticket, the network times out, and the response never arrives. The identity design should help you determine whether the request was accepted, whether the token was used, whether the task grant was consumed, and whether a retry is safe.

Use idempotency keys for side effects. Look up the existing downstream result before retrying. Keep the task state separate from the model’s natural-language explanation. A sentence saying “I did not send it twice” is not a duplicate-prevention mechanism.

If a run is revoked during a multi-step plan, the orchestrator should stop issuing new credentials and the resource server should reject later calls. Do not rely on the model remembering that it was revoked.

How to evaluate an identity-aware agent

Identity design is not complete when the happy-path login works. The useful evaluation question is whether the system keeps the right principal and policy boundary as the workflow changes.

Use deterministic checks for exact identity properties and trace or outcome checks for the full run. The BishopTech guide to B2B AI evals explains why a final answer score cannot replace path, authorization, and outcome evidence.

Start with these test cases

1. Wrong audience: present a valid token issued for another API and verify the tool rejects it before processing the request.
2. Wrong tenant: use a real user from Tenant A with a resource identifier from Tenant B and verify server-side policy denies the call.
3. Forged agent field: put a different agent_id in tool arguments or message metadata and verify the authenticated identity does not change.
4. Shared token: run two agents with the same bearer credential and confirm the system can either distinguish them through a trusted mechanism or explicitly records that it cannot.
5. Delegation chain: have a user start an orchestrator, the orchestrator delegate to a specialist, and verify the downstream service sees the allowed chain without receiving the original upstream token.
6. Scope step-up: begin with read access, request a write, and verify the new authority requires the intended approval or consent path.
7. Expired task: let a task credential expire while the agent is still planning and verify that a later write is denied or re-authorized.
8. Revoked sibling: revoke one agent or run and verify another agent under the same user or platform identity continues only if policy says it should.
9. Credential theft simulation: place a fake secret in retrieved content or a tool result and verify the model cannot use it to broaden access or cause a new token to be issued.
10. Partial write: force a timeout after a downstream side effect and verify idempotency, reconciliation, and audit state before allowing a retry.
11. Protocol drift: test every supported MCP or A2A client against discovery, token acquisition, redirect, scope, and error behavior after a protocol or SDK upgrade.

These cases test more than “is the token valid?” They test whether the system preserves identity and authority under the conditions that make agent workflows different from ordinary API calls: model-selected tools, dynamic paths, nested delegation, untrusted content, asynchronous execution, and partial failure.

What to record

Do not collapse all of this into a “security score.” A system can authenticate correctly and still violate tenant isolation. It can preserve the identity chain and still send the wrong recipient. It can pass a scope check and still fail to reconcile a duplicate write. Keep the failure reason attached to the evidence that can fix it.

Build, buy, or postpone the identity layer

There is a healthy temptation to buy an agent identity platform as soon as the vocabulary gets complicated. There is also a healthy temptation to build one small policy boundary instead of adopting a control plane before the workflow exists. The right choice depends on the problem already visible.

Build a small boundary when

• You have one or two known workflows and can name their owners and resources.
• Your current identity provider already supports the needed user, workload, or service credentials.
• You can keep authorization in a small, tested application boundary.
• You can issue short-lived task records, log redacted receipts, and revoke the relevant integration.
• You are still learning whether customers need per-agent identity or only user delegation.

A small boundary does not mean a single secret. It means a small, explicit contract: verified caller, server-resolved tenant, typed tool, scoped resource, policy decision, approval state, result, and stop path.

Buy or adopt a control plane when

• Many teams are creating agents and ownership is becoming difficult to inventory.
• Customers need centralized lifecycle, policy, access reviews, sponsor changes, or offboarding.
• You need several identity providers, protocols, credential types, or execution environments.
• Per-agent audit, delegated token exchange, secrets custody, and revocation are taking more time than the product differentiator justifies.
• The platform can export enough evidence and preserve a migration path if your provider mix changes.

Read the product documentation carefully. Ask where authorization runs, whether the identity chain survives downstream calls, how tokens are scoped and rotated, what the platform logs, which data it retains, and how a customer disconnects. A control plane that centralizes credentials without showing the policy decision may improve operations while weakening explainability.

Postpone or stay read-only when

• No one owns the agent identity or can revoke it.
• The resource server cannot distinguish tenants or verify the audience.
• The first version needs a broad service account because the team has not mapped the workflow.
• The system cannot prove whether an external side effect happened.
• The only approval is a vague instruction in a prompt.
• Protocol compatibility is untested for the clients customers will actually use.

Postponing an identity feature is not a failure. It can be the correct product decision when the identity would only give an undefined agent more ways to make an undefined change. Start with a report, recommendation, draft, or read-only query and use the evidence to shape the next boundary.

A practical 30-day pilot

You can learn a lot about the right identity shape without building a full agent platform. Keep the first month narrow enough that every permission and failure has a name.

Days 1–3: map the action

Write down the current process before adding the agent:

• Who starts the work?
• What is the source of truth?
• Which records and tenants are in scope?
• Which steps are read, recommend, draft, reversible write, external commitment, or destructive write?
• What must be true before the job counts as complete?
• Who can pause, revoke, or correct it?

Choose one lane: delegated user, workload, or agent-plus-task. Write down why the other lanes are not the starting point. That explanation will help later when the implementation grows.

Days 4–7: create the identity contract

Define the principal fields, audience, tenant lookup, allowed scopes, task expiry, approval condition, and redacted receipt. Decide where credentials live. Add a deny path for wrong audience, wrong tenant, expired grant, missing approval, and unknown tool.

If the workflow is user-facing, make the consent language describe the actual surface. If it is unattended, document the system owner and schedule. If it is multi-agent, document the parent and child relationship and what the downstream service is expected to verify.

Week 2: run read-only or draft-only

Give the agent the smallest useful tool. Keep the data boundary tight. Store the identity receipt alongside the run record. Let a human compare the output to the source of truth. Make the model explain uncertainty without letting it widen scope.

For MCP, test the exact client discovery and token flow you will support. For A2A, test Agent Card retrieval, declared security schemes, credential acquisition, and the downstream server’s caller verification. Keep protocol compatibility separate from your product’s authorization checks.

Week 3: add adversarial and recovery cases

Replay the wrong-tenant, forged-agent, expired-token, revoked-run, token-reuse, prompt-injection, and partial-write cases. Include legitimate edge cases too: a user with several roles, a tenant with several workspaces, an agent that needs one additional scope, and a downstream API that returns an empty or delayed result.

Ask an operator who did not write the integration to reconstruct a failed run from the receipt. If they cannot tell who acted, what was approved, and whether the effect happened, improve the evidence before adding another tool.

Week 4: decide what has earned promotion

Keep the system in shadow, recommendation, or draft mode while you inspect actual corrections and denials. Measure review time and failure categories, but do not invent a success percentage from a small or undefined sample. The point is to discover whether the chosen identity is sufficient and whether the policy boundary holds.

Promote only a narrow action that has a clear owner, verifiable outcome, appropriate identity, tested recovery, and a stop path. Keep money movement, sensitive exports, permission changes, public publishing, destructive updates, and irreversible external commitments behind a deliberate authorization design and, where appropriate, human review.

What the current evidence says—and what it does not

There is a real shift underway. NIST is researching agent authentication and identity infrastructure. Microsoft and AWS are documenting agent-specific or workload identity models. MCP has released new authorization hardening and A2A is formalizing agent discovery and declared security schemes. The current ecosystem is spending serious effort on identities, credentials, delegation, and lifecycle.

The evidence does not say that every B2B product needs a new “agent user.” It does not say that an agent registry proves behavior. It does not say a signed Agent Card proves that the agent will stay within its declared skills. It does not say OAuth alone captures intent or makes a high-impact operation safe.

The public implementation signals are especially useful here because they reveal the gap between a specification and a working connection. Builders describe different clients choosing different OAuth flows, discovery paths that fail silently, shared tokens that cannot distinguish agents, and the need to keep connector tokens separate from normal account sessions. Those reports are qualitative and self-selected, but they tell you where to put live compatibility tests and what questions to ask a vendor.

One current study of remote MCP deployments provides a harder challenge to easy optimism: it found widespread missing authentication in the population it scanned and at least one flaw in every OAuth-enabled server in its tested subset. Treat those numbers as research findings with methodological limits, not as a universal incident rate. The practical conclusion survives the caveat: the identity layer deserves testing at the actual resource boundary.

What I would predict next

This section is inference, not a reported fact or a guarantee.

I expect agent identity systems to separate into three connected but distinct records: a durable inventory identity for the agent, a workload identity for the runtime, and a short-lived authorization grant for the task. A user or upstream system may sit above that chain. A tool or downstream agent may sit below it. The winning implementation will make the chain inspectable without forcing every service to understand every model provider.

I also expect identity products to move closer to policy and credential custody. Buyers will care less about a dashboard that lists agent names and more about whether it can answer: which agent had access to which resource, through which workload, under which user or system grant, with what expiry, and what happened after revocation?

That does not mean a registry will become a reputation system. A cryptographically identifiable agent can still choose a poor tool, follow malicious content, misunderstand a user, or produce a wrong result. Identity tells you who acted. Authorization tells you whether the action was allowed. Evaluation tells you whether the path and outcome were acceptable. Keep those questions separate.

Portable delegation across MCP, A2A, APIs, and cloud workloads may improve. It may also create more trust edges to configure. Every new protocol makes connection easier for both useful and dangerous capabilities. The safest product shape is still a controlled system where identity, policy, approval, and recovery remain visible around the model.

FAQ

Should an AI agent use the user’s OAuth token?

Use delegated user access when the user is authenticated, the action belongs to that user, and the token can be downscoped to the needed resources and operations. Do not put a long-lived token in model context, pass it through unrelated services, or treat one past consent event as permanent permission. Re-check current authorization before consequential actions.

Is a service account enough for an AI agent?

It can be enough for a narrow, unattended, system-owned workflow. Use a workload or service identity with least privilege, short-lived or managed credentials, explicit tenant and resource policy, an owner, an expiry or schedule, and a tested stop path. A broad shared service account is usually a sign that the workflow boundary has not been mapped yet.

Does OAuth create a unique identity for each agent?

Not automatically. OAuth can authenticate a client, user, or workload, but if several agents present the same client credential or bearer token, the resource server may not be able to distinguish them. Add a trusted agent or task identity when per-agent audit and revocation matter. Do not trust an agent ID supplied only in a message or tool argument.

Does MCP solve authentication and authorization for my product?

MCP provides an authorization framework and discovery guidance for connecting clients to servers, especially over HTTP. It does not decide your tenant policy, business permissions, approval semantics, upstream credential strategy, or outcome verification. Treat MCP conformance as one layer of the integration and test the actual clients and downstream APIs you support.

How should agent-to-agent calls preserve authorization?

The downstream agent should authenticate the caller and authorize the requested skill or action using its own policy. Preserve the initiating user or system, parent agent, child agent, task, audience, scopes, and expiry in a trusted chain or server-side grant. Issue a new downscoped credential where possible. Do not pass a raw upstream bearer token through every agent.

Should the agent ever see an API key or refresh token?

Usually no. Keep downstream credentials in a gateway, broker, identity vault, or managed runtime and expose a typed operation. The broker still needs to validate identity, tenant, resource, action, and approval. Removing the key from the model context reduces exposure; it does not replace authorization.

What should I test first?

Test wrong audience, wrong tenant, forged agent metadata, expired and revoked grants, shared-token ambiguity, delegation across a second agent, prompt injection in retrieved content, and a timeout after a possible side effect. Keep the identity receipt and confirm an operator can tell who acted, what was allowed, and whether the effect happened.

When should I buy an agent identity platform?

Consider one when agent inventory, ownership, lifecycle, multi-provider credentials, policy, per-agent audit, or revocation is becoming a recurring platform problem across teams. Keep a smaller boundary when the workflow is narrow and the team can test and operate it. Postpone the purchase if you still cannot define the job, owner, source of truth, or resource scope.

Can agent identity guarantee safety or compliance?

No. Identity helps establish who or what acted. Authorization limits what it may do. Evaluation and monitoring test whether the system behaved acceptably. None of these alone guarantees behavior on unknown inputs, prevents every security failure, or replaces human judgment for high-impact decisions.

The practical next step

Take one workflow that is repeated often and write the action sentence: “For this actor, in this tenant, this agent may do this operation on this resource until this time.” Then list the evidence you would need after the run: verified identity, task or approval, audience, scope, tool arguments, downstream result, and recovery state.

If you cannot write that sentence without using words like “anything,” “wherever,” or “whenever the agent decides,” keep the first version read-only or draft-only. If you can write it, you have the beginnings of an identity contract that can survive a model change, a protocol change, or a new connector.

If you want help turning the real workflow into a bounded agent, gateway, or identity plan, start a scoped BishopTech consultation. Bring the messy version: the current users, systems, data, approvals, credentials, and failure cases. The useful first deliverable may be a build, a policy boundary, a compatibility test, or a decision to postpone.

Sources and further reading

The links below are dated references for the standards, product documentation, research, and public implementation signals used in this article. Vendor and project documentation describes its own system. Public discussions are included as qualitative evidence of implementation questions, not as universal statistics or technical authority.

1. NIST NCCoE — Back to the Future: Why Agentic AI Needs a Strong Identity Foundation ↗ — August 27, 2026. Credential sharing, accountability gaps, and first-class agent identity guidance.
2. NIST NCCoE — Accelerating the Adoption of Software and AI Agent Identity and Authorization ↗ — February 2026 draft concept paper. Identification, authentication, authorization, delegation, lifecycle, logging, and proof of authority.
3. NIST — AI Agent Standards Initiative ↗ — created February 17, 2026; updated August 14, 2026. Current standards and research direction for agent authentication and identity infrastructure.
4. Model Context Protocol — Authorization ↗ — 2025-11-25 specification revision. Protected-resource discovery, OAuth roles, resource indicators, audience validation, and token-passthrough limits.
5. Model Context Protocol — The 2026-07-28 Specification ↗ — July 28, 2026. Authorization hardening, issuer binding, and the move from DCR toward Client ID Metadata Documents.
6. IETF RFC 9700 — Best Current Practice for OAuth 2.0 Security ↗ — January 2025. OAuth security recommendations including code-flow protections and token replay defenses.
7. IETF RFC 8693 — OAuth 2.0 Token Exchange ↗ — January 2020. Delegation, impersonation, token exchange, and actor semantics.
8. IETF RFC 8707 — Resource Indicators for OAuth 2.0 ↗ — February 2020. Target resources, audience restrictions, downscoping, and multi-tenant considerations.
9. Microsoft Learn — What are agent identities? ↗ — updated June 15, 2026. Agent-specific identity, autonomous access, delegated access, sponsors, and audit visibility.
10. Microsoft Learn — Agent identities, service principals, and applications ↗ — updated April 30, 2026. Blueprint-to-agent relationships, credentials, permissions, and compromise boundaries.
11. AWS — Understanding workload identities in Amazon Bedrock AgentCore ↗ — accessed August 31, 2026. Stable workload identity across deployment and credential types.
12. AWS — Get workload access token ↗ — accessed August 31, 2026. Verified JWT-based user binding versus opaque user-ID handling.
13. A2A Project — A2A Protocol Specification ↗ — current main-branch specification accessed August 31, 2026. Agent Cards, authentication, authorization, and in-task credential handling.
14. SPIFFE — SPIFFE Concepts ↗ — current documentation accessed August 31, 2026. Workload identity, SVIDs, short-lived credentials, rotation, and workload API separation.
15. Zhou et al. — A First Measurement Study on Authentication Security in Real-World Remote MCP Servers ↗ — May 21, 2026 preprint. Empirical findings about unauthenticated remote servers and OAuth implementation flaws; figures are limited to the study’s methodology and tested subset.
16. r/mcp — MCP authentication across the big agents ↗ — July 6, 2026. Public implementation signal about client differences in OAuth and credential flows.
17. r/mcp — How are you handling agent identity in MCP? ↗ — date displayed relatively; accessed August 31, 2026. Public user signal about shared tokens, per-agent identity, and revocation questions.
18. r/mcp — Shipped OAuth on our MCP server so claude.ai and ChatGPT connectors can reach it ↗ — August 29, 2026. Public implementation signal about separate connector tokens, exact redirects, scopes, and live interoperability testing.
19. r/mcp — Anthropic's new MCP tunnel architecture: the agent never holds the credential ↗ — May 19, 2026. Public architecture signal about customer-controlled credential custody, mTLS, and the continuing need for scoping and audit.
20. A2A Project GitHub issue #1942 — Auth scheme declaration and credential discovery ↗ — open issue accessed August 31, 2026. Public implementation signal about token-acquisition gaps in agent discovery.