Govern every LLM call with Safeguard AI Gateway

Safeguard AI Gateway is a runtime guardrail layer that sits between your application and the model provider. It evaluates every prompt, response and tool call for direct and indirect prompt injection, jailbreak patterns and sensitive data moving in either direction, runs in monitor mode by default, fails open so your app keeps working, and records each decision as an audited guardrail event.

One thing to know before you plan a rollout. Monitor mode is the default: it evaluates traffic and emits guardrail events. Enforce mode, which redacts or blocks, is turned on per tenant by an admin. Everything below about blocking and redacting describes enforce mode as documented, and you should confirm with Safeguard what it covers for your tenant before you plan around it.

This post is for the CISO, AI platform owner and ML engineering lead shipping LLM features, and the privacy or GRC lead who must show that controls on prompts and responses exist and ran. It covers placement, checks, fail-safe design, logging, the policy file, the surrounding Safeguard capabilities and a 30 day rollout.

Key takeaways

• What it is: a runtime enforcement point for the AI in your applications, the docs' analog of the Package Firewall for prompts, responses and tool calls. It runs as an inline proxy or a thin SDK shim around your LLM client.
• Two modes: Monitor (the default everywhere) evaluates every interaction, records an event and passes traffic unchanged. Enforce redacts or blocks per your policy and is turned on per tenant by an admin.
• Checks by direction: prompt side, direct and indirect injection, jailbreak patterns and sensitive data. Response side, PII egress, toxicity and hallucination monitoring, and output schema. Both, rate and abuse limits.
• Safe-fail: fail-open with an alert, a 150 ms default evaluation budget, and bounded inspection. Fail-closed is an explicit tenant opt-in.
• Evidence: one tenant-scoped, audited event per decision. Raw prompt and response text is never persisted.
• Limits: no CLI command yet, decisions are events rather than findings, and no published detection rates.
• The wider stack: AI-BOM (what to protect), AI-SPM (model files), MCP Guardrail and agent identity (tool traffic and who holds access), Red Team (do the guardrails hold).

What problem does an LLM gateway solve?

Most LLM features start the same way. The application builds a prompt from a system instruction, the user's message and some retrieved context, sends it to a provider, and acts on the answer. Controls, if any, live inside that application: a regex, a moderation call, a system prompt asking the model to behave.

That works for one feature. With ten features in five services from four teams, three questions get hard:

1. Is every model call covered by the same controls, or does each team implement its own subset?
2. Can we change a control once and have it apply everywhere, without a release in every service?
3. Can we prove what happened, with a record that does not itself become a store of sensitive text?

The OWASP Top 10 for LLM Applications (2025 edition) names the risks a gateway is positioned against. LLM01 Prompt Injection covers user prompts that alter the model's behaviour or output in unintended ways, including injected content that is invisible to humans as long as the model parses it. LLM02 Sensitive Information Disclosure covers personal data, financial details, health records and confidential business data exposed through model output. LLM05 Improper Output Handling covers model output passed downstream without validation. LLM10 Unbounded Consumption covers excessive and uncontrolled inference, including what OWASP calls denial of wallet.

OWASP is also direct about the limit: "it is unclear if there are fool-proof methods of prevention" for prompt injection. Its mitigations are layered: constrain model behaviour, validate output formats, filter input and output, enforce least privilege, require human approval for high-risk actions, segregate external content, and test adversarially. A gateway gives you one consistent place for several of those layers (filtering, output validation, rate limits, logging) across every service. It does not replace least privilege or human approval in the application.

For background on the category, see what an AI agent gateway is.

Where the gateway sits in the request path

According to the docs, the gateway runs "as an inline proxy (or a thin SDK shim around your LLM client) between your app and the model provider." The shape is simple:

Your application or agent
        |
        v
Safeguard AI Gateway   (evaluate prompt-side checks, record event)
        |
        v
Model provider upstream
        |
        v
Safeguard AI Gateway   (evaluate response-side checks, record event)
        |
        v
Your application or agent

The provider is part of the per-tenant policy. The representative configuration in the docs names the provider and its upstream URL, so the gateway knows where to forward traffic it has evaluated. Tool calls are part of the same interaction: the docs describe the gateway as evaluating "prompts, responses, and tool calls," and the indirect injection check explicitly scans retrieved or tool-supplied content, not just the human's turn.

