Most companies keep AI agents in read-only mode. They're right to be cautious. Gate is the layer that changes that — a deterministic control plane between every agent decision and every production write. Policy decides what executes. Risk gets scored. Humans approve what matters. Everything logged forever.
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. Every company shipping agents to production will need it. Most teams are rebuilding it from scratch — badly. Gate is the infrastructure.
These aren't edge cases. They're the first three things that go wrong when agents move from read-only to write-path. Every team hits them.
Hello {{customer_name}} to hundreds of contacts before anyone noticed the unresolved variable.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 — because the policy doesn't care what built the agent.
| Feature | Framework built-in HITL | Zehrava Gate |
|---|---|---|
| Enforcement | Opt-in. Dev forgets to add it. It doesn't run. | Mandatory. Policy-driven. No bypass. |
| Audit log | Console logs scattered across 5 different repos. | Centralized. Immutable. Queryable by intent ID. |
| Cross-team | Siloed per framework. Engineering can't see Marketing's queue. | One queue. Every agent. Every team. Every framework. |
| Identity | The agent is code. No verified sender. No accountability. | Every intent has a verified sender. Agent registry enforced. |
| Execution | Agent writes directly. No expiry. No one-time enforcement. | Signed execution order. Worker runs in your VPC. 15-min token TTL. |
| Policy | Hardcoded per agent. Inconsistent. Not shareable. | Shared YAML policies. Same rules across every agent. |
Agent submits intent. Gate evaluates YAML policy in microseconds — no LLM, deterministic, same answer every time. Low risk auto-approves. High risk waits for a human. Approved writes get a signed execution token that expires in 15 minutes. Your worker runs it inside your own VPC. Ledger sealed.
Agent calls gate.propose() — or POST /v1/intents — with destination, policy, and payload. Intent is registered with a unique ID. Unknown agents are rejected. Duplicate intents (idempotency key match) are blocked.
Gate evaluates the policy deterministically — no LLM, same input always same output. Risk score calculated from destination, record count, financial value, sensitivity tags. Policy decision stored immutably.
Blocked · scored · decidedLow-risk auto-approves by policy. High-risk enters the approval queue — reviewers see risk score, estimated records, sensitivity tags, destination. Approve or reject with one click. Full context, no guessing.
Held for review Auto-approvedGate issues a signed execution order with a one-time token (15 min TTL). In runner_exec mode a trusted worker inside your VPC fetches it and executes — credentials never leave your environment. Token expires. Replay blocked.
Token-gated executionEvery state transition is logged — proposed, policy_checked, approved, execution_requested, execution_succeeded. Queryable by intent ID. Not deletable. The record of everything your agents have ever done.
Ledger sealedV2 governs writes when the agent calls the SDK. V3 closes that gap. Three layers, all live: a forward proxy intercepts outbound HTTP, a TLS layer handles HTTPS, and a credential vault means the agent never holds production secrets. No SDK changes required. No path around it.
V2 is opt-in. An agent that skips gate.propose() writes directly to production. A retry loop that ignores duplicate_blocked fires twice. V3 puts Gate in the network path — not the application layer.
One environment variable. All outbound HTTP routes through Gate. No agent code changes. Destination maps to policy via registry.
HTTP_PROXY=http://gate:4001
Gate deployed in front of specific APIs. Agent routes to Gate's URL. Works for services that ignore proxy variables.
POST gate.internal/sfdc/...
Gate holds no credentials. Fetches from 1Password, HashiCorp, or AWS at execution time. Agent never touches production secrets.
op://AI-Agents/Stripe/key
Zero-trust credentials: In vault mode, the agent submits intent only. Gate evaluates policy, fetches the credential ephemerally, executes the API call, then discards it from memory. A compromised agent has nothing to exfiltrate. 1Password handles custody. Gate handles authorization.
Execution continuity for governed agent runs. When a tracked run breaks during approval, execution, or retry, it resumes from the last safe point without replaying side effects.
Explore Run Ledger →Submit intent, get a policy decision in milliseconds. Approved? Request an execution order. Worker runs it in your VPC. Reports back. Ledger sealed. The surface area is intentionally small — complexity lives in the policy file.
import { Gate } from "zehrava-gate" const gate = new Gate({ endpoint: "https://gate.yourco.com", apiKey: "gate_sk_..." }) // 1. Submit intent — get 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.intentId, p.status, p.risk_score, p.risk_level, p.blockReason // 2. Human approves (dashboard, Slack, or API) await gate.approve({ intentId: p.intentId }) // 3. Get signed execution order (15-min TTL) const order = await gate.execute({ intentId: p.intentId }) // order.execution_token → worker runs in your VPC // 4. Full audit trail const audit = await gate.verify({ intentId: p.intentId }) // proposed → policy_checked → approved → execution_requested → execution_succeeded
from zehrava_gate import Gate gate = Gate(endpoint="https://gate.yourco.com", api_key="gate_sk_...") p = gate.propose(payload="payout_batch.csv", destination="netsuite.payout", policy="finance-high-risk") print(p["status"]) # pending_approval — always, for finance-high-risk
Need continuity across interruption? Use Run Ledger for tracked runs.
Or use the Dashboard for approvals, audit trails, and run inspection.
Gate checks: who sent this, where it's going, whether policy allows it, and whether a human approved it. Your downstream system validates the data. Gate controls whether it gets there.
No DSL. No rule engine. Drop a YAML file in your policy directory and Gate picks it up. Any engineer can read it. Any compliance team can audit it.
destinations
Allowlist of target systems. Anything outside this list is blocked.
block_if_terms
Terms to scan payload for. Normalized matching — strips punctuation, decodes leet.
require_approval
Set to always — every intent goes to human review regardless of other rules.
auto_approve_under
Record count threshold. Below this → auto-approved. Above require_approval_over → pending.
allowed_types
File extension allowlist for file-based payloads.
expiry_minutes
How long a pending intent can wait before it expires.
One control plane. Every framework. Every write. One ledger.
That's the moment it clicks. An agent tried to write. Gate stopped it. You saw why. Now you know what governance looks like.
npm install zehrava-gate npx zehrava-gate --port 4000
import { Gate } from "zehrava-gate" const gate = new Gate({ endpoint: "http://localhost:4000" }) const p = await gate.propose({ payload: "./leads.csv", destination: "salesforce.import", policy: "crm-low-risk", recordCount: 847 }) console.log(p.status) // "pending_approval" — over the 100-record threshold // Change recordCount to 50 → "approved" immediately // Change destination to "unknown.system" → "blocked"
Gate is free to run on your own infrastructure. For managed hosting, integrations, or enterprise support — let’s talk.
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. The latency is whatever your SQLite + Node can do on the hardware you run it on.
"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 that 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 the execution was attempted by an authenticated worker with a valid one-time token.
Cryptographic execution proofs — the worker signs the result, Gate verifies — is on the roadmap. For now, the audit trail shows who authorized what, when, and what outcome was reported. That's auditable accountability, not cryptographic proof.
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 to Salesforce 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 issues a signed execution order saying "this write is authorized" — the worker reads it, verifies the token, executes using its own credentials. Gate is in the decision path, not the credential path.
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 own it. You control retention.
Intent payloads can contain sensitive data. Gate knows this. PII scrubber runs on every unauthenticated read endpoint — emails, phone numbers, payload content stripped before anything goes out. Authenticated API calls get full data; public endpoints get scrubbed data.
Cloud-hosted is on the roadmap. SOC 2, encryption at rest, configurable data residency — not shipped yet. If you have a hard compliance requirement today, self-host. It's a 5-minute deploy.
Storage retention: configurable TTL per policy is on the roadmap. Right now you control retention by controlling the database. Delete what you don't need.
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 sent, duplicate records created, refunds issued that shouldn't have been. So agents stay sandboxed. Features get cut. Roadmaps stall.
Gate is what changes that. A deterministic control plane between agent intent and production execution. Policy decides what runs. Humans approve what matters. Every action logged. Companies stop treating agents as a liability and start shipping them to write-path.
The bet is that this is infrastructure, not application logic. Every team building governance from scratch is building the same thing. The roadmap — network-level enforcement, schema-aware policies, signed audit logs — makes Gate non-optional. Right now we're at cooperative adoption. The goal is enforced standard.
V3 Phase 1 is live — forward proxy enforcement shipping now. Get notified when credential vault integration, HTTPS tunneling, and Kubernetes sidecar support ship. No spam — just release notes.
No account required. Unsubscribe any time.