Kirto

The agent control plane

Observe, govern and prove every AI agent, across every vendor.

Self-hosted: the control plane runs in your network.

case 4821 · refundillustrative run

Flow runs the process

  1. Claim received
  2. Assess claim
  3. Approve refund
  4. Pay out

Gate decides each call the agent makes

  • llmgpt-4.1 → azure-eupass · rewrote 2 spans: IBAN, national ID
  • a2afraud-checkpass · key claims-agent
  • mcpmail.senddenied · rule no-external-email · control AC-4

Both leave proof

Flow case record7 entries · replays to the same chain
Gate audit trail#48213 · sha256:9f2c…e71a · signed
An illustrative run. Gate refused the call that would have mailed the claim outside, and both records can be checked without trusting the agent.
Platform

Two products, one control plane

Gate watches every agent from outside its loop. Flow runs the processes agents work inside. Both leave proof.

Works with

ModelsGate
OpenAI · Anthropic · Azure OpenAI · Amazon Bedrock · Gemini · Mistral · xAI · DeepSeek · Groq · Together · Fireworks · Cerebras · Perplexity · OpenRouter, and any OpenAI-compatible endpoint, hosted or your own
Tools and agentsGate
MCP · A2A
ProcessesFlow
BPMN · CMMN · DMN · Arazzo

How the platform fits together

Why two products

Agents fail in two places

One is the call: what goes out to a model or a tool, and what comes back. The other is the process: what the agent was doing, in what order, and on whose approval. Gate holds the first and Flow runs the second.

In the callGate

Personal data leaves in a prompt.
Gate finds 83 kinds of identifier in the request and rewrites them before the call leaves.
A tool result carries instructions from someone who is not the user.
Gate's detectors read tool results as well as the user's turn.
An agent calls a tool outside its rules.
Access rules read the server, the method and the tool from the request, and Gate refuses the call.

In the processFlow

A run crashes halfway and its state is gone.
Flow keeps the run's state as data in a replicated log and resumes from the last recorded step.
Nobody can reproduce a decision.
Flow records each branch condition with its expression and result, and replays a case against its pinned model.
An approval gets skipped.
A person's approval is a task in the process, and the run waits on it until someone completes it.
Architecture

Where Kirto runs

Gate sits on the line every agent call crosses on its way out. Flow sits beside the systems you already run, and its agents' calls cross Gate like any other caller's.

your network

Your applicationsany language, any SDK
Agents from any frameworkbuilt in-house or bought
Your BPM platformCamunda, Flowable, and the rest
Flowruns the processes agents work inside
Signed audit trailGate, to your collector
Replayable case recordFlow, kept with the case

where calls go

Model providershosted or self-hosted
MCP serverstools the agents call
Peer agentsover A2A
Self-hosted: the control plane runs in your network. Keep the BPM platform you have: Flow runs the agent's process beside it, and Gate covers the AI calls from any of them.
Proof

Check the record yourself

A record is evidence when someone outside the system that wrote it can check it. Both records come with the command that does.

Gate's audit trail

$ kirto-gate audit verify gateway.log
NODE  KID               ENTRIES  SEQ   ORIGIN   CLOSED  SIGNED  STATUS
gw-a  da3b27d1a322d9c0  7        1..7  genesis  true    true    ok
25 other lines ignored
verified

Each record is hashed, chained to the one before it on that node, and signed with ed25519. The command runs offline on the exported trail, reports any record altered, removed, moved or forged, and exits 1 when one is. It needs no gateway, no cluster and no credential.

Verify the audit trail

Flow's case record

$ kirto-flow-replay -model refund.bpmn -history case-4821.json

The command feeds the case's recorded inputs through a fresh engine on the pinned model and compares the chain it derives with the stored one. Exit 0 means they match, and 1 means they diverged. The same replay runs in the modeler and on the gateway's replay endpoint.

What a replay checks
Adoption

Start with Gate, add Flow

  1. 01

    Put Gate on the path

    Point your applications and agents at Gate in place of the provider, or run it behind the gateway you already have over ext_proc. From that call on, every request is checked and recorded.

    Govern your first provider
  2. 02

    Model the agent's process in Flow

    Write the steps around the agent in BPMN, CMMN and DMN: what it is for, which tools it may reach, and where a person approves. Its calls keep going through Gate.

    Kirto Flow
  3. 03

    Tie both to your controls

    Each rule names the controls it implements, so a refusal carries the control id into the signed record. A governance platform reads the decisions back from the trail.

    Forrester's AEGIS domains, one by one

Run it in your network

Self-hosted: the control plane runs in your network. We show Gate and Flow on a deployment shaped like yours.