Two consequences follow. It sees what the model sees: the gateway inspects the assembled prompt, including the retrieved documents and tool outputs where indirect injection hides, which a control on the user's text box never sees. It is on the critical path: anything inline can add latency or fail, which is why the safe-fail design below matters as much as the checks. A guardrail that takes your AI feature down gets switched off, and then it protects nothing.

Monitor mode and enforce mode

The gateway runs in one of two modes. Here is how the docs define them, side by side.

The docs call monitor mode "the safe way to baseline what enforcement would do before turning it on." Each event records the gateway's verdict while traffic flows unchanged, so a week of events answers concrete questions before anything is blocked: which prompts would the injection check have stopped, and are they attacks or users pasting unusual text? Which responses would have been redacted, and would they still be useful? How much latency does evaluation add per route? For the longer argument, see monitor before you block with Safeguard AI Gateway.

Plan monitor first, then enforce

You can run the gateway in monitor mode with full evaluation and guardrail events, and you can write a policy whose checks say block or redact (the documented default policy does). Those verdicts act on live traffic once an admin turns on enforce mode for your tenant. The first month of any LLM guardrail rollout should be monitor mode anyway, because you cannot tune what you have not measured.

What the gateway checks on each direction

Each interaction is checked along the direction it flows. This table reproduces the documented checks and their default verdicts.

A verdict of block, redact or throttle changes traffic only in enforce mode. In monitor mode the check is evaluated and recorded on the event, and the traffic passes through. Here is each check: what it is for, what the docs say, and what it cannot do alone.

Direct prompt injection

This is the case most people picture: a user types something that tries to override the system instructions. OWASP describes input that "directly alters the behavior of the model in unintended or unexpected ways," intentional or accidental. The docs describe the gateway's check as "pattern plus classifier detection." Patterns catch known phrasings cheaply; a classifier generalises to phrasings no pattern lists. Neither is perfect and no detection rates are published, so use the monitor period to see what the check flags on your traffic and how often legitimate prompts trip it.

Pair it with least privilege. If a successful injection could make your support bot send email or query a customer table, the real fix is that the bot cannot do those things without a separate authorisation step. The gateway reduces how often a hostile prompt reaches the model; least privilege limits the damage when one gets through.

Indirect injection from RAG and tool output

Indirect injection catches teams out. OWASP defines it as an LLM accepting input from external sources, such as websites or files, whose content alters the model's behaviour. NIST AI 600-1, the Generative AI Profile, describes adversaries "injecting prompts into data likely to be retrieved," with no direct interface to the system needed. In practice that is any text your application did not write and the user did not type: a knowledge base article, a customer email being summarised, a fetched web page, a tool result, a database row.

The docs say the gateway's indirect injection check "scans retrieved or tool-supplied content, not just the user's turn," because "retrieved content (RAG results, tool output) is untrusted." This is the strongest argument for guardrails at a gateway: the UI never sees the retrieved chunks, but the gateway sees the assembled prompt. Pair it with OWASP's advice to "separate and clearly denote untrusted content," and with the OWASP cheat sheet's warning not to treat text labels or prompt wording as an enforcement boundary.

Jailbreak patterns

OWASP treats jailbreaking as "a form of prompt injection" that makes the model disregard its safety protocols entirely. The gateway keeps it as a separate check with the same default verdict as injection. The separation is useful because the response you want can differ: block on a public chatbot, monitor on an internal tool your red team uses. Each check is set independently in the policy.

PII in the prompt

This check defaults to redact. Redaction is driven by the policy's redact block, which names patterns (email and ssn among those in the docs' example) and a replacement string ([REDACTED]). In enforce mode, prompt text matching those patterns is replaced before it reaches the provider, so the provider never receives it, which addresses OWASP LLM02's point that users may unintentionally share sensitive data.

Two honest notes. This is pattern redaction of strings that match the patterns you configure on the gateway path. It does not replace keeping personal data out of prompts in the first place. And redaction on live traffic is part of enforce mode, so in monitor mode the event records a match while the prompt goes out as written. Keep routes that must never send such data off production traffic until you have confirmed enforce mode for your tenant.

PII egress in responses

