Where your code and data go with Safeguard, deployment by deployment

Your code goes only where your deployment model sends it. Safeguard runs as multi-tenant SaaS in US, EU (Frankfurt, Germany) and Gov regions, as a single-tenant private VPC, fully on-prem, or air-gapped with its own models offline. With the local runner, source code never leaves your machine; only the resulting SBOM and findings go back.

That is the whole answer in one paragraph. The rest of this post walks the data path end to end, deployment by deployment, so a CISO, a security architect or a procurement reviewer can match each class of data to a model and write the answer into a questionnaire without guessing.

Key takeaways

• Safeguard offers four deployment models: SaaS (multi-tenant, regions US, EU in Frankfurt Germany, and Gov), private VPC or dedicated tenancy, on-prem, and air-gapped. All four are available today.
• The AI mode is a separate choice from the deployment model. Full AI, Zero AI, bring your own model and local models are configurable per tenant, so "no LLM anywhere" is possible even on SaaS.
• The local runner, built into the Safeguard CLI, scans on your machine and uploads only the SBOM and findings. Nothing connects in to it; it opens outbound HTTPS itself.
• In an air-gapped install, no component inside the perimeter calls outbound. Updates arrive as signed snapshot bundles over a diode, removable media, a short DMZ window or a pull replica.
• Customer code, SBOMs and telemetry are not used to train shared models.
• Deployment readiness and certification are different things. The architecture is designed for FedRAMP High; SOC 2 Type II is in progress. None of these is an authorization or a certificate.

The short answer, model by model

Two other choices change the answer as much as hosting does: the tenant's AI mode, and how code reaches the platform (an SCM integration, an SBOM upload or the local runner).

Why a regulated buyer asks about data before features

For financial services, government, defense and sovereign buyers, the first three questions are about data, not features. A reviewer cannot score a scanner's precision in a week, but they can score whether a vendor will hold source code, whether a model provider sees it, and which jurisdiction stores the results. The questions tend to come in this order:

1. Where does our source code go, and does it have to leave our network at all?
2. What else leaves: dependency manifests, SBOMs, findings, container images, prompts?
3. Which country and which tenancy holds what does leave?
4. Who and what can read it: other tenants, the vendor's staff, a model provider, a model training pipeline?
5. What network openings do we have to make, inbound or outbound?
6. What can the vendor prove today, and what is still in progress?

A good answer handles each one separately. "Designed for FedRAMP High" says nothing about where code goes, and "your code stays local" says nothing about assurance.

What data Safeguard actually handles

Before picking a model, list the data. SAST takes a GitHub, GitLab, Bitbucket or any Git-compatible repository; SCA takes an SBOM upload, a source code integration or a container image integration; DAST takes any network-reachable target, on a private or public network.

For many teams, SBOMs and findings may go to a hosted service while source code may not. The local runner exists for exactly that split.

SaaS: multi-tenant, in the US, EU (Frankfurt, Germany) or Gov region

Safeguard's hosted service is multi-tenant and multi-region. The regions are the US, the EU and Gov. The EU region is hosted in Frankfurt, Germany, so a tenant in the EU region keeps its stored data in the EU. There is no other in-country SaaS region today. If a regulator or a contract requires that data stay in a specific country outside those regions, the answer is a private VPC, on-prem or air-gapped deployment in that country, not a SaaS tenant.

What "multi-tenant" means for your data

Safeguard uses a tenant-based structure with data isolation for enterprise customers. A shared tenant exists only for consumer single-plan users and never for enterprise accounts. An enterprise organization's projects, SBOMs, findings and settings sit in its own tenant.

If you need more separation than logical tenancy, the next step up is a private VPC or dedicated tenancy, covered below. For a deeper look at the isolation design, see how Safeguard isolates tenants.

How code reaches a SaaS tenant

There are three routes, and the route matters more than the region.

An SCM integration. You connect GitHub, GitLab, Bitbucket or another Git host, and the hosted platform reads the repository through that integration. This is the most convenient route and the one that sends the most data: the platform needs repository contents to scan them.

An SBOM upload. You generate an SBOM yourself, in CI or on a build machine, and upload it. The platform matches components against vulnerability databases and stores the SBOM and findings. Source code never touches the hosted service, though the SBOM does describe your components and versions in detail.

