AI Agent Identity vs Authorization: What Identity Cannot Approve

Reviewed 17 August 2026 · 16 minute read

AI agent identity answers who or what is acting, who owns it and which credentials it controls. Authorization answers whether that agent may perform a particular action, on a particular resource, for a particular purpose, under current policy. Enterprise deployments need both. A verified identity becomes an input to the decision; it is not the decision itself.

Consider a merchant receiving a request from a known shopping agent. The TLS connection is valid. The OAuth token has the expected audience. The agent belongs to a large enterprise buyer.

May it place a EUR 50,000 order?

Nothing in that identity evidence answers the question. It does not say which employee or business function delegated purchasing authority, which suppliers are allowed, whether the budget is EUR 500 or EUR 50,000, whether the delivery address can change, or whether approval is required.

Treating authentication as authorization leaves agentic commerce without a transaction-specific decision. A verified identity is the subject of that decision, not the decision itself.

Five claims hide behind a "trusted" AI agent

When a team says an agent is trusted, ask which claim it means:

1. The runtime controls a valid credential.
2. The agent is operated by a named organisation.
3. A principal delegated a bounded action to that agent.
4. Current business policy permits this transaction.
5. The executed result can be traced to the preceding claims.

These claims have different issuers, lifetimes and failure modes.

OAuth can authenticate and convey scopes. Workload identity can bind a process to a key. An agent card or passport can name capabilities and ownership. A mandate can express task-specific authority. A policy engine can decide against current budgets and supplier state. A signed receipt can bind what the enforcement system recorded.

Collapsing these into a single bearer token makes the system simple until the first dispute.

How Entra, Okta, SailPoint and Concordium divide the identity problem

The products do not make identical claims. They start from different trust systems and buyer needs.

Swipe horizontally to inspect the full diagram.

Microsoft's current Agent ID documentation includes distinct agent identities, blueprints, owner and sponsor relationships, lifecycle controls and Conditional Access. It also describes agent user accounts for cases where a digital worker needs resources normally limited to user identities. Microsoft Entra Agent ID is the better fit when Microsoft identity and Microsoft 365 participation are the central deployment boundary.

Okta's product reached general availability in April 2026 according to its support documentation. Current materials describe agent discovery, registration, lifecycle events and centralized access controls. Okta for AI Agents product status and Okta's AI agent discovery documentation support those claims. Okta is the better fit when a company wants agent governance tied to an existing Okta estate.

SailPoint describes aggregating agents across systems and governing ownership, permissions and access with its identity-security model. SailPoint's Agent Identity Security overview makes it a natural fit for inventory, certification and entitlement governance.

Concordium starts from a portable registry and verified-owner model. Its technical documentation describes an on-chain registry, Agent Cards whose bytes are protected by an on-chain SHA-256 hash and optional linkage to a verified human owner. Concordium's Agent Registry documentation is relevant when public or cross-chain identity verification matters.

Enterprise agent market positioning

Product-scope analysis, not market share, quality or maturity

Text summary of highlighted companies

Company or protocol	Primary scope represented on the map
Intelliger	Transaction-specific authority, deterministic enforcement, reconciliation and portable evidence.
Concordium	Verified ownership, agent registry and identity-linked transaction infrastructure.
Okta for AI Agents	Agent identity, lifecycle, access and governance.
Microsoft Entra Agent ID	Enterprise agent identity, ownership, lifecycle and Microsoft ecosystem access.
SailPoint	Agent inventory, ownership, access review and entitlement governance.
Experian Agent Trust	Consumer identity, intent, fraud and payment trust signals.

None of these boundaries makes the other layer unnecessary. If Entra, Okta, SailPoint or Concordium already provides the identity, keep it. Project the verified subject, owner, tenant, credential method and status into the transaction-control decision.

Authentication proves control of a credential

In an ordinary API flow, the merchant verifies a token, certificate or request signature. That can prove that the caller possesses a credential associated with a client or workload, subject to the issuer and verification policy.

It cannot prove the caller's present business purpose. A valid credential may be:

