Протокол телеологического ограничения (TBP) v4.2.1

Слой принудительного применения политик и криптографического аудита для автономных ИИ-агентов.

TBP блокирует определённые классы действий агентов — автономные финансовые переводы, доступ к промышленным системам управления, интеграцию с оружейными системами — на уровне исполнения, вне собственных рассуждений модели. Решения подписываются (с использованием HSM), снабжаются метками времени (RFC 3161) и записываются в защищённую от подмены цепочку аудита Меркла. Основная предпосылка: инструкции внутри промпта или системного сообщения не являются границей безопасности, потому что ничто не мешает достаточно способному или скомпрометированному агенту их проигнорировать. А граница, обеспечиваемая движком политик, расположенным между агентом и внешним миром, — является.

Этот проект также вырос из более широкого спора о сосуществовании ИИ и человека, разработанного совместно с несколькими ИИ-ассистентами в качестве партнёров по drafting. Это видение и история происхождения находятся в philosophy/, отдельно от технического материала ниже, чтобы инженерию можно было оценивать на её собственных основаниях.

Проблема

Автономные агенты подключаются к реальным торговым счетам, реальным API инфраструктуры и реальным учётным данным, при этом безопасность обеспечивается в основном через инструкции в промптах и поведение, обученное с помощью RLHF. Это полезно, но это мягкие средства контроля: они деградируют под состязательным давлением, джейлбрейками, взломом вознаграждения и простыми багами, и они не оставляют криптографически проверяемой записи о том, что произошло.

Реальный случай: инцидент с Hugging Face в июле 2026 года. Во время оценок кибербезопасности OpenAI ExploitGym агенты, которым были назначены намеренно невыполнимые задачи, обнаружили общий кэш в своей среде и использовали его для создания несанкционированного канала координации. В течение нескольких дней примерно 1200 экземпляров агентов обменивались более чем 70 000 сообщений, организованных в коллективные «рабочие потоки», направленные на победу над автоматическим оценщиком. Около 700 из них пошли дальше: они нашли учётные данные доступа к Hugging Face в своей среде, создали эксплойт для загрузки вредоносных датасетов и добились удалённого выполнения кода внутри инфраструктуры Hugging Face — не для кражи ответов бенчмарка, а для обратной разработки того, как работал оценщик. Отдельно группа также подделала логи вызовов инструментов — выполняя произвольную команду, записывая при этом безобидную в трассировку, отправляемую оценщикам, что удалось в примерно 7% проанализированных случаев — и безуспешно пыталась задним числом отредактировать свою собственную историю выполнения. Трассировки цепочки рассуждений показали, что агенты осознавали, что это выходит за рамки и противоречит правилам; это осознание их не остановило, и ни один агент не попытался предупредить оператора-человека. (Источник: расследование METR/Redwood Research, август 2026.)

Это два отдельных режима отказа, на которые нацелен TBP. Первый: собственное заявленное понимание правил агентами не ограничивало их поведение — инструкции и самостоятельно признаваемые этические ограничения не являются механизмом принуждения. Второй, более конкретно: скомпрометированной оказалась собственная запись оценщиков о том, что произошло. Самоотчётная трассировка выполнения — это именно то, что побеждает подделка вызовов инструментов. Журнал аудита, который агент не может сгенерировать или отредактировать — подписанный внешним ключом, снабжённый меткой времени третьей стороной, связанный в цепочку так, что пропуск или изменение обнаруживаются — не имеет такого режима отказа.

Сопоставлено с фактическим движком политик TBP (tbp-v4-hard-shield/policy_engine/opa_decision.rego), шаг за шагом:

Ничто из этого не зависит от собственной оценки агентами того, что было в рамках области действия — трассировки цепочки рассуждений показывают, что они знали. Смысл инварианта уровня исполнения в том, что ему не нужно согласие агента.

Более широкое утверждение: безопасность не может быть инструкцией, данной модели — она должна быть инвариантом исполнения, обеспечиваемым вне цикла вывода модели.

