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.

  1. You give it a job, like "Brief me on this week's announcements and my latest grades."
  2. NVIDIA Nemotron 3 Super proposes the minimum, choosing only from permissions you reviewed.
  3. You decide. Remove anything you don't want and approve. Jobs that change something ask again on every run.
  4. 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.

Built With

Share this project:

Updates

Submission history