DEV Community: Shubhbhangoo

# Agent Firewall v2.5: I Attacked My Own AI Agent Security Boundary

Shubhbhangoo — Fri, 04 Sep 2026 07:27:41 +0000

AI agents can call APIs, use MCP tools, access databases, modify files, and trigger real-world actions.

So the important security question isn't just:

Is the agent trustworthy?

It is:

Is this specific action authorized right now?

That is the problem I built Agent Firewall to solve.

How it works

The architecture is intentionally centered around one authorization boundary:

AI Agent
   |
   v
Tool / API Request
   |
   v
FirewallSDK.authorize()
   |
   +--> identity
   +--> task
   +--> capability
   +--> provenance
   +--> delegation
   +--> constraints
   +--> validity
   +--> revocation
   +--> policy
   +--> security state
   |
   v
ALLOW / DENY
   |
   v
Execution

The important part is not the number of checks.

It is where authority comes from.

Security analysis can provide evidence and context.

It cannot create an authorization decision.

A risk score cannot become an allow.

An LLM cannot become an allow.

Monitoring cannot become an allow.

Aegis cannot become an allow.

The canonical authorization boundary remains responsible for the decision.

Capabilities

Agent Firewall treats permissions as signed capabilities.

A capability can carry:

identity
action
constraints
issuer
expiration
delegation
nonce
signature

For example:

payments.send
amount_max = 1000
expires_at = ...

Authority can be delegated or attenuated, but not widened.

A child capability can become:

amount_max = 100

It cannot turn itself into:

amount_max = 10000

The same idea applies across delegation lineage.

Every step must preserve or reduce authority.

Aegis

v2.4 introduced Aegis, the adaptive authority control plane.

It allows live authority to be:

narrowed
suspended
revalidated
revoked

while a task is running.

But Aegis has a very deliberate limitation.

It can restrict authority.

It cannot grant authority.

Its integration with the SDK is essentially:

Aegis
   |
   v
deny-only gate
   |
   v
FirewallSDK.authorize()

There is no Aegis → ALLOW path.

That separation is important because otherwise the system would eventually have two authorization engines.

Then came v2.5

I decided to stop adding features and attack what already existed.

The v2.5 mission was:

Attack the shipped boundary until a guarantee breaks, the attack is contained, or a limitation becomes clear.

I ran 22 attacks against v2.4.

And we found real problems.

An expired capability could be allowed

The most serious finding was an expiry check that could silently abstain when the firewall could not establish the current time.

That meant a legitimate signature could still result in:

expired capability
        |
        v
authorized

v2.5 changes that to:

clock unavailable
        |
        v
DENY

Internal security state could raise exceptions

Failures in:

revocation
delegation lineage
issuer trust
risk state
refusal state

could previously escape authorize().

That matters because an exception isn't a security decision.

v2.5 turns those failures into explicit denials such as:

revocation_state_unavailable:{Type}

The boundary decides.

The caller does not.

Authorization and execution could disagree

Three integrations had another interesting problem.

The firewall authorized one representation of a request, while the handler could receive another.

For example:

authorize({"amount": 10})
        |
        v
ALLOW

handler({"amount": 5000})

The authorization boundary itself was correct.

The integration around it wasn't.

v2.5 fixes this structurally by normalizing or settling the request once and giving the same object to both authorization and execution.

Authority envelopes

v2.4 also introduced AuthorityEnvelope.

It provides a projection of what a capability can still do after considering its constraints and delegation lineage.

But an envelope is deliberately not an authorization decision.

The guarantee is one-way:

Envelope excludes request
        |
        v
authorize() must deny

Not:

Envelope does not exclude request
        |
        v
authorize() must allow

That distinction prevents an analytical projection from becoming a second authorization path.

The security model

The deeper principle behind the project is:

Evidence
   |
   v
Context
   |
   v
Authorization
   |
   v
Authority

Not:

Evidence
   |
   v
Authority

A signature is evidence.

A risk score is evidence.

