Security & Data Handling

Deployment model

Every customer gets their own dedicated FireWeave instance — self-hosted in your environment, or run for you as a managed deployment. There is no shared FireWeave tenancy and no multi-customer database, so separation is structural rather than a row-level filter you have to trust. Self-hosted deployments run the full stack inside your network, and license verification works offline. Disconnected environments can import configuration snapshots rather than polling a live management plane, though some optional features — vulnerability feeds, URL category updates — expect outbound access.

Data flows

FireWeave reads configuration data from Panorama, cloud control planes, and connected network devices. It does not capture, mirror, or analyze packet traffic. Discovered configuration and topology data is stored in the FireWeave database; in self-hosted deployments that database lives entirely inside the customer environment.

Secrets handling

API keys, SSH credentials, and service-account tokens used by integrations are encrypted at rest using a per-connection key. Secrets are never written to application logs and are redacted from error reports. Access to stored secrets is scoped to the integration that needs them.

AI data handling

Policy analysis is deterministic. AI assistance is layered on top and is optional. When AI is used, requests go to a model endpoint you choose — Anthropic Claude, Google Gemini, OpenAI, Azure OpenAI, or an on-prem Ollama deployment. Your data is never used to train any model, and FireWeave hosts no inference of its own. Point it at a local model and no AI request leaves your network. The Model Context Protocol surface is read-only, ships disabled, and is covered on the AI & MCP page.

Transport security

• HTTPS enforced on all marketing and application traffic
• Outbound SMTP from this site uses TLS 1.2+ with certificate verification
• Integration connections use the strongest TLS or SSH profile each target supports
• Internal service-to-service traffic is mTLS-authenticated

Web application hardening

• Middleware rejects requests from known security scanners (sqlmap, nikto, nessus, burp, nmap, masscan)
• Contact form is rate-limited per IP and honeypot-protected
• Submission payloads are size-capped and input-sanitized server-side
• No third-party trackers, analytics, or advertising tags on the marketing site

Compliance posture

FireWeave performs continuous policy validation against custom and standard frameworks chosen by each customer; the platform is framework-agnostic and does not prescribe a single standard. Our internal security program is aligned with ISO/IEC 27001 control families.

Formal third-party certifications are in planning. Contact us for the current roadmap and any required attestations.

Reporting a vulnerability

If you believe you have found a security issue in FireWeave or this site, please email security@fireweave.io. Please include reproduction steps and your contact details. We will acknowledge within two business days and keep you updated through remediation.

We ask that researchers do not perform automated scanning against production systems and do not access or modify data that does not belong to them.