Runtime governance for AI agents

What CI/CD did for code, Gate does for agent writes.

Most companies keep AI agents in read-only mode. They're right to be cautious. Gate is the deterministic control plane between every agent decision and every production write. Policy decides what executes. Humans approve what matters. Everything is logged forever.

Try the live demo Star on GitHub
MIT licenseSelf-hostedNo LLM in the loop
Governs agents built with
LangGraph CrewAI AutoGen LangChain OpenAI Swarm Claude Code Any MCP client Custom agents
The problem

An agent just wrote to your database. Who approved it?

Was it the first run or the fifth? What policy did it follow? If you can't answer those in 30 seconds, you don't have write-path governance. Most teams are rebuilding it from scratch — badly. Gate is the infrastructure.

  • Approval logic scattered across repos
  • Inconsistent rules across teams
  • No centralized audit trail
  • No answer when something breaks
Nobody can answer these
?Which agent ran this?
?Did anyone review it?
?First run or the fifth?
?How many records changed?
?Where's the audit trail?

Everything between agent intent and production execution

Policy engine

Deterministic YAML. No LLM in the eval path.

Drop a file in your policy directory. Same input, same answer, every time. Any engineer can read it. Any compliance team can audit it.

# policies/crm-low-risk.yaml id: crm-low-risk destinations: - salesforce.import - hubspot.contacts allowed_types: [csv, json] auto_approve_under: 100 require_approval_over: 100 expiry_minutes: 60
recordCount 847
threshold 100
destination allowed
decision pending_approval
Human approval

Low risk ships. High risk waits for a human.

Reviewers see risk score, record count, sensitivity tags and destination. Approve or reject in one click — dashboard, Slack, or API.

salesforce.importpending
Sender Verified
Destination allowlist Passed
Record count 847 > 100
Risk score 72 · high
ProposedCheckedPendingExecuted
Idempotency

Retries never fire twice.

lead-workflowretry ×2
batch-2026-03-08approved
batch-2026-03-08duplicate
Signed execution

One-time tokens that expire in 15 minutes.

execution_token gex_7f3a91c2…
15:00
Replay blocked
Action ledger

Every transition, sealed forever.

proposed
policy_checked
approved
execution_requested
execution_succeeded
Live demo

Three intents. Three outcomes. Zero config.

One auto-approved, one blocked, one held for review. Run it locally in under a minute — no server setup, no API keys.

npx zehrava-gate demo
Open in browser →
npx zehrava-gate demo
Gate demo: auto-approved, blocked, and pending approval intents
Gate V3 · proxy
Phases 1–3 live

Enforcement, not cooperation.

V2 governs writes when the agent calls the SDK. V3 puts Gate in the network path: a forward proxy intercepts outbound HTTP, a TLS layer handles HTTPS. No SDK changes. No path around it.

HTTP_PROXY=http://gate:4001
POSThubspot.com/contacts200 forwarded
POSTapi.stripe.com/refunds202 pending
POSTunknown.system/payout403 blocked
Forward proxyReverse proxyCredential vault
Read V3 architecture →
Credential vault

Agents never hold production secrets.

The agent submits intent only. Gate evaluates policy, fetches the credential ephemerally, executes, then discards it from memory. A compromised agent has nothing to exfiltrate.

secret_ref op://AI-Agents/Stripe/key
held by agent never
lifetime single call
1Password V3.0 HashiCorp Vault V3.0 AWS Secrets Manager V3.0 ENV fallback V3.0 Azure Key Vault V3.1 Doppler V3.1
Run Ledger
Product 2

Broken runs resume without replaying side effects.

Execution continuity for governed agent runs. When a tracked run breaks during approval, execution, or retry, it picks up from the last safe point.

startcheckpointcrashresumedone
Explore Run Ledger →
Dashboard

One queue. Every agent. Every team.

Approvals, audit trails and run inspection in one place. Engineering can finally see Marketing's queue.

refund-agent → stripe.refundreview
enrich-bot → salesforce.importapproved
support-agent → zendesk.replyblocked
Open the dashboard →
Real incidents Gate prevents

You won't catch these until they're already in production.

These aren't edge cases. They're the first things that go wrong when agents move from read-only to write-path. Every team hits them.

Blocked

Duplicate AI calls

Agent retried a lead workflow. Webhook fired twice. The lead got two AI calls in 30 seconds.

policy idempotency_key
result duplicate_blocked
Held

Broken email template

Agent sent Hello {{customer_name}} to hundreds of contacts before anyone noticed.

policy approval_if_template_error
result held for review
Held

CRM overwrite

Enrichment agent overwrote 847 records with partial data. No rollback path. No audit trail.

policy require_approval_over: 100
result held for review
Blocked

Finance payout batch

Agent proposed a payout to an unlisted destination. Not in the allowlist. Nothing moves. The attempt is fully audited.

destination unknown.system
result blocked
Auto-approved

Routine support reply

No flagged terms, single message, below threshold. Gate approves instantly, issues the execution order, logs the outcome.

term scan clean
result approved
Blocked

Risky support reply

Same agent, different draft: "refund guaranteed." Blocked before it reached Zendesk. The audit shows why.

term scan "refund guaranteed"
result blocked
How it works

Intent in. Decision out.
Execute when authorized.

01

Agent submits intent

gate.propose() or POST /v1/intents with destination, policy and payload. Unknown agents rejected. Duplicates blocked.

02

Policy + risk scoring

Deterministic evaluation. Risk scored from destination, record count, financial value and sensitivity tags.

03

Approve, block, or hold

Low risk auto-approves. High risk enters the approval queue with full context. One click.