The local runner. The scan runs on your machine and only the SBOM and findings go back. This is the route for teams that will not grant OAuth access to a cloud service at all.

Where your AI features run in SaaS

Safeguard's own models run inside Safeguard's deployment, and the docs state that Safeguard's own product features send no customer data to third-party AI providers. Two choices change that, both yours: Zero AI, which removes models entirely, or routing jobs to a model you bring. Both are covered below.

The local runner: source code stays on your machine

The local runner is not a separate product. According to the runner documentation, it is part of the Safeguard CLI: open the interactive terminal, sign in, and the machine starts polling the platform for work assigned to it. It runs each scan job locally and uploads only the resulting SBOM and findings, never your source code.

The docs list three situations where it fits: your repository is private and you cannot or will not give a cloud service OAuth access; you work in a restricted network where only outbound HTTPS is allowed; or you want the assistant to fix vulnerabilities in code you have not pushed yet.

How the runner talks to the platform

The runner sends a heartbeat and polls the platform for jobs assigned to its machine. All traffic is outbound HTTPS that the runner opens, and nothing connects to it. When it claims a job, it executes the job with its own local scan server, uploads the result files (the SBOM and findings) and reports the job status. Source code stays on the machine.

One detail matters to network teams. By default, runner start long-polls, which means it holds an outbound request open while it waits for work. On a network that forbids held connections, the --poll-wait 0 flag switches it to polling at a fixed interval, set by the SAFEGUARD_POLL_INTERVAL environment variable. Either way the direction is the same: the runner calls out, and the platform never calls in. There is no inbound port to open and no listener to expose.

Install and first run

The runner ships with the CLI, through the one-line installer.

# macOS and Linux
curl -fsSL https://cli.safeguard.sh/install | bash

# Windows (PowerShell)
irm https://cli.safeguard.sh/install.ps1 | iex

The docs note there is no Homebrew formula, winget package or container image for it; the CLI installation docs cover version pinning and checksums. Then start it:

safeguard
# inside the terminal, type /login

Your browser opens, you approve the session, and the runner starts. The first run also downloads the scanner tools and the vulnerability database, which is worth knowing when you plan egress rules: that download is outbound too.

Headless mode for build machines

On a shared build host or a dedicated scanning VM, you usually want the runner without a terminal UI.

# Serve assistant turns for this workspace without the terminal UI
safeguard runner start --workspace ./path/to/repo

# On networks that forbid held connections, poll at a fixed interval instead
SAFEGUARD_POLL_INTERVAL=30 safeguard runner start --workspace ./path/to/repo --poll-wait 0

# Is it running, and what is it doing
safeguard runner status

# Drain in-flight work and stop
safeguard runner stop

The --permission-mode flag sets how much the assistant may do without asking, from supervised to autonomous. For CI, safeguard exec runs a single turn with no prompts and defaults to strict permissions: nothing is asked, and anything the policy file has not approved in advance is denied. Since CLI v11.10.0, the interactive CLI asks before any command that changes something, while read-only commands run in the default Auto mode without a prompt.

Two update commands do different things: safeguard self-update updates the binary, and safeguard update refreshes the vulnerability databases. Both are outbound pulls you initiate, so route them through the same proxy as the polling traffic.

For more on this route, see why the local runner keeps source on your machine and does the Safeguard CLI upload your source code.

Private VPC and dedicated tenancy

A private VPC deployment is a single-tenant deployment in a private network, isolated for one customer, and offered for Enterprise. The platform is cloud-agnostic, so this is not locked to one cloud provider. Safeguard can also be deployed on the public cloud you choose.

What changes compared with SaaS is tenancy. In multi-tenant SaaS, isolation is logical inside a shared service; in a private VPC, nothing is shared with another customer. That is the usual requirement when policy says sensitive data may be processed only in an environment dedicated to the organization.

What does not change is the AI mode question. A private VPC can run Safeguard's models as a single-tenant inference cluster in the private network, according to the AI models documentation. It can also run Zero AI, or route work to a model you bring.

Settle three things in the contract and architecture review, because they vary by deal:

