Inspiration

Most authorization systems still think in terms of one user authorizing one app. That model works for traditional software, but it starts breaking down the moment AI systems become agentic. As soon as a user asks one root agent to handle a goal, and that root agent begins delegating work to sub-agents, the question is no longer just “what can this app do?” It becomes “which actor is doing what, under whose authority, with what limits, and how can that authority be revoked?”

That gap is what inspired Warrant. We wanted to build something that did not treat agent authorization as a thin UI layer on top of OAuth, but as a real systems problem. Auth0 for AI Agents and Token Vault gave us the right foundation for secure delegated access to external tools, but we wanted to explore the missing layer above that: a model where a user authorizes a root agent, and child agents operate under narrower, revocable warrants instead of inheriting one flat identity.

In short, Warrant came from a simple conviction: OAuth was designed for apps. AI agents need warrants.

What it does

Warrant is a multi-agent authorization system built with Auth0 for AI Agents and Token Vault. It allows a user to authorize a root agent, which can then delegate narrower, time-bounded, revocable authority to child agents such as a Planner, Calendar Agent, and Comms Agent.

Instead of letting every part of the system share one broad access boundary, Warrant introduces an explicit delegation model. Each child agent gets:

a specific role,
a limited set of capabilities,
a constrained context window,
a bounded warrant,
and a visible runtime identity.

The system distinguishes three critical control surfaces:

deny — when a child agent tries to exceed its warrant,
approve — when an action is allowed in principle but sensitive in practice,
revoke — when a branch of delegated authority should be invalidated without collapsing the rest of the workflow.

For the demo scenario, a user asks Warrant to prepare an investor update and coordinate follow-ups. The Planner breaks the goal into subtasks, the Calendar Agent handles schedule-related reasoning, and the Comms Agent drafts follow-up communication. Every action passes through Warrant’s control layer, which decides whether it should be denied, gated behind approval, executed, or blocked due to branch revocation. The result is a system where multi-agent behavior becomes bounded, legible, and traceable instead of opaque and overprivileged.

How we built it

We built Warrant as a layered system instead of a single monolithic assistant.

At the foundation, we used Auth0 for AI Agents and Token Vault as the secure identity and delegated-access layer. This gave us a proper way to connect user-authorized external access and keep sensitive provider interactions grounded in a real authorization flow rather than ad hoc credential handling.

On top of that, we built a custom Warrant layer that models delegated authority between agents. A parent can create a child warrant, but the child can only receive a narrower subset of the parent’s authority. That gave us the core semantics we wanted: bounded delegation, branch-level revocation, and explicit runtime accountability.

For the agentic runtime, we used Gemma 4 31B as the reasoning model and built a role-bounded runtime around it. Instead of pretending that one generic model call was a whole multi-agent system, we defined separate runtime actors:

Planner Agent for decomposition and delegation,
Calendar Agent for schedule-aware reasoning,
Comms Agent for drafting and communication proposals.

All of them use the same underlying model family, but they differ in role, context, prompt, tool scope, output schema, and warrant constraints. That separation is what makes the system genuinely agentic for our use case.

We also built:

a proposal-to-control bridge, where agents propose actions and the system decides whether those actions are denied, approval-required, executable, or blocked by revoke,
a runtime event layer, so graph and timeline surfaces can point to real runtime actors instead of placeholders,
and a delegation topology view, which makes the chain of delegated authority inspectable.

The entire architecture was built around one principle: the model can propose, but the system decides.

Challenges we ran into

The hardest challenge was not building an AI-powered demo. It was making the system truthful.

It is very easy to fake a “multi-agent” system by calling the same model a few times with different prompts and naming those outputs different agents. We did not want that. We wanted the Planner, Calendar, and Comms layers to be real runtime actors with distinct roles, contexts, capabilities, and control boundaries. That meant a lot of extra work around contracts, runtime state, structured proposals, and action routing.

Another big challenge was preserving the distinction between:

model reasoning,
agent runtime state,
authorization policy,
approval flow,
and actual execution.

