On the governed path, no unauthorized action can execute.

Definitions

Governed path. An action is on the governed path when it passes through a ZLAR gate — either the PreToolUse hook (for Claude Code, Cursor, Windsurf) or the MCP TCP proxy (for any MCP-connected agent). If an action does not pass through the gate, the gate has nothing to enforce.

Human authorization. An action is human-authorized if either: (a) a human signed the policy rule that permits it, using an Ed25519 private key the agent does not possess, or (b) a human explicitly approved it in real time via Telegram, and the approval is cryptographically bound to the exact action requested.

The gate. bin/zlar-gate — a bash script with no model inference, no reasoning, no intelligence. It reads a tool call from stdin, evaluates it against a signed policy, and writes a JSON response to stdout: allow or deny. That is all it does.

Proof

The gate has exactly five terminal states. Every tool call reaches exactly one of them.

State 1: Policy says deny

The policy rule matching the tool call specifies action: deny. The gate blocks the action immediately. No Telegram message. No human decision needed. The policy — signed by a human with an Ed25519 key — pre-determined that this class of action is not permitted.

State 2: Policy says allow

The policy rule matching the tool call specifies action: allow. The gate permits the action. The policy — signed by a human — pre-determined that this class of action is permitted. The human authorized it at the time they signed the policy.

State 3: Policy says ask — human decides

The policy rule specifies action: ask. The gate sends a message to the human via Telegram and denies the action while waiting. The agent is told to retry after the human decides.

On retry, the gate checks for a human response. Four sub-cases:

3a. Human approves. The gate finds an approval callback. Before allowing, it verifies the SHA-256 action hash matches the exact tool call — rule|tool_name|detail. If the hash matches, the action is allowed. The human explicitly authorized this specific action.

3b. Human denies. The gate finds a denial callback. The action remains blocked.

3c. Human does not respond. The pending file ages past the configured timeout. The gate treats expiry as denial. The action remains blocked.

3d. Approval hash mismatch. If the approval was for a different action, the SHA-256 hash will not match. The approval is rejected. The action remains blocked.

State 4: Ask fails — Telegram unreachable

The gate attempts to send a Telegram message and fails. The gate denies the action.

The action never executes. The gate does not fall back to allowing. It does not assume the human would have approved. If the human cannot be reached, the answer is no.

State 5: Gate crashes

Any unhandled error triggers the ERR trap.

set -euo pipefail
trap '_gate_crash $LINENO' ERR

_gate_crash() {
    echo '{"hookSpecificOutput":{"hookEventName":"PreToolUse",
           "permissionDecision":"deny",
           "permissionDecisionReason":"ZLAR gate crash"}}'
    exit 0
}

The trap outputs a valid deny response and exits cleanly. The action is blocked. exit 0 is deliberate: the host framework interprets non-zero exit as a non-blocking error and continues. By exiting 0 with a deny payload, the gate ensures its crash produces a valid blocking response that the host framework respects.

State 0: No rule matches

If no policy rule matches the tool call, the gate applies the default action. The default is deny.

If the policy file does not specify a default, the fallback is deny. The gate is closed until a human opens it.

The policy cannot be modified by the agent

The policy file is Ed25519-signed. The gate verifies the signature at load time. If verification fails, the gate denies all actions.

An agent cannot write a permissive policy and have the gate enforce it, because the agent does not possess the Ed25519 private key. The key never lives on the agent's machine. The key is held by the human.

The gate cannot be persuaded

The gate performs four operations: pattern matching, comparison, lookup, and timestamp arithmetic. It does not perform inference, interpretation, or reasoning. It has no language model. It has no prompt. It has no context window. It has no objective function.

Persuasion requires a reasoning target. The gate has none. This is not a limitation. It is the design.

Summary

In every state, either a human authorized the action, or the action was blocked. There is no state in which an unauthorized action executes.

What this proof does not cover

A proof that does not state its own boundaries is not a proof. It is marketing.

What this proof means

On the governed path, the gate is a deterministic function from (tool call, signed policy, human decision) to (allow, deny). The function has no intelligence. It has no attack surface for reasoning-based attacks. It cannot be prompt-injected, context-drifted, or persuaded, because it does not reason.

If the enforcement layer uses intelligence, the enforcement layer can be attacked with intelligence. If the enforcement layer is deterministic, the only attacks are against the policy (a human artifact, signed with Ed25519, stored outside agent context) or against the infrastructure below the gate (the operating system, the hook runner, the hardware). Those attacks exist. They are real. They are documented above. But they are a fundamentally different class of attack than reasoning-based persuasion — and they have well-understood mitigations.

The absence of intelligence in the gate is not a limitation. It is the security property.

Verification

Every claim in this document references specific lines in bin/zlar-gate (Gate v2.5.1). The source code is Apache 2.0 licensed and publicly available. Every claim can be independently verified by reading the source.