• Whose cloud account holds the deployment, and who holds administrative access to it.
• Which outbound connections the deployment needs, for example vulnerability feed updates and platform releases, and whether those go through your proxy.
• Who operates upgrades and how fast security patches are applied.

Get those answers in writing.

On-prem: the full platform in your datacenter

On-prem means the full platform inside your own datacenter or infrastructure, and it is available today, not a future promise. The AI models come with it. The AI models documentation says that on-prem, Griffin, Eagle and Lion run as quantized builds on customer GPUs, and Zero, which has no model weights, runs in process on the platform. Safeguard's catalog lists Lion as Lion; the two names refer to the same model.

On-prem answers the residency question completely. The platform, its storage and its models are where you put them. If a regulator wants data held in a specific country that is not covered by the SaaS regions, on-prem in that country is the straightforward answer.

The trade-off is operations: you run the infrastructure, plan inference capacity if you want AI in the loop, and own the upgrade cadence. The air-gapped section below covers the published install footprint and upgrade procedure.

Air-gapped: the complete stack, models included, with no outbound dependency

The air-gapped deployment documentation describes a deployment that runs every capability inside your perimeter with no internet egress required. According to that page, every product has an air-gapped equivalent: the full web app (ESSCM, Portal, TPRM and OSM); Griffin, Eagle and Lion as quantized builds on customer GPUs; Zero, running in process with no model inference; continuous scanning driven by delta-shipped vulnerability feeds; and the MCP server, API, CLI, desktop app and runner. A Kubernetes admission controller admits images without cloud connectivity, and container rebuilds run inside your environment using your mirrored registries.

The reference architecture

The docs describe a simple shape. A signed snapshot bundle ships from Safeguard on the cadence you choose. A Receiver, positioned in a DMZ, verifies the signatures and pushes deltas to the Control Plane. The Control Plane runs every Safeguard component inside the perimeter: the web app, the API and MCP server, inference, the scanner and storage (Postgres, S3-compatible object storage and a secrets vault). The page states it directly: no component inside the perimeter ever calls outbound.

That is what separates air-gapped from on-prem with the firewall closed: there is no hidden dependency waiting to break.

What is inside a snapshot bundle

Each signed bundle contains, according to the docs:

• Vulnerability feed deltas from NVD, GitHub Advisory, OSV, Safeguard Research, CISA KEV and daily EPSS.
• Gold artifact deltas (tarballs and OCI layers).
• Model updates for Safeguard's classification model.
• Policy template updates.
• Platform binaries when releases ship.

Every bundle is signed with Safeguard's air-gap signing key and can be verified independently against a public transparency log, or against a private transparency log for classified tenancies.

How bundles cross the gap

The cadence is configurable from hourly down to quarterly, and the choice belongs in your risk register: on a quarterly cadence, vulnerability data inside the perimeter can be a quarter old, so findings for new disclosures arrive late. The docs also list hot-patch bundles with accelerated signing for critical issues.

Install footprint

A production air-gapped deployment needs a Kubernetes cluster (OpenShift, EKS Anywhere, Rancher or upstream Kubernetes), Postgres 15 or later, S3-compatible object storage and, optionally, a GPU pool for inference; the docs give the minimum cluster shape.

For evaluations, a single-node proof of concept works, and Safeguard ships a one-VM appliance image for that case, so a program can evaluate inside its own boundary before committing hardware.

Inference without GPUs

Some isolated sites cannot spare GPU time. The docs describe three fallbacks: CPU-only quantized builds of Griffin, Eagle and Lion that are usable for triage and summarization but slower than GPU; a batch inference mode that queues analysis jobs and processes them overnight; and a retrieval-only mode that returns static answers from the shipped knowledge base without live inference. Zero AI is the fourth option: the deterministic platform with no model at all.

Upgrades, keys and access inside the perimeter

The operational runbook in the docs covers four things a security architect will ask about.

Upgrades. Validate the new bundle's signatures, install blue/green with Helm into a new namespace, cut over through your ingress, and keep the previous namespace for one release cycle as a rollback.

Key rotation. Signing keys rotate on a configurable cadence, annually by default. Rotation is a two-person, signed and logged operation, and both old and new keys are trusted for a grace period during the change.

