TBP-NETWORK

**Teleological Bounding Protocol (TBP)**의 네트워크 수준 구현 — 단일 머신에서 WWW 규모의 엔터프라이즈 배포에 이르기까지, 네트워크를 통한 AI 에이전트 행동의 증명된 거버넌스.

« 기존의 접근 제어는 당신이 들어올 수 있는지를 결정한다; TBP는 일단 들어온 후 무엇을 할 수 있는지를 결정한다 — 그리고 그것을 증명한다. 우리는 모델이 아니라 역량을 통치한다. »

신뢰에 의한 파트너십은 결코 없다 — 오직 증명된 핸드셰이크에 의해서만. 그것이 목표다: 개체 간 핸드셰이크(명세 §3)는 서로를 신뢰하지 않는 개체들이 정책, 이력, 활성 상태를 서로에게 증명할 수 있게 한다. 핸드셰이크 자체는 아직 구축되지 않았다 (#33). 이 저장소가 오늘 담고 있는 것은 그 이전에 오는 것과 그것이 기반할 것들이다 — PEP, 셀 브로커와 레지스트리, NAC, 감독, 배포 가이드 — 이는 TBP의 거버넌스를 단일 머신에서 하나의 조직 아래 있는 소규모 머신 네트워크로 확장한다.

사용해 보기: 세 대의 머신에서 TBP의 DEV-TEST

프로덕션용이 아니다. 일회용 키, 잃어버려도 되는 머신, 실제 데이터 없음. 프로덕션 릴리스가 하기 전에 당신이 TBP를 깨뜨려 볼 수 있도록 존재한다.

TBP-NETWORK는 프로덕션 릴리스가 존재하기 전에 실행하고 공격해 볼 수 있는 간단한 배포를 제공한다. 세 대의 머신, 각각 하나의 스크립트로 배포된다: M1 셀(brokerd와 그 OPA), M2 애플리케이션 서버(pepd와 소규모 애플리케이션), M3 에이전트. 이것은 전체가 작동하는지를 테스트한다 — 인증서로 등록된 에이전트, 상호 TLS를 통한 결정, 서버가 검사하는 토큰, 컨트롤러가 통치하는 서버의 상태 — 실제 바이너리와 실제 집행으로; 오직 키 의례만 단순화되었다. 단일 머신 변형을 통해 셀만 따로 살펴볼 수 있다.

모든 것이 **deploy/dev-test/**에 있다: 각 머신의 용도와 이유, 새 Debian 12 머신에서의 정확한 절차, 테스트할 시나리오, 어디를 공격할지, 그것이 증명하는 것과 증명하지 않는 것 — 그리고 당신이 시도하는 각 환경에 대해 우리에게 수치와 의견을 보내는 방법, 우리가 원하는 것. 악용 가능한 것은 모두 SECURITY.md를 통해, 공개 이슈가 아니라.

TBP가 무엇인지 — 그리고 무엇이 아닌지

TBP는 모든 구멍을 막지 않는다; 모든 구멍을 감사한다. 그것은 우회해야 할 한계가 아니라, 창립 가정이다(명세 §1: "우리는 모든 구멍을 막지 않는다; 우리는 구멍을 영향도로 순위 매기고 비례적으로 완화한다 — 거버넌스는 완전성이 아니라 할당이다"). TBP는 자급자족적인 보안 시스템이 아니다 — SELinux, 방화벽, IAM, 또는 OS 수준 샌드박싱을 대체하지 않으며, 설계상 결코 그럴 것이다. 그것이 하는 일은 더 좁고 양보할 수 없다: 어떤 통치된 행동도 암호학적으로 증명 가능한 결정 없이 실행되지 않으며, 어떤 결정도 — 허용이든 거부든 — 증명 불가능하거나 손상된 채로 감사 체인을 벗어나지 않는다. TBP는 배포가 이미 가진 집행 스택 위에 있는 거버넌스 및 증명 계층이지, 그것의 대체물이 아니다.

TBP가 얼마나 제한하는지는 프로토콜 속성이 아니라 배포 선택이다. 전면 허용 (모니터 모드, 모든 것이 기록되고 아무것도 차단되지 않음)과 전면 거부 사이에는 전체 스펙트럼이 있으며, 이는 셀이 어떤 OPA 규칙 팩을 로드하는지, 어떤 규모 (아래)에서 작동하는지, 그리고 계획 계약, 정족수, (계획된) 위험 점수 계층을 얼마나 밀어붙이는지에 의해 형성된다 (#177–#181). 개인 랩과 규제된 프로덕션 셀은 동일한 프로토콜을 그 스펙트럼의 매우 다른 지점에서 실행할 수 있으며, 그것은 격차가 아니라 설계다 — 규모별 관리 콘솔을 위해 계획된 규칙 팩 / 상태 프리셋은 아래 "다음 계획된 작업"을 참조.

그 스펙트럼의 어느 지점에서도 정확히 두 가지는 움직이지 않는다:

1. 핵심 프로토콜이 담지하는 세 가지 양도 불가능한 불변식 — F-STABILITY (자율적 가치 이전 / 시장 조작 없음), I-INTEGRITY (산업/OT 시스템의 자율적 에이전트 제어 없음), W-MONOPOLY (치명적 킬 체인 또는 WMD 개발로의 통합 없음) — 참조 tbp4.2.1/README.md. 이것들은 나쁜 행동이 사후에 접근을 취소함으로써 되돌릴 수 없는 범주다; 어떤 배포 상태, 규칙 팩, 규모도 결코 이것들을 완화하지 않는다.
2. 증명 가능한 감사 — 어떤 행동이 일어났다는 것, 그리고 그 기록이 변조되지 않았다는 것은 항상 구성에 의해 증명 가능하다(해시 전용 리프, 머클 앵커 체인, §6.2), 그 위에 로드된 정책이 얼마나 관대하거나 엄격한지와 무관하게.

그 외 모든 것 — 허용 봉투가 얼마나 넓은지, 운영자가 얼마나 많은 마찰을 받아들이는지, 어떤 구성이 인간 서명을 요구하는지 — 은 프로토콜 자체의 속성이 아니라 복잡성, 운영 필요, 그리고 주어진 배포가 실제로 실행할 수 있는 것 사이의 선택이다.

언어에 관한 참고: 참조 명세는 이제 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, 프랑스어 원본의 영어 번역)는 내용 면에서 대체되지 않았다 — 그것은 같은 프로토콜이며 거기서 먼저 개발되었다 — 그러나 앞으로 인용 가능한 참조는 아니다.

읽는 데 유용한 지표:

• §1 교리 — 열 가지 양보할 수 없는 규칙.
• §13 구현 순서 — 따라야 할 순서(HSM → OPA → PEP → NAC → 번역기), 그리고 파일럿 P1의 정확한 범위.
• §9.1 마찰 예산 — TBP 배포가 실제로 작동하는지를 결정하는 지연 시간과 중재율 임계값; 모든 구성 결정에서 이것을 염두에 두라.
• docs/glossaire.md — 개념당 하나의 정규 용어, 이 저장소의 코드와 문서 전반에 걸쳐 일관되게 사용될 것 (CONTRIBUTING.md 참조).

메인 TBP 저장소와의 관계

프로토콜 자체 — 명세, 형식 교리, 적대적 감사, 핵심 구현(HSM 서명, 머클 감사 체인, OPA 정책 엔진) — 는 Responsible-Alliance-Protocol에 있으며, Apache 2.0(오픈)으로 라이선스되고, 여기 트리 내 tbp4.2.1/에 특정 커밋에 고정된 git 서브모듈로 벤더링되어 있다 — 포크가 아니라 포인터: 이 저장소는 그 코드에 대해 이슈나 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), 결코 자동이 아니다. 업스트림의 보안 수정 뒤로 조용히 뒤처지는 고정된 서브모듈은 서브모듈이 전혀 없는 것보다 나쁘다 — 그것을 올리는 것을 다른 의존성 업데이트와 같은 주의로 다루고, 먼저 핵심 저장소 자체의 변경 로그를 확인하라.

규정 준수 매핑

TBP는 21개의 외부 보안, AI 거버넌스, 규제 프레임워크에 대해 통제 항목별로 점검되었다 — 마케팅 주장이 아니라, 무엇이 커버되고, 무엇이 부분적이며, 무엇이 구조적으로 TBP의 범위 밖인지에 대해 정직한 격차 분석으로서. 전체 분석(표준당 하나의 파일, 모든 ✅ 뒤의 정확한 메커니즘에 대한 인용 포함)은 tbp-compliance/에 있다; 이 표는 요약이다.