TL-Gate: one gate between any AI agent and the real world

1. What TL-Gate is — in plain words

AI agents already write files, call APIs, and move money. The uncomfortable question is not "can they act" — it's "who said this exact action was allowed, and can you prove it afterwards?" Today the answer is usually a log line the agent itself wrote, or a hook that can be switched off. Both are stories, not evidence.

TL-Gate is a gate that stands before the side effect. An action must show a signed, independently verifiable receipt saying: this principal allowed this agent to do this action on this target with this tool. No receipt for this exact action — nothing happens.

Just as important is what TL-Gate is not: not an orchestrator, not an LLM, not a memory system. It does not plan your work and does not judge whether the result is true. It does one job — a mandatory, fail-closed boundary that provably links permission, scope, tool, execution, validation, and finality.

2. The problem: logs are stories

Modern agent stacks can decompose tasks, pick models, call tools, keep memory. None of that proves: who allowed the action; in what scope; with which tool and version; whether the actual arguments matched the allowed ones; what really executed; who validated the result; and whether anything changed after validation. Hooks, callbacks, tracing and logs live inside the same trusted environment, can be disabled or edited, and record claims, not cryptographically linked chains.

3. The formula

Orchestrator plans.
Agent proposes.
TL-Gate governs and executes through a controlled boundary.
Verifier checks receipts.
Second Brain stores only receipt-bound knowledge.

Each line is a separate truth domain. The orchestrator owns the plan; TL-Gate owns governed execution; each validator owns its own check; a TimeLayer receipt attests one digest with quorum signatures; Second Brain owns computed knowledge state. Nobody vouches for anybody else.

4. How one action travels through the gate

The agent's proposal is normalized into an immutable ActionIntent: canonical target, BLAKE3 digest of the arguments, tool identity and version, side-effect class, chain coordinates. The commitment is BLAKE3("TL-GATE/INTENT/v1" || canonical_intent) — change anything, and it is a different action that needs its own receipts.

The pre-execution gate then demands the mandatory triple — permission_receipt, scope_receipt, tool_receipt — each independently verified and each bound to this intent. The decision has exactly two values: ALLOW or STOP(reason). There is no "best-effort allow".

On ALLOW, the action runs only through the Controlled Tool Broker — the single place where real side effects happen. The broker re-checks the intent digest, passes secret handles (never values), captures exact input and output digests, and produces an execution_receipt. Assigned validators (deterministic checks, tests, an independent model judge, a human) produce a validation_receipt; only then does the finalizer notarize a final_receipt. Until that moment the result is officially NON_FINAL — the state machine even has honest states for "executed but not finalized" and "effect unknown after a crash".

5. The receipt chain

permission → scope → tool → execution → validation → final

Every receipt carries its own domain separator (TL-GATE/PERMISSION/v1, TL-GATE/EXECUTION/v1, …), the previous receipt's commitment, a sequence number, and the subject commitment. The same 32 bytes can never be replayed across domains, chains cannot fork silently, and a missing link stops the chain. Evidence is stored as bounded immutable capsules per action chain — not an endless editable journal. Your content stays with you: only digests reach the notarial layer.

6. Action classes and enforcement modes

• R0 pure computation · R1 read-only access · W1 reversible write · W2 transactional effect · W3 irreversible/high-impact (typically demands human approval).
• Enforcement, weakest to strongest: cooperative (in-process) → broker-enforced (credentials live in a separate process) → isolated (sandbox boundary) → air-gapped permission → hardware-backed.

7. Principles that don't bend

#	Rule
P-02	No valid receipt → no action. Missing, expired, revoked, or somebody else's receipt all mean STOP.
P-03	Enforcement stands before the side effect, not after it.
P-05	Agents cannot self-authorize; adapters and orchestrators cannot either.
P-06	Model output is not proof. "Done", "success", "verified" prove nothing.
P-08	Finality is explicit: output exists ≠ FINAL.
P-10	BLAKE3 only, always domain-separated. A bare 32-byte hash with no type is not a commitment.
P-12	Uncertainty never becomes permission: timeout, unknown schema, unavailable verifier — STOP.
P-13	Delegation cannot amplify trust: a child agent gets the same scope or narrower.

The full set (P-01…P-14), the trust boundaries, the error model, and the wire format live in the specification in the repository.

8. Status, repository, roadmap

Status: Proposed Architecture Specification v0.1, Phase 0 (protocol freeze) in progress. The repository is public and the code that exists is small and honest: canonical intent commitments and bound-only offline verification are implemented and tested; every other command of the future CLI answers STOP(NOT_IMPLEMENTED) — fail-closed by construction, no pretend features.

git clone https://github.com/TimeLayer-OS/timelayer-agent-gate
cargo test                       # 6/6 green
tl-gate intent digest examples/intent.json
tl-gate verify cert.tlcert bundle.tlbundle --expect <digest>

Roadmap: Phase 0 protocol freeze → Phase 1 local universal gate (filesystem/process/HTTP broker) → Phase 2 MCP control plane → Phase 3 multi-agent delegation → Phase 4 Second Brain bridge → Phase 5 strong isolation modes.

github.com/TimeLayer-OS/timelayer-agent-gate — spec (RU normative + EN edition), Rust workspace, JSON schemas, roadmap.

9. Where it sits among TimeLayer tools

• timelayer-verifier — the independent offline verifier. TL-Gate calls it and never re-implements it.
• TL-Agent — the receipt-gated agent SDK; its permission bundles become one possible receipt source through an adapter.
• Second Brain — the knowledge base on receipts; only results carrying a final_receipt may be promoted into it.
• receipt-driven-examples — minimal copy-me patterns; reference material, not runtime.