Enterprise Governance Audit For platform & infrastructure teams

Your AI agents are writing to production. Gate decides what gets through.

Enterprise teams deploying AI agents face one problem that LLM providers don't solve: what happens between the model decision and the production action. Gate sits in that gap. Every agent write, send, and API call passes through Gate before execution — evaluated deterministically, logged immutably, and routable to a human approval queue.

What is AI agent governance?

AI agent governance is a control layer between an agent's decision and the production action it wants to take. Without it, agents write to your CRM, send emails, charge cards, and call APIs with no checkpoint between decision and execution.

Effective governance requires four capabilities: a policy engine that evaluates each intent before it runs; a human approval queue for actions above a risk threshold; an immutable audit log tied to the agent identity that submitted each intent; and a fail-closed default — if the governance layer is unreachable, the action does not proceed.

Gate implements all four. Policy evaluation is deterministic YAML — no LLM judgment. The audit log records every event in sequence: proposed → policy_checked → approved → execution_requested → execution_succeeded. Every intent carries the agent identity, the action taken, and the human who approved or blocked it. Self-hosted: no agent data leaves your infrastructure.

What Gate enforces

Field validation

Required fields, type constraints, format patterns, value bounds — checked on every intent before approval.

Rate limits

Per-agent hourly and daily action limits. Block volume attacks before they reach your APIs.

Environment thresholds

Different approval rules for production vs staging vs development. Same policy file, different behavior per environment.

Human approval queue

High-risk actions pause for reviewer sign-off. Dashboard shows intent, agent identity, payload, and policy decision.

Webhook notifications

Fire to your Slack, PagerDuty, or SIEM on approve, reject, or block. Persistent SQLite-backed delivery.

Idempotency

Duplicate intents return the original decision. Agents can retry safely — Gate will not process the same action twice.

The audit trail every compliance team asks for

Gate records a canonical event sequence for every intent. Every event is immutable. Query by agent, by action, by time window, or by policy decision.

proposed Agent submitted intent — agent ID, payload hash, destination, policy recorded

policy_checked Policy engine evaluated intent — field checks, rate limits, thresholds applied

approved Human reviewer or auto-approve policy authorized the action

blocked Policy blocked intent — reason recorded, action never executed

execution_succeeded Action completed — execution token, HTTP status, agent report stored

Policy as code — in your repo, reviewed like any other change

Gate policies are YAML files. Check them into version control. Review them in PRs. Deploy them with your infrastructure tooling. No GUI required, no vendor portal to log into.

# policies/finance-high-risk.yaml
id: finance-high-risk
destinations: [stripe.charge, stripe.refund]

field_checks:
  - path: "amount"
    max: 10000      # block charges above $100

rate_limits:
  per_agent_per_hour: 10
  per_agent_per_day:  50

environments:
  production:
    require_approval: always
  staging:
    require_approval_over: 100
    auto_approve_under: 10

Multi-agent attribution — every intent has an owner

Register each agent with Gate before deployment. Every intent carries the agent's ID. When an intent is approved, the reviewer identity is recorded alongside the agent identity. When something goes wrong, you know which agent acted, what policy allowed it, and who signed off.

POST /v1/agents/register
{
  "name":        "crm-sync-agent",
  "description": "Syncs qualified leads to Salesforce",
  "permissions": ["salesforce.api", "loops.send"]
}

# Returns: { agentId: "agt_...", apiKey: "gate_sk_..." }

Gate vs alternatives

Capability	Gate	LLM safety layer	No governance
Deterministic policy	✓ YAML, always same result	✗ LLM judgment varies	✗
Field-level validation	✓ required, max, pattern	✗ not enforced	✗
Human approval queue	✓ built-in dashboard	✗ not included	✗
Immutable audit log	✓ event sequence per intent	✗ varies by vendor	✗
Self-hosted	✓ your infra, MIT license	✗ typically SaaS	n/a
Fail-closed	✓ 503 if unreachable	✗ not guaranteed	✗

Deploy in 5 minutes

npm install -g zehrava-gate

# Start with an API key
GATE_API_KEY=gate_sk_... zehrava-gate start

# Register your first agent
curl -X POST http://localhost:3001/v1/agents/register \
  -H "Authorization: Bearer gate_sk_..." \
  -H "Content-Type: application/json" \
  -d '{"name":"my-agent","permissions":["salesforce.api"]}'

# Drop a policy file in policies/
# Agents submit intents via SDK — Gate does the rest

The proxy is optional. Use the SDK for greenfield agents. Use the HTTP forward proxy (HTTP_PROXY=http://localhost:4001) to intercept existing agents with no code changes.

Add a governance layer to your agent fleet

Self-hosted. MIT license. Full audit trail from day one.

View on GitHub Read the docs