Most conversations about AI agents focus on what they can do.
Very few focus on what they should be allowed to do.
That gap is what I kept thinking about when I built Vouch for
the Auth0 "Authorized to Act" hackathon.
The Problem:
AI agents are getting good at taking actions: booking meetings,
calling APIs, sending emails, managing files. But the current
delegation models are broken. You either leak credentials in
prompts, which is dangerous, or you hand the agent broad OAuth
access and hope it stays in its lane, which is just risky in a
different way.
There is no clean way to say: this agent can do X on service A,
for user B, until this session ends. Nothing more. That missing
primitive is the whole problem.
How Vouch Works:
Vouch sits between the agent and the services it wants to interact
with. Instead of giving the agent raw credentials, you define a
permission scope for each action. The agent operates within that
scope and nothing outside it.
The credential delegation runs through Auth0 Token Vault. When a
user authorizes an action, Vouch generates a scoped token tied to
that specific permission. The agent uses the token to act. It
never sees the underlying credentials. When the session ends,
access is revoked.
The agent brain is Llama 3.3 70B running through Groq's API.
Backend is Node.js and Express, frontend is React and Vite.
Built the whole thing in 48 hours.
The Hard Part:
The auth flow was not the challenge. The permission schema was.
Too broad and the whole point falls apart. Too narrow and the
agent becomes useless. I went through three complete redesigns
before landing on something that felt both flexible and actually
enforceable. That balance took most of the 48 hours.
The Takeaway:
Capability gets all the attention. Constraint gets almost none.
As agents get more capable, the trust problem gets harder, not
easier. An agent that can browse the web, write code, and send
emails on your behalf needs a much more sophisticated permission
model than anything running in production today.
Scoped delegation with session-bound tokens is not the final
answer. But I think it is the right direction.
Live: vouch-q017.onrender.com
GitHub: github.com/Anish0104/vouch
If you are building in the agentic space, how are you handling
permissioning? Would love to hear how others are defining trust
in their stack.