Agent Firewall

Inspiration

AI agents are getting access to real tools — sending Slack messages, creating GitHub issues, even deleting repositories. But there's no standardized way to control what an agent can and cannot do with those permissions. We asked: what if there was an authorization firewall that sits between the AI agent and the APIs it calls, enforcing policies and requiring human approval for dangerous actions?

What it does

Agent Firewall is a zero-trust authorization layer for AI agents. Every tool call the agent makes is intercepted and evaluated against a YAML-based policy engine that classifies actions by risk level:

• Low risk (e.g., list repos, list channels) — auto-approved, executed via Auth0 Token Vault
• Medium risk (e.g., create issue) — auto-approved with full audit logging
• High risk (e.g., send Slack message) — requires step-up authorization via a simulated CIBA flow. The agent pauses and the user must explicitly approve on the Approvals page before execution proceeds
• Critical risk (e.g., delete repo) — always denied by policy, no override possible Every action generates an immutable consent receipt with the tool name, arguments, risk level, policy rule matched, auth method used, and result — creating a complete audit trail.

How I built it (Tenant Name: dev-pwopxn4m26rz83r0)

The stack is Next.js 16 with Turbopack, Vercel AI SDK v6 for the chat interface, and Auth0 for authentication. The key integration is Auth0 Token Vault — third-party tokens for GitHub and Slack are never stored in the application. Instead, Token Vault manages the OAuth tokens and the app exchanges them at runtime via Auth0's federated token exchange grant.

The policy engine loads YAML rules at startup and matches each tool call against action patterns with wildcard support. The step-up approval flow creates a pending consent receipt, surfaces it on the Approvals page with the full action payload, and only executes via a fresh Token Vault token after the user clicks "Approve & Execute."

A key architectural challenge was Vercel's serverless environment — receipts created on one instance aren't available on another. The solution: the client always sends the full tool name and arguments alongside the receipt ID during approval, so any serverless instance can execute the action.

Challenges I ran into

The biggest challenge was making the step-up approval flow work reliably across Vercel's serverless instances. Pending receipts created on instance A weren't available when the approval API hit instance B. The fix was a client-first architecture where localStorage is the source of truth, and the approval request always includes enough data for any instance to execute.

Another challenge was receipt status consistency — polling from multiple sources (localStorage, server memory, chat session) caused resolved approvals to flip back to "pending." A status-priority merge algorithm fixed this: approved/denied always wins over pending during deduplication.

Accomplishments that I'm proud of

• The complete policy-to-execution pipeline: YAML policy match → risk classification → auth method selection → Token Vault token exchange → execution → consent receipt — all in a single tool call
• The step-up approval flow that genuinely blocks agent execution until explicit human authorization
• Zero token storage in the application — Auth0 Token Vault handles all third-party credentials
• Default-deny security posture: any action not matching a policy rule is automatically blocked as critical risk

What I learned

Auth0 Token Vault is a powerful primitive for agent authorization. The federated token exchange grant means the agent application never touches refresh tokens, which is exactly the security model you want when an AI is acting on behalf of a user. The pattern of "policy engine decides, Token Vault executes" feels like the right abstraction for agent authorization.

I also learned that serverless architectures require careful thinking about state — you can't assume in-memory state persists between requests, which fundamentally shaped the approval flow design.

What's next for Agent Firewall

• Real CIBA integration with Auth0 push notifications for mobile approval
• Configurable policy editor in the UI (currently YAML file)
• Support for more providers beyond GitHub and Slack
• Rate limiting and anomaly detection on agent actions
• Multi-tenant support for team-based agent governance

📝 Blog Post: Token Vault as the Missing Piece for Agent Authorization

Building Agent Firewall taught me that the hardest part of AI agent authorization isn't the policy engine or the UI - it's the token plumbing. Getting Auth0 Token Vault to work end-to-end required understanding a chain of dependencies: the GitHub connection must use a GitHub App (not OAuth App) with expiring tokens enabled, the connection Purpose must be set to "Authentication and Connected Accounts for Token Vault" so Auth0 requests refresh tokens during login, the My Account API must be enabled on the tenant, and the application needs a client grant for the My Account API with create:me:connected_accounts scope. Missing any single link in this chain produces the same cryptic error: federated_connection_refresh_token_not_found.

The breakthrough insight was that Token Vault's getAccessTokenForConnection() performs a federated token exchange under the hood - it needs a stored refresh token from the identity provider to mint fresh access tokens on demand. Without the Connected Accounts flow storing that refresh token, the exchange has nothing to work with. Once I understood this dependency chain, everything clicked: the Connected Accounts flow is the "setup" step that populates Token Vault, and getAccessTokenForConnection() is the "runtime" step that uses it.

The zero-trust policy engine was the fun part. YAML rules with wildcard matching (delete_* catches all destructive operations) and a default-deny posture means agents can never accidentally access something they shouldn't. Every action produces a consent receipt - a structured audit log that answers "what did the agent do, who authorized it, and what policy allowed it?" This pattern is reusable beyond hackathons: any production AI agent that touches third-party APIs should have this kind of authorization layer.

The key insight I'd share with the Auth0 community: agents shouldn't hold tokens; they should earn them per action. Token Vault makes that pattern practical.

Built With

• auth0
• auth0-token-vault
• next.js
• openai
• react
• tailwind-css
• typescript
• vercel
• vercel-ai-sdk