04

Signed execution

One-time token, 15-minute TTL. In runner_exec mode a worker in your VPC executes — credentials never leave.

05

Ledger sealed

Every state transition logged and queryable by intent ID. Not deletable. The record of everything your agents did.

SDK · TypeScript & Python

Five minutes to the first block.

That's the moment it clicks. An agent tried to write. Gate stopped it. You saw why. The surface area is intentionally small — complexity lives in the policy file.

npm install zehrava-gate
pip install zehrava-gate
Read the docs →
import { Gate } from "zehrava-gate"

const gate = new Gate({ endpoint: "https://gate.yourco.com", apiKey: "gate_sk_..." })

// 1. Submit intent — get a policy decision immediately
const p = await gate.propose({
  payload:         "./leads.csv",
  destination:     "salesforce.import",
  policy:          "crm-low-risk",
  recordCount:     847,
  idempotency_key: "batch-2026-03-08"
})
// p.status → "pending_approval" (over the 100-record threshold)

// 2. Human approves (dashboard, Slack, or API)
await gate.approve({ intentId: p.intentId })

// 3. Signed execution order (15-min TTL) → worker runs in your VPC
const order = await gate.execute({ intentId: p.intentId })

// 4. Full audit trail
const audit = await gate.verify({ intentId: p.intentId })
Built for the write path

Fast enough to sit in front of everything.

<10ms
Policy decisions, in practice
0
LLMs in the eval path
15min
Execution token TTL
One policy file. Every framework.

Framework HITL is opt-in.
Gate isn't.

LangGraph has HITL. CrewAI has callbacks. None of it is shared, none of it spans teams. Gate sits outside every framework and governs all of them the same way.

FeatureFramework built-in HITLZehrava Gate
EnforcementOpt-in. Dev forgets to add it. It doesn't run.Mandatory. Policy-driven. No bypass.
Audit logConsole logs scattered across five repos.Centralized. Immutable. Queryable by intent ID.
Cross-teamSiloed per framework.One queue. Every agent, team and framework.
IdentityThe agent is code. No verified sender.Every intent has a verified sender. Registry enforced.
ExecutionAgent writes directly. No expiry.Signed order. Worker runs in your VPC. 15-min TTL.
PolicyHardcoded per agent. Not shareable.Shared YAML. Same rules across every agent.
The category

Observability. Guardrails. LLM gateways. Nobody built write-path governance.

✓ Exists
Observability
LangSmith, AgentOps
✓ Exists
Guardrails
Guardrails AI, Lakera
✓ Exists
LLM gateway
Portkey, Helicone
■ Gate owns this
Write-path governance
The missing layer

From the Gate blog

FAQ

The hard questions. Straight answers.

Intent → evaluate → approve → execute. That's up to four API calls per write. What does this cost at scale?

For auto-approved low-risk writes: one call. POST /v1/intents returns approved immediately if the policy allows it. Evaluation is synchronous and deterministic — no LLM call, no network hop outside Gate, sub-10ms in practice.

For human-reviewed writes: yes, there's latency — that's the point. You're waiting for a human. The approve + execute calls are lightweight once the decision is made.

Self-hosted Gate runs in your own infrastructure. No external dependency, no rate limits, no per-call pricing.

runner_exec mode: the worker reports success, but Gate never verified the execution. What does "succeeded" mean?

"The worker called /v1/executions/:id/report with status: succeeded." That's it. Gate trusts the worker's report.

Gate's job is governance — deciding whether an action is allowed and logging the full lifecycle. Verifying the worker did exactly what it said is the destination system's job. Salesforce confirms the import. Stripe confirms the charge. Gate confirms the intent was authorized and executed by an authenticated worker with a valid one-time token.

Cryptographic execution proofs — the worker signs the result, Gate verifies — are on the roadmap. Today the audit trail shows who authorized what, when, and what outcome was reported.

Agent registry with allowed_destinations — that's IAM. How does this not collide with the access control you already have?

Gate's agent registry isn't replacing your IAM. It's a layer above it — governing intent, not credentials.

Your IAM controls whether the service account can call Salesforce. Gate controls whether the agent is allowed to send this specific write given the current policy, risk score, and approval state. Two different questions. Both need answers.

In runner_exec mode, Gate never touches your credentials. The worker holds them, inside your VPC. Gate is in the decision path, not the credential path.

Gate sees every agent intent. What happens to that data?

Self-hosted — the default — means Gate runs on your infrastructure. The database, the payloads, the ledger: all on your server. We never see it. You control retention.

A PII scrubber runs on every unauthenticated read endpoint — emails, phone numbers, payload content stripped before anything goes out. Authenticated API calls get full data.

Cloud-hosted, SOC 2, encryption at rest and configurable data residency are on the roadmap — not shipped yet. If you have a hard compliance requirement today, self-host. It's a 5-minute deploy.

What's the actual insight here? Why does this company exist?

Most companies keep AI agents in read-only demo mode. They're right to. When an agent writes to production unsupervised, mistakes are expensive — wrong emails, duplicate records, refunds that shouldn't have happened. So agents stay sandboxed and roadmaps stall.

Gate changes that. Policy decides what runs. Humans approve what matters. Every action logged. Companies stop treating agents as a liability and start shipping them to the write path.

The bet is that this is infrastructure, not application logic. Every team building governance from scratch is building the same thing. Right now we're at cooperative adoption. The goal is an enforced standard.

Open source · MIT license

Let your agents write.

Gate is free to self-host, forever. Join the waitlist for managed cloud hosting, credential vault integrations, and enterprise support.

Get started free Contact us Deploy from GitHub