agent-interlock

Agent Interlock é um framework Python 3.11 (Apache-2.0) que aplica a ideia de engenharia de segurança de um interlock à interação agente-para-agente. Os atores são declarados em manifestos ActorSpec, a superfície de cada ator é envolvida com um SDK ou proxy, e a comunicação entre eles é observada, julgada e bloqueada para que apenas links declarados possam se conectar. O projeto centra-se em um gateway de ferramentas MCP. As ameaças de M1 a M9 - envenenamento de ferramentas, rug pull, sombreamento de ferramentas, publicação de ferramentas envenenadas, confused deputy ou passthrough de token, comprometimento do host via servidor MCP, descoberta ou modificação de configuração de agente, colheita de credenciais e exfiltração de dados - são tratadas no nível do fluxo de dados, cada uma com vereditos padrão como QUARANTINE, BLOCK, HOLD, CHALLENGE ou SANITIZE. A aplicação é promovida em estágios de OBSERVE, passando por SHADOW até ENFORCE, e a promoção para ENFORCE requer duas aprovações assinadas. Uma única tabela de Check com 29 verificações sustenta três pontos de aplicação, cada um selecionando seu próprio perfil: gateway MCP com 21 verificações, SDK com 19 e broker A2A com 17. O README afirma claramente que o mecanismo é compartilhado, mas a cobertura não é, e que o broker não possui controle de egresso, volume ou taint. Os componentes incluem o SDK (define_actor, connect, wrap), um runtime que intercepta a comunicação inter-ator, um orquestrador que executa DAGs de tarefas verificadas via transportes A2A, MCP e humanos, um broker A2A que lida com cartões de agente e tarefas com pré-aplicação, um ledger append-only que registra eventos de requisição, veredito, ação e resultado separadamente, visualizações de grafo para caminhos de design, runtime e ataque, uma UI web Studio baseada em boxes para edição de arquitetura e exportação de manifestos, um adaptador Anthropic Tool Runner e um comando interlock verify que executa nove cenários L1 contra as próprias ferramentas protegidas do projeto, em vez de fixtures do framework. Outras áreas evidenciadas incluem ferramentas MCP JSON-RPC tools/list, tools/call e a aplicação de list-changed vinculada a digests de arquitetura; um cliente Streamable HTTP JSON/SSE com vinculação de sessão; descoberta MCP OAuth, PKCE S256, introspecção RFC 7662, verificação opcional de JWKS/JWT e consentimento de loopback; um cliente stdio JSONL com pinning de artefatos, atestação de sandbox assinada e planos de lançamento Bubblewrap; admissão de proveniência assinada para publicadores; guardas de egresso por destino compiladas a partir de manifestos de arquitetura; particionamento PostgreSQL, FORCE RLS baseado em session_user e um adaptador de ledger append-only com APIs HTTP de evento e trace; ingestão OTLP/HTTP JSON; sinks de auditoria assinados; reconciliação de drift entre design e runtime para arestas multi-agente; limites de confiança internos/externos direcionais; e uma suíte de cenários end-to-end de dados falsos com fixtures determinísticas usando endereços .invalid. O núcleo de referência não possui dependências de runtime externas, com integrações PostgreSQL e Anthropic como extras opcionais. O README é franco sobre o que não foi entregue: nenhum adaptador LangGraph ou Claude Agent SDK, nenhum proxy sidecar, a interceptação do conector MCP no lado do servidor ficou fora de escopo porque essas ferramentas são executadas no lado do provedor, um avaliador de aceitação que é apenas estrutural e um parser de manifesto que ainda descarta alguns campos e ações de efeito colateral. Também registra que o SDK não consegue acessar a API de aprovação do gateway, portanto, uma gravação externa de uma ferramenta envolvida falha no modo fechado (fails closed) em vez de ser aprovável via SDK. Trabalhos de integração externa genuínos, como Sigstore, KMS/HSM, provedores de identidade, sidecars de egresso reais, TLS e rate limiting distribuído, constam como pendentes.