If those layers blur together, the product becomes much easier to build — but also much less meaningful. A major part of the work was keeping those layers separate enough that Warrant could honestly claim to solve a real authorization problem.

We also ran into the classic pain of ambitious prototype building:

UI consistency issues,
graph topology layout and overflow problems,
state drift across repeated runs,
integration breakages between waves,
and the difficulty of making a system both inspectable and usable under demo constraints.

Finally, one of the deepest design challenges was deciding how much autonomy to give the agents. We deliberately chose bounded autonomy over “agent swarm” theatrics. That was the right call conceptually, but it required discipline throughout the implementation.

Accomplishments that we're proud of

We are proud that Warrant is not just another assistant with tool access. It is a concrete attempt to model a new authorization problem: how delegated authority should work in a multi-agent system.

The accomplishment we are most proud of is the conceptual integrity of the system. Warrant does not treat authorization as an afterthought. It treats it as the product. That meant building:

a root-to-child delegation model,
runtime-distinct agents,
explicit warrants,
deny/approve/revoke as first-class control surfaces,
and visible lineage across actions and branches.

We are also proud of the fact that Warrant makes a difficult systems concept legible. The topology graph, runtime states, and audit flow are all meant to show not just what happened, but who acted, under what authority, and why the system allowed or blocked that behavior.

Another accomplishment is the runtime architecture itself. Even though the agents can share the same underlying model family, they are not just renamed prompts. The Planner, Calendar, and Comms roles are structurally distinct in purpose, context, outputs, and control boundaries. That gave us a version of “agentic” behavior that feels much more honest and grounded.

And finally, we are proud that Warrant surfaces a bigger idea than the demo itself. Even in prototype form, it points toward a future where AI systems need delegation-aware authorization, not just app-style access tokens.

What we learned

The biggest thing we learned is that the line between an LLM and an agent becomes clear the moment you stop thinking in terms of “one model call” and start thinking in terms of:

goals,
runtime actors,
state,
tools,
proposals,
controls,
and execution boundaries.

A model alone is not the interesting part. The interesting part is the runtime around it.

We also learned that agent authorization is not just a backend security problem. It is a product design problem. Users need to understand:

what has been authorized,
what has been delegated,
what is still bounded,
what is sensitive,
and what can be revoked.

That means consent, approval, denial, and revocation all need to be visible in the product experience, not hidden inside internal logic.

On the engineering side, we learned how quickly complexity compounds when ambitious systems are built in parallel. Clean worktree strategy, contract stabilization, and tight branch ownership were not “nice to have” process details — they were necessary to keep the project coherent.

And maybe most importantly, we learned that the most exciting part of building with AI is not raw model capability. It is designing systems around model capability that are actually worthy of trust.

What's next for Warrant — OAuth for Apps. AI Agents Need Warrants.

The current version of Warrant is a strong prototype, but we see it as the beginning of a bigger direction.

The next step is to make the delegation model even more powerful and production-ready. That includes:

stronger runtime hardening,
even more robust graph and timeline UX,
cleaner replayability and scenario restoration,
and better visibility into branch-level authority consumption over time.

We also want to expand the policy model beyond the current scenario and explore richer warrant semantics, such as:

stronger capability budgeting,
deeper lineage inspection,
more expressive approval conditions,
and finer-grained revocation patterns across larger agent trees.

On the product side, we want to keep improving the user experience of consent legibility. One of the most interesting open problems is not just whether an agent can act, but whether a human can truly understand the future blast radius of the authority they are granting.

Longer term, Warrant points toward a broader idea: if multi-agent systems become normal, then app-style flat consent will stop being enough. We believe systems will need explicit, inspectable, revocable chains of delegated authority — and Warrant is our first concrete step toward that future.

OAuth Was Designed for Apps. AI Agents Need Warrants.

The practical problem

If you have built an agent-enabled product recently, you have probably shipped some version of this:

User signs in.
User connects Google or Microsoft.
Agent can now read and write on the user’s behalf.