Access. Because the control plane is isolated, people sign in through your existing SSO (SAML or OIDC) against your own directory, operators reach it through bastion hosts or privileged access management, and SCIM sync runs inside the perimeter.

The install runbook itself, with hardening baselines, Helm values, the day-zero signing key ceremony and disaster recovery, is provided as a private repository to authorized tenants. For the most common questions about this model, see the air-gapped deployment FAQ.

The four AI modes, and where prompts and code go in each

The deployment model decides where the platform runs. The AI mode decides whether any language model sees your data, and whose model it is. Safeguard makes this configurable per tenant, and the offering calls it the single strongest answer to the "what touches our code" question.

Zero AI is not a reduced product

In Zero AI mode every scanner still works. What you give up is the model-driven layer, such as chat and natural-language search. For a buyer whose policy says no generative AI may process source code, Zero AI turns a policy conflict into a configuration setting.

Safeguard's model catalog also lists Zero as a model id with no weights and no inference. It answers data questions without any model at all, which is why it can run in process on an air-gapped platform.

Bring your own model, step by step

The bring your own model documentation is written for Safeguard's API Platform console, a separate product, but it also describes how a tenant admin adds a model to the platform itself, and that part applies here. According to that page:

1. In ESSCM, open Integrations, then Configure Scanner, then Models.
2. Under Your own models, select Add model.
3. Enter a name, choose the provider and the type: a frontier vendor through your account, or a self-hosted endpoint.
4. Choose which API it speaks: OpenAI-compatible, Anthropic Messages or Google Gemini.
5. Enter the model name at the vendor, the endpoint URL where needed, and the API key, then save.

The key goes into Safeguard's credential vault, separate from the model's settings, is fetched only when a call is made, and is never logged. The Route jobs to this model option sends work from Safeguard's own AI features, such as search and chat, to that model.

Two data path consequences follow, and both belong in your review.

First, Safeguard's servers make the call. The docs state that a self-hosted endpoint must be reachable from Safeguard. On SaaS that means your endpoint has to accept requests from Safeguard's hosted service. On-prem or in a private VPC, the call stays inside whatever network you give the platform.

Second, a hosted closed model always runs on its provider's infrastructure. Safeguard's deployment options page says closed models are never installed on-prem or in an air-gapped environment, so using one always means sending the request to its provider's API. If you pick a hosted model from an outside provider, the data you route to it is governed by your agreement with that provider, not by Safeguard's hosting. In an air-gapped deployment, the practical choices are Safeguard's local models, an open-weight model you host yourself, or Zero AI.

No training on customer data

Safeguard's offering states that customer code, SBOMs and telemetry are not used to train shared models. The AI models documentation says the same in its privacy section and adds two details: per-tenant fine-tunes are opt-in and stay inside the tenant boundary, and inference requests are logged with tenant-scoped keys for audit only, with request bodies kept only for a short default retention that Enterprise can configure. Dedicated and on-prem model deployment is available for Enterprise.

For a decision guide on the modes, see Zero AI, Full AI or bring your own model.

AI mode and deployment, combined

Network posture: polling, encryption, zero trust

These are the answers that belong in every security questionnaire, and the offering lists them as available today.

No open or persistent inbound connections. Safeguard's architecture polls. The platform does not reach into your network, so there is no inbound firewall rule to request. The runner documentation describes what that looks like on the wire: outbound HTTPS opened by the runner, long-poll by default, fixed-interval polling with --poll-wait 0 where held connections are not allowed.

Encrypted request communication throughout. Traffic between your machines and the platform is HTTPS.

Zero trust across the platform, not just at the edge. NIST's SP 800-207, published in August 2020, describes zero trust as assuming no implicit trust based on network location or asset ownership, with authentication and authorization performed before a session to a resource is established. Safeguard applies that model across its platform, which is also why an outbound-only runner fits zero trust network programs: nothing is trusted because of where it sits.

Tenant isolation. Enterprise data sits in its own tenant; the shared tenant exists only for consumer single-plan users.

Privacy mode. Search and conversation history are not stored in private mode.

What your network team will want to see

A short, honest list of flows helps more than a diagram. For SaaS with the local runner, it looks like this:

For air-gapped, the table shrinks to one row: the bundle crossing into the Receiver in the DMZ, through the channel you chose.

Certification wording, said precisely

Deployment capability is ready now. Certification status is a separate matter, and conflating the two is the fastest way to lose credibility in a security review. Here is the wording Safeguard uses and why.

FedRAMP

FedRAMP is run by the US General Services Administration, and fedramp.gov maintains the FedRAMP Marketplace, its searchable database of certified cloud services, authorizing agencies and recognized assessors. A vendor either appears there or does not. "Designed to FedRAMP High requirements" describes how an architecture was built; it is not a substitute for checking the Marketplace.

Defense contractors and the cloud clause

Many US defense suppliers meet this question through DFARS clause 252.204-7012. When a contractor uses an external cloud service provider to store, process or transmit covered defense information, the clause requires the contractor to ensure the provider meets security requirements equivalent to the FedRAMP Moderate baseline, along with the clause's incident reporting and forensic requirements. That is why so many defense programs choose on-prem or air-gapped deployment for a security platform that will see source code: when the platform runs inside the contractor's own boundary, the scan data never goes to an external cloud service at all.

CMMC

The CMMC program rule at 32 CFR 170.14 defines three levels. Level 1 uses the safeguarding requirements in FAR 52.204-21, Level 2 is identical to NIST SP 800-171 Revision 2, and Level 3 adds selected requirements from NIST SP 800-172. Note that the rule references Revision 2 even though NIST published SP 800-171 Revision 3 in May 2024; your assessor will tell you which revision your assessment uses. Some Level 3 requirements concern controlling information flows between security domains. An isolated deployment with signed, one-way updates is designed for that kind of boundary, but only your assessment can say whether your systems meet a level.

ITAR

Export rules are where precise wording matters most. The ITAR at 22 CFR 120.54 lists activities that are not exports, including, under specific conditions, sending or storing unclassified technical data secured with end-to-end encryption using FIPS 140-2 compliant modules or comparable strength, provided it is not sent to or stored in a proscribed country. Those conditions are narrow. The simple engineering answer for software that may contain technical data is to keep the platform inside the boundary, as the air-gapped and on-prem models do. Whether a flow is an export is a question for your export counsel.

SOC 2

The AICPA describes SOC 2 as a report on an examination of controls at a service organization relevant to security, availability, processing integrity, confidentiality or privacy; its SOC 2 resource page has the guides. Safeguard's SOC 2 Type II audit is in progress. Safeguard publishes the status of its compliance frameworks on its Trust Center, where restricted documents such as audit reports are released through Request access after review. Whatever the vendor, confirm the report's scope covers the product and deployment you are buying.

For a broader treatment of how to answer these questions on paper, see answering data residency questions in security questionnaires and AppSec RFP questions on data handling and deployment.

EU buyers: what the Frankfurt region does and does not settle

For a European buyer, the EU region in Frankfurt, Germany answers the storage location question: a tenant in that region keeps its stored data in the EU. It does not settle every question. The European Commission's guidance on international data transfers covers how personal data moving outside the EU is protected, through adequacy decisions and standard contractual clauses among other tools. A security platform mostly processes code, components and findings rather than personal data, but it also holds user accounts, audit logs and sometimes names in commit metadata. So three follow-up questions are fair:

• Which personal data does the tenant hold (user accounts, audit entries, commit author fields)?
• From where can the vendor's staff access the tenant for support, and under which contractual terms?
• If you add your own model, where does that provider process requests?

The first depends on what you connect, the second belongs in the data processing agreement, and the third is governed by your agreement with the model provider. If the answers do not fit your policy, a private VPC or on-prem deployment inside the EU removes the shared hosting question.

Which model fits which data class

The offering's segment guidance and the data table above combine into a practical decision matrix. Treat it as a starting point for your own classification scheme.

Financial services teams usually start with the local runner and Zero AI; government, defense and sovereign buyers with air-gapped deployment and offline models; scale-ups working toward SOC 2 or ISO 27001 with SaaS and Full AI. Our earlier guide to picking a model by data class covers the same decision in a shorter form.

Walkthrough: prove the data path during an evaluation

