Why AI Agents Need Live Authorization, Not Just Valid Credentials

A valid token. An invalid purchase.

Imagine you let an AI purchasing agent spend up to $1,000 on supplies. You give it a properly signed credential and send it off to work. Then two things happen at nearly the same time:

Both services can verify the credential's signature. Both can see that the original grant allowed $1,000. Neither can learn from that signature alone that the other service is trying to use the same money.

Nothing is wrong with the cryptography. What is missing is a shared answer to a different question: How much authority is still available right now?

Authentication and authorization are not the same job

Authentication tells a service who presented a credential. A signed authorization can establish what that issuer originally granted, subject to its terms. Before a consequential action, however, the service also needs to know whether the proposed action is still permitted.

That decision may depend on a changing budget, a revocation, a parent delegation, an expiration, or work already in progress. Static token validation does not automatically synchronize those facts between independent systems.

Would shorter-lived tokens fix this?

Short expiration times are useful. They reduce how long a stolen or outdated credential may remain useful. But they do not prevent two valid requests arriving in the same second from using the same allowance twice. Nor does checking a token's signature again reveal another service's pending reservation.

If every action passes through one application and one transactional database, you may already have the tools to solve this: a conditional balance update or row-level lock, paired with an idempotency record and a durable outcome log. You do not automatically need an outside service.

It gets harder when separate agents, teams or services can act independently. In that setting, they need to agree on the same current balance and on what to do when a result is unknown. That is the problem a shared clearing layer is designed to solve.

The fix: reserve first, then execute

For a shared, limited allowance, move the decision into one authoritative state service. Each executor asks that service to reserve exactly what it intends to use. That reservation must be atomic: either the full request succeeds, or no capacity is taken.

Take the same $1,000 limit. If Service A reserves $700 first, the shared balance drops to $300. Service B's $500 request is then refused. If B wins the race instead, A's $700 request is refused. The result depends on order; the total never exceeds the available allowance.

A practical execution path looks like this:

1. Issue a bounded grant. Specify the subject, allowance and unit.
2. Reserve an exact action. Include its amount, intended action, counterparty and stable idempotency key.
3. Validate just before execution. Check that the clearance and its authority chain are still current.
4. Perform the external action once. Pass your own stable transaction ID to the downstream service where supported.
5. Record the result. Mark the reservation consumed if the effect happened, or released only if it definitely did not.
6. Reconcile uncertainty. If the result is unknown, keep that authority unavailable until the external outcome is established.

That last step matters more than it first appears.

The failure people miss: the payment worked, but the reply vanished

Say the agent reserves $400 and asks a supplier to place an order. The supplier accepts it. Before the response gets back, the network connection drops.

Did the order happen? The agent does not know. Retrying the purchase with a brand-new transaction ID could place a second order. Releasing the $400 could let another agent spend money that was already committed.

The safe response is not to guess. Keep the clearance INDETERMINATE, check the supplier's authoritative order state using the original transaction ID, then reconcile it as CONSUMED or RELEASED when the evidence supports that outcome.

An idempotency key also belongs on the reservation request. If that request must be retried, the same key and identical request should return the same logical reservation rather than create another one. External execution still needs its own retry and idempotency discipline; a reservation alone cannot make a third-party purchase exactly once.

What if a human revokes permission halfway through?

Consider a manager who freezes an agent's purchasing authority after noticing suspicious activity. A clearance signed a minute earlier may still be cryptographically valid. That is not permission to ignore the freeze.

Check live state immediately before execution, including the status of parent authorities. If validation fails or cannot be completed, do not begin a new consequential action. If an external effect is already underway, follow the application's documented cancellation and reconciliation rules; revocation cannot magically undo a real-world transaction that already happened.

Delegation has the same accounting problem. Giving two sub-agents $600 each from a $1,000 parent grant should not create $1,200 of usable authority. Allocation must reduce what remains available at the parent.