That flow works when one app process acts as one principal. It gets shaky when a root planner starts delegating to specialized child agents.

Our hackathon project, Warrant, started from one narrow question:

What authorization model do we need once a user-approved planner delegates to specialized child agents with different risk profiles?

Short answer: app-level OAuth consent is necessary, but not sufficient.

Where flat consent breaks

OAuth gives your app delegated tokens. It does not model internal delegation chains or branch-level authority.

Once your planner decomposes work, you now have multiple actors:

Planner agent (decomposes)
Calendar agent (reads schedule context)
Comms agent (drafts and maybe sends)

If all those branches share one flat "the app is authorized" truth, two important controls disappear:

capability narrowing per child branch
branch-level revocation after authority was already delegated

You can still hardcode checks in business logic, but without an explicit delegation contract the system becomes hard to inspect, hard to audit, and hard to revoke safely.

Why Token Vault is still non-negotiable

This is not an OAuth replacement argument.

In Warrant, Auth0 for AI Agents + Token Vault are load-bearing:

user identity/session boundary
provider connected-account flow
delegated external access path to Calendar/Gmail
execution-release boundary for sensitive send actions

Without Auth0’s delegated provider path, our external actions cannot run.

But Token Vault alone still answers only part of the question: "Can the app call Google right now?"

For multi-agent delegation, we also need: "Should this branch be allowed to request this action at this point in lineage?"

What we added: a warrant layer

A warrant is an application-level delegation contract attached to lineage:

id, parentId, agentId
purpose
capabilities
resource constraints
delegation controls (canDelegate, maxChildren)
expiry and status

Child warrants can only narrow parent authority. They cannot expand.

That gives us an explicit local policy gate before provider execution:

Local warrant check (capability + constraints + status)
Approval check (for sensitive actions)
Auth0/provider readiness check

Only after all three pass do we execute externally.

At a high level, the split of responsibilities is:

Auth0/Token Vault: identity + external delegated access rails
Warrant layer: internal delegation rules and branch lifecycle control

Concrete product moments from the demo

The scenario prompt is intentionally mundane: Prepare my investor update for tomorrow and coordinate follow-ups.

The proof moments are about control boundaries, not model novelty.

1) Child warrant narrowing

Planner gets the parent warrant, then delegates narrower child warrants:

Calendar can read one bounded time window
Comms can draft for bounded recipients and request one send

2) Overreach denial

Comms attempts a send to an out-of-bounds recipient. Warrant blocks it as denied_policy before any provider execution path is considered.

3) Approval-gated send

Comms prepares an in-bounds send. Even though policy allows the branch to request it, execution pauses until user approval of the exact message preview.

4) Branch revoke

User revokes the Comms branch. Later Comms send attempts are blocked immediately, while Calendar remains active.

That is the insight in one line: authorization should remain controllable after delegation, not only at initial root consent.

A practical detail that mattered for us: approval state is represented separately from policy denial and provider failure. That made "why this is blocked" understandable in under a minute during demo reviews.

Why this matters for Auth0 builders

If you are building with Auth0 AI surfaces today, you already have a strong substrate for identity and delegated external access.

The next question is internal authority shape:

How does authority fan out when agents spawn workers?
Which branch can do what?
How do you revoke one risky branch without shutting everything down?
How do you explain deny/approval/revoke events to humans quickly?

Token Vault gives trustworthy external delegation rails. A warrant layer gives legible internal delegation governance.

Implementation takeaways that improved reliability

Keep local-policy and provider-readiness outcomes separate.
- Do not collapse denial, approval-pending, and provider-unavailable into one generic blocked state.
Keep approval-required as a first-class state, not an afterthought.
- "Draft authority" and "send authority" should be visibly different.
Make graph and timeline derive from one canonical scenario state.
- If UI surfaces drift, your security story drifts.
Make revocation branch-scoped and immediate.
- Revocation should not feel like soft UI deletion.
Keep actor identity and lineage attached to every meaningful event.
- We kept root request ID, acting runtime actor, warrant ID, parent warrant ID, and result together in timeline records.