Autonomous agents make mistakes. Gate catches them before they land.
Autonomous agents are powerful because they act without waiting for a human. That's also exactly why they need a guardrail. Gate is a runtime control plane that intercepts every action an agent tries to take — before the API call fires, before the email sends, before the record writes. Evaluated against policy. Logged. Routable to human review.
An agent misreads a condition and fires a bulk email to 47,000 contacts at 2am. A CRM sync agent writes corrupted data to 847 production records. A refund agent processes a $10,000 charge instead of $100. All three happened. All three would have been caught by a record-count or field-value check at the intent layer.
What are AI agent guardrails?
AI agent guardrails are enforcement mechanisms that run between an agent's decision and the action it wants to execute. They intercept the intended action, evaluate it against a defined policy, and either permit it, block it, or route it to human approval before execution.
Effective guardrails share three properties. First, they are deterministic — the same input always produces the same decision. LLM-based safety layers drift; YAML policy files do not. Second, they are fail-closed — if the guardrail is unreachable or errors, the action does not proceed. Third, they are auditable — every intent, every decision, and every execution is logged with the agent identity and timestamp.
Gate implements all three. Policies are YAML files you version-control. If Gate is unreachable, agents get a 503 and the action is not forwarded. Every intent produces an immutable audit trail: proposed → policy_checked → approved → execution_succeeded. Install with npm install -g zehrava-gate and start in under 5 minutes.
How Gate intercepts an agent action
Agent submits intent
Before calling any external API, agent calls gate.propose() with the action, destination, and payload. Gate receives the intent, records it, and runs policy evaluation synchronously.
Policy evaluated deterministically
Gate checks the intent against your YAML policy: destination allowlist, field validation, rate limits, environment thresholds, sensitive term scan. Same input, same output, every time. No LLM call in the evaluation path.
Decision returned immediately
approved — agent proceeds. blocked — Gate returns the policy reason, agent halts that action. pending_approval — intent queued for human review; agent polls or waits.
Execution token issued on approval
Approved intents get an execution token (gex_...). Agent presents the token to execute. Token is single-use. No token, no execution.
Result reported back
After execution, agent reports success or failure. Gate closes the audit trail: execution_succeeded or execution_failed with HTTP status and metadata.
Two integration paths
SDK integration (greenfield agents)
Four lines to add Gate to any agent:
const { Gate } = require('zehrava-gate');
const gate = new Gate({ endpoint: 'http://localhost:3001', apiKey: process.env.GATE_API_KEY });
// Before every write action:
const intent = await gate.propose({
payload: JSON.stringify(actionPayload),
destination: 'salesforce.api',
policy: 'crm-low-risk',
recordCount: records.length,
});
if (intent.status === 'approved') {
await salesforce.update(records); // gate approved — proceed
} else if (intent.status === 'blocked') {
throw new Error(intent.blockReason); // gate blocked — halt
}
// pending_approval → poll or notify humanHTTP proxy integration (existing agents, no code changes)
Set HTTP_PROXY=http://localhost:4001. Gate intercepts all outbound HTTP/HTTPS traffic from your agent, submits each request as an intent, and forwards only approved requests.
HTTP_PROXY=http://localhost:4001 \
NODE_EXTRA_CA_CERTS=/opt/zehrava-gate/data/proxy-ca/ca.crt \
node your-agent.jsPending requests can hold the connection open with X-Gate-Wait: true — Gate auto-forwards when approved. Rejected requests get a 403. Gate unreachable returns 503 and does not forward.
Write the policies that match your risk model
Gate ships with no default allow-all policy. Every destination needs a policy. Every policy lives in a YAML file in your repo.
# policies/crm-writes.yaml
id: crm-writes
destinations: [salesforce.api, hubspot.api]
field_checks:
- path: "email"
required: true
pattern: "^[^@]+@[^@]+\\.[^@]+$"
- path: "records"
max_length: 500 # never more than 500 records in one write
rate_limits:
per_agent_per_hour: 20
per_agent_per_day: 100
environments:
production:
require_approval_over: 10 # anything above 10 records → human review
auto_approve_under: 1
staging:
auto_approve_under: 500 # staging: auto-approve everything under 500
development:
require_approval: neverWhat Gate protects against — and what it doesn't
Gate is honest about its scope.
Gate catches: volume errors (agent writes 5,000 records when it should write 5), field errors (amount of 10000 when policy caps at 100), rate abuse (agent loops and fires 200 API calls in an hour), actions to unauthorized destinations, and duplicate actions (idempotency blocks retries).
Gate does not catch: a model that deliberately modifies the policy files it's governed by, semantic mistakes that pass field validation (wrong contact ID that's still a valid string), or actions through channels Gate isn't intercepting.
Gate is a commit checkpoint, not a jailbreak defense. It reduces the blast radius of agent mistakes — which is the problem that actually destroys production environments.
Start in 5 minutes
npm install -g zehrava-gate
# Generate an API key and start
zehrava-gate start --api-key gate_sk_$(openssl rand -hex 20)
# Open the dashboard
open http://localhost:3001/dashboardDrop policy files in ./policies/. Gate hot-reloads them. Register your agents via POST /v1/agents/register. Point your agent at Gate with the SDK or proxy. Done.
Add a runtime checkpoint to your agent
Self-hosted. MIT license. Audit-ready from the first intent.
View on GitHub Read the docs