On the response path the gateway checks for personal data leaving in the model's output, again defaulting to redact. This catches a different failure: the model repeating personal data from retrieved context, a tool result or earlier turns to a user who should not see it. The policy key is pii_egress, so you can, for example, redact personal data on a customer-facing route while monitoring it on an analyst route where the analyst is entitled to it. OWASP's LLM02 mitigations start with access controls on data sources; egress redaction is the backstop for what retrieval permissions miss.

Toxicity and hallucination monitoring

Both default to monitor, deliberately. They are judgment calls with real false positive costs, and blocking a correct answer because a detector was unsure is a product failure. NIST AI 600-1 calls hallucination confabulation, "the production of confidently stated but erroneous or false content," and OWASP covers it as LLM09 Misinformation. Grounding, citations and human review are the real controls; the gateway shows which routes produce flagged responses.

Output format and schema enforcement

When your application expects structured output, the gateway checks the response against that expectation and defaults to block on violation. This maps to OWASP LLM05 Improper Output Handling, whose examples include model output passed into a shell, a SQL query, HTML or a file path without validation. A schema check catches malformed output before your code parses it. Parameterised queries and output encoding still belong in the application.

Rate and abuse limits

The last check applies in both directions, defaulting to throttle. The representative policy sets a per-tenant requests-per-minute ceiling and a burst allowance. This is the answer to OWASP LLM10 Unbounded Consumption, which covers input floods, denial of wallet, context window overflow and model extraction through high-volume querying. One ceiling at the gateway applies to every service behind it, so one runaway agent loop cannot spend the month's model budget in an afternoon.

Safe-fail by design: why the gateway fails open

The docs state the principle plainly: "a failure in the gateway is never a failure of your application." Three mechanisms implement it.

Why fail-open is the right default for most teams

If a guardrail's failure mode is "the customer-facing assistant returns errors," the business will see the guardrail as the bigger risk and route around it. Fail-open with an alert keeps the feature up and tells you exactly which window of traffic went through unevaluated. That is the trade that keeps the gateway in the path long enough to be useful, and during monitor mode it costs nothing beyond a gap in events.

When fail-closed is worth it

Fail-closed fits the narrow set of routes where an unevaluated request is worse than no request: a route sending regulated personal data to a model, where an unredacted prompt would be a reportable disclosure; an agent that can move money or change production, where a human can retry later; a small internal tool where an outage is an inconvenience. Because fail-closed is a tenant opt-in in the documented policy rather than a per-route switch, discuss with Safeguard how to structure tenants so the rest of your traffic keeps the fail-open default.

The docs do not spell out how the evaluation budget interacts with fail_mode: closed: the budget text says over-budget traffic passes through with an alert. Confirm the combined behaviour with Safeguard before relying on fail-closed for a latency-sensitive route.

Reasoning about the budget and truncation

Whether 150 ms is generous depends on the route. For a chat assistant that streams an answer over several seconds, it is a small share of the total; for an autocomplete or classification call on a hot path, it may be large. Each event carries its latency overhead, so compare it with your route's end-to-end latency from your own telemetry and change eval_budget_ms where needed. A lower budget means more pass-through alerts under load; a higher one means more added latency in the worst case.

Watch the truncation flag too. Routes that send whole documents or long agent transcripts will have content that is only partly scanned. A truncation flag on a route that normally sends short prompts is a signal in itself, since OWASP LLM10 lists input floods and context window overflow as abuse patterns.

Walkthrough: the per-tenant policy, line by line

The gateway is configured per tenant. Here is the representative policy from the docs, abridged: the provider values are placeholders and the rate values are left for you to set.

aigateway:
  mode: monitor                 # monitor | enforce
  fail_mode: open               # open (never break the app) | closed
  eval_budget_ms: 150           # per-request eval cap; over budget -> pass through + alert
  provider: { name: <your-provider>, upstream: "<provider-url>" }
  checks:
    injection: block
    indirect_injection: block
    pii_egress: redact
    jailbreak: block
    toxicity: monitor
    hallucination: monitor
  rate: { rpm_per_tenant: <ceiling>, burst: <allowance> }
  redact: { patterns: [email, ssn], replacement: "[REDACTED]" }

The docs summarise the default policy as "monitor mode, fail-open, with injection/jailbreak set to block and PII egress set to redact." Here is what each line means for you.