A working example using the GoGuides Authority Clearing Network

GoGuides ACN 1.1 exposes an HTTPS/JSON API for bounded delegated authority. These requests use the documented endpoints and request fields. They reserve and validate authority; they do not make a purchase or transfer money.

First, check the public service and key-discovery endpoints. No API key is needed for these reads:

curl https://www.goguides.com/api/v1/status
curl https://www.goguides.com/api/v1/public-key

With an ACN account and API key, issue a $1,000 spending grant. Keep the key out of shell history and application logs; the shell environment variable below is only a placeholder:

curl -X POST 'https://www.goguides.com/api/v1/authority/issue' \
  -H "X-GoGuides-API-Key: $ACN_API_KEY" \
  -H 'Content-Type: application/json' \
  --data '{
    "subject":"purchasing-agent-17",
    "authority_type":"spending",
    "unit":"USD",
    "amount":"1000.00000000"
  }'

Save the returned authority_id. Now reserve $700 for one exact action:

curl -X POST 'https://www.goguides.com/api/v1/clearance' \
  -H "X-GoGuides-API-Key: $ACN_API_KEY" \
  -H 'Content-Type: application/json' \
  --data '{
    "authority_id":"AUTHORITY_ID",
    "amount":"700.00000000",
    "idempotency_key":"purchase-2026-0001",
    "action":"purchase",
    "counterparty":"vendor.example",
    "ttl_seconds":120
  }'

The reservation response supplies a clearance identifier and signed token. Before the relying service attempts the actual order, validate that clearance for the same action and counterparty:

curl -X POST 'https://www.goguides.com/api/v1/clearance/validate' \
  -H "X-GoGuides-API-Key: $ACN_API_KEY" \
  -H 'Content-Type: application/json' \
  --data '{
    "clearance_id":"CLEARANCE_ID",
    "signed_token":"SIGNED_TOKEN",
    "action":"purchase",
    "counterparty":"vendor.example"
  }'

Only proceed if the response explicitly confirms current validity. After the supplier confirms an order was placed, submit the outcome:

curl -X POST 'https://www.goguides.com/api/v1/clearance/CLEARANCE_ID/receipt' \
  -H "X-GoGuides-API-Key: $ACN_API_KEY" \
  -H 'Content-Type: application/json' \
  --data '{
    "result":"CONSUMED",
    "external_action_id":"vendor-order-92831"
  }'

Use RELEASED only when the action definitely never occurred. For an unknown external outcome, record INDETERMINATE and reconcile later. You can inspect the authority's evidence through GET /api/v1/evidence/{authority_id}.

See the ACN technical white paper for full request examples and failure semantics, and the OpenAPI contract for integration details. The examples above are illustrative: use test subjects and counterparties before connecting a real purchasing system.

Integration checklist: seven questions to settle before launch

1. What unit is being limited: dollars, credits, messages, inventory, or something else?
2. Where is the single authoritative balance, and can it reserve atomically across simultaneous requests?
3. Are action, amount, counterparty, expiry and delegation scope bound to each clearance?
4. Does every retry reuse a stable idempotency key and the identical original request?
5. Can the executor check current authority immediately before the external side effect?
6. How does the system distinguish CONSUMED, RELEASED and INDETERMINATE outcomes?
7. When clearing is unavailable, does the executor stop safely rather than treating an old signature as sufficient?

If your answer to any of those questions is “we'll work that out later,” it is worth working out before an autonomous agent can spend money or make irreversible changes.

What live authorization does not solve

It cannot tell you whether the requested purchase is wise, legal or fraudulent. It cannot guarantee that an outside supplier will honor a cancellation, and it cannot reverse an action that has already happened. Those decisions and controls belong to the relying organization's own policies and the external system executing the action.

What it can do is keep separate agents from independently treating the same limited grant as fully available. It makes current authority an explicit step in the execution path, rather than a hopeful assumption based on yesterday's signature.