Agent Firewall
An agent firewall is an application and runtime enforcement boundary controlling what AI agents may do. Every proposed tool call, API action, file access, credential use, and MCP operation is evaluated against policy before it executes — allowed, denied, held for approval, or observed.
What Cirvix is not claiming.
The term "firewall" gets stretched. Here is exactly what this page means by it.
Cirvix is not a network firewall. It does not filter packets, manage ports, or sit on your network perimeter. Anyone evaluating it as network infrastructure is evaluating the wrong thing. The "firewall" here is a runtime authorization boundary inside the agent's execution path: it understands actions — which tool, which resource, which credentials, under whose policy — and decides per action, before execution.
That distinction is load-bearing. A network firewall waves through a credential exfiltration to an approved domain, because the destination is allowed. An agent firewall denies it, because the action — this agent sending that secret there — violates policy. Content and authority matter; packets don't carry either.
How it differs from the neighbors.
Six nearby categories, each doing a different job. None of them authorizes agent actions.
| Technology | Controls | What it misses about agents |
|---|---|---|
| Network firewall | Hosts, ports, protocols | Cannot see which action an agent performs on an approved host |
| WAF | Malicious HTTP patterns | Legitimate-looking authorized-shaped abuse passes as clean traffic |
| API gateway | Routing, rate limits, keys | No per-action authorization against agent policy; no hold-for-approval |
| IAM | Who holds which permissions | Static grants; cannot evaluate the specific action in its current context |
| Prompt firewall | Malicious or injected text | Operates on text, not consequences; a clean prompt can still request a harmful action |
| EDR | Endpoint malware-like behavior | Agent tool abuse looks like normal authorized software doing its job |
| Agent firewall (Cirvix) | Whether this agent may take this action now | This row: allow / deny / hold / audit_only per action, default-deny, fail closed |
How the boundary holds.
Same eight-stage pipeline as the rest of the control plane, applied to every action.
Parse, normalize, secret-detect, risk-classify, evaluate, approve, sanitize, audit — the full sequence is documented in the AI-agent security guide and the policy engine. Three properties make it a firewall rather than a monitor:
Inline, not observational
The decision happens on the execution path, before the action runs. Post-hoc detection is logging; this is gating.
Default-deny
Anything not explicitly permitted is refused — new tools, new servers, new endpoints included.
Fail closed
When the boundary cannot decide safely — including over-quota conditions — it denies rather than waving the call through.
Related boundaries: MCP security for the tool-server surface, the threat model for stated limits, and the escape benchmark for reproducible evidence that held actions stay held.
Agent firewall, asked directly.
What is an AI agent firewall?
A runtime enforcement boundary deciding per agent action — allow, deny, hold, or observe — under default-deny. Cirvix implements it in-process, on the execution path.
Is it a network firewall?
No. It governs action meaning and authority, not packets and ports — and catches abuse on approved destinations that network controls wave through.
How does it differ from a WAF or API gateway?
Those filter traffic patterns and manage routing. An agent firewall authorizes the specific action by the specific agent, with human-approval holds and observation modes.
Does it replace IAM or EDR?
No. Separate layers: IAM for identity, EDR for endpoints, the agent firewall for agent actions. They compose.
Put a boundary
around every agent action.
Deny the first out-of-policy call in minutes, with evidence attached.