← Back to blog

How We Use Auth0 for AI Agents

6 min read

Bonus Blog Post Submission Authorized to Act: Auth0 for AI Agents

Commerce operations involve real money. When AI agents can change pricing, toggle promotions, and send notifications on your behalf, the authorization model isn't a feature. It's the product.

Commerce Changeset is a multi-agent system that reads product data from Google Sheets, decomposes natural-language requests into discrete operations, evaluates each against a policy engine, gets phone-based approval for risky changes, executes writes, and sends email receipts. Four agents, one user, zero shared credentials.

Auth0's AI Agents platform has four pillars. We use all of them. Here's how.

User Authentication

Auth0 Universal Login handles the identity layer. We use @auth0/nextjs-auth0 v4 with the middleware pattern, not the legacy route handler. The session includes offline_access so we get a refresh token that Token Vault can exchange later.

Connected Accounts lets users link their Google account through a standard OAuth consent flow. Auth0 stores the federated credential. The app never sees it.

Token Vault: How Agents Get API Access

This is the centerpiece. Token Vault brokers short-lived, scoped access tokens between our agents and Google's APIs. The user connects their Google account once. Every downstream agent gets exactly the permissions its role requires.

User Sessionrefresh_tokenAuth0Token VaultGoogle APIscoped access_tokenOBO exchangescoped token

Each agent wraps its tools with auth0AI.withTokenVault() and calls getAccessTokenFromTokenVault() inside the tool execution context. The token exchange happens at runtime, not at login. Agents never see the refresh token.

AgentScopeWhat it does
Readerspreadsheets.readonlyPulls product data and launch schedules
WriterspreadsheetsExecutes approved price/promo/inventory changes
Notifiergmail.sendSends execution receipts via Gmail

The Orchestrator has no API access at all. It plans, but it can't act. That's deliberate.

Async Authorization: CIBA + Guardian

Not every operation should execute silently. Our policy engine (json-rules-engine, 7 rules) assigns risk tiers to each operation. Tier 0 is a read. Tier 1 is a low-risk write. Tier 2+ requires explicit approval before the Writer agent touches anything.

We use CIBA (Client-Initiated Backchannel Authentication) to send a Guardian push notification to the user's phone. The binding message describes what's about to happen: Approve: Update price for SKU-1234. The user taps Approve or Deny. No browser redirect, no popup.

This is auth0AI.withAsyncAuthorization() from @auth0/ai-vercel. It blocks until the user responds or the timeout expires. In our demo, the timeout is 10 seconds. In production, 120.

Stress-Aware Risk Escalation

This is where we go beyond what Auth0 ships today. The platform gives us the building blocks. We wire them to a new signal: the user's cognitive state.

Commerce Changeset uses Gemini Live for voice input. A sidecar model analyzes vocal patterns in real time and classifies the user's emotional state: calm, stressed, rushed, or uncertain. When the stress level exceeds 0.7 or the session runs longer than 60 minutes, the policy engine escalates the risk tier. A Tier 2 write becomes Tier 3.

The approval mechanism is currently the same for both tiers. But the classification changes, the UI turns red, and the audit trail records why the tier escalated. The infrastructure is ready for differentiated enforcement: confirmation phrases, shorter timeouts, or dual-approver workflows.

An important note on consent: stress and fatigue signals are opt-in, assistive, and escalation-only. They never block an operation — they add a confirmation step. Voice-derived signals are ephemeral session metadata: no recordings are stored, no biometric profiles are built, and no data leaves the session. The user can disable voice-aware escalation at any time without affecting their base permissions. When no voice context exists, the policy engine evaluates operations with standard rules and zero behavioral penalty.

The Audit Trail

Every execution produces an ExecutionReceipt with the full OBO delegation chain: which agents acted, what tools they were granted, what operations they performed, and how long each took. Each agent delegation includes a tokenExchangeId tying it back to the Token Vault exchange. The whole receipt is sealed with a SHA-256 audit hash.

If something goes wrong, you can trace every decision from the user's request to the API call that executed it.

Full Pipeline

Here's the 10-step architecture. Every arrow through the Auth0 layer is a Token Vault exchange or a CIBA approval gate.

User / Auth0Universal Login + MFA1OrchestratorPlans only — no API access2Reader AgentToken Vault OBOspreadsheets.readonly3LLM AnalysisDiscrete operations4Policy Enginejson-rules-engine — 7 rulesT0T1T2T35CIBA GateGuardian push (Tier 2+)auto-approve (Tier 0/1)6Writer AgentToken Vault OBOspreadsheets (read-write)7Reader VerifyRead-back comparison8Notifier AgentToken Vault OBOgmail.send9ReceiptSHA-256 audit hash10OBO chainCOMMERCE CHANGESET — AGENT PIPELINE

What's Next

Differentiated Tier 3 enforcement. Continuous trust scoring that modulates agent autonomy in real time, not just binary approve/deny. And context boundaries between agents so the Writer only sees the operations it's been approved to execute.

For implementation details and the sharp edges we hit along the way, see Building Trust Surfaces for AI Agents.