1. mode. In monitor, every check is evaluated and recorded and traffic passes unchanged whatever the verdicts say. enforce makes the verdicts take effect; an admin turns it on per tenant.
2. fail_mode. open lets traffic through with an alert when the gateway errors or times out; closed is the explicit opt-in.
3. eval_budget_ms. The per-request evaluation cap; over budget, traffic passes through with an alert.
4. provider. The provider's name and upstream URL, where evaluated traffic is forwarded.
5. checks. One key per check, each with its own verdict, so a single check can stay on monitor while you tune it even after the tenant is in enforce mode.
6. rate. A per-tenant requests-per-minute ceiling and burst allowance. Size yours from monitor data and your provider's limits.
7. redact. The named redaction patterns and the replacement string the model or user sees instead of the matched text.

The docs also say plainly: "There is no CLI command for running the gateway yet." The policy is per-tenant configuration, not something you run from a terminal.

A staged set of policies

The documented keys are enough to express a sensible rollout as three versions of the same file. These use only the keys shown above.

Stage 1, baseline. Leave the default as it is. Every check is evaluated and recorded; nothing changes traffic because the mode is monitor.

Stage 2, enforce on injection only. Once you have confirmed enforce mode for your tenant and your monitor data shows the injection checks flag what you expect, switch the mode and set the checks you are still tuning to monitor (a value the docs show for other checks; confirm each key accepts it):

aigateway:
  mode: enforce
  fail_mode: open
  eval_budget_ms: 150
  provider: { name: <your-provider>, upstream: "<provider-url>" }
  checks:
    injection: block
    indirect_injection: block
    jailbreak: block
    pii_egress: monitor
    toxicity: monitor
    hallucination: monitor
  rate: { rpm_per_tenant: <ceiling>, burst: <allowance> }
  redact: { patterns: [email, ssn], replacement: "[REDACTED]" }

Stage 3, redact egress. After a period with injection enforced and your egress events reviewed, set pii_egress back to redact, which brings you to the documented default policy with the mode set to enforce.

The order matters. Injection blocking produces a clear user-facing result (a refused request) that is easy to explain and easy to tune. Egress redaction changes the content of answers, which can break downstream parsing or make answers less useful, so it deserves its own review step.

What gets logged, and what never does

Privacy and GRC leads care most about this part, and the docs are specific.

One event per decision. Gateway decisions are "high-volume runtime telemetry," so they are recorded as guardrail events rather than standard findings. Each event carries:

Tenant-scoped and audited. Guardrail events belong to your tenant and are audited.

Raw text is never persisted. The docs say "Raw prompt and response text is never persisted," and that events carry redacted metadata only. This is what makes the gateway usable for regulated data: a log of every prompt would itself become the largest store of sensitive conversational data in the company.

Static AI issues are findings, not events. Runtime decisions are events, while "static AI issues (model scans, agent/MCP analysis) still flow into the unified findings model as AI-security findings." Your AppSec queue does not fill with a finding per flagged prompt.

A contrast worth knowing: Guard's audit trail for MCP tool traffic

If you also route agent tool traffic through MCP Guardrail (Guard, covered below), its audit design differs. The Guard audit docs list input_params and output_result columns carrying request parameters and the tool's response as JSON, after any output filters your policy applies, with 90 days as the default retention on a self-hosted Guard Proxy. The gateway keeps redacted metadata; Guard keeps filtered payloads. Describe both correctly in your data map, and use Guard's PII masking filter where tool responses carry personal data.

How the gateway fits with AI-BOM, AI-SPM, MCP Guardrail and Red Team

The gateway answers one question: is this prompt, response or tool call acceptable right now? Other Safeguard capabilities answer the questions around it.

AI-BOM: know what to protect first

You cannot route an integration you do not know exists. AI-BOM discovery inventories AI assets across three surfaces, per its docs: in code, imports of AI SDKs (openai, anthropic, langchain, transformers, llama_index), model weight files, prompt templates, notebooks and MCP server configuration; in cloud, managed inference endpoints through your cloud connectors; in SaaS, connected but unsanctioned AI tools through shadow-AI detection. That inventory is your gateway coverage list. It is part of the AI-SPM engine. See also discovering shadow AI models in production.

A separate capability, AI agent discovery, covers AI coding agents on your people's computers through the Safeguard CLI and Desktop app: which agents are installed, what each may do, which MCP servers and models they use. It is switched on per organisation by Safeguard, then by your administrator, then by each person (safeguard aidr collect on).