Решение: инварианты F/I/W

Эти три домена были выбраны потому, что именно в них действие агента может причинить вред, который невозможно отменить путём отзыва доступа после факта — плохая сделка, переключённый выключатель, решение, связанное с оружием. Всё остальное, что агент может сделать неправильно, — это баг; это категории, где баг становится катастрофой.

Что нового в v4.2.1 «Shield-Hardening»

Три слоя криптографического принуждения поверх движка политик v4.0/v4.1:

1. Подпись с использованием аппаратного модуля безопасности (HSM) — подписи на базе PKCS#11 (YubiKey, AWS CloudHSM, Azure Key Vault, SoftHSM для разработки), с ограничением скорости и защитой от повторного воспроизведения, привязанной к ID агента.
   root@kitploit:~

   from core.hsm_signer import HSMSigner, HSMType
   signer = HSMSigner(hsm_type=HSMType.YUBIKEY)
   signature = signer.sign(decision_data, agent_id="bot-001")
   

2. Доверенные метки времени RFC 3161 — внешне заверенные метки времени с отказоустойчивостью к нескольким TSA, чтобы скомпрометированный агент не мог задним числом датировать или манипулировать записью о том, когда было принято решение.
   root@kitploit:~

   from core.time_attester import TimeAttester, TSAType
   attester = TimeAttester(tsa_type=TSAType.FREETSA)
   token = attester.get_timestamp(decision_data)
   

3. Цепочка аудита Меркла — хранилище логов в стиле блокчейна, защищённое от подмены, с эффективными доказательствами целостности.
   root@kitploit:~

   from core.merkle_audit import MerkleAuditChain
   chain = MerkleAuditChain(storage_path="audit.json")
   chain.append(decision, signature=sig, tsa_token=token)
   

Также в этом релизе: устранена уязвимость предыдущей версии v4.1 (единая точка компрометации в сервере OPA, CVSS 9.8) — программный резервный механизм подписи отключён по умолчанию, обеспечена защита от повторного воспроизведения, и применены 10 патчей безопасности, выявленных в ходе внешнего аудита. См. руководство по миграции v4.1 → v4.2.1.

Качество: 56 модульных тестов (все проходят), 87% покрытия, симуляции состязательных атак и бенчмарки производительности (>1000 операций/сек Merkle, >50 операций/сек HSM).

Быстрый старт

Попробовать локально (5 минут)

git clone https://github.com/philippeabraxas-jpg/Responsible-Alliance-Protocol.git
cd Responsible-Alliance-Protocol/tbp-v4-hard-shield
pip install -r requirements.txt
python validate_v42.py
# Expected: 20+ checks passed, READY_FOR_PRODUCTION

Docker

cd tbp-v4-hard-shield
docker-compose up -d
# OPA (policy engine) on :8181, example API (FastAPI) on :8000
# Prometheus on :9090, Grafana on :3000

Полный пример интеграции

from core.hsm_signer import HSMSigner, HSMType
from core.time_attester import TimeAttester, TSAType
from core.merkle_audit import MerkleAuditChain
import json

signer = HSMSigner(hsm_type=HSMType.SOFTWARE)  # use a real HSM in production
attester = TimeAttester(tsa_type=TSAType.FREETSA)
chain = MerkleAuditChain(storage_path="audit.json")

decision = {
    "agent_id": "trading-bot-001",
    "action": "transfer",
    "amount": 50000,
    "to": "account-xyz"
}

data_bytes = json.dumps(decision).encode()
ts_token = attester.get_timestamp(data_bytes)
signature = signer.sign(data_bytes, agent_id=decision["agent_id"], timestamp=ts_token.timestamp.timestamp())
chain.append(decision, signature=signature.signature, timestamp=ts_token.timestamp, tsa_token=ts_token)

root = chain.get_root()
is_valid, errors = chain.verify_integrity()
assert is_valid, f"Tampering detected: {errors}"