• too broadly scoped;
• copied from another runtime;
• valid after an employee withdrew a task;
• associated with the right company but wrong department;
• used for an amount or supplier the principal never approved.

Sender-constrained credentials such as DPoP and mTLS reduce token replay. They still do not invent the missing business delegation. The OAuth DPoP standard describes proof-of-possession mechanisms for access and refresh tokens, including binding tokens to a public key. RFC 9449 solves a credential theft problem, not the full commerce authority problem.

Identity remains essential. The authorization layer needs a stable subject, accountable organisation, trusted issuer, current key and revocation state. It just needs more.

Scopes are too coarse for a purchase

A token with orders:write may be technically valid for an order endpoint. Commerce authority usually depends on transaction fields:

action       order.create
supplier     approved-supplier-17
product      industrial-sensor/SKU-882
quantity     12
unit price   EUR 640.00
total        EUR 7,680.00
destination  plant-7/receiving
purpose      maintenance-work-order-491
expiry       2026-08-11T12:00:00Z

Adding thousands of OAuth scopes for suppliers, budgets, destinations and purposes creates an unmanageable authorization vocabulary. Put stable API permissions in scopes. Put transaction-specific delegation in a typed mandate and current business conditions in policy.

Google's AP2 work recognizes the same gap for payments. Its official announcement frames authorization as proving that a user gave an agent specific authority for a particular purchase and introduces a framework for intent and accountability. The AP2 announcement treats agent authority as a protocol object rather than a prompt convention.

Enterprise commerce needs the pattern beyond payment. Negotiation, data disclosure, refunds, order changes and delegation to child agents need authority too.

Represent delegated authority as typed data

A mandate should be short-lived, explicit and bound to the agent's proof key. The example below is illustrative rather than an AP2 or OATI schema:

{
  "id": "mandate:procurement:wo-491",
  "issuer": "org:manufacturer:maintenance",
  "subject": "agent:procurement:12",
  "proof_key": "key:agent:procurement:12#runtime-4",
  "purpose": "maintenance-work-order-491",
  "actions": ["catalog.search", "offer.request", "order.create"],
  "resources": ["category:industrial-sensors"],
  "counterparties": ["supplier:17", "supplier:23"],
  "destinations": ["plant:7/receiving"],
  "constraints": {
    "currency": "EUR",
    "max_unit_price": "700.00",
    "max_total": "8000.00",
    "max_uses": 1,
    "delegation_depth": 1
  },
  "not_before": "2026-08-11T09:00:00Z",
  "expires_at": "2026-08-11T12:00:00Z"
}

Use decimal arithmetic for money. Define whether tax and shipping count toward each limit. Give resources and destinations stable identifiers. State omission semantics. A missing counterparties field must not mean every supplier is allowed.

If an agent delegates to a child, every child constraint must be equal to or narrower than the parent. Budget capacity must be allocated, not copied. A parent with EUR 8,000 remaining cannot create two children that each spend EUR 8,000.

Bind authority to the exact transaction

A valid mandate can still be attached to the wrong request. The gateway should normalize the incoming protocol call into a canonical transaction envelope and sign or digest all security-relevant fields.

type CommerceTransaction = {
  id: string;
  agentId: string;
  organisationId: string;
  mandateId: string;
  action: string;
  resource: string;
  counterparty: string;
  destination: string;
  purpose: string;
  amount: { value: string; currency: string };
  requestDigest: string;
  audience: string;
  issuedAt: string;
  nonce: string;
};

The requestDigest should cover the selected variant, quantity, price terms, delivery address, payment or checkout references and any field that changes business meaning. Use a specified canonicalization algorithm so independent implementations produce the same bytes.

Then verify in a deliberate order:

schema
-> issuer chain and key
-> signature
-> status and revocation
-> activation, expiry and audience
-> request digest binding
-> replay claim
-> mandate subject and proof key
-> action, resource, purpose and counterparty
-> amount, usage and delegation
-> current business policy
-> approval when required