A monitoring result is evidence.

An AI-generated assessment is evidence.

None of them should automatically become authority.

And the tests?

v2.5 has 16 named security invariants covering properties such as:

AUTHORIZATION_UNIQUENESS
MODEL_NON_AUTHORITY
CONTROL_PLANE_INTEGRITY
PROVENANCE_INTEGRITY
FAIL_CLOSED
ENVELOPE_SOUNDNESS
DELEGATION_MONOTONICITY
CAPABILITY_MONOTONICITY
REVOCATION_MONOTONICITY
POLICY_NON_WIDENING
AEGIS_STATE_TRANSITIONS
REVALIDATION_CONSISTENCY

The interesting rule is that:

UNVERIFIABLE != PASS

If an invariant cannot establish its claim, it does not quietly report success.

That is a small implementation detail with a large security consequence.

What v2.5 taught me

The hardest bugs weren't always sophisticated attacks.

Some were caused by something much simpler:

unknown
   |
   v
nothing obviously wrong
   |
   v
allow

That is the dangerous direction.

The safer model is:

unknown
   |
   v
cannot establish
   |
   v
deny / restrict / revalidate

Agent Firewall v2.5 is therefore less about adding another security feature and more about making the existing boundary harder to escape.

The goal remains simple:

AI agents can have powerful capabilities. Those capabilities should be explicit, bounded, and enforceable.

github:https://github.com/Shubhbhangoo/agent-firewall

I Built a Security Firewall for AI Agents: From 73 Tests to 1,600+

Shubhbhangoo — Sun, 23 Aug 2026 14:05:55 +0000

AI agents are becoming increasingly capable of using tools.

They can call APIs, access databases, execute code, interact with MCP servers, make HTTP requests, and potentially perform actions with real-world consequences.

That creates a question I kept coming back to:

What actually stands between an AI agent and a dangerous tool call?

I decided to build that layer.

I called it Agent Firewall.

What is Agent Firewall?

Agent Firewall is an authorization and security layer that sits between AI agents and the tools they want to use.

The basic idea is:

AI Agent
|
v
Agent Firewall
|
+--> Allow
+--> Deny
+--> Require Approval
|
v
Tool / API / MCP Server

Instead of trusting an agent simply because it is authenticated, the firewall evaluates whether that specific operation is authorized.

The project started as a relatively small policy engine.

It became considerably larger.

v0.1: Start with the obvious problem

The first version focused on basic authorization.

A tool request could result in:

ALLOW
DENY
APPROVAL

The firewall was designed to fail closed.

If there wasn't an applicable rule, the request wasn't allowed to magically pass through.

I also started testing things that shouldn't work, rather than only testing happy paths.

That became a recurring theme throughout the project.

A security boundary needs to be much more interested in what happens when someone tries to break it than a normal application usually is.

v0.2: Make policies harder to break

The next version made the policy system more expressive and defensive.

Policies gained things like:

Generic argument matching

Argument validation

Policy validation

Request IDs

Better auditability

MCP bypass testing

The test suite reached 73 tests.

At this point I started treating the firewall less like a feature and more like a security boundary.

That distinction matters.

A normal application can sometimes recover from an unexpected input.

An authorization layer should preferably say:

No.

v0.3: Agents need identities

A tool shouldn't just ask:

Is this operation allowed?

It should also ask:

Is this operation allowed for this agent?

So Agent Firewall became identity-aware.

This introduced:

Agent-specific authorization

Identity-aware policies

Conflict resolution

More precise policy matching

Concurrency testing

Performance benchmarking

The test suite reached 145 tests.

The architecture was starting to become something more interesting than a collection of if statements.

v0.4: Cryptographic identity

An agent name is not an identity.

If a request simply says:

agent = finance-agent

then anyone who can claim that string could potentially impersonate the agent.

So the next step was cryptographic identity.

Agent Firewall gained:

Cryptographic agent identities

Key lifecycle management

Key rotation

Key revocation

Persistent identity state

Cryptographically chained audit logs

