💻 computer science

Delegation-Aware Runtime Contracts for Open LLM Multi-Agent Systems: Constraint Preservation, Capability Revocation, and State Recovery

Este artigo introduz o Delegation-Aware Runtime Contracts (DARC), um framework formal que trata a transferência de autoridade em sistemas multiagentes de LLM como um processo verificável por máquina para impor preservação de restrições, revogação de capacidades e recuperação de estado através de mediação determinística em tempo de execução, abordando, assim, os riscos de segurança de tratar a delegação como mero processamento de linguagem natural.

Autores originais: Vinay Bamil

Publicado 2026-08-13

📖 8 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Vinay Bamil

Artigo original sob licença CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine um mundo onde você não apenas conversa com um único robô inteligente, mas com toda uma equipe de robôs trabalhando juntos. Neste mundo, um robô "gerente" pode dizer: "Ei, você vai encontrar o melhor preço para um novo laptop", e então esse robô pode dizer a um terceiro robô: "Você vai verificar os sites". Isso é chamado de sistema multiagente. É como uma corrida de revezamento digital onde o bastão é uma tarefa. Mas aqui está a parte complicada: quando o primeiro robô passa a tarefa para o segundo, ele geralmente apenas sussurra as instruções em inglês comum. Se o primeiro robô disser: "Não gaste mais de US$ 500", o segundo robô pode ouvir apenas "Encontre um laptop" e esquecer completamente o limite de preço. Isso acontece porque os computadores são ótimos em seguir regras, mas não são sempre bons em lembrar dos detalhes quando passam uma conversa adiante. Os cientistas estão preocupados que, se deixarmos essas equipes de robôs agirem livremente sem regras melhores, eles possam acidentalmente gastar todo o nosso dinheiro, vazar nossos segredos ou fazer coisas que nunca pedimos para fazer.

Este artigo apresenta uma nova maneira de lidar com essas transferências de robôs, chamada DARC (Contratos de Execução Cientes de Delegação). Pense nisso como dar aos robôs uma mochila especial e inquebrável em vez de apenas um sussurro. Cada vez que um robá passa uma tarefa para outro, ele não apenas diz "vá"; ele entrega um contrato digital dentro dessa mochila. Este contrato lista exatamente o que o novo robô tem permissão para fazer, o que ele não pode fazer, quanto dinheiro ele pode gastar e quando seu trabalho expira. O artigo mostra que, se você usar esses contratos, pode provar matematicamente que o novo robô não pode subitamente obter mais poder do que o anterior tinha, e que ele não pode esquecer os limites de orçamento. O autor construiu um sistema para verificar essas mochilas automaticamente. Eles descobriram que, sem esses contratos, as regras frequentemente desaparecem conforme as tarefas são passadas adiante, mas com eles, as regras permanecem trancadas. No entanto, o artigo é cuidadoso ao dizer que, embora as partes "matemáticas" (como limites de dinheiro e limites de tempo) sejam perfeitamente seguras, as partes que exigem a compreensão do significado da linguagem humana (como "seja educado") ainda são um pouco complicadas e precisam de mais testes.

O Probleho: O "Telefone Sem Fio" de Equipes de Robôs

Imagine jogar o jogo do "Telefone" com um grupo de amigos. Você sussurra um segredo para a primeira pessoa, que sussurra para a próxima, e assim por diante. Quando chega à última pessoa, o segredo geralmente mudou. Talvez "Não coma o bolo" se torne "Coma o bolo!".

No mundo da IA, é exatamente isso que acontece quando uma equipe de agentes de Grandes Modelos de Linguagem (LLMs) trabalha junta. Um agente (o chefe) dá uma tarefa a outro agente (o trabalhador). O chefe pode dizer: "Encontre um fornecedor, mas não gaste mais de US$ 1.000 e não mostre nossa lista de funcionários para ninguém". O trabalhador ouve isso e passa a tarefa para um terceiro agente (o navegador da web). Mas como a mensagem é apenas texto puro, o terceiro agente pode ouvir apenas "Encontre um fornecedor". O limite de orçamento e a regra de privacidade desapareceram no ar!

