Safeguard
Use Case · Runtime Protection · Early access

Runtime Protection Inside Your Application.

Guard (early access) runs inside your application as middleware and hooks at the library and framework level. It checks requests, SQL queries, shell commands, file paths, outbound calls, LLM client calls and MCP tool calls against the guardrails you write in Safeguard. Rules start in Monitor mode, so you see what they would block before they block anything.

◈ the drill — the rule ran in monitor mode before anyone enforced it
In your app
Runs
Monitor
Default Mode
SQL · Exec · LLM · MCP
Checks
Early access
Availability

A Firewall Sees The Request. Guard Sees What It Does.

Scanning finds what is wrong in code, dependencies and configuration before deploy. A firewall in front of the app sees the request. Neither sees what the request turns into inside your code: the SQL query it builds, the command it runs, the file it opens, the host it calls or the prompt it sends to a model.

Guard runs inside the application, as middleware and as hooks in the libraries your code already uses, so each check is made where the risk is: at the database call, the command call, the outbound call or the LLM client call.

Guard works at the library and framework level inside your application, not in the operating system. For a service you cannot change, Guard also runs as a proxy or sidecar in front of it.

Sensitive Data Leaves Inside Requests

Secrets and personal data end up in queries, prompts, logs and outbound calls. Nobody meant to send them, and nothing in the path stops them.

Agents Act Through Tools

An AI agent's MCP tool calls are real actions. A poisoned tool description or an injected instruction becomes a real request.

Rules That Might Break Things Never Ship

A blocking rule that misfires takes a service down, so teams avoid writing one. Without a safe way to try a rule, nothing gets enforced.

No Record Of What Was Enforced

After an incident the question is which rule was in force on which service, and what it did. Without a decision log there is no answer.

What It Does

Guardrails In The Request Path.

Middleware Or Runner

One middleware line for Express, FastAPI, Django, Spring Boot, ASP.NET or Go, or Guard's runner for Node, Python and Java with no code change. A proxy or sidecar covers services you cannot change. Everything installs from registry.safeguard.sh with your organisation's pull token.

Hooks Where The Risk Is

Checks on SQL queries as they run, shell commands, file paths, outbound calls, deserialization, LLM client calls and MCP tool calls, alongside rules on the request itself.

Monitor, Then Enforce

Every guardrail starts in Monitor mode. Switching it to Enforce takes an explicit confirmation, and you can switch back at any time.

Decision Log

Each decision records the service, rule, action and time, with sensitive payloads redacted by default. Filter it and export it.

The Pipeline

From Policy To Enforced Request.

  1. 01

    Write guardrails

    Pick a template on the Policies page and test the rule against a sample request before it goes anywhere.

  2. 02

    Add Guard to your app

    Create a registry token with Guard access, add Guard's package from registry.safeguard.sh, verify it with cosign, and add the middleware line or start the app with Guard's runner.

  3. 03

    Sync

    The proxy or SDK pulls the current policy version; the app shows each service's version, mode and last check-in.

  4. 04

    Monitor

    Decisions stream to the decision log: allowed, blocked, redacted or recorded only, with where in your code it happened and never the values.

  5. 05

    Enforce

    Switch a guardrail to Enforce once you are happy with what it catches. Each change of mode is recorded.

  6. 06

    Review

    Filter decisions by service, rule, action and time, and export them for an incident review or as audit evidence.

Outcomes In Production.

Less Sensitive Data Leaving

Prompts carrying secrets blocked, secrets redacted from responses
Egress limited to the hosts you allow
Payloads redacted in the decision log by default

Safer Rollout Of Rules

Monitor mode before enforcement
A confirmation to switch to Enforce
Switch back to Monitor at any time

A Record Of Enforcement

Policy version per connected service
Every decision logged
Export for incident reviews and audits

Guard is in early access. Pair it with Safeguard's scanning and SBOMs for what you ship, and with the MCP Server for how agents reach Safeguard.

Bring One Service. We Will Connect It In Monitor Mode.

Guard is in early access. Book a call and we will connect one service with you and walk through its first decisions.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.