Agent security is not web application security. An agent that can read your Postgres database can also drop tables, exfiltrate credentials, or call functions that open outbound network connections. Traditional WAFs filter HTTP requests. Agent firewalls need to parse SQL verbs, inspect tool arguments, and enforce policy on actions the agent constructs dynamically at runtime.
Claw Patrol is a proxy that sits between your agent and every external service it touches. It intercepts traffic at the wire level, evaluates each action against custom rules, and logs everything. The model is closer to a CASB (cloud access security broker) than a WAF. You wrap your agent invocation with clawpatrol run, and every outbound request passes through the rule engine before it reaches Postgres, Kubernetes, Slack, or any other tool.
What an Agent Firewall Actually Intercepts
Agent firewalls operate at the tool-call boundary. They parse protocol-specific traffic and match on semantic primitives, not just URLs.
HTTP requests: Match on method, path, headers, and body content. Route suspicious payloads through an LLM judge before they leave the network.
SQL statements: Parse Postgres and ClickHouse queries. Match by SQL verb (SELECT, UPDATE, DROP), table name, function calls, and substrings of the statement itself. Block dangerous functions like pg_read_file, lo_get, and dblink that can read the filesystem or open outbound connections from inside the database.
Kubernetes API calls: Match on resource type, namespace, and operation. Prevent an agent from deleting production pods or reading secrets it should not access.
Credential handling: The agent never holds raw credentials. Claw Patrol injects them at request time and strips them from logs. If the agent is compromised by prompt injection, the attacker gets a proxied session, not the keys.
Rule Engine Architecture
Rules are written in CEL (Common Expression Language) and evaluated in real time. No restart required. You define conditions, approval flows, and priority order.
rule "pg-banned-functions" {
endpoint = postgres.pg-staging
priority = 100
condition = <<-CEL
sets.intersects(sql.functions, [
'pg_read_file',
'pg_read_binary_file',
'lo_get',
'dblink_connect',
'dblink_exec'
])
CEL
action = deny
}
rule "message-send-content-check" {
endpoint = https.messaging-api
condition = <<-CEL
http.method == 'POST' &&
http.path == '/v1/messages/send'
CEL
approve = [llm_approver.message-content-judge]
}The first rule blocks SQL functions that could exfiltrate data or pivot to other systems. The second routes user-facing messages through an LLM judge that checks for unsafe content, missing context, or malformed markdown.
Rules can reference:
- Protocol-specific fields:
sql.verb,sql.tables,http.headers,k8s.resource - LLM approvers: External models that evaluate semantic safety
- Rate limits: Per-endpoint, per-agent, or per-user quotas
- Audit metadata: Attach tags, track which rule fired, and log justifications
Why Static Guardrails Fail for Agents
Static guardrails operate at the prompt level. They scan input and output text for banned patterns. This works for chatbots. It breaks for agents that construct tool calls dynamically.
Dynamic tool arguments: An agent might build a SQL query by concatenating user input with retrieved context. Static filters cannot see the final query until it is already constructed. By then, the agent has committed to the action.
Multi-step workflows: An agent might read a database, summarize the results, and post to Slack. A static guardrail sees three separate actions. It cannot enforce a policy like “do not post customer PII to public channels” because it does not track state across steps.
Credential leakage: If the agent holds credentials, prompt injection can trick it into echoing them back or sending them to an attacker-controlled endpoint. Static filters cannot prevent this because the credentials are already in memory.
Agent firewalls solve these problems by intercepting actions at execution time, parsing protocol-specific payloads, and maintaining state across the session.
Comparison: Agent Firewalls vs. Traditional Security Layers
| Layer | Scope | Enforcement Point | Protocol Awareness | State Tracking |
|---|---|---|---|---|
| WAF | HTTP requests | Edge | HTTP only | Per-request |
| CASB | Cloud API calls | Proxy | Multi-protocol | Per-session |
| Static Guardrails | Prompt I/O | Pre/post-generation | Text only | None |
| Agent Firewall | Tool calls | Runtime proxy | SQL, HTTP, k8s, etc. | Cross-action |
Agent firewalls combine CASB-style proxying with protocol-specific parsing and cross-action state tracking. They enforce policy at the moment the agent attempts to execute a tool call, not before or after.
Deployment Shape
Claw Patrol runs as a sidecar or standalone proxy. You prefix your agent command with clawpatrol run. The proxy intercepts all outbound traffic, evaluates rules, and forwards approved requests.
Sidecar mode: Deploy Claw Patrol as a container alongside your agent. The agent connects to localhost:8080. The proxy forwards to real endpoints.
Gateway mode: Run Claw Patrol as a centralized gateway. Multiple agents connect through it. Useful for enforcing organization-wide policies and aggregating audit logs.
Credential injection: The agent never sees raw credentials. Claw Patrol reads them from a secret store (Vault, AWS Secrets Manager, environment variables) and injects them into outbound requests. Logs are scrubbed before they hit disk.
Observability and Audit Logs
Every action generates a structured log entry:
- Timestamp and agent identifier
- Tool name and arguments
- Rule evaluations (which rules matched, which fired)
- Approval status (allowed, denied, escalated)
- Response metadata (status code, latency, error message)
The admin dashboard shows:
- Real-time feed of all agent actions
- Drill-down into individual requests (headers, body, SQL statement)
- Rule hit counts and denial reasons
- Credential usage (which keys were injected, when, and for what)
This is critical for post-incident forensics. If an agent misbehaves, you can reconstruct the exact sequence of tool calls, see which rules should have fired, and identify gaps in your policy.
Failure Modes
Latency overhead: Every tool call passes through the rule engine. Expect 5-20ms of added latency per action. For agents that make hundreds of tool calls per session, this adds up.
Rule complexity: CEL is expressive but not Turing-complete. Complex policies (e.g., “allow this SQL query only if the user has read the privacy policy in the last 30 days”) require external approvers or pre-computed state.
Bypass via protocol tunneling: If the agent can open raw TCP sockets or shell out to curl, it can bypass the proxy. You need OS-level sandboxing (seccomp, network namespaces) to prevent this.
LLM approver reliability: Rules that delegate to LLM judges inherit the judge’s failure modes: hallucinations, prompt injection, and latency spikes. You need fallback logic (deny by default, escalate to human, allow with audit).
State explosion: Tracking state across multi-step workflows requires session storage. If the agent crashes and restarts, the firewall loses context. You need persistent state (Redis, Postgres) and session replay logic.
When to Use an Agent Firewall
You are deploying agents with write access to production systems: Databases, Kubernetes, Slack, payment APIs. The cost of a mistake is high.
You need audit logs for compliance: SOC 2, HIPAA, GDPR. You must prove that agents did not access data they should not have.
You are experimenting with untrusted or open-source agents: You want to run third-party agents without giving them full access to your infrastructure.
You have multiple agents with overlapping permissions: Centralized policy enforcement is easier than managing per-agent credentials and ACLs.
When to Avoid It
Your agent only reads public data: If the agent cannot modify state or access secrets, the risk is low. Static guardrails and rate limits are sufficient.
You need sub-millisecond latency: The proxy adds overhead. If your agent is latency-sensitive (real-time trading, high-frequency data processing), the cost may outweigh the benefit.
You have strong OS-level isolation: If your agent runs in a locked-down container with seccomp, network policies, and no shell access, the attack surface is already small.
You are prototyping: Early-stage projects change fast. Writing and maintaining rules is overhead. Wait until you have stable tool interfaces and known threat models.
Technical Verdict
Agent firewalls are a new security primitive. They address threats that traditional WAFs and static guardrails miss: dynamic tool construction, multi-step workflows, and credential leakage. Claw Patrol’s approach (wire-level interception, protocol-specific parsing, real-time rule evaluation) is sound. The trade-offs are latency overhead, rule complexity, and the need for persistent state tracking.
Use an agent firewall when you deploy agents with write access to production systems and need audit logs for compliance. Skip it if your agent only reads public data or you already have strong OS-level isolation. The category is early. Expect tooling to mature as more teams deploy agents in production and discover new attack vectors.