Claims about data paths are easy to test. Here is a sequence to run in a proof of concept with standard operating system tools.

Step 1. Pick a test machine and a sample repository on the network segment where the runner will live.

Step 2. Install the CLI and sign in.

curl -fsSL https://cli.safeguard.sh/install | bash
safeguard
# type /login, approve in the browser, then exit the terminal UI

Step 3. Run a local scan and inspect the output before anything else.

cd ~/src/sample-repo
safeguard scan --dir .
ls ./output

As the CLI usage docs describe, the CLI writes results as JSON files under --output, which defaults to ./output. Open the files and confirm what they contain: components, versions, findings. This is the shape of what a runner uploads. The same command takes --image <name> for a container image and --sbom <file> for an existing SBOM.

Step 4. Start the runner headless and watch its connections.

safeguard runner start --workspace ~/src/sample-repo
safeguard runner status

In a second terminal, list the runner's network connections.

# macOS or Linux: established TCP connections for the runner process
lsof -nP -iTCP -sTCP:ESTABLISHED | grep -i safeguard

# Linux alternative
ss -tnp | grep -i safeguard

You should see outbound connections from your machine to the platform and no listening sockets that accept connections from outside. To confirm there is no listener, check for listening sockets too.

lsof -nP -iTCP -sTCP:LISTEN | grep -i safeguard

The runner executes jobs with its own local scan server, so if you see a listener, note its bind address. A local server bound to the loopback address is reachable only from the machine itself; anything bound to an external interface is worth raising with Safeguard during the evaluation.

Step 5. Test the strict network case. If your proxy forbids held connections, restart the runner with fixed-interval polling and confirm it still claims jobs.

safeguard runner stop
SAFEGUARD_POLL_INTERVAL=30 safeguard runner start --workspace ~/src/sample-repo --poll-wait 0

Step 6. Check your proxy logs. Where the runner's outbound HTTPS passes through an inspecting proxy, confirm the destinations and that request sizes look like SBOM and findings uploads rather than repository archives. That log is the evidence your reviewer wants.

Step 7. Record the tenant settings. Write down the AI mode, whether privacy mode is on, and any models added under Your own models. With the proxy evidence, that is your data path record.

Questions to put in your security questionnaire

These get specific answers out of any vendor, including Safeguard.

1. Which deployment models are available today, and which is proposed for us?
2. In which region will our tenant live, and which country hosts it?
3. Will our source code leave our network under the proposed design? If yes, by which route?
4. What exactly does a local scanning component upload, and can we inspect it before upload?
5. Which network flows are required, in which direction, and who initiates them?
6. Which AI mode will our tenant use? Can we turn AI off entirely and keep the scanners?
7. If we bring our own model, which servers call it, and what must be reachable?
8. Is any customer data used to train shared models? Are per-tenant fine-tunes opt-in?
9. For air-gapped: how are updates signed and verified, and how are signing keys rotated?
10. Which certifications are complete, which are in progress, and what does each report cover?

Common mistakes

Treating the region as the whole answer. A tenant in the EU region keeps stored data in the EU, but a model you route work to may process requests elsewhere, and support access is a contract question. Answer residency per data flow, not per tenant.

Granting repository access when the runner would do. Teams often connect an SCM integration during a trial because it is quick, then discover in the security review that the policy forbids it. Start regulated evaluations with the local runner.

Assuming Zero AI means fewer scanners. It does not. Every scanner still works with no LLM in the loop. Test it on a real repository before deciding the trade-off.

Reading "designed for" as "authorized". Architecture designed to FedRAMP High requirements is not a FedRAMP authorization, and the same caution applies to any other "designed for" claim. Check the issuing body's list.

Forgetting that a hosted closed model leaves the building. Bring your own model is a strong option, but a closed model hosted by its provider is always called over that provider's API, even when your Safeguard platform is on-prem.

Planning an air-gapped install without a bundle cadence. The update channel and cadence determine how current your vulnerability data is. Decide them, document them, and put the staleness window in your risk register.

Opening an inbound firewall rule out of habit. The runner needs outbound HTTPS only. A request for an inbound rule means something has been misunderstood.

FAQ

Does Safeguard store my source code?

