Blast Radius Auth

Inspiration

Every AI agent today gets authorized with a simple yes/no capability check — "Can this agent access Gmail?" But nobody asks the critical follow-up: "Should this agent be allowed to delete 47,000 emails permanently?"

We realized that a bank doesn't just ask "are you authorized to transfer money?" — it asks "is this specific transfer normal for you?" AI agents have no equivalent. An agent with gmail.modify scope can archive 3 read emails or permanently delete your entire inbox using the exact same OAuth token. That's a massive gap in how we think about AI agent security.

We wanted to build the authorization layer that measures the blast radius of every action before it happens — and revokes the token mid-execution if the scope grows beyond what was authorized.

What it does

Blast Radius Auth scores every AI agent action on two axes simultaneously:

Scope: How many records/people/data does this action touch?
Reversibility: Can this action be undone?

Based on the combined score (0-100), the system applies proportional authorization:

LOW (0-25): Auto-approved, token issued instantly — no friction for safe actions
MEDIUM (26-50): User confirms on the dashboard before the agent proceeds
HIGH/CRITICAL (51-100): CIBA push notification sent to the user's phone via Auth0 Guardian — the user must approve on their device, and a cryptographically signed consent receipt is generated

The most novel feature is mid-action token invalidation: if an agent is authorized to process 100 emails but discovers 5,000 during execution, the token self-invalidates and the agent halts immediately. 4,950 items are protected from unauthorized scope expansion. No other auth system does this.

The system uses real Gmail data — actual email counts from the user's inbox drive the blast radius calculation, not mock data.

How we built it

Backend (FastAPI + Python):

Blast radius calculator with logarithmic scope scaling and weighted reversibility baselines
LLM-powered action classification using Claude Haiku — classifies free-text tasks into structured action types with reasoning
Auth0 Token Vault integration for magnitude-scoped Google OAuth tokens
Auth0 CIBA integration for step-up authentication via Guardian push notifications
RSA-2048 signed consent receipts for cryptographic audit trails
Real Gmail API integration — live email counts retrieved through Auth0's stored Google tokens
Mid-action monitoring endpoint for runtime scope validation

Frontend (Next.js + TypeScript + Tailwind):

Live blast radius gauge (semicircle visualization, 0-100)
Scope x Reversibility matrix highlighting the current action's position
Action cards with approve/deny for pending authorizations
Consent receipt display with downloadable signed records
Real-time agent activity log showing every step of the authorization flow
Mid-action breach alert visualization showing authorized vs. discovered vs. processed counts

Agent (LangGraph + Claude Sonnet):

ReAct agent with mandatory 4-step workflow: count → score → authorize → execute
Tools that call real Gmail API for email counts
Mid-action radius checks every N items during execution

Auth0:

Token Vault with Token Vault grant type for federated Google token retrieval
CIBA with Guardian push notifications for human-in-the-loop approval
Management API for user enrollment and MFA setup

Challenges we ran into

CIBA binding message constraints: Auth0 limits binding messages to 64 characters with restricted character sets. We had to compress blast radius details into a very compact format.
Token Vault grant type: The Auth0 Token Vault grant type wasn't immediately available — we had to enable it through the Advanced Settings Grant Types tab, which was hard to find in the new Auth0 dashboard UI.
Guardian MFA enrollment: Getting CIBA to work required a real user enrolled in Guardian push notifications. The enrollment flow needed a proper login redirect with MFA enforcement before CIBA could send push notifications.
Frontend timeout vs. CIBA polling: The CIBA flow polls Auth0 for up to 60 seconds waiting for user approval on their phone. The default browser fetch timeout would kill the request before the user could approve. We had to implement a 120-second AbortController timeout.
LLM classification accuracy: Initial keyword-based heuristics were too coarse — "send a welcome email" scored HIGH because "send" was flagged as irreversible. Switching to Claude Haiku for classification solved this with nuanced reasoning.
Google OAuth scopes: Adding Gmail and Calendar scopes to the Auth0 social connection required configuring upstream_params on the connection, not just the standard scope array.

Accomplishments that we're proud of

