Stop asking the model to enforce its own limits
A policy gateway in front of your AI traffic. It sees every interaction, decides against policy you wrote, and either records what it would have done or actually does it. Roughly 100ms added at p95, streaming included.
If you arrived here without a finding that calls for it, you probably do not need this yet. That is not modesty, it is the order we recommend things in.
Most findings do not need a gateway
Three places a finding can be closed. We will tell you which one yours belongs in, and two of the three do not involve us again after the report.
Fix it in your code
A missing ownership check on an endpoint. A scope that was never validated. Most of what we find lives here, and the right answer is a pull request in your repo, not a product from us.
Fix it in your architecture
Retrieval indexes that should never have held the document. Tool wiring that gave an agent reach it did not need. Design changes, and again nothing to buy.
Cannot be fixed in either
A failure that comes from the model's own generative behaviour. You can tighten the prompt and it will hold until someone phrases the request differently. This is the one that needs enforcement outside the model, before it acts.
We have a commercial interest in you reaching row three, and you should assume we know that. It is why the published cases on this site close in the client's own code, and why the finding that justifies a gateway has to be one you can reproduce yourself.
Observe before you enforce
The same policies, the same decisions, the same logs. The only difference is whether a decision reaches your traffic. Nobody should put an enforcement layer in a production path on the strength of a demo.
Observe
Every request and response is evaluated and logged with the decision that would have been taken. Your traffic is untouched.
Use it to
- Find out what your real traffic looks like against a policy before that policy can break anything
- Tune out false positives on your own data rather than on our test cases
- Show a security committee a month of evidence instead of an argument
- Quantify the finding: how often does the thing we found actually get attempted
Enforce
The decision is applied before the model, agent or tool acts. Allow, narrow the scope, redact, or block, per policy.
Worth knowing
- Move policies to enforce one at a time. It is not a global switch you flip once
- Responses are evaluated as well as requests, so a leak on the way out is in scope
- Streaming responses are enforced inline rather than passed through
- You decide what happens if the gateway is unavailable, per policy, in either direction
What a platform owner will ask first
Product facts rather than client results. If one of these is a problem for your path, it is better to know now than after a procurement cycle.
Where it sits
Two integration paths, and neither requires rewriting how your application talks to a model.
Either
- Repoint your base URL. The gateway is provider-compatible, so your existing SDK or client keeps working and the traffic goes through us on the way past.
- Put it in front of your app. A reverse proxy at the edge, ahead of the application, with no application code change at all.
Which one you pick usually comes down to whether you want the policy boundary at the model call or at the application perimeter. We will have an opinion and it is not a strong one.
The decision log is the point, not a side effect. It is the artifact your auditor asks for and the one that tells you whether a policy is doing anything.
You own the policy. You own the operations.
This matters more than any feature on the page. We are a red team that also sells an enforcement layer, and the way that stays honest is a boundary we do not cross.
| Responsibility | Yours | Ours |
|---|---|---|
| Writing the policy | You author it and you change it, without asking us | We advise, and we will tell you when a policy is theatre |
| Running the enforcement | Your operations, your on-call, your change control | Nothing. We do not run security operations for anyone |
| Deciding what to enforce | Yours, informed by findings you can reproduce | We map each finding to the narrowest control that closes it |
| The software | Deploy it in your cloud, or consume it as SaaS | We build and maintain it, and we are accountable for it |
The same line appears on the program page under what we do not do: we hand findings to whoever runs your operations. A gateway you control does not change that. A managed service where we ran your policy would, which is why we do not offer one.
In your cloud, or in ours
Two deployment shapes. The decision is usually made for you by where your AI traffic is allowed to go.
Runs inside your perimeter
The gateway is deployed in your own private cloud. Prompts, responses and decision logs never leave your environment, and data residency is whatever your cloud account already is.
Usually the answer for regulated buyers, and the one that makes a data protection review short.
Consume it as a service
We run the gateway. You configure whether request and response bodies are retained at all, and for how long, so the retention posture is a setting rather than something you inherit from us.
Faster to stand up, and the sensible way to run an observe-mode pilot before committing infrastructure to it.
What this is not
A gateway in a traffic path attracts hopeful assumptions. Worth closing them off here rather than in month two.
| Not this | Why |
|---|---|
| A replacement for fixing the finding | Where a finding can be closed in your code, close it. A gateway that compensates for a missing authorisation check is a second place for the same bug to live |
| A model firewall that makes AI safe | It enforces policy you wrote about identity, scope and actions. It does not have an opinion about whether your model is good |
| A monitoring or SOC service | It produces decision logs. Someone on your side reads them, and that someone is not us |
| A certification or attestation | It generates the evidence an auditor asks for. We are not an auditor and neither is the gateway |
Scoped per deployment
There is no list price here, and publishing one would be a guess. Two deployments with the same traffic volume can differ by an order of magnitude in what they need enforced.
Surfaces enforced
One production assistant is not the same job as every agent and tool call across a platform.
Where it runs
Self-hosted in your cloud and SaaS are priced differently, because what we are responsible for differs.
How many findings we found
Deliberately. Enforcement is not priced against the severity of the report that led to it.
You get a number in the first conversation rather than after a discovery phase, and an observe-mode pilot is the normal way to start.
Start in observe mode
A month of decision logs against your real traffic, with nothing blocked, is the cheapest way to find out whether this is worth enforcing. Twenty minutes on a call is enough to scope it.