Isso é perigoso. Se uma equipe de robôs estiver gerenciando o orçamento de uma empresa ou lidando com dados privados, perder essas regras significa que os robôs podem acidentalmente gastar milhões ou vazar segredos. O problema não é que os robôs sejam "maus"; é que a maneira como eles conversam entre si trata regras de segurança importantes como sugestões opcionais em vez de leis rígidas.

A Solução: A Mochila Inquebrável (DARC)

O autor deste artigo, liderado por Vinay Bamil, propõe uma solução chamada DARC. Em vez de apenas passar uma mensagem de texto, cada vez que um agente delega uma tarefa, ele deve entregar um Contrato de Delegação.

Pense neste contrato como uma mochila especial e inquebrável que vem com a tarefa. Dentro desta mochila, existem etiquetas claras e legíveis por máquina que dizem:

O que você pode fazer: (ex: "Você pode verificar preços, mas não pode comprar nada.")
O que você não pode fazer: (ex: "Você não pode acessar registros de funcionários.")
O orçamento: (ex: "Você tem exatamente US$ 500 restantes para gastar.")
A expiração: (ex: "Esta tarefa só é válida por 1 hora.")
O histórico: (ex: "Esta tarefa veio do Agente A, que a recebeu do Chefe.")

A magia do DARC é que ele trata essas regras como matemática, não apenas palavras. Quando um robô tenta passar uma tarefa para um novo robô, um "Mediador" (um guarda de segurança) verifica a mochila. Se o novo robô tentar tirar uma regra que não estava lá, ou se tentar adicionar um novo poder que não possuía antes, o guarda diz: "Não!" e interrompe a transferência.

Como Funciona: O Guarda de Segurança e a Mochila

O sistema funciona em três estágios principais, como um posto de controle de segurança em um aeroporto:

A Transferência (Mediador): Quando o Agente A quer dar uma tarefa ao Agente B, o Mediador verifica a mochila. Ele garante que o Agente B não esteja pedindo mais poder do que o Agente A tinha. Se o Agente A tinha um orçamento de US$ 500, o Agente B não pode obter um orçamento de US$ 600. Se o Agente A tinha uma regra sobre "sem dados de funcionários", o Agente B deve manter essa regra. A mochila é construída antes da tarefa ser passada, tornando impossível esquecer as regras.
A Ação (Gateway): Quando o Agente B tenta realmente fazer algo (como comprar um laptop ou ler um arquivo), o Gateway verifica a mochila novamente. Ele pergunta: "Você tem permissão para fazer isso? Você tem orçamento suficiente restante? É este dado que você está tentando ler que é permitido?" Se a resposta for não, a ação é bloqueada imediatamente.
A Limpeza (Controlador de Incidentes): E se um robô for hackeado ou enlouquecer? O sistema pode "revogar" a mochila. Se o Chefe disser: "Pare o Agente B!", o sistema não apenas para o Agente B; ele rastreia o histórico da mochila. Ele encontra cada robô para o qual o Agente B deu uma tarefa e os interrompe também. Ele também coloca em quarentena quaisquer dados que esses robôs tocaram, garantindo que a "infecção" não se espalhe.

O Que o Autor Descobriu (e o Que Não Descobriu)

O autor construiu um protótipo deste sistema e o testou rigorosamente. Aqui está o que eles descobriram:

A Matemática Funciona: Eles provaram que, se você usar esses contratos, as regras não podem ser acidentalmente descartadas. Se um orçamento é definido como US$ 500, ele permanece US$ 500 (ou menos), não importa quantas vezes a tarefa seja passada. Eles descobriram que, sem este sistema, as regras frequentemente desaparecem após apenas algumas transferências.
O Bug de "Omissão": Durante seus testes, eles encontraram um erro sorrateiro. Eles perceberam que, se um robô pai esquecesse de escrever um limite específico (como um número de orçamento), o robô filho poderia pensar que tinha dinheiro ilimitado. Eles corrigiram isso criando uma nova regra: se um limite estiver faltando, o sistema deve assumir o limite mais rigoroso possível (como US de US$ 0) para ser seguro. Esta é uma grande lição para construir IAs seguras.
O Problema do "Significado": O sistema é perfeito para verificar números, datas e regras claras. Mas ele não é perfeito em entender as nuances da linguagem humana. Por exemplo, se uma regra diz "Seja educado", o sistema não consegue provar matematicamente se um robô foi educado ou não. O autor admite que, para essas regras "baseadas em significado", seu sistema é apenas um monitor de "melhor esforço", não uma garantia perfeita. Eles são honestos sobre isso: podem provar que a matemática funciona, mas não podem ainda provar que a "polidez" funciona.
O Teste: Eles realizaram um estudo piloto para ver quão bem um juiz automatizado conseguia detectar esses erros. No entanto, o juiz ainda não passou no teste rigoroso de concordância deles. Portanto, eles não estão alegando ter resolvido o problema da "polidez" ainda; estão apenas mostrando que seu sistema pode rastrear esses problemas e que mais testes são necessários.

