philippeabraxas-jpg/tbp-networkTeoria e implementação do protocolo TBP para proteger IA em rede em redes pequenas a abertas da web
Implementação em nível de rede do Teleological Bounding Protocol (TBP) — governança atestada de ações de agentes de IA numa rede, de uma única máquina a implantações empresariais até à escala da WWW.
« O controlo de acesso existente decide se entras; o TBP decide o que te é permitido fazer depois de entrares — e prova-o. Governamos capacidades, não modelos. »
Nunca uma parceria por confiança — apenas por um handshake atestado. Esse é o objetivo: o handshake entre entidades (spec §3) permite que entidades que não confiam umas nas outras provem política, histórico e vivacidade entre si. O handshake em si ainda não está construído (#33). O que este repositório contém hoje é o que vem antes dele e aquilo em que ele se apoiará — os PEPs, o broker de célula e os registos, NAC, supervisão, os guias de implantação — o que estende a governança do TBP de uma única máquina para uma pequena rede de máquinas sob uma organização.
Não para produção. Chaves descartáveis, máquinas que podes perder, sem dados reais. Existe para que possas tentar quebrar o TBP antes que um lançamento de produção o faça.
O TBP-NETWORK inclui uma implantação simples para executar e atacar antes de existir um lançamento de produção. Três máquinas,
cada uma implantada por um script: M1 a célula (brokerd e o seu OPA), M2 um servidor de aplicação (pepd e uma
pequena aplicação), M3 um agente. Testa que o conjunto funciona — um agente inscrito pelo seu certificado,
uma decisão sobre mutual TLS, um token verificado por um servidor, a postura do servidor governada pelos controladores — com os
binários reais e a aplicação real; apenas a cerimónia de chaves é simplificada. Uma variante de uma só máquina permite-te olhar para a
célula isoladamente.
Está tudo em deploy/dev-test/: para que serve cada máquina e porquê, o procedimento exato a partir de máquinas Debian 12 limpas, o cenário a testar, onde atacar, o que prova e o que não prova — e como nos enviar os teus números e comentários para cada ambiente que experimentares, o que queremos. Qualquer coisa explorável passa por SECURITY.md, não por uma issue pública.
O TBP não fecha todos os buracos; audita todos os buracos. Isso não é uma limitação a contornar, é o postulado fundador (spec §1: "não fechamos todos os buracos; classificamos os buracos por impacto e mitigamos proporcionalmente — a governança é alocação, não completude"). O TBP não é um sistema de segurança autossuficiente — não substitui SELinux, firewalls, IAM ou sandboxing ao nível do SO, e nunca o fará por design. O que faz é mais restrito e não negociável: nenhuma ação governada é executada sem uma decisão criptograficamente provável, e nenhuma decisão — permitir ou negar — escapa à cadeia de auditoria de forma não provável e não corrompida. O TBP é uma camada de governança e atestação sobre qualquer stack de aplicação que uma implantação já tenha, não um substituto dela.
Quanto o TBP restringe é uma escolha de implantação, não uma propriedade do protocolo. Entre permitir-tudo (modo de monitorização, tudo registado, nada bloqueado) e negar-tudo existe todo um espetro, moldado por quais pacotes de regras OPA uma célula carrega, em que escala (abaixo) opera, e até onde empurra contratos de plano, quórum e a (planeada) camada de pontuação de risco (#177–#181). Um laboratório pessoal e uma célula de produção regulada podem executar o protocolo idêntico em pontos muito diferentes desse espetro, e isso é por design, não uma lacuna — ver "Próximo trabalho planeado" abaixo para os presets de pacotes de regras / postura planeados para a consola de administração por escala.
Exatamente duas coisas não se movem, em nenhum ponto desse espetro:
tbp4.2.1/README.md.
Estas são as categorias onde uma ação má não é reversível
revogando o acesso após o facto; nenhuma postura de implantação, pacote de regras ou
escala alguma vez as relaxa.Tudo o resto — quão amplo é o envelope permitido, quanta fricção um operador aceita, que composições exigem uma assinatura humana — é uma escolha entre complexidade, necessidade operacional e o que uma dada implantação consegue realmente executar, não uma propriedade do protocolo em si.
Nota sobre a linguagem: a especificação de referência é agora
docs/spec-en-v1.0.md (inglês) — este é o
documento de código e as auditorias devem ser construídas contra ele. O seu número de versão
reinicia para 1.0 deliberadamente: é um recomeço limpo para um documento citável e versionado
(§13: "versionado conservadoramente; as alterações passam por transições assinadas
e atestadas"), não uma continuação da contagem da própria nota de trabalho —
a nota de trabalho com número mais alto não é o documento mais recente. A
nota de trabalho do autor — mais densa, menos linear, útil para escavar a justificação de design,
mas não a que se deve citar — existe em duas línguas:
docs/spec-v1.4.10.md (inglês) e
docs/spec-v1.4.10.fr.md (francês original).
A mesma convenção aplica-se em todo o repositório: cada documento originalmente
escrito em francês tem agora um primário em inglês no seu caminho original, com
o original francês mantido ao lado como <name>.fr.md. O glossário
(docs/glossaire.md) continua a ter origem francesa (§14 do documento francês é
a sua fonte de verdade terminológica) com uma coluna de glosa em inglês para
legibilidade — isto está inalterado.
A especificação completa é docs/spec-en-v1.0.md
— é a fonte de verdade para qualquer decisão de design ou configuração neste
repositório. Este README apenas resume o necessário para se orientar;
em caso de dúvida, a spec governa. A nota de trabalho
(docs/spec-v1.4.10.md, tradução inglesa do original francês) não
está ultrapassada em termos de conteúdo — é o mesmo protocolo, desenvolvido lá
primeiro — mas não é a referência citável daqui em diante.