Put the agent firewall in observe mode before it blocks real work

The awkward moment comes after the demo works.

An agent triages the alert. It checks the dashboard, queries logs, reads the deploy history, and finds the bad rollout faster than a tired human would have. Someone asks the obvious next question: can it roll the service back?

That is where the system changes shape.

The agent is no longer a chat window or a coding assistant. It is an operator with hands near production. To be useful, it needs access to systems that can delete data, leak secrets, merge unsafe code, page customers, or spend real money.

Prompt instructions are not enough for that moment. Broad credentials are worse. If the agent process holds the tools and the secrets, and the only control is "please do not do dangerous things," the team has asked the agent to supervise itself.

That is why agent firewalls are becoming a concrete operations pattern rather than a security metaphor.

The useful version does not begin by blocking everything. It begins by watching real traffic, writing down every decision it would have made, and turning only the clearest policies into enforcement.

Deno's signal: put the decision point outside the agent

Deno's May 2026 post on Claw Patrol is one of the clearest public descriptions of the pattern.

Deno says it uses agents for production work: triaging PagerDuty alerts, checking dashboards, querying logs, running kubectl, rolling back bad deploys, and other operational tasks. The same post names the systems those agents may need to touch: AWS, GCP, Postgres, Kubernetes, ClickHouse, GitHub, Slack, and Grafana.

That is a powerful toolbox. It is also a dangerous one.

Deno names the risk plainly. Commands like kubectl delete namespace prod and psql -c 'DROP TABLE users' are one tool call away.

The important design choice in Claw Patrol is where the control sits. Deno argues the guard cannot live inside the agent process because the agent process holds the tools and credentials. If the model is confused, manipulated, or simply wrong, it cannot be trusted to decide whether its own next action is safe.

Claw Patrol moves the decision point outside the agent.

According to the Claw Patrol README, it is a "Security firewall for agents." It sits between agents and production systems, parses traffic at the wire, and gates actions against HCL rules.

The architecture is practical rather than mystical. Agent traffic runs through a WireGuard or Tailscale tunnel to a gateway. The gateway parses inner protocols, holds the real credentials, injects them when a request is allowed, and evaluates each request against rules.

Those rules can inspect different kinds of intent:

• HTTP method, path, and body
• SQL verbs, tables, and functions
• Kubernetes verbs, resources, and namespaces

The verdict can allow the request, deny it, or pause it for approval. Deno describes approval chains that can include a model judge, a human in Slack, or both.

The credentials stay on the gateway. The agent can send placeholders. The gateway swaps in the real token only after policy allows the request.

That single move changes the trust model. The agent can propose action. The firewall decides whether the action gets real authority.

Claw Patrol is still early. Deno calls it alpha software and released it under MIT. The public GitHub repository was created in late April 2026, and the project shipped a v0.2.11 release on June 12. Those details will age quickly, but the operating pattern is already visible.

The pattern is not "buy this tool." It is "separate the agent's request from the credentialed decision."

CI needs the same boundary

Production shells are not the only place agents get too close to authority.

A coding agent can open a pull request that changes application code, dependency files, GitHub Actions permissions, MCP configuration, or the repository instructions that guide future agents. If the CI system treats every PR as a normal human-authored change, the agent can drift outside its assignment without much ceremony.

That is why Agent Gate is an interesting companion signal. Its README describes it as a "Deterministic CI firewall for AI-generated pull requests" and states: "No AI PR gets merged without proof."

Agent Gate is built for a different surface than Claw Patrol. It does not sit between an agent and Kubernetes. It sits in the pull request path.

The checks are concrete: PR contracts, risky paths, agent instruction drift, workflow permissions, and test evidence before merge. The README says it uses no checkout of PR code, no runtime LLM calls, no repository script execution, and no policy loaded from an untrusted PR head.

That last part matters. A CI firewall cannot safely ask the untrusted PR to define the rules that judge it.