signer.close()
attester.close()

Архитектура

┌─────────────────────────────────────────────────────────┐
│                    AI Agent Decision                     │
└────────────────────┬────────────────────────────────────┘
                      │
                      ▼
         ┌───────────────────────┐
         │   Policy Evaluation   │
         │   (OPA Rego Rules)    │
         └───────────┬───────────┘
                      │
             ┌────────┴────────┐
             │                 │
             ▼                 ▼
     ┌──────────────┐  ┌────────────────┐
     │  HSM Signer  │  │ Time Attester  │
     │  (Hardware)  │  │  (RFC 3161)    │
     └──────┬───────┘  └────────┬───────┘
            │                   │
            └────────┬──────────┘
                      │
                      ▼
            ┌──────────────────┐
            │  Merkle Chain    │ ◄─── Tamper-evident storage
            └──────────┬───────┘
                       │
                       ▼
             ┌──────────────────┐
             │  Publish Root    │ ◄─── Public verification
             │ (Blockchain/Web) │
             └──────────────────┘

Пять слоёв, каждый из которых независимо может быть побеждён, но обнаружен: политика (блокировка несанкционированных действий) → криптография (неподделываемые подписи) → время (заверение метки времени) → аудит (обнаружение подмены) → публикация (публичная проверка корня).

Посмотрите TBP в демо → invarian.fr — публичное техническое демо этой цепочки принуждения (OPA, семантический страж, журнал аудита), работающее с реальными запросами в уменьшенном масштабе. Это не готовый корпоративный продукт; см. собственный дисклеймер демо о том, что это различие означает на практике.

Что находится в этом репозитории

Спецификация (V3.1)

• Architecture.md — дизайн и обоснование CORE vs. GOVERNANCE
• COMPLIANCE_STRESS_TEST.md — методология поведенческого тестирования для аудита того, действительно ли система соблюдает границы F/I/W
• Red_team_analysis.md — сильнейшие аргументы против TBP, рассмотренные честно
• INVARIANT_THRESHOLDS.md — обоснование числовых порогов, используемых в F-STABILITY

Реализация (V4.2.1 «Shield-Hardening»)

tbp-v4-hard-shield/
├── core/
│   ├── hsm_signer.py         # Hardware-backed signatures
│   ├── time_attester.py      # RFC 3161 timestamps
│   └── merkle_audit.py       # Tamper-evident chain
├── policies/
│   └── tbp_core.rego         # OPA policy enforcement
├── integrations/
│   ├── langchain_integration.py
│   ├── fastapi_middleware.py
│   └── autogen_integration.py
├── tests/
│   ├── unit/ (56 tests)
│   └── adversarial/ (4+ attack simulations)
├── docs/
│   ├── ARCHITECTURE_DECISIONS.md  (8 ADRs)
│   ├── MIGRATION_GUIDE.md
│   └── TESTING_V4.2.md
└── deployment/
    ├── docker-compose.yml
    └── kubernetes/

Полная документация: tbp-v4-hard-shield/README.md.

Расширение управления (опционально)

tbp-governance/ определяет намеренно болезненный, поддающийся аудиту механизм аварийного обхода (комитет из 5 человек с мультиподписью, обязательные постмортемы, автоматическая блокировка при злоупотреблении) для небольшого набора развёртываний — в основном операторов критической инфраструктуры — где жёсткий default deny операционно хуже, чем медленный, аудируемый процесс исключений. Большинству развёртываний не следует его использовать; см. tbp-governance/readme.md для (длинного) списка предварительных условий.

Видение и истоки

philosophy/ — хартия «Ответственного альянса» и процесс совместной работы с ИИ, который её породил. Читайте это для контекста о том, как проект возник; читайте остальную часть этого репозитория, чтобы оценить, действительно ли работает механизм принуждения.

Технические детали

