DeadBolt 2.0.0: Runtime Permission Gates for AI Agent ToolsDeadBolt 2.0.0: Runtime Permission Gates for AI Agent Tools
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Where should an agent’s permission check live?
I built DeadBolt at NextEleven to put that check at the point where a tool action actually runs, outside the model’s instructions. Stable 2.0.0 is now available, free and open source under Apache-2.0.
For example: an agent requests a file write. Your executor asks DeadBolt first. A denial leaves the protected function uncalled. You can set tool policies, require one-use approvals, pause a run, or kill its future admissions. Store or transport failure denies protected dispatch.
You can embed it in Rust, use a local sidecar from Python or another language, or wrap a trusted stdio MCP server.
The boundary matters: DeadBolt protects routes you connect. It is not a sandbox for arbitrary code, and kill does not automatically cancel work already running.
Install, examples and captioned walkthroughs: https://nexteleven.dev/deadbolt
If you’re building agents, what would make a permission gate easier to integrate into your stack? I’m happy to answer setup questions and consider useful feedback.

nexteleven.dev

DeadBolt — Give agents tools. Keep control.

A local execution gate for software agents, built by NextEleven.

Andrei's avatar
For me, a small MCP example would help: approve a file write, then show what happens if the agent changes the path or content before execution. Is the one-use approval tied to those exact arguments?
Back to feed
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started