FireWeave

AI & MCP

Your AI can read your network. It still can’t change it.

Every vendor in this category now ships an AI assistant. Very few can answer the question your security architect will actually ask: what stops it making a change nobody approved? This page is our answer, in more detail than you probably want.

Choose your own model

FireWeave is not tied to one AI provider. Point it at a hosted model or run it entirely against a local one, so no configuration data leaves your network. Failover between providers is built in.

Hosted models

  • Anthropic Claude
  • Google Gemini
  • OpenAI
  • Azure OpenAI

Self-hosted models

  • Ollama, running on your own hardware
  • Any OpenAI-compatible endpoint
  • No FireWeave-hosted inference — ever
  • Your data is never used to train a model

The FireWeave MCP server

FireWeave speaks the Model Context Protocol, so Claude Code, Claude Desktop, a SOAR platform or your own agent can query your firewall estate directly. It is a thin adapter in front of the same API the product uses — which means your existing authentication, permissions and audit apply unchanged. There is no second enforcement path to drift.

Connect any MCP client

claude mcp add --transport http fireweave \
  https://fireweave.internal:8200/mcp \
  --header "Authorization: Bearer <token>"

Tokens are issued per service account from the admin console, shown once, and revocable from the same screen.

Find things

  • Resolve a firewall from a partial name or serial
  • Firewall and device inventory
  • Security rules and NAT rules

Answer questions

  • Find the network path between two points
  • Find the rules applicable to a given flow
  • Interfaces, zones, routes and ARP tables

Assess

  • Shadowed rules that will never match
  • Risky and overly permissive rules
  • Device routing tables for non-firewall hops

Bring your own AI. We’re the approval gate.

What the model can do

Read. Analyse. Explain. And draft an access request — which lands in the same approval queue a human request would, waiting for a person to approve it.

What it cannot do

Push a rule. Commit a change. Touch a device. Nothing deploys from the MCP surface, by architecture rather than by prompt.

How that is enforced

  • The MCP surface ships disabled — a new deployment must deliberately turn it on
  • Write requests need two independent switches, both off by default, both failing closed
  • Only a human can flip the write toggle; a machine token cannot
  • Every tool call writes an audit row: account, client, tool, hashed input and output, latency
  • Your RBAC is re-checked on every forwarded call, and revoked tokens die immediately
  • State-changing tools cannot be exposed without an approval requirement — the catalog refuses to load otherwise

Why you can trust what it tells you

The model never computes the answer. Paths, verdicts and rule matches come from deterministic engines running against your real configuration; the model chooses which question to ask and puts the result into English.

Evidence, not assertion

  • Findings are split into proved, assumed and not-tested
  • Each claim traces back to the command that produced it
  • The report tells you what was never verified

Calibrated confidence

  • Confidence is a published formula, not a model's opinion
  • Hard caps the model cannot argue past
  • A slowness symptom can never be blamed on policy at high confidence
  • Every score ships with the caps and penalties applied

See it against your own estate

Twenty minutes. We’ll connect a client, ask your network a real question, and show you the audit row it produced.

Book a 20-minute demo