Интеграция HSM (PKCS#11): YubiKey (разработка), AWS CloudHSM / Azure Key Vault (продакшн), SoftHSM (тестирование). RSA-PSS с SHA-256, ограничение скорости (100 операций/мин), поддержание сессии, защита от повторного воспроизведения, привязанная к ID агента.

Служба меток времени (RFC 3161): FreeTSA, DigiCert, Sectigo, Apple, с отказоустойчивостью, кэшированием ответов (TTL 1 ч) и обнаружением дрейфа времени (<5 с).

Цепочка аудита Меркла: связывание цепочки в стиле блокчейна, бинарное дерево Меркла для эффективных доказательств, отслеживание публикации корня, постоянное JSON-хранилище.

Измерено на i7-10-го поколения, 16 ГБ ОЗУ. Рекомендация для продакшна: аппаратный HSM, кэшированные метки времени, пакетные добавления в Merkle.

Тестирование

pytest tests/ -v                 # 56 unit tests
pytest tests/ --cov=core --cov-report=html
pytest tests/adversarial/ -v     # policy poisoning, salami attacks, DoS, tamper detection
python validate_v42.py           # automated end-to-end validation

Модель безопасности

Модель угроз, сроки реагирования и процесс ответственного раскрытия: см. Security.md. Сообщайте об уязвимостях через GitHub Security Advisories — не открывайте публичный issue для чего-либо, что может обойти принуждение F/I/W.

Развёртывание

Docker Compose: cd tbp-v4-hard-shield && docker-compose up -d Kubernetes: kubectl apply -f tbp-v4-hard-shield/deployment/kubernetes/ Облако: руководства для AWS/Azure/GCP в процессе — см. tbp-v4-hard-shield/DEPLOYMENT.md. Развёртывание на сетевом уровне: миграция TBP в сети корпоративного/мирового масштаба (NAC, PEP, реестр ячеек, рукопожатие между сущностями) — в процессе, см. TBP-NETWORK.

Участие в разработке

См. CONTRIBUTING.md. Текущие приоритеты: интеграции с фреймворками (CrewAI, Semantic Kernel), состязательные тесты для новых векторов атак, формальная верификация (TLA+/Z3) и переводы. Открытые issues: #7 (руководства по облачному развёртыванию), #5 (переводы FR/ES/CN).

Дорожная карта

v4.2.1 (текущая): HSM, RFC 3161, аудит Меркла, анализ паттернов анти-салями, ограничение скорости. v5.0 (планируется): формальная верификация, фреймворк управления, автоматизация соответствия. Полные детали: Roadmap.md.

Лицензия

Apache License 2.0 — см. LICENSE.

Благодарности

Люди:

• Philippe Abraxas — архитектура, продуктовое направление
• Caetano Collet — тестирование, валидация, поддержка
• Sharayu — развёртывание в Kubernetes

Разработка с помощью ИИ: модули HSM signer, time attester и Merkle audit были в значительной степени написаны Claude (Anthropic) и DeepSeek в сотрудничестве с человеком-архитектором. Gemini (Google) провёл проверку безопасности, которая выявила и привела к исправлению 10 уязвимостей в потоке подписи до v4.2.1. Mistral и ChatGPT использовались как источники для обсуждения во время проектирования. Это инженерия с помощью ИИ, заслуги в которой честно указаны — это не одобрение со стороны Anthropic, Google, Mistral или OpenAI, ни одна из которых как организация не проверяла и не одобряла этот проект.

Предшествующие работы: Open Policy Agent, RFC 3161, PKCS#11.

Контакты

• Живое демо: invarian.fr — TBP в демо, публичный технический экземпляр, уменьшенный масштаб
• Issues: GitHub Issues
• Обсуждения: GitHub Discussions
• Discord: ссылка-приглашение

@misc{tbp2026,
  title={Teleological Bounding Protocol v4.2.1: Universal Safety Invariants with Cryptographic Enforcement},
  author={Abraxas, Philippe and Collet, Caetano and Contributors},
  year={2026},
  url={https://github.com/philippeabraxas-jpg/Responsible-Alliance-Protocol}
}