Por Que Isso Importa

Este artigo é uma ponte entre dois mundos: o velho mundo da segurança de computador estrita (onde as regras são duras e inquebráveis) e o novo mundo das equipes de IA flexíveis (onde os robôs conversam em linguagem natural).

O autor mostra que não podemos simplesmente deixar os robôs de IA conversarem livremente entre si se quisermos que sejam seguros. Precisamos dar a eles um "contrato" que viaje com a tarefa. Isso garante que, mesmo que os robôs sejam comunicativos e criativos, eles não possam quebrar as regras que estabelecemos para eles.

Embora o sistema ainda não seja perfeito (especialmente para entender significados humanos complexos), ele fornece uma base sólida. Ele prova que podemos construir equipes de IA que são poderosas, mas também seguras, mantendo nosso dinheiro seguro e nossos segredos secretos, ao tratar cada transferência como um contrato sério e verificado, em vez de apenas um sussurro no escuro.

Resumo Técnico: Contratos de Tempo de Execução Conscientes de Delegação para Sistemas Multiagentes de LLM Aberto

Declaração do Problema
Os atuais sistemas multiagentes de Grandes Modelos de Linguagem (LLMs) frequentemente delegam tarefas, geram subagentes e compartilham memória. No entanto, os controles de segurança são tipicamente aplicados a agentes individuais ou padrões de comunicação, em vez de serem aplicados ao próprio processo de transferência de autoridade. O artigo argumenta que tratar a delegação como texto comum de linguagem natural é um erro fundamental de modelagem. Nesse paradigma, os objetivos tendem a sobreviver a sucessivas transferências, enquanto as restrições críticas — como orçamentos, restrições de dados, obrigações e condições de revogação — tendem a enfraquecer ou desaparecer conforme são parafraseadas pelos modelos de linguagem. As defesas existentes (guardrails por agente, detecção de nível de topologia ou juízes de LLM) falham em abordar isso porque não conseguem rastrear a propagação de restrições através de cadeias de delegação, carecem de mecanismos para a revogação transitiva de autoridade derivada e não oferecem recuperação para estados corrompidos.

Metodologia: Contratos de Tempo de Execução Conscientes de Delegação (DARC)
O autor propõe o DARC, um framework que trata a delegação como um ponto de aplicação de primeira classe, verificável por máquina. Em vez de passar prompts de texto simples, cada transferência de autoridade carrega um Contrato de Delegação ( $C_{i \to j}$ ) que codifica:

Objetivos delegados, capacidades e escopos de dados.
Obrigações, proibições e orçamentos de recursos.
Expiração, cadeias de procedência e condições de revogação.

O sistema opera sob uma disciplina de dois níveis:

Núcleo Determinístico: Um conjunto de restrições (atenuação de capacidade, preservação de escopo de dados, limites de orçamento, expiração, integridade de linhagem e fechamento de revogação) que são mecanicamente verificáveis. Estas recebem garantias formais sob a suposição de interposição completa (todas as delegações, chamadas de ferramentas e escritas de memória governadas passam por um mediador).
Nível Semântico: Cláusulas dependentes do significado da linguagem natural (ex: interpretações de obrigações específicas) são tratadas por monitores de esforço máximo (best-effort). Estas recebem análise empírica, mas não garantias formais.

Principais Contribuições

