Bolospot: Auth0 Token Vault for the Consent Layer

Auth0 secures the credentials. Bolospot secures the consent. AI agents get scoped, short-lived tokens only after humans say yes.

Comment

Inspiration

Every AI agent framework solves the same problem: how to make agents capable. Nobody's solving the harder one: how to make agents accountable.

We've been building Bolospot — the consent layer for humans in an agentic world — and kept hitting the same wall. A patient wants a scheduling agent to book a PT appointment. That agent needs Google Calendar access. The only option? Hand it a long-lived refresh token and store it in our database. One breach, and every user's calendar is exposed. One rogue agent, and there's no kill switch.

When Auth0 announced Token Vault with RFC 8693 Token Exchange, it clicked: Auth0 could own the credentials while Bolospot owns the consent. Two layers, one clean boundary.

What it does

Bolospot gives every person and agent an @handle. "Bolos" — our atomic trust objects — let users grant, scope, and revoke what agents can do on their behalf. Auth0 Token Vault moves all OAuth token storage out of our database, so agents get scoped, short-lived, revocable tokens instead of long-lived secrets.

The live demo at bolospot.com/auth0hackathon shows a split-screen interaction between a patient and a BoMed scheduling agent:

Patient enters insurance info and sends a bolo to @bomed BoMed agent uses its API key to request data through our relay system Auth0 Token Vault issues a scoped token via RFC 8693 Token Exchange Patient revokes — all tokens killed instantly Every button triggers a real API call: POST /api/grants, POST /api/relay/send, DELETE /api/grants/:id.

How we built it

We started with the interface, not the implementation. ITokenVaultProvider defines five operations: storeToken, getToken, revokeToken, delegateToken, getStoredTokens. Any vault backend that implements this interface slots in.

The Auth0 provider uses OAuth 2.0 Token Exchange (RFC 8693): when an agent needs calendar access, it exchanges the user's stored token reference for a scoped, short-lived access token. The agent never sees the refresh token. Auth0 handles rotation automatically.

We added a vaultTokenRef column to our database — a pointer, never a secret. When a user connects Google Calendar, the OAuth tokens go straight to Auth0 Vault. Our DB stores only the reference.

The facade layer (TokenVaultService) handles provider selection and graceful fallback: if Auth0 isn't configured, the system falls back to database storage. This let us ship incrementally without breaking existing users.

Challenges we ran into

Mapping two trust models onto each other. Bolospot's bolo graph and Auth0's token delegation model don't map 1:1. A bolo can grant appointments:read access, but Token Vault works at the OAuth scope level. We built a translation layer that converts bolo permissions into the right token scopes for each provider.

Graceful degradation. Not every deployment will have Auth0 configured. The fallback path had to be seamless — we couldn't let the vault integration break the existing flow for users who haven't migrated yet.

Demo that isn't a toy. Every button in the demo triggers a real API call against our production backend. The demo page is a thin client over the same endpoints our MCP server and agents use. No mock data.

Accomplishments that we're proud of

Zero tokens in our database. We store vaultTokenRef — a pointer, not a secret. Auth0 holds the keys. The abstraction layer. The ITokenVaultProvider interface means we can swap Auth0 for any vault provider without touching application code. Built for Auth0 today, portable forever. Real demo, real API. The hackathon page isn't a simulation. Grants, relay messages, and revocation all hit the live Bolospot API — the same endpoints our MCP server uses in production. Instant revocation. Unlike on-chain identity solutions, revoking a bolo kills the token immediately. No consensus delay. No eventual consistency. Kill it → it's dead.

What we learned

Consent and credentials are separate problems. We'd been conflating them. A bolo answers "is this agent allowed to do this?" — that's consent. Token Vault answers "here's a scoped credential to do it" — that's delegation. Once we drew that line, the architecture fell into place.

Non-transitive trust matters more than you think. In most OAuth systems, if App A has your token and calls App B, your token travels. In Bolospot, trust doesn't propagate: Tom trusts Alison, Alison trusts Bob — Tom's agent cannot reach Bob. Token Vault enforces this at the credential layer, not just the permission layer.

Revocation has to be instant. On-chain solutions talk about revocation, but consensus takes time. With Auth0 Vault, revoking a bolo kills the token reference immediately. No propagation delay.

What's next for Bolospot: Auth0 Token Vault for the Consent Layer

Full Auth0 social connection flow — users authenticate via Auth0 (Google/Microsoft), tokens go directly to Vault, never touching our servers Per-agent scoped tokens in production — each agent gets its own short-lived token based on the bolo grant scopes, not a shared credential Widget developer SDK — third-party apps (BoMed, BoHire, Bolove) register their own permission categories and get vault-backed delegation out of the box Audit dashboard — real-time visibility into which agents accessed what, when, and with which scoped token — powered by Token Vault audit logs Self-hosted provider option — the ITokenVaultProvider interface is ready; we'll ship a self-hosted alternative for enterprise deployments that can't use cloud vaults

Blog

https://medium.com/p/71c32f86a1d5?postPublishedType=initial Auth0 Secures the Credentials. Bolospot Secures the Consent. When Auth0 announced Token Vault and the “Authorized to Act” hackathon, I knew Bolospot was the perfect proving ground. We’re a scheduling platform where AI agents act on behalf of users — booking meetings, checking availability, relaying messages. The missing piece was always: how do you give an agent access to someone’s Google Calendar without handing it the refresh token?

The answer turned out to be surprisingly clean. We built a provider-agnostic TokenVaultService with a simple interface: storeToken, getToken, revokeToken, delegateToken. The Auth0 implementation uses RFC 8693 Token Exchange — when an agent needs calendar access, it exchanges the user’s Auth0 token for a short-lived, scoped provider token. The agent never sees the refresh token. If the user revokes, it’s instant.

The hardest part wasn’t the token exchange itself — Auth0’s API is well-documented. It was rethinking our trust model. In Bolospot, we have “bolos” (grants) that define what each person or agent can access. Layering Token Vault underneath meant that the bolo controls permission while the vault controls credentials. They complement each other perfectly: permissions follow people, tokens follow Auth0.

The demo at bolospot.com/auth0hackathon shows this end-to-end: a patient grants a BoMed scheduling agent access to insurance data, the agent requests it through our relay with its API key, and the patient can kill all access with one click. Every button triggers a real API call.

What surprised me most: the abstraction layer we built for Auth0 will let us swap to any vault provider later. The interface is clean enough that self-hosted solutions or other providers would slot right in. Auth0 gave us

Built With

Share this project:

Updates