TL-Gate: одни ворота между любым ИИ-агентом и реальным миром

1. Что такое TL-Gate — простыми словами

ИИ-агенты уже пишут файлы, дёргают API и двигают деньги. Неудобный вопрос не в том, «умеют ли они действовать», а в том, «кто разрешил именно это действие — и чем вы это докажете потом?» Сегодня ответ обычно — строчка в логе, которую написал сам агент, или хук, который можно выключить. И то и другое — рассказ, а не доказательство.

TL-Gate — это ворота, стоящие до побочного эффекта. Действие обязано предъявить подписанную, независимо проверяемую квитанцию: этот владелец разрешил этому агенту сделать это действие над этой целью этим инструментом. Нет квитанции на именно это действие — ничего не происходит.

Не менее важно, чем TL-Gate не является: это не оркестратор, не LLM и не память. Он не планирует вашу работу и не судит, истинен ли результат. У него одна работа — обязательная fail-closed граница, доказуемо связывающая разрешение, scope, инструмент, исполнение, проверку и финальность.

2. Проблема: логи — это рассказы

Современный агентный стек умеет разбивать задачи, выбирать модели, вызывать инструменты, помнить контекст. Ничто из этого не доказывает: кто разрешил действие; в какой области; каким инструментом и какой версией; совпали ли фактические аргументы с разрешёнными; что реально исполнилось; кто проверил результат; не изменилось ли что-то после проверки. Хуки, колбэки, трейсинг и логи живут внутри той же доверенной среды, отключаются и редактируются, и фиксируют заявления, а не криптографически связанные цепочки.

3. Формула

Оркестратор планирует.
Агент предлагает действие.
TL-Gate управляет допуском и проводит действие через контролируемую границу.
Verifier проверяет квитанции.
Second Brain принимает только знание, связанное с доказательством.

Каждая строка — отдельный домен истины. Оркестратор отвечает за план; TL-Gate — за управляемое исполнение; каждый валидатор — за свою проверку; квитанция TimeLayer заверяет один дайджест кворумными подписями; Second Brain — за вычисляемое состояние знания. Никто не ручается за чужую зону.

4. Как действие проходит через ворота

Предложение агента нормализуется в неизменяемый ActionIntent: каноническая цель, BLAKE3-дайджест аргументов, идентичность и версия инструмента, класс побочного эффекта, координаты цепочки. Коммитмент — BLAKE3("TL-GATE/INTENT/v1" || canonical_intent): измените что угодно — это уже другое действие, которому нужны свои квитанции.

Дальше pre-execution gate требует обязательную тройку — permission_receipt, scope_receipt, tool_receipt, — каждая проверяется независимо и каждая привязана к этому intent. Решение принимает ровно два значения: ALLOW или STOP(причина). Никакого «best-effort allow» нет.

При ALLOW действие идёт только через Controlled Tool Broker — единственное место, где случаются реальные побочные эффекты. Брокер перепроверяет дайджест intent, передаёт ссылки на секреты (никогда значения), фиксирует точные дайджесты входа и выхода и формирует execution_receipt. Назначенные валидаторы (детерминированные проверки, тесты, независимый модельный судья, человек) дают validation_receipt; только после этого финализатор заверяет final_receipt. До этого момента результат официально NON_FINAL — в машине состояний даже есть честные состояния «исполнено, но не финализировано» и «эффект неизвестен после сбоя».

5. Цепочка квитанций

permission → scope → tool → execution → validation → final

Каждая квитанция несёт свой domain separator (TL-GATE/PERMISSION/v1, TL-GATE/EXECUTION/v1, …), коммитмент предыдущей квитанции, порядковый номер и коммитмент субъекта. Одни и те же 32 байта нельзя переиграть между доменами, цепочка не форкается молча, пропущенное звено её останавливает. Доказательства хранятся ограниченными неизменяемыми капсулами на цепочку — а не бесконечным редактируемым журналом. Ваш контент остаётся у вас: в нотариальный слой уходят только дайджесты.

6. Классы действий и режимы enforcement

• R0 чистое вычисление · R1 только чтение · W1 обратимая запись · W2 транзакционный эффект · W3 необратимое/высокорисковое (как правило, требует одобрения человека).
• Enforcement от слабого к сильному: cooperative (в одном процессе) → broker-enforced (креды живут в отдельном процессе) → isolated (граница песочницы) → air-gapped permission → hardware-backed.

7. Принципы, которые не гнутся

#	Правило
P-02	Нет валидной квитанции → нет действия. Отсутствующая, просроченная, отозванная или чужая — всегда STOP.
P-03	Проверка стоит до побочного эффекта, а не после.
P-05	Агент не может разрешить сам себе; адаптер и оркестратор — тоже.
P-06	Вывод модели — не доказательство. «Готово», «успешно», «проверено» не доказывают ничего.
P-08	Финальность явная: наличие результата ≠ FINAL.
P-10	Только BLAKE3, всегда с domain separation. Голые 32 байта без типа — не коммитмент.
P-12	Неопределённость не превращается в разрешение: таймаут, незнакомая схема, недоступный verifier — STOP.
P-13	Делегирование не усиливает доверие: дочерний агент получает тот же scope или уже.

Полный набор (P-01…P-14), границы доверия, модель ошибок и wire-формат — в спецификации в репозитории.

8. Статус, репозиторий, дорожная карта

Статус: Proposed Architecture Specification v0.1, идёт Phase 0 — заморозка протокола. Репозиторий публичный, и код в нём маленький, но честный: канонические intent-коммитменты и только-привязанная офлайн-проверка реализованы и покрыты тестами; все остальные команды будущего CLI отвечают STOP(NOT_IMPLEMENTED) — fail-closed по построению, никаких притворных фич.

git clone https://github.com/TimeLayer-OS/timelayer-agent-gate
cargo test                       # 6/6 зелёные
tl-gate intent digest examples/intent.json
tl-gate verify cert.tlcert bundle.tlbundle --expect <дайджест>

Дорожная карта: Phase 0 заморозка протокола → Phase 1 локальные универсальные ворота (брокер файлов/процессов/HTTP) → Phase 2 MCP control plane → Phase 3 делегирование в мультиагентных системах → Phase 4 мост в Second Brain → Phase 5 сильная изоляция.

github.com/TimeLayer-OS/timelayer-agent-gate — спека (русская нормативная + английская редакция), Rust-workspace, JSON-схемы, roadmap.

9. Место среди инструментов TimeLayer

• timelayer-verifier — независимый офлайн-верификатор. TL-Gate вызывает его и никогда не переизобретает.
• TL-Agent — receipt-gated SDK агента; его permission-бандлы станут одним из источников квитанций через адаптер.
• Второй мозг — база знаний на квитанциях; в неё попадают только результаты с final_receipt.
• receipt-driven-examples — минимальные примеры-шаблоны; справочный материал, не рантайм.