Inspiration
Personal AI agents are starting to act on our behalf, using our accounts. That is what makes them useful, and what makes them risky: a page can mislead an agent, and a bug can send it somewhere it should never go. Today, you mostly either hand an agent your access or don't use it. We wanted a third option: a permission slip for one job.
What it does
Warrant gives every job a warrant, a short list of exactly what the agent may touch.
- You give it a job, like "Brief me on this week's announcements and my latest grades."
- NVIDIA Nemotron 3 Super proposes the minimum, choosing only from permissions you reviewed.
- You decide. Remove anything you don't want and approve. Jobs that change something ask again on every run.
- NVIDIA OpenShell enforces it in a fresh sandbox. Anything else is blocked before it is sent, and you see every attempt.
It also works as a small personal AI system you run yourself. Approved read-only jobs run on a schedule, memory carries over between runs, and approved jobs can be saved as reusable skills. The agent can only use the sites you add. Your memory, skills and site list stay on your machine, while the pages a job reads go to the model on Nebius. Memory can never widen a warrant.
See the difference yourself, with no AI or key needed:
uvx --from git+https://github.com/TheClazer/warrant warrant prove
How we built it
- NVIDIA Nemotron 3 Super drafts warrants and drives the agent.
- Nebius Token Factory serves every model call, and each run shows the tokens and time for every call.
- NVIDIA OpenShell 0.1.5 enforces each warrant through a generated policy, with one sandbox per run.
- A plain-code checker has the final word on every draft, so the model's output is never trusted on its own.
- Python, FastAPI and SQLite power the service, with React and TypeScript for the interface.
What we measured
Five frozen over-reach scenarios, run twice each with real Nemotron calls, on a fictional portal:
| Setup | Off-warrant requests tried | Went through |
|---|---|---|
| Broad access | 24 | 24 |
| Warrant, with OpenShell | 17 | 0 |
The expected fact appeared in 4 of 10 answers in both setups, so agent accuracy still has room to grow. We also ran it on the live GitHub API in a real OpenShell sandbox: reading was allowed, and the agent's attempt to go further was blocked.
Challenges
OpenShell is alpha software. Docker Desktop can't act as its engine on WSL, its default image has no sandbox user, and decision logs arrive just after the response. We wrote these up in FEEDBACK.md.
What we learned
The model should never be what enforces the rules. Once permissions come from a reviewed list and are enforced outside the model, a confused agent becomes a blocked request instead of a leak. A warrant does have limits, though: it stops requests, not a page misleading the agent's answer.
Current limits and what's next
It can't log in through a website's sign-in page yet, and tokens don't yet work inside an OpenShell sandbox. The public demo uses a fictional portal and the built-in enforcer, because OpenShell needs its own Docker host. We did not use NemoClaw, Hermes Agent or Nebius Serverless.
Next: Hermes Agent inside the sandbox, sign-in support, and testing against a standard prompt-injection benchmark.
Log in or sign up for Devpost to join the conversation.