Ordering is not cosmetic. Do not reserve budget for a malformed request. Do not execute before the replay claim is durable. Do not allow a cached approval to revive an expired mandate.

Keep policy deterministic

The model may interpret "replace the failed sensors at plant 7" and propose candidate products. It may explain why supplier 17 is a good fit. It should not decide whether the total is within authority.

function evaluateOrder(
  tx: CommerceTransaction,
  m: Mandate,
  state: State,
): Decision {
  if (m.status !== 'active') return deny('mandate_inactive');
  if (!m.actions.includes(tx.action)) return deny('action_not_allowed');
  if (!m.counterparties.includes(tx.counterparty))
    return deny('supplier_not_allowed');
  if (!m.destinations.includes(tx.destination))
    return deny('destination_not_allowed');
  if (tx.purpose !== m.purpose) return deny('purpose_mismatch');
  if (tx.amount.currency !== m.constraints.currency)
    return deny('currency_mismatch');
  if (decimal(tx.amount.value).gt(decimal(m.constraints.max_total))) {
    return deny('total_above_mandate');
  }
  if (!state.approvedSuppliers.has(tx.counterparty))
    return deny('supplier_suspended');
  if (state.remainingBudget.lt(decimal(tx.amount.value))) {
    return deny('business_budget_exceeded');
  }
  return allow();
}

The mandate answers what was delegated. Policy answers whether the transaction is acceptable now. A supplier might be suspended after mandate issuance. A budget may have been consumed by another transaction. A destination may enter a restricted state.

Return structured decisions such as allow, deny, transform or approval_required. Record the policy version and facts used. If a transform changes amount, product, supplier or destination, create a new transaction digest and reevaluate approval.

Broker execution credentials after the decision

The purchasing agent should not hold a reusable supplier API key or payment credential. After authorization, a gateway can obtain a short-lived capability, inject it into the connector and execute the canonical request.

agent proposal
  -> runtime identity verification
  -> mandate verification
  -> deterministic policy
  -> human approval when required
  -> temporary credential broker
  -> supplier or payment API
  -> outcome reconciliation
  -> signed receipt

This limits prompt injection. Malicious catalog text might convince the model to attempt a different destination. It cannot change the signed mandate, expand policy or reveal a credential the model never receives.

Revocation is part of authorization

Short expiry reduces risk but does not replace revocation. Enterprises need to stop authority when an agent is compromised, an employee cancels a task, a supplier is blocked or a runtime key leaks.

Resolve revocation by target: issuer, agent identity, runtime key and mandate. Define cache freshness by risk. A material payment should fail closed when required trust or replay state cannot be checked. A low-risk catalog read may have a separately configured degraded mode.

Keep revocation local enough that the transaction path does not depend on a central SaaS call every time. Signed policy bundles and short-lived trust caches can support local enforcement, but the outage rules must be explicit and tested.

Issue evidence without overstating it

After execution, a receipt can bind the agent, organisation, mandate, canonical request digest, policy decision, approval, provider reference and observed result.

{
  "transaction_id": "tx:order:491-12",
  "agent_id": "agent:procurement:12",
  "mandate_id": "mandate:procurement:wo-491",
  "decision": "allow",
  "outcome": "accepted",
  "request_digest": "sha256:...",
  "policy_digest": "sha256:...",
  "provider_reference": "supplier-order:SO-18827",
  "occurred_at": "2026-08-11T09:44:12Z",
  "issuer": "org:manufacturer:gateway"
}

A valid signature supports verification that the holder of the signing key attested to the receipt. Trust resolution connects that key to an issuer under a policy. Neither establishes that the supplier fulfilled the order or that every upstream fact was true. Reconcile acceptance, shipment, delivery, return and dispute as separate outcome events.

When only the buyer operates the trust layer, label the evidence unilateral. A supplier countersignature can raise assurance for the fields the supplier signs. It does not retroactively validate the buyer's internal policy record.

Attacks to test before launch

Mandate substitution. Attach a valid mandate for another plant or work order.