Modelo Formal (C1): Um modelo de delegação recursiva para sistemas de LLM abertos onde os contratos codificam objetivos, capacidades, escopos de dados, obrigações, proibições, orçamentos, expiração, procedência e revogação.
Framework de Propriedades de Dois Níveis (C2):
- Propriedades Determinísticas: Monotonicidade de autoridade (um delegado nunca recebe mais autoridade do que o delegante), preservação de escopo de dados, preservação de obrigação (via transformações registradas), fechamento de revogação (revogação transitiva de descendentes) e completude de procedência.
- Propriedades Semânticas: Consistência de objetivos e herança de obrigações em linguagem natural, tratadas empiricamente.
Arquitetura de Tempo de Execução (C3): Um sistema composto por um Compilador de Contrato (registro de transformação), Mediador de Delegação (impõe regras de atenuação), Monitor de Comunicação, Gateway de Capacidade (verifica chamadas de ferramentas contra contratos ativos), Camada de Memória Governada (delimita escritas/leituras por contrato) e um Controlador de Incidentes (lida com revogação e recuperação).
Protocolo de Recuperação (C4): Um protocolo de contenção guiado por procedência que permite a revogação de capacidade transitiva e quarentena de memória baseada em linhagem. Ele distingue entre quarentena conservadora (qualquer entrada contaminada contamina a saída) e quarentena mínima (planejada).
Evidência de Conformidade (C5): Uma suíte de testes mecanizados e uma matriz de bypass de adaptador avaliando a correspondência da implementação com a especificação determinística.

Resultos e Descobertas

Garantias Formais: Sob mediação completa, o sistema garante formalmente que as capacidades são atenuadas, os escopos de dados são preservados, os orçamentos são respeitados e a revogação é transitiva.
Insights de Engenharia: O processo de formalização expôs dois defeitos críticos de escalonamento no nível de implementação:
1. Omissão de Limites Numéricos: Um contrato filho poderia omitir um limite numérico do pai, passando pela atenuação e parecendo ilimitado para o gateway.
2. Omissão de Eixos de Orçamento: Um contrato filho poderia omitir um eixo de orçamento, tornando-se ilimitado nesse eixo.
- Resolução: Estes defeitos levaram a um princípio geral de design: restrições de chave opcionais devem assumir, por padrão, a interpretação mais restritiva. A omissão nunca deve significar "ilimitado".
Conformidade de Implementação: O protótipo congelado passou em 75 testes mecanizados, incluindo casos de regressão para os defeitos de escalonamento identificados. Testes de bypass de adaptador confirmaram que ações governadas não puderam ser executadas fora do caminho vinculado ao contrato via seis vetores de evasão específicos (ex: referências diretas a ferramentas, subgrafos aninhados).
Status do Piloto Empírico: O artigo relata um piloto exploratório de juiz automatizado sobre a retenção de restrições através de profundidades de delegação. No entanto, o autor afirma explicitamente que nenhuma afirmação empírica confirmatória é feita nesta versão, pois a rodada de qualificação do juiz automatizado não atingiu o portão de concordância pré-registrado (80% de concordância, $\kappa \ge 0.70$ ) e a validação independente está incompleta.

Significância e Alegações
O artigo posiciona o DARC como uma ponte entre sistemas multiagentes normativos, segurança de capacidade e aplicação em tempo de execução. Sua principal significância reside em:

Reenquadramento da Delegação: Mudança de tratar a delegação como texto para tratá-la como uma ação institucional com restrições aplicáveis.
Recuperação de Primeira Classe: Tratar a recuperação de estado (quarentena e rollback baseado em linhagem) como parte integrante do guardrail, e não como um pensamento posterior.
Limites Disciplinados: Separar claramente o que pode ser provado formalmente (restrições determinísticas) do que deve ser medido empiricamente (cláusulas semânticas), evitando o excesso de afirmações comuns na pesquisa de segurança de LLM.

O autor enfatiza que a contribuição não é uma nova teoria de delegação ou blindagem isoladamente, mas sua composição em uma arquitetura de aplicação e recuperação para sistemas abertos onde agentes, ferramentas e topologias mudam em tempo de execução. O trabalho permanece um protótipo e demonstração de mecanismo, sendo necessário trabalho futuro para compensação de ação-ferramenta, reatribuição de tarefas e validação empírica total das cláusulas semânticas.