Agent Gate's failure modes also map cleanly to real operating risk. It can catch out-of-contract edits, workflow permission escalation, agent control-plane drift, missing test evidence, and MCP config drift.

The rollout advice is the part more teams should copy. Agent Gate recommends a short observe path: start in warn mode, learn the repo's risk profile, then turn proven policies into merge gates. Its repository governance docs recommend non-blocking warn mode while policy is tuned, then block mode only after false positives are understood.

That is the operating lesson.

A firewall that blocks the wrong thing on day one will be bypassed by day two. A firewall that observes first can earn the right to enforce.

The artifact is a rollout plan, not a guardrail slogan

Most teams do not need a philosophical policy called "AI agent governance." They need a working artifact that answers operational questions.

Which traffic can the firewall see?

Which systems are in scope?

Which actions are always denied?

Which actions pause for approval?

What happens when the approver is asleep?

What receipt does the system write after each decision?

Who owns false positives?

Who decides when a warn-only rule becomes a blocking rule?

Those questions turn an agent firewall from an idea into an operating control.

The starting point should be observe mode on real traffic. Not synthetic examples. Not a spreadsheet of imagined risks. Real requests from real agent workflows, with the firewall recording what it would allow, warn on, pause, or deny.

That gives the team evidence before enforcement.

A useful receipt might capture the agent identity, workflow, target system, request type, parsed action, policy version, verdict, approver, timeout path, and final outcome. The receipt should be boring enough for audit and specific enough for debugging.

The goal is not to build a theater of control. The goal is to create a visible path from "we think this is risky" to "we saw this happen ten times, tuned the policy, and now block it."

What belongs in an agent firewall rollout plan

A rollout plan should fit on a few pages. If it turns into a policy binder, nobody will use it when the alert fires.

Start with scope.

Name the agents, workflows, systems, and protocols the firewall can actually observe. A gateway that sees HTTP and Kubernetes traffic cannot magically govern a browser session, a copied API key, or a local shell command that never crosses the gateway.

For production agents, scope might include Kubernetes, Postgres, cloud APIs, Grafana, Slack, and GitHub. For coding agents, it might include GitHub Actions permissions, protected paths, dependency manifests, MCP configuration, and repository instruction files.

Then define observe mode.

Observe mode should record what the firewall would have done without breaking the workflow. It should classify requests into normal, suspicious, approval-needed, and denied-if-enforced. The language can vary. The point is to separate "we saw it" from "we stopped it."

A good observe phase has an owner and an end date. "Warn forever" is just logging with better branding.

Next, pick immediate deny rules.

These should be few and obvious: Kubernetes secrets, production namespace deletion, SQL table drops in customer data stores, GitHub Actions permission escalation from an agent PR, and changes to agent control-plane files outside the PR contract.

The Claw Patrol README includes an example rule that blocks Kubernetes secrets with condition = "k8s.resource == 'secrets'" and a deny verdict. That kind of rule is a good early candidate because the intent is clear.

After deny rules, define approval rules.

Approval rules are for actions that may be legitimate but carry enough risk to pause. A production rollback might need approval during business hours but auto-approve under a specific incident policy. A database migration might need the on-call engineer. A dependency change might need security review if it touches a no-fly-list package.

The approval path needs timeout behavior. If Slack is silent for five minutes, does the request fail closed, fail open, or escalate? Different actions deserve different defaults.

A read-only dashboard query and a production delete should not share the same timeout policy.

Receipts come next.

Every allow, warn, approval, deny, timeout, and override should leave a structured record. The record should include the parsed action, not just raw traffic. "POST /api" is less useful than "agent attempted to delete deployment in production namespace."

Receipts also create the promotion path. If a warning fires twenty times and every owner says it is benign, tune it or remove it. If a warning catches three risky actions with no legitimate use, promote it to block.

Finally, name owners.

Security can help write rules, but operations has to live with the latency. Engineering has to maintain the workflow contracts. Leadership has to decide which risks are acceptable when speed and safety collide.

