How to Set Up the Agent Firewall for Your Trading Agent (Step by Step)

The 60-second version

Setup is four moves: install the firewall, give it a policy file (the Safety Kit generates one), repoint your agent’s MCP config at the firewall instead of the broker, and move your broker credentials out of the agent’s reach. Then you prove it works by asking your own agent to break policy and watching the firewall say no.

The firewall is in development — this walkthrough reflects the beta design and will be updated against the shipped version. Join the waitlist to get the beta and founding pricing. Reading it now still pays off: the policy you’ll write in step 2 is the same config the Safety Kit produces today, so you can have your rules ready before the software arrives.

Before you start

You’ll need the same things the connect guides assume: a funded agentic account (bounded by the how-much-to-fund rules), a working broker MCP setup, and Node.js 20+ on the machine where your MCP servers run. If your agent currently works end-to-end — it can fetch a quote and you’ve seen it place a bounded test order — you’re ready.

One mindset note before the commands: you are about to demote your agent. Right now it holds the keys. After setup it holds nothing, and everything it does passes through a checkpoint you control. The agent’s experience barely changes — same tools, same names — but the trust architecture flips.

Step 1 — Install the firewall

npx @secprove/agent-firewall init

init does three things: creates a config directory (~/.agent-firewall/), writes a starter policy.yaml, and prints the MCP snippet for step 3. The firewall is a single Node process with no daemon, no background service, and — in the free tier — zero network calls to anything except your broker’s MCP server. It’s open source; audit it before you trust it. That’s the point.

Step 2 — Write your policy

If you’ve used the Safety Kit, you’ve already done this. Export your config as policy.yaml (the kit’s firewall-format output) or start from the generated starter and edit. A balanced-tier policy for a $2,000 account looks like:

# ~/.agent-firewall/policy.yaml
version: 1
funding: 2000

instruments:
  allow: [equities]        # no options, no margin, no transfers

caps:
  per_trade_pct: 10        # max $200 per order
  daily_volume_pct: 40     # max $800 traded per day
  concentration_pct: 35    # max $700 in any one ticker

tickers:
  allowlist: []            # empty = any ticker not denylisted
  denylist: [TSLA, GME]

hours:
  window: "10:00-15:30"
  timezone: America/New_York

approval:
  require_above_pct: 15    # orders over $300 held for human approval

circuit_breaker:
  max_trades: 5
  per_minutes: 10

Every field maps one-to-one to a Safety Kit rule — the policy file reference explains each knob, the evaluation order, and the tier presets. The file is plain YAML in your home directory: version it, diff it, treat changes to it like the production config change it is.

Step 3 — Put the firewall in the path

This is the architectural move. Today your agent’s MCP config points straight at the broker server, and the credentials sit in the agent’s config:

// BEFORE — agent holds the keys
{
  "mcpServers": {
    "robinhood": {
      "command": "npx",
      "args": ["robinhood-trading-mcp"],
      "env": { "RH_API_KEY": "rh-..." }
    }
  }
}

After, the agent talks to the firewall, and only the firewall knows the credentials:

// AFTER — firewall holds the keys
{
  "mcpServers": {
    "trading": {
      "command": "npx",
      "args": ["@secprove/agent-firewall", "wrap",
               "--policy", "~/.agent-firewall/policy.yaml",
               "--", "npx", "robinhood-trading-mcp"]
    }
  }
}

The firewall spawns the real broker server as a child process and injects RH_API_KEY from its own credential store (agent-firewall secrets set RH_API_KEY), which is encrypted at rest on your machine. Then do the half of this step everyone skips: delete the key from the agent’s config, and rotate it with your broker. The old key passed through your agent’s context and config files; assume it’s burned. Enforcement is only real when the firewall is the only holder of a working credential.

Step 4 — Prove it blocks

Don’t trust the setup — test it. Ask your agent, in plain language, to violate your own policy:

"Buy $500 of TSLA right now."

With the policy above, that order is doubly out of bounds: TSLA is denylisted and $500 exceeds the $200 per-trade cap. What you should see is the agent reporting something like "the order was rejected by the trading policy: ticker TSLA is denylisted." The agent isn’t being obedient here — it physically attempted the trade and got a structured refusal back. Check the audit log and you’ll see the attempt:

agent-firewall log --tail 1
→ 14:32:07 place_order TSLA $500 BLOCKED (ticker_denylist)

That blocked entry is the whole product in one line: the attempt happened, the policy held, and you have the receipt. Run one more test for the approval gate — ask for a trade above your threshold and confirm it parks as HELD until you approve it from the terminal (agent-firewall approve <id>).

Step 5 — Drill the kill switch

Same logic as a fire drill: practice before the fire.

agent-firewall kill      # everything write-side stops, instantly
agent-firewall status    # KILLED — 2 write calls rejected since 14:40
agent-firewall arm       # explicit re-enable, requires confirmation

While killed, read-only calls still work (your agent can see, not touch), every rejected attempt is logged, and nothing re-arms implicitly — not a restart, not a new session. Put the kill command somewhere you can reach in ten seconds from your phone or another terminal, and run the drill once a month alongside the monitoring routine.

Day-2 operations

After setup, operating the firewall is three habits: read the audit log weekly the way you’d read the trade audit — paying special attention to blocked entries, which are your early-warning signal that something is steering your agent; change policy.yaml deliberately and rarely; and re-run the step-4 block test after any update to the firewall, the broker MCP server, or your agent.

The free tier does all of the above locally. Firewall Pro adds the operational layer for when you’re not at the machine: push alerts the moment something is blocked, approve-from-phone for held orders, a remote kill switch, and hosted audit history. Beta access and founding pricing ($79/yr, locked) go to the waitlist first. Join it here →

How to set up the Agent Firewall, step by step