AI-SPM: the model files your apps load

The gateway watches traffic to a model; AI-SPM looks at the model artifacts your applications load. Its docs describe static analysis of files in formats including pickle, PyTorch archives, safetensors, GGUF and ONNX without loading them, with findings mapped to CWEs such as CWE-502 and flowing into the unified findings model. If you self-host open weight models, AI-SPM covers the artifact and the gateway covers the conversation. See AI-SPM, the AI Gateway and AI-BOM together.

MCP Guardrail: governing agent tool traffic

Agents also call tools, increasingly over the Model Context Protocol. Safeguard's MCP Guardrail, documented as Guard, enforces policy on those calls. You point your agent's MCP client at a Guard proxy URL instead of the upstream server, and Guard evaluates every JSON-RPC call against your live Safeguard policy before forwarding allowed ones; blocked requests never reach the upstream server.

Guard rules are authored in your workspace, match on method, tool name (glob wildcards) and agent ID, and resolve to allow, deny or monitor in priority order, first match wins. With no match, Guard falls back to monitor. Rules can carry input filters such as block_pattern, max_length and jailbreak_check, and output filters such as pii_mask, column_redact and row_limit.

The two products cover different traffic with the same observe-first philosophy. An agent that reads an injected instruction in a retrieved document and then tries a tool call to act on it meets the gateway's indirect injection check on the way in and Guard's tool policy on the way out. See how MCP Guardrail works and what to ask an MCP guardrail vendor. The MCP specification's security best practices are worth reading alongside: they call token passthrough an anti-pattern that leads to a "confused deputy" problem, which correct token audience validation fixes, not a guardrail.

Agent identity: which agent holds what access

Guard keeps agents as first-class records. A registered agent carries a status (active, blocked or quarantined), a risk score and anomaly score maintained by Guard, request counters and a last-seen time. A proxy URL can be bound to one agent so every call through it is attributed to that agent for policy, scoring and audit. If one agent misbehaves, you block or quarantine it without touching the rest. More in MCP Guardrail and agent identity.

Red Team: prove the guardrails hold

The gateway docs point to Red Team for "validating that your AI guardrails actually hold." Its docs describe a harness that probes AI guardrails, such as prompt injection and jailbreak resistance, "with benign test cases to confirm the guardrails hold," under signed rules of engagement, against verified in-scope targets, with a global kill-switch. This is OWASP's seventh prompt injection mitigation, adversarial testing, made routine: run it after every policy change.

Mapping the gateway to OWASP, NIST and the EU AI Act

Buyers and auditors increasingly ask how a control maps to a recognised framework. Here is an honest mapping, with what the gateway covers and what still belongs elsewhere.

OWASP Top 10 for LLM Applications 2025

NIST AI RMF and the Generative AI Profile

The NIST AI Risk Management Framework (AI RMF 1.0, NIST AI 100-1, released 26 January 2023) is voluntary. Its core has four functions: GOVERN, MAP, MEASURE and MANAGE. Two subcategories line up closely with what a gateway produces. MEASURE 2.7 says AI system security and resilience are evaluated and documented. MANAGE 4.1 says post-deployment AI system monitoring plans are implemented. Monitor mode events, and the latency and verdict data in them, can support the monitoring MANAGE 4.1 describes, and Red Team results against the guardrails can support the evaluation MEASURE 2.7 asks for.

NIST AI 600-1, the Generative AI Profile released 26 July 2024, lists risks that are unique to or worsened by generative AI. Three are directly relevant: Confabulation (which the hallucination monitor watches), Data Privacy (which the redaction checks address in enforce mode) and Information Security (which includes prompt injection, described in the profile in both direct and indirect forms).

EU AI Act

This is general information, not legal advice, and whether these obligations apply to you depends on how your system is classified under the Act. Two articles of Regulation (EU) 2024/1689 are often raised in gateway conversations. Article 12 says high-risk AI systems "shall technically allow for the automatic recording of events (logs) over the lifetime of the system." Article 15 says high-risk AI systems shall be resilient against attempts by unauthorised third parties to alter their use, outputs or performance by exploiting system vulnerabilities, with technical solutions that include, where appropriate, measures against inputs designed to cause the model to make a mistake.

