AI agent governance for enterprise teams

Enterprise AI teams deploy agents that write to production — CRM records, financial systems, customer-facing emails. Gate is the write-path control plane that ensures every agent action is evaluated, approved, and logged before it executes.

The compliance problem with AI agents

Enterprise teams deploying AI agents face a governance gap. Observability tools — LangSmith, Datadog, Honeycomb — record what happened. They do not prevent unauthorized writes.

The 4 write-path risks that observability does not solve:

1. Unauthorized destination writes — agent writes to a system not in its policy scope
2. Batch size violations — agent imports 50,000 CRM records when policy requires approval over 1,000
3. Content policy violations — agent sends email containing terms flagged by legal ("refund guaranteed", "settlement")
4. Retry loop duplication — agent retries failed write and creates duplicate records across 3 systems

Gate intercepts all 4 classes before they reach production.

How Gate enforces policy at the write boundary

Gate evaluates a YAML policy at the moment an agent submits an intent. No LLM processes the policy at evaluation time. The same input always produces the same output — deterministic enforcement, no drift.

The 5 evaluation checks Gate runs on every intent:

1. Destination allowlist — writes only to systems the policy permits
2. Record count threshold — auto-approve under threshold, require approval over
3. Term scan — block if payload contains any flagged string (legal, compliance, brand)
4. Sensitivity tags — PII, financial, health, legal, internal_only tags trigger elevated risk score
5. Idempotency key — blocks duplicate submissions from the same agent

Audit trail — every write, every actor, every decision

Gate writes an immutable audit event for every state transition. The canonical audit trail for an approved write contains 5 events:

1. proposed — agent submitted intent with payload hash, destination, policy
2. policy_checked — Gate evaluated policy; result and reason recorded
3. approved — approved by policy (auto) or by named human reviewer
4. execution_requested — execution order issued; one-time gex_ token generated
5. execution_succeeded — worker reported outcome; write confirmed

Every event records: actor name, timestamp, metadata. The audit trail is queryable via GET /v1/intents/:id/audit.

Human-in-the-loop — when approval is required

Gate routes intents to human review based on policy thresholds. Enterprise teams configure 3 approval triggers:

1. Record count — any write over N records requires approval (require_approval_over: 1000)
2. Risk level — high or critical risk score escalates to review
3. Always require — specific destinations always require human sign-off (require_approval: always)

Human reviewers approve or reject at /dashboard. Approval fires a persistent webhook (SQLite-backed — survives server restarts). The workflow integrates with existing Slack or email notification pipelines via webhook.

Multi-agent audit — on_behalf_of

Enterprise agent architectures use orchestrators that spawn leaf agents. The on_behalf_of field records the orchestrator agent ID in every intent the leaf agent submits. The audit trail shows the full chain of accountability — which orchestrator triggered which leaf agent to submit which write.

# Leaf agent submits intent on behalf of orchestrator
p = gate.propose(
    payload=payload,
    destination="salesforce.import",
    policy="crm-standard",
    record_count=record_count,
    on_behalf_of="agt_orchestrator_id",   # who instructed this agent
    idempotency_key=f"sync-{batch_id}"    # prevents retry duplication
)

Deployment inside your VPC

Gate runs as a single Node.js process with a SQLite database. Enterprise teams deploy it inside the VPC alongside agent workers. No credentials leave the VPC — the execution token travels from Gate to the worker that holds production credentials.

3 deployment options:

1. npx — npx zehrava-gate --port 4000 --data-dir /data --policy-dir /policies
2. Docker — mount /data and /policies volumes, expose port
3. Source — clone, npm install, configure environment, run with PM2

Gate vs existing enterprise tooling