-
-
-
Actions Page - Users review/edit/approve AI suggestions
-
Actions Page - User edits AI suggestion
-
Actions Page - User approved suggestion; AI nudge
-
Chat Page - Calendar auth
-
Chat Page - CIBA auth
-
Chat Page - Approval needed
-
Permissions Page
-
Permissions Page - Confidence Routing close-up
-
Audit Log
-
Exploring MCP
Inspiration
DealFlow was built to prove an AI agent can be both powerful AND trustworthy. The solution's intial features were suggesting actions with clear justification, letting users review and edit before anything executes, and using Auth0 Token Vault so the AI never touches credentials. Then it was extended by exposing the same secure pipeline to external AI agents via MCP, turning one app's security into a reusable pattern for the AI agent ecosystem.
What it does
DealFlow follows a graduated trust architecture. There are four trust levels and three execution surfaces in one Auth0 Token Vault pipeline.
Graduated trust is the idea that not every AI action deserves the same level of scrutiny and not every action deserves the same level of freedom either. Think about how trust works with a new employee. Day one, you don't hand them the company credit card and say "go for it." But you also don't make them get approval to send a calendar invite. You calibrate low-risk stuff to flow freely, high-stakes stuff gets a guardrails, and over time as they prove themselves, some of the guardrails relax. DealFlow does the same thing with an AI sales agent by structurally baking the guardrails into the architecture.
| Surface | Trust | Consent | Use Case |
|---|---|---|---|
| Action Center | Low | In-app review + edit | AI suggests, user reviews every action |
| Chat UI | Medium | Real-time + step-up | User directs, AI pauses for sensitive ops |
| MCP + CIBA | High | Phone push notification | External agent acts, user consents on device |
| MCP (read) | Autonomous | None needed | Read-only queries, no data modified |
Key Features
The four levels, from most autonomous to most controlled:
1. Autonomous read (MCP external agents) — Checking a calendar, listing deals, searching contacts. No human in the loop. The data flows and nobody needs to tap anything. This is the equivalent of letting the new hire look at the shared drive.
2. High trust with device consent (MCP write + CIBA) — An external AI agent wants to draft an email or book a meeting through your system. That's a real action in the real world with your name on it. So before it happens, your phone buzzes with a Guardian push notification describing exactly what's about to happen. One tap to approve and the action executes within a time-boxed window. You didn't have to be at your computer but, you did have to consciously say yes (and all is logged).
3. Collaborative with guardrails (Chat UI) — You're in the conversation, directing the agent in real time. It can chain tools together ie. pull deal details, check your calendar, draft a follow-up email etc. If it tries to create a deal over your threshold ($50K in this demo) or close one as won, the system hits a speed bump. Step-up approval right in the chat, and for the really sensitive stuff, CIBA sends it to your phone too (or your team leader).
4. Maximum control (Action Center) — The AI proposes actions based on what it sees in your pipeline: "you should email this prospect", "book a follow-up with that account", but it doesn't do anything. You see the draft, you can edit it word by word, and only when you explicitly hit approve does it execute through Token Vault. This is the "I want to see everything before it goes out" mode.
The key insight: all four levels use the same Auth0 Token Vault pipeline underneath. It's not four different auth systems. It's one pipeline with consent gates that open or close based on how much trust the context warrants. The security can adapt to the situation rather than forcing one-size-fits-all.
And it's not static. The system watches your approval patterns. If you've approved 5+ similar actions at high confidence, it nudges you: "hey, want to auto-approve these?" It never auto-escalates its own permissions, but it does suggest relaxing yours. Trust grows over time, just like it does with people. And with features like 'confidence routing', we allow users to build the trust at a pace they are comfortable with.
How it was built
Next.js 16 (App Router), Auth0 Token Vault, Claude Sonnet 4.6 via Vercel AI SDK v6, Upstash Redis, Model Context Protocol. Direct RFC 8693 token exchange and CIBA via HTTP — the @auth0/ai-vercel SDK swallows errors (#175), Auth0 endpoints called directly for full observability.
7 days (March 31 – April 6, 2026). 380+ commits, 700+ tests, 11 ADRs, 31 documented insights.
Challenges
- SDK error swallowing —
@auth0/ai-vercelv5'sTokenVaultAuthorizerBasesilently returnsundefinedon failed exchanges, masking the real Auth0 API error. Fix: direct HTTP to/oauth/token. - Token Vault tokenset deletion doesn't revoke access — Auth0 silently re-provisions. Fix: application-level disconnect via Redis flags.
- Token Vault doesn't support scope narrowing — the
scopeparameter is ignored on federated exchanges. Fix: application-layer scope awareness. - CIBA + Token Vault composition — Auth0 documents them as separate pillars. No official guide combines CIBA as a gate before Token Vault exchange in a batch model. DealFlow wired them together.
Accomplishments
- Graduated trust architecture: Four trust levels, three surfaces, one Token Vault pipeline — security adapts to the surface's trust properties
- IETF draft alignment: DealFlow's three surfaces loosely map to the delegation patterns described in individual Internet-Draft
draft-klrc-aiagent-auth-01(March 2026): user-delegated (Chat), pre-authorized (Action Center), and agent-to-agent (MCP). Our strongest area is authorization — RFC 8693 token exchange, CIBA human-in-the-loop, step-up auth, and surface-aware trust graduation. Note: this is an individual draft, not adopted IETF consensus. - CIBA batch scheduling: One Guardian push approves all actions, time-boxed execution within the CIBA token's lifetime
- Trust calibration: System observes approval patterns and recommends autonomy upgrades and user decides, never auto-escalating on its own
- Confidence routing: AI scores suggestions where users can elect to have high confidence auto-approve and/or low confidence forced reviews regardless of autonomy setting
- 31 documented insights: SDK bugs, Token Vault behaviors, CIBA patterns, and findings that benefit the Auth0 community
What I learned
Token Vault is a powerful primitive and "Authorized to Act" forced me to boost my knowledge on token management 300%; it was awesome. It also made thing much more enjoyable in terms of getting things set-up. I found the dashboard to be logical/relatively straightforward...well, just a few UI notes, ha. But overall, things went fast. The piece of mind with short-lived tokens as well as ease of management are huge and wouldn't have understood how huge without this challenge.
What's next for auth0 by Tofte
- Incremental authorization (request OAuth scopes only when needed)
- Multi-user workspaces with team-level policies
- Published reference integration examples for external MCP agents
📝 Bonus Blog Post: What I Learned Composing CIBA + Token Vault for Batch Agent Consent
Auth0 Token Vault solves credential management. But when your AI agent operates across three different surfaces of chat, action queue, and MCP for external agents you need consent that adapts; confidently.
The gap found: Auth0 documents Token Vault and CIBA as separate features. By combining them, the DealFlow project uses CIBA as an authorization gate before Token Vault token exchange in a batch model.
How? A cron job gathers pending AI-suggested actions, sends one Guardian push: "DealFlow: 5 actions - 3 email, 2 calendar, 1 slack" to user. On phone approval, exchanges tokens through Token Vault within the CIBA token's time-boxed window. One tap, batch execution, automatic expiry. This is an attempt to fill the gap between "always ask" and "never ask."
What broke along the way:
- The
@auth0/ai-vercelSDK silently swallows token exchange errors — failed exchanges return "Authorization required" instead of the real Auth0 error. We filed #175. Fix: call/oauth/tokendirectly via RFC 8693. - Deleting a tokenset doesn't revoke access; Auth0 silently re-provisions on the next exchange. Fix: application-level Redis flags.
- Token Vault ignores the
scopeparameter on federated exchanges. Fix: application-layer scope awareness per tool.
All 31 insights documented with root cause and fix in our repo.
Built With
- auth0
- ciba
- claude
- framer-motion
- next.js
- react
- tailwind-css
- token-vault
- typescript
- upstash-redis
- vercel
- vercel-ai-sdk
Log in or sign up for Devpost to join the conversation.