Every AI gateway routes. Gate decides, and proves what it decided.

When to use something else

Each position is the better choice for somebody. The cases below are the ones where it beats Gate, each argued in its own post.

A marketplaceOpenRouter, Requesty, Vercel AI Gateway

A developer with nobody asking. One person, one project, the model changes weekly, and a marketplace that does not store prompts by default beats most teams' own logging.

A proxyLiteLLM, Portkey, Helicone

Five people and three providers. Run LiteLLM, and keep it upgraded, because that is where the list of known fields lives.

The API gateway you runKong, Apigee, Tyk, Traefik, Envoy AI Gateway, kgateway, agentgateway

Keep the one you run. Keys, quotas and a model allowlist are answered by its own AI plugin, on the routes it already owns.

The cloud's ownBedrock Guardrails, Azure API Management, Model Armor

A single-cloud shop whose verifier reads the account's logs from inside the account. Everything it covers, it covers for that one cloud.

A detectorPresidio, Lakera, Prisma AIRS, Guardrails AI, NeMo Guardrails

Any content the process on the path cannot recognise on its own: injection, jailbreaks, toxicity. Buy the detector, then decide separately what holds the connection.

A governance platform's SDKCredo AI, Holistic AI, watsonx.governance, OneTrust

One application, one supported language, no agents talking to tools directly. It stops working at the first service that does not embed it.

Questions to ask any of them

Each asks about a position, never about one vendor's product, so the answers keep for longer than a feature table does. Four are about what happens while the call is open, three about what is left afterwards, and one about who can undo either: eight in all. A record makes prevention checkable and is no substitute for it, which is the order they are in.

Under each question is what a weak answer tells you, and beside it is Gate's. No other product is named here for an absence. Ask, and read what comes back.

While the call is open

1. Can it refuse the call, or only report on it?A product that reports was never holding the connection, so the request had already gone.GateIt refuses. One process holds the connection while the rule runs, so a denied request never reaches the provider, and the caller gets a bounded reason at once. Nobody has to read an alert later.
2. Does it read the arguments, or only the route?A route says which model. It does not say what the tool is about to do.Gateargs is a policy variable at the MCP hop, beside the tool's name, so a rule can refuse a write to an issue tracker from a bare workload before the call leaves. An unguarded read of an args field is refused when the rule is written.What a rule reads at each hop
3. Does it know the person behind the agent, or only the key?A key names a workload. It cannot say whether anybody asked for this.Gateagent and user are separate principals, filled from the one token the identity provider issued, and present at every hop. A refusal can turn on whether anybody is behind the agent.Who the agent is
4. When it changes something, is it the same process that found it?Two passes means the finder and the rewriter can disagree about where a value started.GateYes. The in-process detectors return byte offsets into the text as sent, and the operator rewrites that value in place, with nothing re-serialized in between. A redaction cannot miss a field the detector found, and cannot damage one it did not.One pass, one address

Afterwards

5. If a record was altered or removed, what would show it?Nothing to show it means the record is a claim about their storage.GateEvery record is chained to the one before it on that node and signed with that node's key. kirto-gate audit verify reads a trail in any order, with anything interleaved, and reports every record that was altered, removed from the middle, moved or forged, by sequence number.Verify the audit trail
6. What does the record contain, and what does it deliberately not?Anything that keeps your prompts is a data store you now have to assess.GateThe decision, the rule that made it, the control identifiers that rule named, and how many spans a redaction rewrote. Never the prompt and never the response. Reads and admitted requests are left out on purpose, and the documentation says so.The four ways to check that claim
7. Which party, besides the store the records sit in, has to be honest for that check to hold?Every name in the answer is a party you are trusting. Count them.GateA quorum of your own cluster. A chain cannot show it was cut at the end, so each node offers its signed head to the cluster about once a minute, and kirto-gate audit verify -heads reports a trail that stops short of a witnessed head. Raft holds the heads and never the records; the records go to your collector, in your account. A cluster of one witnesses itself, and there the collector is the witness.What a cluster survives

Whoever runs it

8. Who can turn it off, and would you know?Anyone who can edit the rule is part of the control. Ask how many that is, and what records them doing it.GateTwo answers, because there are two planes. A team cannot loosen a deployment-wide access rule: its own profile narrows the rule or leaves it alone. Changing the rule through the admin API is decided by a Cedar policy that denies by default and names roles your identity provider assigns. The write is a config.source.write record, naming the caller, in the same signed trail as the decisions the rule goes on to make. Whoever can edit the configuration file on the host holds more than any role, and the threat model lists that as a limit.Evidence

Two limits belong beside the answers about the record. A key used by somebody other than the node is not something a trail can show. It proves what the key signed, and keeping the key where only the node reaches it is the deployment's job. Reads and admitted requests are absent from the trail on purpose, because the record is bounded.