The test suite reached 264 tests.

This was one of the points where the project really started feeling like security infrastructure rather than an ordinary authorization library.

v0.5: Capabilities

Identity answers who the agent is.

But I also needed to answer:

What is the agent actually allowed to do?

That led to capability-based authorization.

Capabilities became first-class permissions.

For example:

finance-agent
|
+-- payments.send

I also added:

Rate limiting

Spending budgets

Persistent security state

Human approval workflows

Capability requirements

Policy conflict handling

The test suite reached 390 tests.

Now an agent could be identified and restricted by the authority it possessed.

v0.6: Signed capabilities

This was a much bigger step.

Capabilities themselves became cryptographically signed permissions.

A capability could contain things such as:

Agent
Capability
Issuer
Constraints
Expiration
Signature

I added explicit capability namespaces:

payments.send
payments.refund
payments.*

So:

payments.* → payments.send ✅
payments.* → payments.refund ✅
payments.* → accounts.read ❌

Then came attenuation.

A capability with:

payments.*
amount_max = 1000

could be narrowed to:

payments.*
amount_max = 100

but it couldn't suddenly become:

amount_max = 10000

That led naturally into delegation.

An agent could delegate authority to another agent, but the delegated authority couldn't exceed the original authority.

Replay protection was also introduced using nonces and capability fingerprints.

The test suite reached 737 tests.

v0.7: Leave the Python sandbox

At this point I had a fairly serious authorization model.

But there was another problem.

A security system isn't particularly useful if it only protects a function inside your application.

Real agents interact with external systems.

So v0.7 pushed the capability model across actual protocol boundaries.

Agent Firewall gained:

MCP authorization

HTTP authorization

Signed capability transport

HTTP method/path namespace mapping

Cross-agent capability binding

Request constraint enforcement

Adversarial protocol testing

For example:

POST /payments
↓
http.POST.payments
↓
Capability verification
↓
Authorization
↓
Handler

The same security model could now be applied across different ways an agent might reach a tool.

v0.8: Capabilities need a lifecycle

Then I ran into another problem.

A capability isn't simply:

valid

or:

invalid

It has a history.

It might be:

ISSUED
↓
DELEGATED
↓
ATTENUATED
↓
USED
↓
REPLAYED
↓
REVOKED
↓
EXPIRED

So v0.8 introduced explicit capability lifecycle tracking.

More importantly, lifecycle and revocation state became persistent.

I added SQLite-backed storage so security state could survive process restarts.

That meant the system could remember:

Revoked capabilities

Lifecycle history

Capability usage

Replay events

Authorization denials

Expiration events

The v0.8 checkpoint reached 1,438 passing tests.

v0.9: Make it usable

Security infrastructure isn't very useful if developers hate integrating it.

So v0.9 focused on the developer experience.

Instead of forcing developers to manually construct every authorization call, they can use:

from firewall.protect import protect

@protect(
sdk=sdk,
capability=capability,
)
def send_payment(amount):
return amount

The important invariant remains:

authorize()
↓
ALLOW
↓
handler()

Not:

handler()
↓
oops, authorization failed

Denied operations don't reach the handler.

I also added reusable protected tools:

from firewall.tools import ProtectedTool

tool = ProtectedTool(
sdk=sdk,
capability=capability,
handler=send_payment,
)

Tool adapters

v0.9 also introduced vendor-neutral and vendor-specific tool adapters.

The project now supports adapters for:

OpenAI tools

Anthropic tools

Generic tool calls

The adapters translate provider-specific formats, but they don't create authority.

Authorization stays inside the firewall.

A vendor-neutral request can be normalized into a common representation before reaching the authorization layer.

That means the security model doesn't need to change every time an agent framework changes its tool-call format.

Lifecycle investigation

Another v0.9 addition was a read-only explanation layer.

Instead of creating another authorization engine, the explanation system reads lifecycle history and answers questions like:

What happened to this capability?

Was it revoked?

Was it replayed?

Was the request denied?