A gateway's guardrail events are one input to an Article 12 logging design, and its injection checks are one input to Article 15 resilience. Neither is the whole answer; your counsel decides what your system needs.

CISA and the UK NCSC guidelines

The joint Guidelines for Secure AI System Development (UK NCSC and CISA, 26 November 2023) cover four areas: secure design, development, deployment, and operation and maintenance. The last explicitly includes logging and monitoring, which monitor mode supports.

How do we prove the controls ran?

This is the GRC lead's question, and it is a fair one. A control that exists on a diagram but leaves no trace is hard to defend in an audit. Here is how to build an evidence trail from what the docs describe.

1. Coverage. From the AI-BOM inventory, list every service with an AI SDK import and every managed endpoint, and record which route through the gateway. The gap should shrink month over month.
2. Configuration. Keep dated versions of the per-tenant policy in change management, with approver and reason. Mode, fail mode, budget and each verdict are what an auditor asks about.
3. Operation. Guardrail events show evaluation happened on live traffic, and their mode field shows whether enforcement was on. Pass-through alerts show where it was not, which an honest evidence trail should include.
4. Effectiveness. Keep Red Team guardrail validation results with each policy version.
5. Privacy. Record in your DPIA that raw prompt and response text is never persisted, and record Guard's different payload retention if you use it for tool traffic.

A 30 day rollout plan

This plan assumes one AI platform team, a handful of LLM-backed services and a GRC lead who needs evidence by the end. Adjust the pace to your size.

Afterwards, add services in waves, switch egress to redact after its review, and keep Red Team validation scheduled. If you have not confirmed enforce mode for your tenant by week 4, stay in monitor and widen coverage; coverage and evidence are worth having on their own.

Honest limits

• Monitor is the default; enforce is per tenant. Redact and block apply in enforce mode, which an admin turns on for the tenant.
• No CLI command, and events rather than findings. Plan how your team reviews events, for example a weekly review of high-verdict categories.
• No published detection rates. Measure on your own traffic.
• Fail-open and truncation leave gaps by design. Pass-through alerts and truncation flags mark them; review both.
• No filter is complete. The OWASP cheat sheet notes a guardrail model "is itself an LLM and is itself susceptible to prompt injection." Least privilege, human approval and output handling in the app remain essential.

Common mistakes

Going straight to enforce. Blocking before you have a baseline means your first signal about false positives comes from angry users. Run monitor mode on real traffic first. The docs make it the default for this reason.

Only checking the user's message. Indirect injection arrives in retrieved documents and tool output. If your control lives in the chat UI, it never sees those. Put the check where the assembled prompt is visible.

Treating redaction as a data protection programme. Pattern redaction on the gateway path catches strings that match configured patterns. It does not decide who may see what. Fix retrieval permissions first; use egress redaction as the backstop.

Assuming monitor mode redacts. It does not. In monitor mode a match is recorded and the text goes through unchanged. Keep routes that must never send certain data unredacted off production traffic until you have confirmed enforce mode for your tenant.

Fail-closed everywhere, or alerts nobody reads. Fail-closed turns every gateway hiccup into an outage, so reserve it for the few routes that need it. Fail-open is safe only if someone reads the pass-through alerts; route them to your AI feature's on-call channel.

Forgetting the tool layer. A gateway on model traffic does not decide whether an agent may call a tool. Pair it with tool-level policy (MCP Guardrail) and narrow tool permissions.

Logging prompts in the application "for debugging". The gateway is designed not to persist raw text. If your app logs every prompt anyway, you have rebuilt the sensitive data store the gateway avoided. Review application logging during the rollout.

FAQ

What is an LLM firewall?

An LLM firewall, or AI gateway, is a control point between an application and a model provider that inspects prompts, responses and tool calls against a policy. Safeguard's version evaluates direct and indirect prompt injection, jailbreak patterns, PII in both directions, output schema, toxicity and hallucination signals, and rate limits, then records an event per decision.

Does Safeguard AI Gateway block prompt injection?

In enforce mode, the documented behaviour is to block injection and jailbreak attempts per your policy. An admin turns enforce mode on per tenant. Monitor mode, the default, evaluates and records each interaction and lets traffic through.

What is the difference between monitor mode and enforce mode?

Monitor evaluates every prompt, response and tool call, records a guardrail event and passes traffic unchanged. Enforce acts on the verdict, redacting sensitive data or blocking injection and jailbreak attempts according to your per-tenant policy. Monitor is the default everywhere.

