Secure and govern every AI call, inline.

AI security and governance for every model, MCP tool and agent: keys decide who may call what, detectors inspect each call before it leaves, and every decision is signed into a record a third party can verify.

Request a demoRead the docs
POST /v1/chat/completions200 · 41 ms
key
team-risk · prod
route
gpt-4.1 → azure-eu · passthrough
injection
pass · 0.03
personal data
rewrote 2 spans · IBAN, national ID
tool result
denied · rule no-external-email
record
#48213 · sha256:9f2c…e71a · signed
An audit-trail entry, illustrative.
kinds of personal identifier found, with nothing configured
83
of them confirmed by a checksum, not a pattern alone
51
kinds of credential found: API keys, tokens and private keys
19

Counts from Gate's PII and credential coverage references, generated from the recognizer tables.

Risks we manage

What Gate stops

Prompt injectionInstructions arriving in a user turn or inside a document a tool fetched.Personal dataCard numbers, names and identifiers rewritten before the provider sees them.Agents and toolsMCP servers and A2A agents checked at the same door as the models, and the agent run as one step of a process that replays.LanguageA profile picks the guard model your language needs, with the numbers behind it.
How it works

Keys decide, detectors inspect, the record proves

RoutingByte-for-byte passthrough, translation only when needed, every retry, failover and pool pick counted.DetectorsThe whole detection path scored at byte offsets, and any Hub checkpoint pinned to a commit.EvidenceA signed audit trail and control packs a third party can check.ReconciliationThe provider's own usage ledger checked against yours.

The order carries reasons

One request, in the order the binary handles it. The client authenticates with a virtual key, and access rules decide whether it may proceed. Request guardrails run before a provider is chosen, so the cost estimate and the upstream request both work from the redacted bytes.

The budget is reserved only after the provider has admitted the request, so a refusal above it holds nothing. The client's credential leaves the headers and the provider's goes in. Response guardrails read the stream as it arrives, and the decision is written to the record.

The architecture, step by step
A request in three bands, admit, send and deliver, with the provider beside send and deliver; steps 3 and 7, request guardrails and the credential swap, are the two that change the bytes
Access

Every model, tool and agent behind one door

Teams get keys, budgets and the models they may call. MCP servers and peer agents sit behind the same door as the models, under the same keys, rules and record.

The client change

base_url = "https://api.openai.com/v1"

base_url = "https://gate.internal/v1"

The OpenAI and Anthropic SDKs a team already uses change one line.

  • Keys with a profile. What a key may call, and how much, is set once on its profile.
  • Budgets that stop. Tokens are reserved before the request is forwarded and settled against the provider's reported usage after it.
  • Passthrough first. A request in the provider's own dialect goes through byte for byte. It is translated only when no provider speaks it, and refused when the translation would drop a capability it uses.
  • MCP at its own hop. A rule reads the server, the method, the tool and its arguments. Gate serves the approved servers as a private registry on the MCP registry v0.1 API.
  • Peer agents fronted. An A2A agent answers at Gate's address, with its card rewritten to that address and signed.
Govern your first provider
Virtual keys under their profiles, schematic.
Enforce

Found in the request, rewritten before it leaves

Card numbers, identifiers and secrets are found in the request and rewritten before the provider sees them, and turned back for the tools you trust. A refusal names its rule and says why.

  • In the stream. Requests and responses are both inspected. A streamed response is held only as far as a match could reach, so it is checked without being buffered.
  • Format-preserving. A replaced card number is still a valid card number, so the systems downstream keep working.
  • Rules in CEL. A rule reads the key, the model, the tool and what the detectors found, and denies, rewrites or annotates.
  • Slow detectors off the path. A model-backed check can run beside the stream and enforce from the next turn. A detector that did not run is named on the record.
  • Detectors measured. kirto-gate guardrails eval scores a pinned checkpoint on your own labelled data, through the same inspection a request goes through.
Redact PII from model output

What the client sent

Please cancel my card 4095260993934932, my id is 1044880134, and mail me at aarav@example.com.

pii · fpe · placeholder

What the provider received

Please cancel my card 6880989289285872, my id is <SA_NATIONAL_ID_1>, and mail me at <EMAIL_ADDRESS_1>.

The card is still sixteen digits and still passes Luhn. Only this gateway's key turns it back.

403

sa-ndmo-personal-data-abroad-needs-approval guardrail rule

personal data is processed outside the Kingdom only through a provider whose metadata declares the written approval as transfer_basis

Prove

Every decision signed where it was made

Every decision is a signed, chained record that names the rule and the control it stood for. A governance platform writes the policy it wants enforced into a source it owns, and reads the decisions back.

  • A hash chain per node. Each record is signed with ed25519 by its node, and the cluster witnesses each node's head.
  • controls on every rule. Your framework's identifiers ride onto each decision the rule makes.
  • Never the content. The record carries entity types and counts. The matched text is never written.
  • Checked offline. kirto-gate audit verify reports a record altered, removed, moved, forged or cut short, and needs no gateway and no credential.
  • 4 control packs. 27 controls cited, each with the article it was read from. A pack certifies nothing.
Connect your AI governance platform
{
  "v": 1, "node": "gw-a", "kid": "da3b27d1a322d9c0", "seq": 1182,
  "prev": "a41c…f0", "hash": "7d08…3b", "sig": "Qm9k…",
  "record": {
    "v": 1, "time": "2026-10-14T09:12:07.4Z",
    "event": "guardrail.decision",
    "outcome": "redacted",
    "actor": {"kind": "virtual_key", "name": "support-bot"},
    "rule": "cards",
    "controls": ["pci-dss:3.4", "acme:DP-02"],
    "side": "request",
    "entities": {"CREDIT_CARD": 1}
  }
}
$ kirto-gate audit verify export.jsonl
NODE  KID               ENTRIES  SEQ      ORIGIN   CLOSED  SIGNED  STATUS
gw-a  da3b27d1a322d9c0  1183     1..1183  genesis  false   true    ok
verified
A chain entry and the offline check, with shortened hashes.
Deployment

Runs where you run

Self-hosted: the control plane runs in your network. Keys, budget spend and certificates live in Gate's own raft log, so there is no Postgres or Redis to run beside it.

The front door on Kubernetes

A Helm chart, its own TLS, and replicas that form a raft cluster. Three voters survive the loss of one.

One binary on VMs

A binary, a node file and a directory for its log. Keys, budget spend and certificates live in that log.

Beside the gateway you have

The inspector on an ext_proc filter: the same detectors and policy on traffic Gate does not route.

Where Gate sits

Gate sits on the request path between your applications and the models, MCP servers and peer agents they call. It holds the connection, so a rule refuses a call instead of flagging it afterwards. A governance platform sits above the path, writing the policy and reading the decisions back. An API gateway routes and counts the same calls, and a detector classifies the text it is handed. Gate inspects, refuses and signs in one process.

Its limit is the call it does not see. An agent that reaches a provider or a tool directly is ungoverned, and Gate does not discover it.

Compare Gate with the six kinds of product on the pathThreats and limits