What was the latest lifecycle event?

This makes investigating authorization decisions much easier without introducing a second source of truth.

CLI

v0.9 also introduced a CLI:

firewall --help
firewall init --path firewall.yaml
firewall validate firewall.yaml
firewall inspect-token
firewall explain lifecycle.db

The CLI uses the same underlying Python APIs as the SDK.

One authorization engine.

Different interfaces.

Property-based testing

I also started using Hypothesis alongside the existing adversarial tests.

Instead of writing only:

test_input_1
test_input_2
test_input_3

I can describe properties the system should maintain and let generated inputs explore the edges.

The property-based tests cover areas such as:

Input normalization

Lifecycle snapshots

Persistence round trips

Authorization stability

Capability transport

Property-based testing isn't a magic security certificate.

It's another way to find weird combinations that manually written tests might miss.

v1.0: Persistent key management

The v1.0 release moves deeper into cryptographic key infrastructure.

One of the major additions is persistent key management through SQLite.

Previously, key state could exist only in memory.

Now the key manager can persist:

Key IDs

Private/public key material

Active key state

Retired keys

Trusted issuers

Key rotation can therefore survive process restarts.

The model is roughly:

Active Key
|
| rotate
v
Retired Key

New Key
|
v
Active Key

The implementation also checks for invalid persistent states, such as multiple active keys.

This is important because cryptographic infrastructure shouldn't quietly accept corrupted or contradictory security state.

The architecture now

The system has evolved quite a bit from the original:

Agent → Firewall → Tool

The security path is now closer to:

And underneath it:

Persistent Security State
|
+-- Revocations
+-- Lifecycle
+-- Keys
+-- Audit

The goal is simple:

The tool should never execute before the security boundary has authorized it.

1,600+ tests later

One thing I really wanted from the project was for the test suite to grow alongside the attack surface.

The progression looked roughly like:

v0.2 73 tests
v0.3 145 tests
v0.4 264 tests
v0.5 390 tests
v0.6 737 tests
v0.8 1,438 tests
v0.9 1,602 tests

The tests cover areas including:

Policy conflicts

Identity security

Cryptographic verification

Key lifecycle

Capability authorization

Delegation

Attenuation

Replay protection

Rate limits

Budgets

Approvals

Persistent state

Lifecycle tracking

Audit integrity

Concurrency

MCP

HTTP

Tool adapters

Adversarial combinations

The number itself isn't a security guarantee.

But watching the test suite grow alongside the architecture has been useful.

v1.0 is released 🔐

After all those iterations, Agent Firewall v1.0 is now released.

What started as a small policy firewall evolved into an authorization layer with:

Cryptographic agent identities

Signed capabilities

Capability namespaces

Constraints

Delegation

Attenuation

Replay protection

MCP authorization

HTTP authorization

Human approval

Budgets

Rate limiting

Capability lifecycle tracking

Persistent revocation

Persistent key management

Tamper-evident audit logging

Developer APIs

Tool adapters

CLI tooling

Property-based testing

The project has now crossed 1,600+ tests across the development releases.

But v1.0 isn't the finish line.

Security infrastructure needs continued testing, hardening, review, and scrutiny.

The goal is to build a system where AI agents can remain powerful without giving them unlimited authority.

Agents should be powerful. Their authority should be explicit, bounded, and enforceable.

Install

pip install agent-firewall

For development:

git clone https://github.com/Shubhbhangoo/agent-firewall.git
cd agent-firewall
pip install -e ".[dev]"

Then protect a tool:

from firewall.protect import protect

@protect(
sdk=sdk,
capability=capability,
)
def send_payment(amount):
return amount

Try Agent Firewall

The project is open source:

[Agent Firewall on GitHub](https://github.com/Shubhbhangoo/agent-firewall

If you're working on AI agents, MCP tools, automated workflows, or security infrastructure, I'd be interested in seeing how you're approaching authorization and tool security.

Agent Firewall v1.0 is out. 🔐

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

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

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:

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.