Most "AI-powered" SaaS tools work the same way under the hood: your data goes into a prompt, the prompt goes to OpenAI or Anthropic's API, and the response comes back. For a security scanner, that arrangement is uncomfortable in a specific way - you'd be sending a list of your own site's vulnerabilities to a third party before you've even had a chance to fix them. Shieldome's AI features don't default to that path, and where one feature does use a cloud model, it's worth being precise about exactly what leaves your infrastructure.
What Runs Locally, By Default
Chat about a scan, early triage ranking, the AI confidence review that adjusts false-positive risk, the pentest narrative write-up, remediation steps, and config snippet generation all run on Ollama - either on your own self-hosted instance, or on Shieldome-managed infrastructure for the cloud plan, but never routed through OpenAI, Anthropic, or any other external AI API. The request path for all of these is fixed: your browser to the Shieldome server, the Shieldome server to Ollama, and back - nothing exits that loop to a third-party endpoint.
Browser → Shieldome server → Ollama (your instance or ours) → Shieldome server → BrowserIf you're self-hosting Shieldome and running Ollama on the same machine, that entire path is air-gapped from external networks by construction - there's no API key to a cloud provider for it to reach even if something tried.
The One Feature That Uses a Cloud Model
A separate, clearly opt-in feature - the AI Insights tab on a scan, and the AI Remediation button on an individual finding - uses Anthropic's Claude Haiku model instead of Ollama. It's a distinct code path with its own, narrower data set:
- AI Insights sends the active findings' names, severities, OWASP IDs, and truncated descriptions, plus the target's domain with any IP address redacted - never the full URL, never a path, never request/response bodies or cookies.
- AI Remediation on a single finding sends only that finding's name, severity, description, and evidence excerpt - it doesn't even include the target's domain.
Both require an explicit click - neither runs automatically or in the background - and both require an ANTHROPIC_API_KEY to be configured on the instance at all. Without one, the buttons return an error and no request is made.
Why Draw the Line Here Instead of Just Using Ollama for Everything
The honest reason is that a small local model and a frontier cloud model aren't interchangeable for every task - a two-sentence false-positive estimate is well within what a 7B-parameter model handles reliably, but a longer, more nuanced executive-level analysis benefits from a stronger model. Rather than quietly routing everything through the cloud to get uniformly better output, that trade-off is confined to one clearly-labeled, opt-in feature with a narrower data footprint than the rest of the product needs in the first place.
Why This Matters If You Care About Data Residency
For teams working through SOC 2 or handling data in scope for PCI DSS, where your vulnerability data physically goes is often as relevant as whether the vulnerability gets fixed. See our SOC 2 technical controls and PCI DSS 4.0 guides for the broader compliance picture this fits into. If you need a strict guarantee that nothing ever reaches a cloud AI provider, self-host Shieldome with your own Ollama instance and simply leave ANTHROPIC_API_KEY unset - AI Insights and AI Remediation stay disabled, and every other AI feature keeps working normally.
See the Full Breakdown
Our AI assistant documentation lists exactly which data path each AI feature uses. Create a free account to try the local AI features on your own scan.