AgentBank

We don’t give agents keys; we mint permission for one intent at a time.

Comment

Inspiration

Local agents (OpenClaw-style) shouldn’t hold OAuth secrets or call the outside world directly. Humans still need control, auditability, and identity the way we expect for real software. We built AgentBank for the Auth0 “Authorized to Act” story: Token Vault holds the tokens, policy holds the authority, and the model only routes intent — it doesn’t “own” access.

What it does

AgentBank is a secure execution layer between a restricted local agent and real APIs. The user sends plain language; OpenAI outputs a structured intent only. Firewall, RBAC, trust, and policy decide allow / deny / step-up. Only the executor exchanges Auth0 Token Vault tokens (e.g. GitHub, Google) or hits Base Sepolia via CDP — then returns sanitized results. Every run can surface intent-scoped permission metadata, a Vault/firewall log, explainability, an orchestration trace (multi-agent visibility), a context buffer, eval scores, and optional autonomous ticks through the same pipeline.

How we built it

Stack: Next.js (App Router), Auth0 session + Token Vault token exchange, OpenAI structured outputs for intent classification, deterministic policy and trust in TypeScript, AgentKit/CDP for testnet demos. POST /api/intent runs the main path; shared runIntentPipeline also powers autonomous ticks. We added in-memory context graph / memory, eval reports, and orchestration steps on each response, plus dashboard tabs for Identity, Guardrails, Trust, Runtime, Audit.

Challenges we ran into

Balancing honest positioning (Vault issues real provider tokens; we bind them per intent in app code) vs a crisp hackathon narrative. Serverless hosting vs wallet file / in-memory state (loans, context, evals) — fine for demos, not production. Step-up today is in-dashboard approval + optional Auth0 re-auth link, not full Auth0 Actions MFA everywhere. Keeping the UI clear while surfacing orchestration, evals, and context without overwhelming first-time viewers.

Accomplishments that we're proud of

Token Vault on the real execution path, not as a slide decoration. A single authority pipeline (router → gates → executor) that’s easy to demo. Per-action permission story (scoped use, logging, local revoke narrative) plus explainability for judges. Runtime tab tying autonomy, eval loop, and context to the same /api/intent contract. A dashboard that still reads as product, not a pile of disconnected APIs.

What we learned

Identity and authority deserve first-class product design, not an afterthought after the chat UI. Visibility (orchestration trace, audit, evals) matters as much as blocking bad actions — especially when talking about multi-agent futures. Auth0 Token Vault fits naturally as the credential boundary if execution stays server-side and the local agent stays untrusted.

What's next for AgentBank

Production persistence (DB for context, eval history, loans, wallet metadata) and real schedulers (queue + cron) for autonomous jobs. Auth0 Actions / MFA for high-risk intents instead of only in-app approve. Router-only vs execute split or stronger preview/confirm APIs for enterprise flows. Stricter eval suites (CI + golden intents) and optional red-team checks. Deeper Token Vault usage patterns (narrower connections, more providers) and a hardened public deploy story with env and callback discipline.

Bonus Blog post

Auth0 Token Vault and why I built around it This is my optional blog for the bonus prize. It is about what I actually shipped with Auth0, especially Token Vault for AI Agents, and it is not the same wording as my short project description.

Why I leaned on Auth0 Token Vault for agents I kept running into the same problem when I thought about local agents and tools. It is not enough to tell people not to paste API keys into a chat. The real question is who is allowed to act for the user, and where the OAuth tokens actually live. I did not want the model or the local UI to own GitHub or Google access. I wanted Auth0 to stay the identity and consent layer, and I wanted my backend to be the only place that turns a signed in user into a real API call.

That is why Auth0 Token Vault is the core of my project, not a side note. The user connects GitHub or Google through Auth0 the way you already would for a normal app. Auth0 stores the federated token in the vault. My server uses Auth0’s token exchange flow so that at runtime I can pull a short lived provider token when policy says execution is allowed. The agent surface never sees that token. My executor does, and only after Auth0 session plus my own rules.

I built AgentBank so the split is obvious: OpenAI only classifies text into a structured intent. Auth0 proves who the user is. Token Vault is how I get OAuth access without teaching the agent my keys. Policy, RBAC, trust, and step up are how I decide if that access should run at all. If I cannot point to one server path that talks to Auth0 for tokens, I do not think the demo is honest. In my app, that path is narrow on purpose.

For anyone else in the Auth0 community building agent demos, my takeaway is simple: start with Auth0 session and Token Vault, then add intent and policy. If you start from “cool agent” and bolt Auth0 on last, you usually end up with secrets in the wrong place. Auth0 already solves identity and delegated access for humans. I am using the same primitives for “agents as clients,” and Token Vault is what makes that feel real instead of theater.

I am proud that my story for judges is not “we called an API.” It is “Auth0 holds the trust, and my app only executes when Auth0 backed identity and Vault backed tokens meet my policy.” That is the part I hope other builders copy.

Built With

  • agentkit/cdp
  • auth0-session-+-token-vault-token-exchange
  • deterministic-policy-and-trust-in-typescript
  • openai-structured-outputs-for-intent-classification
  • stack:-next.js-(app-router)
Share this project:

Updates