Skip to main content
Intelliger
Agentic Commerce Security

Agentic AI Security: Identity Is Not Authority

Agentic AI security needs more than authentication. AI agent authorization, mandates, revocation and signed evidence protect enterprise transactions safely.

Agentic AI Security: Identity Is Not Authority
Intelliger•
14 minute read

Agentic AI security breaks when a correctly signed request is mistaken for permission to transact.

A merchant receives that 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.

Agentic commerce fails dangerously when authentication is treated as authorization. A verified identity is the subject of a policy decision. It is not the decision.

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.

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 is significant because payment ecosystems are treating 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 signature proves that the signing key attested to the receipt. Trust resolution connects the key to an issuer under a policy. It does not prove 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.

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. See the deterministic architecture for agentic payments and the AI audit trail built from signed action receipts.