Mid-action token invalidation actually works end-to-end — this is genuinely novel and no existing auth system does it
Real CIBA push notifications to an actual phone via Guardian — not simulated, real human-in-the-loop
Real Gmail data driving authorization decisions — 201 actual emails from a real inbox, not mock data
Real Google OAuth tokens from Auth0 Token Vault — magnitude metadata embedded alongside real tokens
LLM-powered classification with reasoning — Claude Haiku explains why an action is dangerous
The 4-scenario demo tells a complete story: auto-approve → confirm → phone push → mid-action breach
Cryptographic consent receipts with RSA-2048 signatures — auditable proof of authorization

What we learned

Authorization is fundamentally incomplete for AI agents: OAuth scopes and RBAC were designed for humans clicking buttons, not agents executing thousands of actions autonomously. The gap between "can do" and "should do at this magnitude" is where the real risk lives.
Magnitude matters more than capability: The same gmail.modify permission can be safe or catastrophic depending entirely on scope and reversibility. Authorization systems need to be magnitude-aware.
Auth0's AI agent features are powerful but new: Token Vault, CIBA, and Guardian together enable a genuinely new class of authorization flows. The documentation is still catching up, but the underlying APIs are solid.
Mid-action monitoring is the hardest part: It's easy to check permissions before an action. It's much harder to monitor scope during execution and revoke authorization in real-time. This is where the real engineering challenge lies.
LLMs are better classifiers than regex: Claude Haiku's ability to reason about action severity ("bulk deletion of unread emails is irreversible and likely affects hundreds to thousands of messages") is vastly superior to keyword matching.

What's next for Blast Radius Auth

Real-time WebSocket streaming: Stream blast radius score changes live as the agent discovers more items during execution, with the gauge animating in real-time
Multi-service support: Extend beyond Gmail to Slack, GitHub, databases, and cloud infrastructure — each with their own reversibility baselines
Adaptive baselines: Learn from user behavior to adjust what's "normal" — if a user regularly deletes 500 emails, that shouldn't trigger CRITICAL
Token Vault native integration: Work with Auth0 to embed blast radius claims directly into Token Vault tokens as custom claims, rather than as metadata alongside the token
SDK/middleware: Package as a drop-in middleware for LangChain, LangGraph, CrewAI, and other agent frameworks — @blast_radius_guard decorator for any tool
Compliance reporting: Generate compliance reports from consent receipts — who authorized what, at what magnitude, when, with what signature
Organization policies: Let admins set organization-wide blast radius thresholds — "no agent in this org can affect more than 1000 records without VP approval"

Bonus Blog Post

The Moment We Realized Authorization Was Broken

Halfway through building Blast Radius Auth, we had a moment that crystallized why this project matters. We connected the real Gmail API, typed "Delete all my unread emails," and watched the system pull back 201 actual emails from a live inbox. The blast radius gauge jumped to 69 — HIGH tier. A CIBA push notification hit our phone seconds later via Auth0 Guardian, asking us to approve the deletion of 201 real emails.

That was the moment it clicked: this is the check that should exist everywhere, and doesn't.

The hardest technical challenge was making Auth0 Token Vault and CIBA work together in a way that felt seamless. Token Vault is designed to manage OAuth tokens for external services — we extended it to carry blast radius metadata alongside the Google token. Every token issued now knows its own ceiling: the maximum number of items it's authorized to touch, and whether the action is reversible.

CIBA was a different beast. We spent hours debugging why Guardian push notifications weren't firing, only to discover that the binding message has a 64-character limit with restricted characters — no tildes, no pipes, no emojis. We went from a beautifully formatted blast radius summary to "CRITICAL Delete all emails 10000 items 88." Ugly, but it works.

The real breakthrough was mid-action token invalidation. We authorized an agent for 100 promotional emails, then simulated it discovering 5,000. The token revoked itself at batch 5 — 50 items processed, 4,950 protected. Watching the dashboard gauge jump from MEDIUM to CRITICAL with a red breach alert was genuinely satisfying.

What surprised us most was how natural Auth0's AI agent features felt once wired together. Token Vault handles the OAuth complexity, CIBA handles the human-in-the-loop, and Guardian handles the notification channel. We just had to add the magnitude layer on top. The infrastructure for secure AI agents exists today — it just needs someone to ask the right question: not "can this agent do this?" but "should this agent do this much?"

Building Blast Radius Auth taught us that the next frontier in AI agent security isn't about permissions — it's about proportionality.