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

Shubhbhangoo — Sat, 22 Aug 2026 20:48:47 +0000

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:

Binary access
No expiration built-in
Can't be narrowed
No audit trail
Leaked = game over

Capabilities:

Granular permissions
Time-bound by default
Can be attenuated (narrowed without increasing authority)
Full lifecycle: ISSUED → USED → REVOKED → EXPIRED
Revocable individually

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.

DEV Community: Shubhbhangoo

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