philippeabraxas-jpg/tbp-networkТеория и реализация протокола TBP для защиты сетевого ИИ в малых и открытых веб-сетях
Сетевая реализация Телеологического протокола ограничения (TBP) — аттестованное управление действиями ИИ-агентов в сети, от одной машины до корпоративных развёртываний вплоть до масштаба WWW.
« Существующий контроль доступа решает, попадёте ли вы внутрь; TBP решает, что вам разрешено делать, оказавшись внутри — и доказывает это. Мы управляем возможностями, а не моделями. »
Никогда не партнёрство по доверию — только по аттестованному рукопожатию. Именно этим и является данный репозиторий: межузловое рукопожатие (спецификация §3) и всё вокруг него — NAC, PEP, реестры ячеек — что расширяет управление TBP от одной машины до сети сущностей, которым приходится доверять друг другу, не просто доверяя друг другу.
Примечание о языке: эталонная спецификация теперь —
docs/spec-en-v1.0.md (английский) — это
документ, на который следует ориентироваться при код-аудитах. Рабочая
заметка автора — более плотная, менее линейная, полезная для изучения
обоснований дизайна, но не та, на которую следует ссылаться — существует на двух языках:
docs/spec-v1.4.10.md (английский) и
docs/spec-v1.4.10.fr.md (оригинал на французском).
Та же конвенция применяется по всему репозиторию: каждый документ, изначально
написанный на французском, теперь имеет английскую основную версию по исходному пути, а
французский оригинал хранится рядом как <name>.fr.md. Глоссарий
(docs/glossaire.md) по-прежнему имеет французский источник (§14 французского документа —
это источник истины по терминологии) с колонкой английских пояснений для
удобства чтения — это не изменилось.
Полная спецификация — docs/spec-en-v1.0.md
— она является источником истины для любого проектного или конфигурационного решения в
этом репозитории. Этот README лишь резюмирует необходимое для ориентации;
в случае сомнений — главенствует спецификация. Рабочая заметка
(docs/spec-v1.4.10.md, английский перевод французского оригинала)
не устарела по содержанию — это тот же протокол, разработанный там
в первую очередь — но она не является цитируемым эталоном в дальнейшем.
Полезные ориентиры для её чтения:
docs/glossaire.md — один канонический термин на
понятие, используемый последовательно в коде и документации этого репозитория
(см. CONTRIBUTING.md).Сам протокол — спецификация, формальная доктрина, состязательные аудиты,
основная реализация (подпись HSM, цепочка аудита Merkle, движок политик OPA) —
находится в Responsible-Alliance-Protocol,
лицензирован под Apache 2.0 (открытая), и вендорится в дерево здесь в tbp4.2.1/
как git-субмодуль, закреплённый на конкретном коммите — указатель, а не форк:
этот репозиторий никогда не является местом для подачи issue или PR против того
кода, только против сетевых компонентов развёртывания ниже. Этот репозиторий
является сетевым развёртыванием того же протокола: NAC, локальные PEP,
реестры ячеек, межузловое рукопожатие — компоненты, необходимые для переноса
TBP с одной управляемой машины на управляемую сеть. На момент этого
уведомления собственный код этого репозитория также под Apache 2.0 (см. Лицензирование
ниже) — та же лицензия, что и у основного протокола, одна лицензия для обоих
репозиториев, а не две. Ранее он использовал закрытую лицензию в течение
начальной пилотной фазы; эта фаза завершена.
Поддержание субмодуля в актуальном состоянии: tbp4.2.1/ не обновляется сам —
перевод его на более новый коммит Responsible-Alliance-Protocol является
намеренным, проверяемым действием (cd tbp4.2.1 && git checkout <commit> && cd .. && git add tbp4.2.1 && git commit), никогда автоматическим. Закреплённый
субмодуль, который молча отстаёт от исправления безопасности в upstream, хуже,
чем отсутствие субмодуля вовсе — относитесь к его обновлению с той же тщательностью, что и к любому
другому обновлению зависимости, и сначала проверьте собственный changelog основного репозитория.
tbp4.2.1/ Git submodule: the core protocol (Responsible-Alliance-Protocol,
pinned commit) — working implementation, tests, live at
invarian.fr; includes tbp-v4-hard-shield/ (the OPA policy
engine this repo's PEPs enforce against). Not copied: run
git submodule update --init to fetch it; source of truth
and issue tracker for this code stay in that repository.
docs/ Specification (spec-en-v1.0.md, reference; spec-v1.4.10.md +
spec-v1.4.10.fr.md, working note EN/FR), glossary, audits
figs/ Figures referenced by the spec (see MANIFEST.md)
policies/
├── README.md How to generate capabilities.json correctly
├── gen_capabilities.sh + validate_determinism.go Generation + determinism gate
└── rego/ Illustrative example Rego policies
config/
├── nftables/ Local PEP redirection + P1 router rules (§4.1, §5.1)
├── freeradius/ 802.1X / EAP-TLS + enrolment/revocation scripts (§5.1)
└── sysctl/ Generic kernel hardening
src/
├── pep/ Local policy enforcement point (§4.1, §4.1-bis, §4.3):
│ CWT/COSE token validation (Ed25519), memory-bounded
│ fail-closed anti-replay, clock-status degraded mode,
│ execution quotas, plan-as-contract gate, monitor→closed
│ modes, pepd daemon
│ └── postgres-extension/ Two-hook in-process PEP for PostgreSQL (§4.4)
├── broker/ Cell broker (§5.1): single entry point of the decision
│ flow — orchestration, token issuer, emission envelope,
│ HTTP server (brokerd), epoch/quorum/plan-contract wiring
├── cluster/ Multi-cell fencing (§7.2–§7.5): single-authority epochs
│ (m-of-n verified, monotone, equivocation-detected),
│ k-of-n quorum for class W, mirror/canary promotion
├── registry/ Cell registry (§6): Tessera POSIX cell log with signed
│ checkpoints, disk backpressure, anchoring + TSA,
│ attested state manifest, measured boot (§6.3)
├── supervision/ Independent monitor (§2, §6.2, §7.1): verified chain
│ reading (ChainWatcher), divergence alerting, failover
│ detection, read-only console, supervisord
├── telemetry/ Flow metadata exporters, anti-dribble (§4.1-bis)
└── translator/ Translator (§4.5): runtime hardening (hardened systemd
unit, seccomp allowlist, confinement audit) + controlled
degradation state machine (structured-only, no cloud
fallback; mirror failover / human escalation /
default-deny per system class) + quality measurement
(corpus replay, per-class FNR/FPR gate blocking CI,
stratified human sampling, TBTM1 registry leaf)
deploy/ Multi-machine deployment guides (router, cell, server,
supervisor) with per-machine checklists, monitor→closed
posture switch, and an executable selftest (82 controls)
scripts/genesis/ Genesis ceremony tooling (epoch 0, controller keys §12)
lab/ docker-compose PoC + containerlab P1 topology + netns
tests (802.1X fail-closed, MAB/IoT VLAN, OCSP remediation)
tests/
├── p1_friction/ Friction budget (§9.1): thresholds + Go harness + leading indicators
└── p2_redteam/ Attack scenarios (§13) + evidence-producing runner
.github/ Issue templates, CI (Rego determinism gate + lint)
**Текущий статус (на 2026-09-22): код развёртывания реализован и
протестирован по всему пути — genesis → fencing → registry → broker → PEP →
supervision → translator → deployment.** Каждый пакет `src/` несёт свой
собственный набор тестов (модульные/интеграционные тесты на Go, Python для
инструментов аудита и измерений), а `deploy/selftest/` выполняет руководства
по развёртыванию от начала до конца (**82 контроля, 0 сбоев** — руководство,
которое расходится с кодом, ломается там, а не у оператора). Сейчас против этого
репозитория нет открытых PR — весь находившийся в работе бэклог (T25
контролируемая деградация, T38 ограниченная асинхронная долговечность реестра,
T26 измерение качества переводчика) уже слит. Два пункта остаются открытыми и
отслеживаются намеренно, ни один из них не блокирует пилот: английский перевод
оставшейся французской документации ([#83](https://github.com/philippeabraxas-jpg/TBP-NETWORK/issues/83),
в процессе — большая часть `deploy/` и `docs/` уже имеет английские
основные версии, см. «Примечание о языке» выше), и междоменный слой
(спецификация §13 — отложен самой спецификацией, отслеживается в
[#33](https://github.com/philippeabraxas-jpg/TBP-NETWORK/issues/33), чтобы
«отложено» оставалось видимым, а не молча отсутствовало). Что намеренно
**не** здесь пока помимо этого: нативные корпуса переводчика для каждого языка
(должны быть сформированы на пилоте, §15 — конвейер, который их воспроизводит
и проверяет по ним, построен) и путь эскалации к человеческому арбитражу
(brokerd v1 принимает только `structured` переводчик).
Не развёртывайте `config/` как есть — каждый файл там говорит об этом явно,
стоит повторить и здесь. Протокол, против которого управляет этот код
развёртывания, тоже не скелет: `tbp4.2.1/` вендорит рабочий ядро (HSM
подписывающий, цепочка аудита Меркла, движок политик OPA, тесты, процесс
состязательного анализа) в дерево через git submodule, привязанный к
конкретному коммиту — присутствует здесь, не будучи скопированным или
дублированным.
## Руководство по конфигурации — с чего начать
Исходя из последовательности реализации (§13) и области пилота P1 (§13,
§9.1: 1 серверный VLAN, маршрутизатор Debian, 2 ячейки, 802.1X, центральный реестр,
измеренная регрессия пользовательского опыта = 0):
1. **Genesis и ключи** (§7.2, §3.2) — прежде всего: церемония genesis,
подписанная кворумом контроллеров (m-of-n, HSM), закреплённая
внеполосно. [`scripts/genesis/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/scripts/genesis) предоставляет
инструментарий эпохи-0 (включая dev-путь); сама церемония остаётся
процедурной, а не кодовой — ничто в этом репозитории её не заменяет.
2. **Кластерный fencing** (§7, §13 шаг 2) — выпуск и ротация эпох,
кворум контроллеров (k-of-n) для действий класса-W, продвижение
mirror/canary. Требуется до любого многоячеечного развёртывания, включая
2-ячеечный пилот P1 ниже — одна ячейка может это отложить, пилот не может.
Реализовано в [`src/cluster/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/cluster) (трекер эпох с единым
органом, кворум, продвижение по доказательству получения — приватный ключ
там не хранится) и подключено к брокеру ([`src/broker/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/broker)).
3. **OPA + реестр** — установите OPA, сгенерируйте `policies/capabilities.json`
следуя [`policies/README.md`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/policies/README.md) (удалите
`http.send` и `time.now_ns` перед любым развёртыванием, никогда после;
`validate_determinism.go` и CI-гейт детерминизма обеспечивают это),
запустите его с `lab/docker-compose.yml` для локальной итерации по правилам.
Аттестованный манифест и измеренная загрузка (§6.3, §13 шаг 3) — состояние
самой ячейки должно быть доказуемым до того, как её решения станут
таковыми — реализованы в [`src/registry/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/registry) вместе с
журналом ячейки, backpressure и анкорингом.
4. **PEP** — первый по-настоящему управляемый периметр (§13), реализован в
[`src/pep/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/pep): валидация токенов (CWT/COSE, Ed25519),
ограниченный по памяти fail-closed анти-реплей, режим деградации при
статусе часов, квоты выполнения и гейт план-как-контракт (§4.2, §13 шаг 4 —
только валидация токена управляет одним действием, а не многошаговым
планом, который оператор фактически подписывает). Прочитайте
[`src/pep/README.md`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/pep/README.md) и
[`config/nftables/pep-redirect.nft`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/config/nftables/pep-redirect.nft)
для сетевого перенаправления на стороне Debian. **Сначала разверните в режиме
мониторинга** (логирование, без блокировки) — никогда `closed` при первом
развёртывании (доктрина §5.3); процедура переключения режима —
[`deploy/monitor-to-closed.md`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/deploy/monitor-to-closed.md). Для
PostgreSQL внутрипроцессный PEP с двумя хуками находится в
[`src/pep/postgres-extension/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/pep/postgres-extension) (§4.4).
5. **NAC параллельно** — [`config/freeradius/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/config/freeradius):
802.1X/EAP-TLS с использованием той же PKI, что и рукопожатие (§3), fail-closed
обеспечивается на уровне коммутатора (не только на стороне RADIUS), без
VLAN, назначаемого RADIUS, в v1. Наборы netns в `lab/tests/` проверяют
пути fail-closed, MAB/IoT-VLAN и OCSP-восстановления.
6. **Укрепление хоста** — [`config/sysctl/99-tbp-hardening.conf`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/config/sysctl/99-tbp-hardening.conf)
на каждой машине, запускающей компонент TBP (broker, PEP, registry).
7. **Переводчик последним** (§13) — когда всё остальное стабильно. Поставляется
в [`src/translator/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/translator): укрепление среды выполнения (non-root,
cap-drop, seccomp — отличается от `dm-verity`, который защищает образ в покое,
а не среду выполнения), конечный автомат контролируемой деградации
(только structured, без облачного резерва) и измерение качества
(`measure.py` воспроизводит корпус и проверяет CI на регрессию FNR/FPR,
`tmetrics` вписывает результат как лист реестра, T26, §4.5) — сами
корпуса формируются на пилоте, а не поставляются здесь.
8. **Многомашинное развёртывание** — [`deploy/apercu.md`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/deploy/apercu.md)
является точкой входа (что, где, почему, предварительные условия); он
синтезирует руководства по ролям (маршрутизатор, ячейка, сервер, супервизор)
и их чек-листы приёмки для каждой машины. `deploy/selftest/` **выполняет**
руководства (`bash deploy/selftest/selftest.sh`, 82 контроля,
fail-closed) — запустите его перед тем, как трогать реальную машину.
На каждом шаге измеряйте против бюджета трения (§9.1) — см.
[`tests/p1_friction/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/tests/p1_friction) для точных порогов и
запускаемого стенда. Пилот проваливается, если задержка или частота арбитража
превышают эти пороги, даже если всё остальное работает.
## Дорожная карта: соразмерные масштабы развёртывания
TBP — это сложная система управления полного масштаба — кластерный fencing, кворум,
независимый супервизор, укреплённый переводчик, межузловое
рукопожатие. Не каждому развёртыванию нужно всё это. Малый бизнес на одном
сервере, который хочет «ни один AI-агент не действует без доказуемой,
залогированной причины», не нуждается в двухъячеечном отказоустойчивом
переключении так же, как домашняя сеть не нуждается в SOC. План — упаковать то,
что уже существует в этом репозитории, в **четыре масштаба развёртывания**,
каждый из которых является строгим надмножеством предыдущего — одни и те же
примитивы на всём протяжении (fail-closed, листья только с хешами, мониторинг до
closed), их больше связано вместе по мере роста масштаба, и
безопасностная позиция — и операционная сложность, которую она покупает —
соответственно возрастает:
- **Масштаб 1 — Одна машина.** Один хост, один управляемый периметр: `pepd`
перед сервисом, локальный сайдкар OPA, единственный реестр `CellLog`.
Без кластерного fencing (нечего огораживать с одной ячейкой), без NAC
(нечего допускать в сеть — это один ящик), без демона broker или
supervisor. Genesis сводится к одной паре ключей оператора,
задокументированной как таковая, вместо притворства церемонией кворума,
которой она не является. Наименьшая операционная сложность: правильно
настроить правила OPA, развернуть в режиме мониторинга, следить за бюджетом
трения, заслужить `closed`.
- **Масштаб 2 — Малая команда / один объект.** Несколько машин в одной
LAN за одним `brokerd`, всё ещё единый реестр (fencing пока нет —
одной авторитетной ячейки всё ещё достаточно на этом размере), добавлен NAC
(`config/freeradius/`, 802.1X на коммутаторе) для допуска машин в
сегмент, укрепление хостов применяется везде. Ещё один демон, ещё одна
подсистема, та же модель реестра, что и в масштабе 1.
- **Масштаб 3 — Устойчивый многоячеечный.** То, что уже полностью построено и
задокументировано как пилотное развёртывание P1 выше: 2+ ячейки, кластерный fencing
(выпуск/ротация эпох, кворум k-of-n для действий класса-W,
продвижение mirror/canary), независимый супервизор с консолью только для чтения,
укреплённый переводчик с контролируемой деградацией, полная
последовательность руководств `deploy/` и её 82-контрольный selftest. Для организаций,
которые не могут допустить падения одной ячейки, или чьи управляемые агенты
оправдывают дополнительные машины.
- **Полный масштаб — Мульти-сущность.** Межсущностное рукопожатие (§3):
доказательство политики, непрерывности истории и живости через организационные
границы, а не только через ячейки одной организации —
федерация между независимо управляемыми развёртываниями TBP, которые должны
доверять друг другу, не доверяя друг другу. Намеренно ещё не начато;
отслеживается в [#33](https://github.com/philippeabraxas-jpg/TBP-NETWORK/issues/33)
(T32), чтобы оставаться видимым как более поздняя, отдельная фаза, а не
молча отсутствовать. Это действительно новая работа по протоколу, а не просто больше
машин, запускающих то, что уже существует.
**Честность о том, где это находится**: масштаб 3 поставлен сегодня под
именем pilot-P1, используемым во всём этом README. Масштабы 1 и 2 ещё не
упакованы как собственные руководства — они достижимы сегодня путём развёртывания
подмножества того, что задокументировано (пропустите кластерный fencing и NAC для масштаба 1,
добавьте NAC, но оставьте одну ячейку для масштаба 2), но этот путь ещё не
записан, и ничто сейчас не мешает кому-то правильно связать это самостоятельно
при соблюдении той же доктрины. Полный масштаб требует фактического нового
кода (три доказательства §3), а не просто новых руководств.
### Следующая запланированная работа
Два потока работы, отслеживаемых как отдельные issues, потому что это разные
виды усилий:
1. **Руководства по развёртыванию для каждого масштаба, плюс административный инструментарий, соразмерный каждому
масштабу** ([#86](https://github.com/philippeabraxas-jpg/TBP-NETWORK/issues/86)).
Превращение масштабов выше в `deploy/scale-1.md` /
`deploy/scale-2.md` — масштаб 3 уже имеет свою последовательность руководств, это
`deploy/apercu.md` и синтезируемые им руководства по ролям — это половина
этой работы: задокументированный, покрытый selftest путь для каждого масштаба, а не
«пилотное руководство минус то, что вы сами догадаетесь пропустить». Другая половина —
инструментарий для оператора, который сегодня представляет собой
JSON API только для чтения (`src/supervision/console.go`: `/v1/arbitration`,
`/v1/epoch`, `/v1/indicators`) плюс необработанные файлы и CLI (политики Rego,
редактируемые вручную, `policies/gen_capabilities.sh` /
`validate_determinism.go` для валидации и удаления перед развёртыванием; реестр,
читаемый проверенной проверкой `ChainWatcher`, задействованной в тестах
и selftest, но без UI для просмотра). Три специализированных инструмента
запланированы поверх того, что уже существует, каждый ограничен тем, что
действительно нужно данному масштабу (оператору масштаба 1 не нужны представления
многоячеечного арбитража; оператору масштаба 3 — нужны):
- **панель супервизии** поверх существующей консоли
только для чтения — ориентированная на человека, по-прежнему только для чтения по построению (§7.1
«супервизор видит всё, не трогает ничего» переносится
без изменений, D81);
- **редактор правил/политик** для пакета OPA Rego — редактирование, тестирование
против тех же гейтов детерминизма и удаления возможностей, которые
уже обеспечивает `validate_determinism.go`, и сравнение с тем, что
развёрнуто, прежде чем что-либо попадёт в продакшн;
- **браузер аудита** для реестра — поиск и фильтрация истории
листьев (`KindDecision`, `KindTelemetry`, `KindQuorum`, …) с
тем же проверяемым третьей стороной доказательством контрольной точки, которое `ChainWatcher`
уже делает программно, сделанным понятным для человеческого аудитора вместо
тестового утверждения.
2. **Соответствие стандартам — от проприетарной модели политик к
интероперабельной** ([#87](https://github.com/philippeabraxas-jpg/TBP-NETWORK/issues/87)).
Таксономия правил TBP (классы F/I/W/OUT, §5.3),
её аудиторский след (листья только с хешами, залогированные в Merkle, §6.2) и её
набор контролей (fail-closed, мониторинг-до-closed, кворум для
действий с высокими ставками) сегодня специфичны для TBP — внутренне согласованы
и протестированы, но не отображены на какой-либо внешний фреймворк, который аудитор или
регулятор уже признал бы. Работа состоит в том, чтобы определить, каким
существующим (и возникающим) стандартам это соответствует, и где есть пробелы —
не предполагать, что какой-либо из них применим, или что TBP уже удовлетворяет
им, без предварительного выполнения этого отображения. Кандидаты, которые стоит оценить
в качестве отправной точки: **ISO/IEC 42001** (стандарт системы управления
AI — наиболее близкое соответствие для заявления об «управлении AI»), **NIST
AI Risk Management Framework**, обязательства **EU AI Act** по логированию и
человеческому надзору для систем высокого риска (§4.1 — лист на
решение и §4.2 — арбитраж план-как-контракт структурно
близки к тому, что требуют статьи 12/14 — непроверено, нужно реальное
отображение, а не предположение), **NIST SP 800-207** (Zero Trust
Architecture — спецификация уже позиционирует TBP относительно Zero Trust в
§3.3, формальное сравнение контроль за контролем — естественный следующий
шаг), и **OSCAL** (машиночитаемый формат контролей/оценки NIST —
правдоподобная цель экспорта, чтобы собственный аудиторский след TBP мог питать
стандартный инструментарий соответствия вместо требования специализированного читателя).
Это исследовательская и спецификационная работа прежде, чем код: продукт —
это анализ пробелов и, где существует реальное отображение, либо
код адаптера, либо задокументированная эквивалентность — а не переписывание движка
правил.
## Лицензирование
Двойная лицензия, по поддереву:
- **`docs/` и `figs/`**: [CC BY 4.0](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/docs/LICENSE) — свободно делиться и
адаптировать с указанием авторства.
- **Всё остальное** (`config/`, `src/`, `policies/`, `lab/`, `tests/`,
`deploy/`, `scripts/`, `.github/`): [Apache 2.0](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/LICENSE) — та же лицензия,
что и у ядрового протокола в
[Responsible-Alliance-Protocol](https://github.com/philippeabraxas-jpg/Responsible-Alliance-Protocol).
Этот код был под закрытой лицензией во время начальной пилотной фазы; эта
фаза закончилась — проект не жизнеспособен, если строится в одиночку, и
протокол управления, чья собственная доктрина — «никогда по доверию, всегда по
проверяемому доказательству», не должен просить доверия к своей собственной реализации.
См. [`CONTRIBUTING.md`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/CONTRIBUTING.md) о том, как внести вклад — код
теперь включён, а не только документация — и правила, которым нужно следовать при
редактировании спецификации (нормализация терминологии, проверенные цитаты,
changelog).