Without owners, false positives become folklore. Timeout behavior becomes panic. Enforcement gets turned off during the first incident.

Example

Field note: default-allow is a rollout choice, not a philosophy.

In the Hacker News discussion around Claw Patrol, readers asked about default rules, protocol-specific configuration, per-user credential injection, timeout behavior, and whether service accounts or read-only permissions solve some cases more simply.

Those are not objections to agent firewalls. They are the rollout questions a serious team should answer before enforcement.

Existing controls still matter

An agent firewall does not replace least privilege. It makes least privilege more operational.

A read-only service account is still a good control. Short-lived credentials still help. Separate staging and production credentials still matter. A firewall should not become an excuse to hand a general-purpose agent a god token and hope the gateway catches everything.

The better pattern is layered.

Before an agent gets access, run a security review of the workflow and data boundary. The review should decide whether the agent should touch the system at all.

For code execution, use sandbox contracts. An agent that writes or runs code needs a declared boundary around filesystem access, network access, secrets, and runtime authority.

For repositories, define dependency no-fly lists. Some packages, registries, scripts, and install paths should require extra scrutiny or be blocked outright. That boundary belongs in the same family as CI policy.

For cost-bearing systems, add spend circuit breakers. An agent that can call paid APIs, start cloud jobs, or trigger usage-based workflows needs budget limits and stop conditions.

The firewall is the runtime decision layer across those boundaries. It sees the request at the moment authority would be used.

That is also why Microsoft's Agent Control Specification is worth watching as standards context. Microsoft describes ACS as an open, vendor-neutral standard for runtime governance across the agent lifecycle, independent of framework, runtime, or policy engine.

The standard is not the story here. The direction is.

Agent governance is moving from model instructions into runtime control points, policy engines, receipts, and enforcement paths.

A simple observe-to-enforce ladder

A practical rollout can start small.

Week one: observe.

Route one agent workflow through the control point. Record traffic, parsed actions, suggested verdicts, and receipts. Do not block yet unless the action is obviously catastrophic and already covered by existing policy.

Week two: warn.

Turn the clearest suspicious classes into warnings. Assign owners to review the receipts. Track false positives, missed classifications, unknown protocols, and actions the firewall cannot see.

Week three: approve.

Pick a small set of risky but legitimate actions that require a human pause. Test the approval path during normal hours. Then test the timeout path on purpose. If nobody knows what happens when the approver is unavailable, the control is not ready.

Week four: deny.

Promote only proven rules into blocking mode. Start with actions that have no normal use for the agent: secret reads, production namespace deletion, workflow permission escalation, unauthorized control-plane changes, and destructive SQL against protected tables.

Then repeat.

Each new agent workflow should enter the ladder at observe mode. Each new protocol should be treated as unproven until the firewall can parse it well enough to write meaningful receipts.

This is slower than granting broad credentials. It is faster than cleaning up after an agent with production authority and no external brakes.

The management question

The management question is not "Do we trust the agent?"

Trust is too vague. It collapses design, credentials, monitoring, approval, and accountability into one mood.

The better question is: where does the agent's suggestion become an authorized action?

If that moment happens inside the agent, the control is weak. If it happens at an external gateway, CI firewall, policy engine, or approval checkpoint with receipts, the team has something it can inspect and improve.

Useful agents will keep moving closer to production. Some will handle alerts. Some will maintain code. Some will work customer queues, finance workflows, data pipelines, and internal tools.

The control layer has to move with them.

Start in observe mode. Learn the real traffic. Tune the rules. Write receipts. Promote the rules that survive contact with the workflow.

Then block real work only where the team can explain why.

If you are preparing to give agents production access, BaristaLabs can help map the workflow, risk classes, approval paths, and enforcement ladder before credentials go live.

Map an agent firewall rollout

For a broader control framework, review our AI workflow controls or explore process automation services.