I Built a Capability-Based Security Layer for AI Agents — Here's Why It Matters

Developer Shubh Bhangoo has built Agent Firewall, a capability-based security layer for AI agents that provides fine-grained, cryptographically signed permissions with full lifecycle tracking. The system, now at v0.8 with SQLite-backed persistence, replaces binary API keys with delegable and attenuable capabilities, and includes HTTP and MCP boundaries for authorization. Bhangoo aims to make it production-ready with a v1.0 release.

I Built a Capability-Based Security Layer for AI Agents — Here's Why It Matters The Problem Nobody's Talking About AI agents are everywhere now. They book flights, send emails, process payments, and access your codebase. But here's the question nobody asks: Who authorizes which agent can do what? Most people use API keys. An API key is binary — you have it or you don't. If your finance agent's key leaks, someone can drain your account. If your code-review agent gets compromised, it can push malicious commits. There's no middle ground. I kept hitting this wall while building agent prototypes. So I built something to fix it. What I Built Agent Firewall is a capability-based security layer for AI agents. It gives you fine-grained, cryptographically signed permissions with full lifecycle tracking. Instead of giving an agent a key that unlocks everything, you give it a capability: from agent firewall import FirewallSDK sdk = FirewallSDK revocation store path="revocations.db", lifecycle store path="lifecycle.db", capability = sdk.issue private key=private key, agent="finance-agent", capability="payments.send", constraints={ "amount max": 100, "expires at": "2026-08-30T00:00:00Z" }, That agent can now send payments — but only under 100, and only until August 30th. If you revoke the capability, it's dead immediately. If someone replays an old request, it's rejected. Why Capabilities Beat API Keys API Keys vs Capabilities: API Keys: Capabilities: The Capability Lifecycle Every capability in Agent Firewall has an explicit lifecycle: ISSUED ↓ DELEGATED ↓ ATTENUATED ↓ USED ↓ REPLAYED ↓ REVOKED ↓ DENIED ↓ EXPIRED This isn't just logging — it's security state. You can query whether a capability was used, replayed, or revoked. You can delegate a capability to another agent with reduced authority your finance agent delegates payments.send with amount max=50 to a sub-agent . You can attenuate it yourself. And in v0.8, all of this persists to SQLite. Restart your service, and the revocation registry and lifecycle history survive. Real-World Boundaries Agent Firewall isn't just a library — it's a boundary layer. HTTP boundary: Maps incoming requests to capability namespaces. POST /payments/refund ↓ http.POST.payments.refund MCP boundary: Authorizes Model Context Protocol tool calls before execution. Both boundaries verify the capability, bind it to the agent identity, check constraints, and apply replay protection before allowing execution. The Story Behind It Six months ago, I was building COVID detection models for college assignments. Standard undergrad ML stuff. Then I started playing with AI agents — LangChain, CrewAI, AutoGen — and kept running into the same problem: these agents have way too much power by default. An API key doesn't care which agent is calling, what it's doing, or when it should stop working. So I went deep on capability-based security — a model from operating systems research where permissions are unforgeable tokens that can be delegated and attenuated. I built Agent Firewall to bring that model to the agent era. It now has 1,438 passing tests, including adversarial regression coverage. It has architecture docs and a threat model. And yesterday, I shipped v0.8 with SQLite-backed lifecycle persistence. Where It's Going v1.0 is the next milestone. I'm freezing the API, shipping full documentation, and making this production-ready. The goal is simple: Every AI agent that calls a tool should have an authorization layer that understands who, what, and when. Check out the repo: github.com/Shubhbhangoo/agent-firewall/tree/v0.8 If you're building agents that call tools — payments, APIs, databases, anything — I'd love your feedback. Drop an issue, open a PR, or just tell me what your authorization setup looks like today. I'm Shubh, a fresh CS grad building security infrastructure for the agent era. Follow along as I ship v1.0 and beyond.