Verify

A firewall you think traffic is going through is worse than no firewall, because you will make decisions as if it were enforcing. This page is about proving it.

The local check

vulnetix ai-firewall status

You are reading three things:

  1. Providers — is a key stored, and is the provider allowed?
  2. Local clients — is each detected client wired, or does it point elsewhere (configured, but at something other than the gateway)?
  3. Checks — anything at [error] will fail requests. Anything at [warning] is a bypass or a latent problem.

The check that matters most here is bypasses_firewall: a client on your machine that is talking to a provider directly. It exists because the firewall is a control, not a cage — anyone can unset an environment variable.

vulnetix ai-firewall status --strict   # non-zero exit if any error-level check fails

--strict is what you put in CI.

The end-to-end check

Local state can be right while the request path is still wrong. The only way to know is to send something and watch it get blocked.

1. Add a canary rule

vulnetix ai-firewall policy guardrail canary \
  --rule-type blocked_pattern --action block --pattern 'canary-a1b2c3' --priority 1 --enable

2. Send it through your actual client

Not through curl — through the thing you are trying to verify. Ask your agent, or your app, to repeat the string canary-a1b2c3.

3. You should get a 403, not an answer

{
  "error": {
    "message": "request blocked by AI firewall policy: content matched pattern for policy \"canary\"",
    "type": "policy_violation",
    "code": "request_blocked",
    "blocked_by": "canary"
  }
}

Claude Code renders this as a readable error, not a bare status code — errors come back in the dialect of whatever client asked.

If you get a normal completion, that client is not going through the firewall. Go back to status and look at what it says the client’s base URL is.

4. Remove the canary

vulnetix ai-firewall policy guardrail canary --uuid <uuid> --delete

(Get the UUID from vulnetix ai-firewall get.)

What verification cannot tell you

Be honest with yourself about the boundary:

  • Cursor’s tab completions and Auto mode never route through BYOK, no matter how you configure it — that is a limit of Cursor, not of the firewall. If you assume 100% of Cursor’s traffic is firewalled, you have a hole. See Cursor.
  • A canary proves the request path, not the policy. It shows requests reach the guardrail engine. Whether your actual rules catch what you need them to catch is a separate question — see tuning false positives.
  • Nothing here inspects responses. Guardrails run on what you send. See limitations.

Ongoing assurance

If your organisation has inference logging enabled, every proxied request records which surface it arrived on and how many text segments the guardrails actually read. That second number is the one to watch: a request that parses cleanly but exposes nothing to inspect is a firewall screening nothing, and without it that looks exactly like a clean pass.