AgentGate

Two-layer auth for AI agents. Auth0 Token Vault secures API credentials. Kanoniv Agent Auth secures delegation authority. Together, the complete authorization stack for autonomous agents.

Comment

Inspiration

Every AI agent framework today conflates two very different problems: credentials (which APIs can the agent access?) and authority (what is the agent authorized to do, and who said so?). An agent with a Gmail OAuth token can read, send, and delete emails — but should it? Who authorized that specific action? Can that authorization be revoked without revoking the token?

We built AgentGate because we believe the answer requires two layers of authorization working together.

What it does

AgentGate is a multi-agent system where a human delegates scoped authority to AI agents that call external APIs on their behalf. The human controls both layers:

Layer 1 — Auth0 Token Vault: Which external services (Gmail, GitHub) can agents access? Token Vault handles OAuth token storage, refresh, and scoping.

Layer 2 — Kanoniv Agent Auth: Which actions can each agent perform, for how long, with what constraints? Kanoniv handles cryptographic delegation chains with 6 caveat types (ActionScope, ExpiresAt, MaxCost, Resource, Context, Custom).

The demo shows two agents: a support-agent (reads Gmail + searches GitHub issues, 2h TTL) and a deploy-agent (creates GitHub releases, 30min TTL, max 1 release). Every action is verified against both layers before execution and cryptographically signed for the audit trail.

How we built it

  • Backend: Python (FastAPI) orchestrating the two auth layers
  • Auth Layer 1: Auth0 SDK + Token Vault for Gmail/GitHub credential management
  • Auth Layer 2: kanoniv-agent-auth Python SDK (PyO3 bindings to a Rust engine) for delegation, MCP Proofs, and wrap-mcp proxy
  • Frontend: React dashboard showing active delegations, connected accounts, and real-time enforcement logs (ALLOWED/BLOCKED with reasons)
  • Cryptography: Ed25519 keypairs, did:agent: identifiers, macaroon-style attenuated authority

Auth0 Token Vault Integration

Token Vault is the credentials layer in our "double gate" pattern:

from auth0_ai import TokenVault

vault = TokenVault(domain="agentgate.auth0.com", client_id="...")
gmail_token = vault.get_token(user_id=user.sub, connection="google-oauth2")
github_token = vault.get_token(user_id=user.sub, connection="github")

Before using these tokens, agents must also pass Kanoniv's delegation check — proving they have authority to perform the specific action. This prevents an agent with valid Gmail credentials from performing unauthorized actions.

The Two-Layer Pattern

Most agent frameworks treat authorization as binary: the agent either has access or it doesn't. Our pattern separates concerns:

  1. Verify authority (Kanoniv): Does this agent have a valid delegation chain authorizing gmail.read?
  2. Retrieve credentials (Token Vault): Get the OAuth token for Gmail
  3. Execute: Call the Gmail API with the token
  4. Sign: Record the action with cryptographic provenance

Authority can only be attenuated, never widened — just like macaroon tokens. A human delegates [gmail.read, github.issues.search] to support-agent, and that agent cannot escalate to gmail.send.

Challenges we ran into

Designing caveat attenuation for real workflows was the hardest part. How do you express "can create at most 1 GitHub release in the next 30 minutes" as a composable caveat? Our solution: 6 typed caveat primitives that can be stacked and verified offline without calling any server.

Accomplishments that we're proud of

  • Production-grade engine: 1,589 tests, Rust core with Python/TypeScript/Rust SDKs
  • Offline verification: MCP Proofs are self-contained — verify delegation chains without network calls
  • wrap-mcp: A proxy that adds Kanoniv auth to any existing MCP server with zero code changes

What we learned

Credentials and authority are fundamentally different problems. Token Vault solves credential lifecycle beautifully — storage, refresh, scoping. Kanoniv solves authority lifecycle — delegation chains, time-bounded permissions, cryptographic audit trails. Together they form a complete authorization stack that neither can provide alone.

What's next

  • MCP Proofs as a standard authorization format for agent-to-agent communication
  • wrap-mcp as the default auth layer for any MCP server deployment
  • Deeper Auth0 integration: Token Vault as the default credential backend in Kanoniv's authority engine

Bonus Blog Post

Two Layers of Trust: Why AI Agents Need Both Credentials and Authority

When you hand your car keys to a valet, you're making two distinct trust decisions. First, you're giving them the credentials — the physical key that starts the engine. Second, you're granting authority — park my car, don't take it for a joyride. These are different things, and we intuitively understand the distinction.

AI agents face the same problem, but most frameworks collapse these layers into one. An agent gets an OAuth token for Gmail, and suddenly it can read, compose, forward, and delete emails. The credential (the token) and the authority (what actions are permitted) are fused together.

This is dangerous. As agents become more autonomous and start calling real APIs on our behalf, we need to separate these concerns.

Layer 1: Credentials — Auth0 Token Vault

Token Vault solves the credential problem elegantly. It stores OAuth tokens, handles refresh flows, and scopes API access per user and per connection. When our support-agent needs to read Gmail, Token Vault provides a valid token — no hardcoded secrets, no expired credentials, no manual refresh logic.

But Token Vault intentionally doesn't answer: "Should this particular agent be reading this particular user's email right now?" That's not a credential question. That's an authority question.

Layer 2: Authority — Kanoniv Agent Auth

Kanoniv Agent Auth solves the authority problem with cryptographic delegation chains. A human creates a delegation: "support-agent may perform gmail.read and github.issues.search until 2pm today." This delegation is a signed token that the agent carries. Before every action, the agent creates an MCP Proof — a cryptographic certificate that proves the delegation chain is valid.

The key insight: authority can only be attenuated, never widened. If a human delegates [gmail.read, gmail.send] to agent A, and agent A sub-delegates to agent B, agent B can receive at most those same permissions — and typically fewer. This is the macaroon pattern applied to AI agent authorization.

The Double Gate

In AgentGate, every API call passes through both gates:

  1. Kanoniv gate: Verify the delegation chain. Does this agent have authority for this action? Is the delegation expired? Are all caveats satisfied?
  2. Token Vault gate: Retrieve the credential. Get a valid OAuth token for the requested API.

If either gate fails, the action is blocked. The enforcement dashboard shows exactly why in real time — "BLOCKED: delegation expired 5 minutes ago" or "BLOCKED: action gmail.send not in delegation scope."

Why This Matters Now

As AI agents move from chatbots to autonomous actors — booking flights, managing code, handling customer support — the question isn't whether they need authorization. It's whether our authorization infrastructure is ready.

Token Vault gives us the credential layer. Kanoniv gives us the authority layer. Together, they're the full auth stack that autonomous AI agents demand.

Built With

Share this project:

Updates