The Sovereignty Question: What Happens When You Cannot Send Code to a Third-Party LLM
For a growing number of security and compliance teams, the most disqualifying question in any AI-powered tool evaluation is not "does it work." It is "where does our code go." A defense contractor, a national health system, a bank operating under strict data residency rules: for these buyers, sending proprietary source code to a third-party model API is not a policy preference, it is a line they are not permitted to cross. Historically that has meant choosing between security tooling with real AI capability and tooling that can actually be deployed inside a regulated environment. Those two lists have not overlapped much.
Safeguard was built to close that gap by treating the AI layer itself as configurable, not fixed.
Three ways to run the platform
The first option is full AI mode, where Safeguard's own trained models, Griffin, Eagle, and Lion, sit in the loop doing reachability analysis, adversarial disproof, and compliance narrative work. This is the default experience most customers use, and it is where the platform's autonomous remediation and zero-day discovery capabilities run at full depth.
The second option is Zero AI mode. This is the one that matters most for the sovereignty conversation, because it is a genuine architectural choice, not a marketing label. In Zero AI mode, the entire platform runs deterministically, with no large language model in the loop at all. Every scanner still works. Zero-day discovery still runs, using its deterministic scanner mode rather than the agentic loop. SCA, SAST, DAST, secrets scanning, license compliance, all of it functions without a single call to any LLM, anywhere. For a buyer whose procurement or legal team has flatly ruled out sending code to any model, hosted or otherwise, this is the mode that lets Safeguard clear that bar without asking them to compromise.
The third option is bring your own model. A customer who has already vetted a specific provider, whether that is Claude in one of its variants, OpenAI, Cohere, Mistral, or another provider entirely, can plug that model into Safeguard instead of using Safeguard's own models. This matters for organizations that have already done the procurement and security review work on a particular vendor and do not want to repeat that process for a new tool. Their existing trust relationship carries over.
A fourth configuration extends the same idea further: local and on-prem models, running quantized versions of Griffin, Eagle, and Lion entirely inside the customer's own environment. This gets a regulated buyer the benefit of Safeguard's purpose-built security models without any of that traffic ever leaving their infrastructure.
Why this is a first-class feature, not a footnote
A lot of vendors treat AI configurability as an afterthought, a toggle buried in an admin panel. Safeguard treats it as one of the central reasons a regulated organization can say yes. The mode is configurable per tenant, which means a single organization can run different postures for different environments if it needs to: full AI for a low-sensitivity development pipeline, Zero AI for a classified or air-gapped system, bring your own model for a business unit that has already standardized on a particular provider.
This is also honest framing worth stating plainly: two of Safeguard's three models are trained in house, and one is a fine-tune of an open source base. None of that changes what Zero AI mode or bring your own model give a customer. The point of these modes is not to hide how the models are built, it is to give the customer control over whether any model touches their code at all.
Why this is the wedge for regulated buyers
Most of the AI security tooling market assumes a customer is comfortable sending code to a hosted model somewhere. That assumption quietly excludes a large and growing set of buyers: government agencies, defense contractors, healthcare systems, financial institutions, and any organization operating under strict data residency or export control requirements. Safeguard's answer is not to argue that sending code to a third party is actually fine. It is to make that question unnecessary, by offering a deterministic mode that needs no model at all, alongside the flexibility to use a model the customer already trusts, running wherever the customer needs it to run.
Combined with Safeguard's deploy-anywhere posture, SaaS, private VPC, on-prem, and fully air-gapped, this is what lets Safeguard sit inside environments that would otherwise disqualify almost any AI-driven security platform on sight.
If your organization has a firm answer to "where can our code go" and that answer has ruled out other AI security tools, it is worth a conversation with safeguard.sh about which of these modes fits.
