-
-
Index
-
Auth0's Login
-
Dashboard
-
Connecting apps
-
Connected apps
-
Ready-to-use AI agent
-
Low-risk request
-
High-risk request awaiting confirmation with Guardian CIBA
-
Notification on my phone
-
Confirmation of the high-risk request
-
High-risk request approved
-
Message sent successfully
-
SecureDesk’s audit trail shows every delegated AI action with risk, approval, execution, and live trust visibility.
Inspiration
Most AI agent demos look impressive until you ask one question: what actually stops the agent from doing something it shouldn't? The answer is usually "nothing." Tokens are hardcoded, permissions are all-or-nothing, and there's no real human checkpoint before sensitive actions execute.
I built SecureDesk to answer that question seriously. The goal was to prove that an AI agent can be genuinely useful — operating on real Slack and Gmail accounts in natural language — while keeping credentials protected, actions authorized, and humans in the loop for anything that matters.
What it does
SecureDesk is a corporate AI agent with a chat interface that lets users operate on Slack and Gmail using plain English. You can list channels, read emails, summarize your inbox, post messages, and send emails — all from a single conversational workspace.
But the core of the product is its security model:
- Auth0 Token Vault stores every OAuth credential. The app never sees a raw token. Access is exchanged server-side at runtime, scoped to the exact action needed.
- Auth0 FGA decides whether a user is allowed to invoke a given tool before the agent does anything.
- Risk classification tags every action as low-risk (read) or high-risk (write) before execution.
- Approval flow stops high-risk actions and requires explicit user confirmation. The approval is validated server-side — not trusted from the client.
- CIBA / Auth0 Guardian enables external async approval for high-risk actions when available.
- Persistent audit log records every action, approval, and outcome in Postgres — surviving redeploys and cold starts.
The Trust Center sidebar shows all of this in real time as the agent operates.
How I built it
The stack is Next.js 14 App Router, TypeScript, and Tailwind CSS deployed on Vercel. Auth0 handles login, Connected Accounts, Token Vault, FGA, and CIBA. Gemini 2.5 Flash handles natural language intent parsing, with a deterministic runtime fallback if the model is unavailable. Neon Postgres persists audit logs and approval sessions via Vercel Storage.
The architecture deliberately separates concerns: Gemini interprets intent, the runtime resolves and validates the action, FGA authorizes it, Token Vault provides access, and the result is logged — every step independently verifiable.
Challenges I ran into
The hardest part was making the approval flow genuinely secure rather than just visually present. It's easy to show a confirmation modal and trust the frontend to send an "approved" flag. Making the backend generate a signed session, bind it to a specific user and action, and refuse to execute without server-side validation — that required rethinking the entire request lifecycle.
Integrating Token Vault with two providers simultaneously (Slack and Gmail) also required careful handling of token scopes and refresh cycles, especially when validating real connection state against what Auth0 Connected Accounts reports.
Accomplishments that I'm proud of
The security model isn't decorative. Every layer — Token Vault, FGA, approvals, audit — is doing real work in the execution path. You can't bypass any of it from the client. That was the goal from day one and it held through the entire build.
What I learned
Auth0 Token Vault fundamentally changes how you think about credential management in agentic systems. The mental shift from "store a token and use it" to "request delegated access at runtime" is small in code but enormous in security posture. It should be the default pattern for any agent that touches third-party services.
What's next for SecureDesk
Expanding to more enterprise tools — calendar, cloud storage, project management — using the same Token Vault pattern. Each new integration gets FGA policies, risk classification, and audit logging automatically. The foundation is built to scale.
Blog Post
How Auth0 Token Vault Became the Core of SecureDesk's Security Model
When I started building SecureDesk for the Authorized to Act hackathon, I had one question I wanted to answer honestly: what does it actually mean for an AI agent to be authorized to act?
The answer starts with how you handle credentials.
The problem with the obvious approach
The naive way to build an AI agent that connects to Gmail and Slack is also the dangerous way: store the user's OAuth tokens in your database, pass them to the agent when needed, and let it call the APIs directly. It works. It's fast to build. And it creates a massive attack surface. If your database is compromised, every user's Gmail and Slack access goes with it.
What Token Vault changes
Auth0 Token Vault solves this by removing the credential from the application entirely. When a user connects Gmail or Slack in SecureDesk, the resulting OAuth token never lands in our database — Auth0 stores it. Our backend never sees the raw token at rest.
When the agent needs to act, it asks Token Vault for delegated access at runtime. Token Vault validates the request, handles the token exchange server-side, and returns scoped, time-limited access. The API call happens. Then it's gone. Even if someone compromised our entire codebase and database, they would find zero usable credentials. The tokens live outside our trust boundary by design.
Pairing Token Vault with approval flows
Token Vault protects credentials, but there's a second question: should the agent execute this action right now, without asking? For read-only operations, usually yes. For write operations — sending emails, posting messages — not without explicit approval.
SecureDesk classifies every action by risk level. High-risk actions pause the agent and surface a full approval request showing exactly what will happen and to what data. The approval is validated server-side — a signed session linked to the specific user and action — so bypassing it from the client is not possible. When Auth0 CIBA is available, the approval can also be delivered externally through Auth0 Guardian.
What this makes possible
The result is an agent you can trust with real accounts. Token Vault made the secure path the easy path — and that's the insight I'd take to any team building on Auth0 for AI Agents.
SecureDesk uses Auth0 Token Vault, FGA, CIBA, Next.js 14, Gemini 2.5 Flash, and Vercel Postgres.
Built With
- auth0
- auth0-ciba
- auth0-fga
- auth0-guardian
- auth0-token-vault
- framer-motion
- gmail-api
- google-gemini-2.5-flash
- lucide
- neon-postgres
- next.js
- prisma
- react
- slack-api
- tailwind-css
- typescript
- vercel
- zustand


Log in or sign up for Devpost to join the conversation.