Only if you choose a route that sends it. With an SCM integration, the hosted platform reads repository contents to scan them. With the local runner, the scan happens on your machine and only the SBOM and findings are uploaded. With on-prem or air-gapped deployments, everything stays inside your environment.

Where is Safeguard's EU region, and is there one in my country?

The EU SaaS region is hosted in Frankfurt, Germany, so data stored there stays in the EU. The SaaS regions are the US, the EU and Gov only. If you need data held in a specific country outside those, use a private VPC, on-prem or air-gapped deployment in that country.

Can Safeguard run with no AI at all?

Yes. Zero AI mode runs the entire platform deterministically with no LLM anywhere in the loop, and every scanner still works. The mode is configurable per tenant.

Does Safeguard train its models on customer code?

No. Customer code, SBOMs and telemetry are not used to train shared models. Per-tenant fine-tunes are opt-in and stay inside the tenant boundary.

Is Safeguard FedRAMP authorized?

No. Safeguard's architecture is designed to FedRAMP High requirements, which describes how it was built, not an authorization. Check the FedRAMP Marketplace for any vendor's authorization status.

Does Safeguard have a SOC 2 Type II report?

Safeguard's SOC 2 Type II audit is in progress. Compliance status and restricted reports are available through Safeguard's Trust Center by request.

Can I use my own LLM in an air-gapped deployment?

Only a model you host inside the perimeter. Safeguard's own models run there as quantized builds, and Zero AI needs no model at all. Hosted closed models run only on their providers' infrastructure, so they cannot be reached from an isolated network.

How does an air-gapped deployment get vulnerability updates?

Through signed snapshot bundles containing vulnerability feed deltas, policy templates, model updates and platform releases. They cross the gap by one-way diode, removable media, a short DMZ sync window or a pull replica, on a cadence you set from hourly to quarterly. A Receiver in the DMZ verifies the signatures before anything reaches the control plane.

Why supply chain hygiene still matters wherever you deploy

Choosing where Safeguard runs decides where your scan data lives; it does not change the fact that the applications you build pull many open source components that each need patching. Whether the platform sits in Frankfurt, in your datacenter or behind a diode, the same fix workflow applies to the dependencies and images you ship.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The local runner demo shows the route that keeps source code on your machine. You set up the runner on your own computer, approve it with its device code, then scan from the terminal. It is the same flow a regulated team uses in a proof of concept to show its reviewers that only results go back.

Click through it at your own pace, or open it full screen.

The CLI demo is a real session in which the assistant fixes a vulnerable dependency inside the repository on your machine. You ask it to fix the lodash CVE; it reads the finding and the advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. That is the workflow that lets a team fix code it has not pushed yet, without sending the code anywhere.

Click through it at your own pace, or open it full screen.

The Claude demo shows how to connect Claude to the Safeguard MCP server with OAuth and choose which tools Claude can use. It belongs in a data path review for a different reason: when you connect an outside assistant, what the tools return goes to that assistant's provider under your agreement with them, so choosing tools deliberately is part of deciding what leaves.

Click through it at your own pace, or open it full screen.

To try the runner yourself, get the CLI from safeguard.sh/download and follow the CLI docs.

Quick check

Sources

• Safeguard docs: Air-Gapped Deployment
• Safeguard docs: Local Runner
• Safeguard docs: AI Models (Griffin, Eagle, Lion)
• Safeguard docs: Bring your own model (API Platform console; platform model setup section)
• Safeguard docs: Deployment options (API Platform console; platform deployment rows)
• Safeguard docs: Regions and data residency (API Platform console)
• Safeguard docs: Security and compliance (API Platform console)
• Safeguard docs: Privacy and data (API Platform console)
• Safeguard docs: CLI
• FedRAMP
• eCFR: 48 CFR 252.204-7012, Safeguarding Covered Defense Information and Cyber Incident Reporting
• eCFR: 32 CFR 170.14, CMMC Model
• eCFR: 22 CFR 120.54, Activities that are not exports
• NIST SP 800-207, Zero Trust Architecture
• NIST SP 800-171 Revision 3
• AICPA: SOC 2
• European Commission: International dimension of data protection

Last reviewed: 27 October 2026. Deployment and certification status change over time; check the linked documentation for the latest.