Amount mutation. Authorize EUR 768, then send EUR 7,680 upstream.

Destination swap. Keep the product and amount but change delivery to an employee address.

Scope laundering. Exchange a broad OAuth token and treat the new token as transaction authority.

Budget cloning. Delegate the full remaining budget to several child agents concurrently.

Stale revocation. Continue accepting a cached mandate after emergency cancellation.

Audience confusion. Replay a signed test request against production.

Semantic retry. Repeat the same order with a new transaction ID after a timeout.

Approval reuse. Attach an approval for supplier 17 to an otherwise similar order from supplier 23.

Bypass. Let the agent call the supplier API directly with a standing credential and avoid the policy gateway.

Implementation checklist

• Authenticate runtime credentials and derive the tenant from verified claims.
• Link each agent to an accountable organisation and issuer.
• Keep identity records separate from delegated authority.
• Use typed, short-lived mandates for consequential actions.
• Bind authority to purpose, resources, counterparties and destinations.
• Define money, usage, expiry and delegation semantics precisely.
• Canonicalize and digest the exact transaction request.
• Verify audience, time, revocation and replay state.
• Evaluate hard constraints in deterministic code or policy.
• Reserve budgets and one-time usage atomically.
• Bind human approval to the transaction digest.
• Broker temporary credentials only after authorization.
• Make the gateway difficult to bypass with network and API controls.
• Sign receipts and reconcile later outcomes separately.
• Test substitution, replay, revocation, concurrency and partial failure.

Questions about AI agent identity and authorization

Is agent identity the same as agent authorization?

No. Identity establishes which principal controls a credential and may link that principal to an owner. Authorization decides whether that principal may perform this action, on this resource, within these limits, at this time. A valid identity can still present an invalid or excessive transaction.

Can OAuth scopes authorize an enterprise purchase?

Scopes can restrict access to an API or operation family. They rarely express supplier, amount, cost center, delivery destination, approval digest, cumulative budget and delegation depth together. Use scopes as an outer access boundary and a transaction-aware policy decision for the purchase itself.

Do Entra, Okta or SailPoint replace Intelliger?

No. They address important identity, access and governance responsibilities that Intelliger should consume, not recreate. The complementary Intelliger role is to translate verified identity and business authority into a deterministic decision bound to one normalized transaction, then preserve the resulting evidence.

Does a Concordium identity proof grant enterprise permission?

Not by itself. A public identity or accountability record can strengthen who an actor is and which registry statement was made. The enterprise must still decide whether that actor has a valid mandate for the requested business action and whether current policy allows it.

OATI's current boundary

OATI separates Agent Passport, Mandate, Transaction Envelope, Decision and Receipt. The public developer preview implements schemas, RFC 8785 canonical payloads, Ed25519 and ES256 profiles, issuer and key verification, revocation resolution, time and audience checks, replay protection, deterministic mandate evaluation and non-amplifying delegation. TypeScript, Python and Go run the same 73 conformance cases.

The implemented framework is not a completed commercial enforcement fleet. The production policy compiler and durable evidence and dispute worker remain incomplete, the customer gateway is a reference integration, and independent protocol and implementation review is still open. Intelliger's broader commerce authority registry, merchant runtime and universal connectors are target-state platform capabilities.

The architecture is useful regardless of protocol choice. Authenticate the agent, then ask what it may do, under whose authority, within which limits, against which exact transaction and with what revocation state. Only the full chain supports a consequential commerce decision.

The same separation applies when an agent reaches money. Use the enterprise AI agent identity platform shortlist, compare Microsoft Entra Agent ID with Okta for AI Agents and review the Concordium Agent Registry enterprise architecture before choosing an identity source. Then use the broader AI agent authorization guide, the deterministic architecture for agentic payments and the AI audit trail built from signed action receipts.

Expert review required before publication: an enterprise identity and authorization reviewer should validate the product comparison, token and lifecycle claims, mandate semantics and current implementation boundary.

To map an existing identity provider into one bounded action flow, review the Agent Trust architecture and contact Intelliger.