Where Your Security Platform Runs Should Be Your Decision, Not Ours
Most security tooling is sold as a single deployment story with minor variations. You get the vendor's cloud, on the vendor's terms, and if your organization has requirements that do not fit that story, the conversation usually ends there. That works fine for a large share of the market. It does not work for a regulated bank, a government agency, a defense contractor, or a sovereign entity whose infrastructure requirements are not preferences but legal or contractual obligations. For those organizations, "our platform, our cloud, take it or leave it" is not a minor inconvenience. It is disqualifying.
Safeguard was built around a different premise: that deployment model should be a decision the customer makes based on their own regulatory and architectural needs, not a constraint the vendor imposes because it is easier to support one configuration. That premise touches everything from where the platform physically runs to how it talks to the network to whether an AI model is involved in your workflows at all.
Four ways to deploy, all production-ready today
Safeguard offers four deployment models, and it is worth being clear that all four are production-ready now, not roadmap items described in future tense.
SaaS is the default for most commercial buyers: multi-tenant cloud infrastructure, available across multiple regions including US, EU, and government-specific regions.
Private VPC or dedicated tenancy gives enterprise customers single-tenant isolation, meaning the infrastructure is not shared with other customers, while still running in a cloud environment rather than the customer's own datacenter.
On-prem moves the full platform inside the customer's own datacenter, for organizations whose requirements demand that the software itself, not just the data, stay within infrastructure they control directly.
Air-gapped and sovereign deployment goes further still: the complete offline stack, including the AI models, delivered with signed offline snapshots and no outbound dependency at all. This model is positioned for the highest-assurance environments, including those working toward impact levels like IL4 through IL7, CMMC, and ITAR requirements, where any outbound connection at all is a nonstarter.
Across all four models, the platform is cloud-agnostic. It is not architected around a single cloud provider's specific services, which means a customer choosing private VPC or on-prem is not locked into whichever provider Safeguard happens to prefer internally. That matters for organizations with existing cloud commitments or multi-cloud strategies of their own.
AI in the loop is a choice, not a default you are stuck with
Deployment location is only half the sovereignty question. The other half is whether an AI model is involved at all, and if so, whose model and where it runs. Safeguard treats this as fully configurable rather than fixed, which matters enormously for organizations wary of sending code or findings to a third-party model they do not control.
The platform can run in full AI mode, with Safeguard's own model family in the loop for remediation, discovery, and compliance narrative work. It can also run in Zero AI mode, where the entire platform operates deterministically with no large language model anywhere in the pipeline, useful for organizations with a hard policy against AI involvement in security tooling. Customers who already have an approved-model list can bring their own model instead, whether that means a Claude model, an OpenAI model, or another provider entirely. And for the most sensitive environments, quantized versions of Safeguard's own models can run entirely inside the customer's environment, on their own infrastructure, with no calls out to any external inference service at all.
That mode is configurable per tenant, which means an organization does not have to make one global decision and live with it forever. Different business units or different sensitivity tiers within the same organization can run different modes.
A network posture built for scrutiny, not convenience
Deployment flexibility only matters if the network behavior underneath it holds up to a real security review, and Safeguard's posture is built with that review in mind. The platform does not hold open or persistent connections; it operates on a polling architecture instead, which removes an entire category of firewall and egress concerns that come with tools expecting always-on connectivity. Communication is encrypted throughout, and zero trust principles apply across the platform rather than only at its outer edge.
Isolation follows the customer's plan type: enterprise customers get tenant-based isolation, with their data kept separate from other tenants, while consumer single-plan users share a common tenant. That distinction is intentional rather than an oversight; it reflects the different assurance requirements of an individual developer account versus a regulated enterprise deployment.
Flexibility as the actual point
None of this is flexibility for its own sake. Each option exists because a real category of buyer has a real requirement that a single fixed deployment model cannot satisfy: a bank that needs tenant isolation and a polling architecture before it will discuss features at all, a defense buyer that needs the entire stack, models included, running with no outbound connection, a platform team that wants to bring its own already-approved model rather than adopt a new one. Building for all of these at once, rather than picking one and asking everyone else to adapt, is what lets Safeguard have the same conversation with a five-person startup and a sovereign government deployment.
If your organization has deployment or data handling requirements that have ruled out other security platforms before, it is worth a direct conversation about which of these models fits. Visit safeguard.sh to talk through the deployment option that matches your actual constraints, not a one-size-fits-all default.
