The Problem

AI agents are becoming incredibly capable, but a fundamental problem remains: how can an agent act on behalf of a user without becoming opaque or over-privileged?

Most solutions address this with static OAuth scope selection at connect time. Once granted, the agent has unrestricted access, and users have no way to define ongoing behavioral rules, see which actions require approval, or understand why an action was allowed. The gap between "what the agent can access" and "what the agent should do right now" is where user trust breaks down.

What Axon Does

Axon is a constitution-driven AI productivity agent that bridges this trust gap. It introduces a "constitution layer" between the user and the agent. Users define behavioral rules in plain English. Those rules are enforced at runtime, at the tool execution layer, before any action reaches an external service.

This is not prompt injection. The rules are stored in a database and checked in application code before tool calls execute.

Core Architecture

1. Token Vault Integration Google is connected through Auth0 Token Vault. Third-party OAuth tokens are never stored in the application database. Access is retrieved on demand, per action, through the Token Vault federated exchange.

2. Constitution Rules Users write rules like:

  • Never send emails without my approval
  • Always ask before creating calendar events Violations are not just logged—they are structurally blocked and converted into explicit approval requests.

3. Risk-Based Intent Classification Every tool call is classified into one of five risk tiers: observe, draft, act, transact, admin. Classification determines whether an action executes automatically, requires approval, or is blocked entirely.

4. Approval Queue & Operating Modes Act-tier actions (like sending an email or creating an event) generate approval requests on a dedicated Approvals page. Users can choose between Shadow (observe only), Assist (approvals required for writes), and Autopilot (automatic execution).

5. Full Audit Trail Every action logs the service, action type, risk tier, scopes used, constitution rules applied, reasoning, and outcome.


Bonus Blog Post

Building Axon taught me that the hardest part of AI agents is not model intelligence, but authority.

Modern LLMs are already highly capable of planning, summarizing, drafting, and calling tools. The real challenge begins when an AI assistant moves from “answering questions” to “acting on behalf of a user.” At that point, the key question becomes: how do you let an agent do useful work without giving it invisible or excessive power? That is the exact problem I wanted Axon to explore.

The most valuable part of this build was using Auth0 Token Vault as the delegation layer. Instead of storing third-party Google credentials directly in my own Supabase database, Google access is connected and managed entirely through Auth0. That immediately creates a cleaner security model. The application does not need to become a vulnerable secret store, and the boundary between the user, the app, and the external provider stays much more explicit. I simply request an access token just-in-time when a tool executes.

However, configuring Token Vault was also the highest technical hurdle. The documentation around the required "My Account API", configuring Multi-Resource Refresh Tokens (MRRT), and the specific urn:auth0:params:oauth:grant-type:token-exchange:federated-connection-access-token grant type took extensive debugging. I ended up writing custom Node.js scripts against the Auth0 Management API just to provision the tenant correctly. I also hit roadblocks with GitHub integrations, learning the hard way that standard GitHub OAuth apps don't issue refresh tokens by default, which broke the Token Vault exchange flow.

But Token Vault alone does not solve behavior. The next insight was that users need a way to define what the agent should and should not do in terms they actually understand. That led to the constitution model. A rule like “Never send emails without my approval” is much more human and trustworthy than exposing raw OAuth scope details. It becomes a useful bridge between technical authorization and user intent.

Another important lesson was transparency. Once an agent begins interacting with real services, action logs stop being a nice extra and become a core trust feature. Users need to know what happened, which scopes were used, what type of action it was, and why it was allowed. That auditability ended up feeling just as important as the AI functionality itself.

If I continue Axon after the hackathon, I want to push further on three things: stronger runtime rule parsing, approval queues for multi-agent workflows, and broader service integrations. The biggest takeaway is simple: agent authorization should not be hidden behind a one-time consent screen. It should be continuous, inspectable, and shaped continuously by the user. Auth0 Token Vault provides exactly the right foundation for that future.

Built With

  • auth0
  • gmail-api
  • google-calender-api
  • groq
  • next.js
  • supabase
  • tailwindcss
  • typescript
  • vercel
Share this project:

Updates