philippeabraxas-jpg/tbp-networkТеория и реализация протокола TBP для защиты сетевого ИИ в малых и открытых веб-сетях
Сетевая реализация Teleological Bounding Protocol (TBP) — аттестованное управление действиями ИИ-агентов в сети, от одной машины до корпоративных развёртываний вплоть до масштаба WWW.
« Существующий контроль доступа решает, попадёте ли вы внутрь; TBP решает, что вам разрешено делать, оказавшись внутри — и доказывает это. Мы управляем возможностями, а не моделями. »
Никогда не партнёрство по доверию — только по аттестованному рукопожатию. Такова цель: межсубъектное рукопожатие (спецификация §3) позволяет субъектам, которые не доверяют друг другу, доказывать друг другу политику, историю и работоспособность. Само рукопожатие ещё не построено (#33). То, что этот репозиторий содержит сегодня, — это то, что предшествует ему и на что оно будет опираться — PEP, брокер ячеек и реестры, NAC, супервизия, руководства по развёртыванию — что расширяет управление TBP с одной машины до небольшой сети машин в рамках одной организации.
Не для продакшена. Одноразовые ключи, машины, которые не жалко потерять, никаких реальных данных. Это существует, чтобы вы могли попытаться взломать TBP раньше, чем это сделает продакшен-релиз.
TBP-NETWORK поставляет простое развёртывание, чтобы запустить и атаковать до того, как появится продакшен-релиз. Три машины,
каждая разворачивается одним скриптом: M1 — ячейка (brokerd и её OPA), M2 — сервер приложений (pepd и
небольшое приложение), M3 — агент. Это проверяет, что вся система работает — агент, зарегистрированный по своему сертификату,
решение по взаимному TLS, токен, проверенный сервером, состояние сервера, управляемое контроллерами — с
реальными бинарниками и реальным принуждением; упрощена только церемония работы с ключами. Вариант на одной машине позволяет посмотреть на
ячейку отдельно.
Всё находится в deploy/dev-test/: для чего предназначена каждая машина и почему, точная процедура начиная со свежих машин Debian 12, сценарий для тестирования, где атаковать, что это доказывает и что не доказывает — и как прислать нам свои цифры и комментарии для каждой среды, которую вы попробуете, чего мы и хотим. Всё, что связано с эксплойтами, идёт через SECURITY.md, а не в публичный issue.
TBP не закрывает все дыры; он проводит аудит каждой дыры. Это не ограничение, которое нужно обойти, это основополагающий постулат (спецификация §1: «мы не закрываем все дыры; мы ранжируем дыры по воздействию и смягчаем их пропорционально — управление есть распределение, а не полнота»). TBP не является самодостаточной системой безопасности — он не заменяет SELinux, межсетевые экраны, IAM или песочницы уровня ОС, и по замыслу никогда не будет. То, что он делает, — уже и бескомпромиссно: ни одно управляемое действие не выполняется без криптографически доказуемого решения, и ни одно решение — разрешающее или запрещающее — не избегает цепочки аудита, оставаясь недоказуемым и неискажённым. TBP — это слой управления и аттестации поверх любого стека принуждения, который уже есть у развёртывания, а не его замена.
Насколько TBP ограничивает — это выбор развёртывания, а не свойство протокола. Между allow-all (режим мониторинга, всё логируется, ничего не блокируется) и deny-all лежит целый спектр, определяемый тем, какие наборы правил OPA загружает ячейка, на каком масштабе (см. ниже) она работает и насколько далеко она продвигает контракты планов, кворум и (планируемый) слой оценки рисков (#177–#181). Личная лаборатория и регулируемая продакшен-ячейка могут запускать идентичный протокол в очень разных точках этого спектра, и это по замыслу, а не пробел — см. «Планируемая дальнейшая работа» ниже о пресетах наборов правил / состояний, планируемых для админ-консоли по масштабам.
Ровно две вещи не двигаются ни в одной точке этого спектра:
tbp4.2.1/README.md.
Это категории, где плохое действие не обратимо
отзывом доступа задним числом; никакое состояние развёртывания, набор правил или
масштаб никогда их не ослабляет.Всё остальное — насколько широк разрешённый конверт, сколько трения принимает оператор, какие композиции требуют человеческой подписи — это выбор между сложностью, операционной необходимостью и тем, что данное развёртывание действительно может запустить, а не свойство самого протокола.
Замечание о языке: эталонная спецификация теперь —
docs/spec-en-v1.0.md (английский) — это
документ, по которому следует строить код и аудиты. Его номер версии
сброшен до 1.0 намеренно: это чистый перезапуск в цитируемый, версионированный
документ (§13: «версионируется консервативно; изменения проходят через подписанные,
аттестованные переходы»), а не продолжение собственного счёта рабочей заметки —
рабочая заметка с большим номером не является более новым документом. Рабочая заметка
автора — плотнее, менее линейна, полезна для копания в обосновании дизайна, но не та, на которую следует ссылаться — существует на двух языках:
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, английский перевод французского оригинала) не
вытеснена по содержанию — это тот же протокол, впервые разработанный там — но она не является цитируемым эталоном в дальнейшем.