What happens if the gateway fails or times out?

By default it fails open: on any gateway error or timeout, traffic is allowed through and an alert is raised. Requests that exceed the evaluation budget (150 ms by default) or arrive under backpressure also pass through with an alert. Fail-closed is available only if a tenant explicitly opts in.

Does the gateway store our prompts and responses?

No. The docs say raw prompt and response text is never persisted, and guardrail events carry redacted metadata only: direction, verdict, category, model name, rule, mode and latency overhead. Events are tenant-scoped and audited.

How does the gateway handle indirect prompt injection from RAG?

Its indirect injection check scans retrieved or tool-supplied content, not only the user's turn, because the docs treat retrieved content such as RAG results and tool output as untrusted. Pair it with clear separation of untrusted content in your prompt templates and narrow tool permissions.

How is the AI Gateway different from MCP Guardrail?

The gateway governs the conversation between your app and a model: prompts, responses and tool calls in that interaction. MCP Guardrail (Guard) sits in front of MCP servers and decides whether a specific agent may make a specific tool call, with allow, deny or monitor rules, input and output filters, agent identity and an audit trail.

How should we roll it out without breaking production?

Inventory first with AI-BOM, run the default monitor policy on two pilot services, tune for a week using the events and Red Team validation, then enforce on injection once you have confirmed enforce mode for your tenant, and add egress redaction after its own review.

Fix the software around your AI features too

An AI feature is still software. The service that calls the gateway is built from open source packages, its retrieval layer runs on libraries and containers, and the agent frameworks your team uses ship their own dependency trees, so a vulnerable component there can undo a well-tuned guardrail.

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

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. 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

These demos show Safeguard's agent-facing surfaces rather than the gateway itself, which is configured per tenant and has no CLI command yet. Each one shows a control pattern this post recommends for AI features.

The first demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. It is the same principle as gateway and Guard policy: an assistant should see only the tools its role needs, and an administrator decides which.

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

The second demo is a real Safeguard CLI session. The assistant reads a finding and its advisory, asks before any command that changes something, edits a dependency version, runs the install and tests with approval and pushes nothing. That is OWASP's human approval for high-risk actions, applied to an AI agent working on your code.

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

The third demo is a real Android session: you send work to a computer running the CLI and approve the command on the phone with Allow once, Allow for turn or Deny. It shows how an approval step for agent actions can stay with a person even when they are away from their desk.

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

To try Safeguard yourself, download the apps or start with the CLI documentation.

Quick check

Sources

• Safeguard docs: AI Gateway (LLM Firewall)
• Safeguard docs: AI-BOM Discovery
• Safeguard docs: AI Security Posture Management (AI-SPM)
• Safeguard docs: AI agent discovery
• Safeguard docs: Guardrails and Enforcement
• Safeguard docs: MCP Integrations
• Safeguard docs: MCP tool availability and gating
• Safeguard docs: Guard Policies
• Safeguard docs: Guard Proxy Deployment
• Safeguard docs: Servers and Agents
• Safeguard docs: Audit Trail and Alerts
• Safeguard docs: Red Team (Defensive Adversary Emulation)
• Safeguard docs: Unified Findings
• OWASP Gen AI Security Project: Top 10 for LLM Applications 2025
• OWASP: LLM01:2025 Prompt Injection
• OWASP: LLM02:2025 Sensitive Information Disclosure
• OWASP: LLM05:2025 Improper Output Handling
• OWASP: LLM06:2025 Excessive Agency
• OWASP: LLM09:2025 Misinformation
• OWASP: LLM10:2025 Unbounded Consumption
• OWASP Cheat Sheet Series: LLM Prompt Injection Prevention
• NIST: AI Risk Management Framework
• NIST AI 100-1: Artificial Intelligence Risk Management Framework (AI RMF 1.0)
• NIST AI 600-1: Generative Artificial Intelligence Profile
• EU AI Act, Article 12: Record-Keeping
• EU AI Act, Article 15: Accuracy, Robustness and Cybersecurity
• CISA: CISA and UK NCSC unveil joint guidelines for secure AI system development
• UK NCSC: Guidelines for secure AI system development
• Model Context Protocol: Security Best Practices

Last reviewed: 26 October 2026.