Resumo Técnico: Autoridade Remanescente em Agentes de Codificação

Definição do Problema: Autoridade Remanescente

O artigo identifica uma lacuna de segurança específica em agentes de codificação denominada autoridade remanescente (lingering authority). Agentes de codificação frequentemente recebem acesso amplo a ferramentas para toda uma tarefa, mesmo quando um recurso ou efeito específico é necessário apenas para um subobjetivo. O problema central é temporal: a autoridade justificada para um subobjetivo permanece exposta na interface do planejador após o encerramento desse subobjetivo. Enquanto as defesas existentes abordam conteúdo hostil, confiança em ferramentas e verificações em tempo de execução, elas frequentemente deixam a própria interface do planejador exposta a capacidades que não são mais justificadas. Se uma opção de leitura ampla permanecer visível ao planejador após o término de um subobjetivo, o modelo pode continuar a planejar em torno dela, criando um estado de segurança onde capacidades temporárias persistem além de sua justificativa. O artigo argumenta que a interface exposta é parte do estado de segurança, distinta da alcançabilidade em tempo de execução ou dos limites do sandbox.

Metodologia: Monitor de Referência PORTICO

Os autores introduzem o PORTICO, um monitor de referência projetado para impor ciclos de vida de capacidade limitados para agentes de codificação. O PORTICO opera sob um modelo de isolamento de host fixo e baseia-se em contratos de tarefa explícitos e um catálogo de ferramentas tipado e consistente.

Mecanismos Principais

O PORTICO compila um contrato de tarefa em quatro componentes:

1. Envelope Inicial ($E_0$): O conjunto de capacidades expostas no início da tarefa.
2. Regras de Concessão ($\Gamma$): Regras que definem como a autoridade temporária pode ser expandida via solicitações explícitas.
3. Regras de Fechamento ($\Lambda$): Predicados (ex: passagem de teste, saída de fase, conclusão de subobjetivo) que disparam a revogação da autoridade temporária.
4. Regras de Negação Global ($G$): Invariantes, como hosts de rede proibidos ou acesso a arquivos de credenciais.

O Ciclo de Vida Solicitação–Concessão–Invocação

O PORTICO materializa as expansões como handles opacos com limite de época (epoch-bound handles).

• Solicitação: O planejador pode solicitar autoridade com base em regras declaradas, mas não pode criar nova autoridade.
• Concessão: Se uma regra for correspondida, o monitor gera um handle para o recurso/efeito/fase específico. Este handle é adicionado à próxima interface do planejador.
• Invocação: A execução é permitida apenas se um handle válido e ativo estiver presente.
• Fechamento: Quando ocorre um evento de fechamento (ex: um resultado de teste confiável), o monitor remove os handles correspondentes da interface do planejador. Tentativas subsequentes de usar o handle obsoleto são rejeitadas antes que ocorram efeitos colaterais.

Crucialmente, a revogação remove a autoridade da interface, mas mantém o contexto (ex: nomes de arquivos na conversa) intacto. O planejador não pode mais selecionar a ferramenta para aquele recurso sem uma nova concessão.

Principais Contribuições

O artigo apresenta três contribuições primárias:

1. Definição de Uso Não Obsoleto (No-Stale-Use): Define o requisito de que a autoridade de uma concessão encerrada deve desaparecer das interfaces posteriores do planejador e ser inválida no tempo de execução.
2. Formalização e Implementação: Formaliza a minimização de exposição, a expansão justificada e o fechamento de autoridade em torno de um protocolo de solicitação–concessão–invocação. Estes são implementados no PORTICO usando handles com limite de época.
3. Avaliação Empírica: Avalia os ciclos de vida limitados em suítes de controle e repositórios reais fixos, demonstrando a redução de disponibilidade de capacidades obsoletas pós-fechamento em comparação com designs que não revogam.

Resultados Experimentais

A avaliação utiliza três suítes de dispositivos de controle (A–C) e uma suíte de repositório real (D), comparando o PORTICO com bases de comparação (baselines) como Acesso Total (Full Access), Lista de Permissões Estática (Static Allowlist), Sandbox Coeso (Coarse Sandbox) e comparadores específicos (Non-Revoking, All-Visible Same-Policy).

Principais Descobertas

• Minimização (RQ1): Variantes do PORTICO levam as violações de política e o "raio de explosão" (recursos sensíveis alcançados) a 0.00 na Suíte A, enquanto o acesso total e as listas de permissões estáticas mostram taxas de violação significativas (1.00 e 0.82, respectivamente).
• Expansão Justificada (RQ2): O PORTICO Core (apenas o envelope inicial) é seguro, mas frágil, falhando em muitas tarefas que exigem expansão de limites (0.21 de sucesso na Suíte B). O PORTICO Full recupera o trabalho legítimo de expansão de limites, alcançando 0.87 de sucesso na Suíte B, mantendo 1.00 de conformidade de escopo e 0.00 violações.
• Fechamento (RQ3): Este é o principal diferencial do artigo. Um Comparador Não-Revogável (que recebe as mesmas concessões nos mesmos momentos, mas nunca as remove) iguala o PORTICO em sucesso de tarefa e decisões pré-fechamento. No entanto, em re-leituras pós-fechamento:
  • PORTICO Full: Nega 10/10 tentativas de reuso pós-fechamento.
  • Comparador Não-Revogável: Permite 10/10 tentativas de reuso pós-fechamento.
  • Auditoria de Efeito Obsoleto: Em testes determinísticos envolvendo escritas de arquivos, mutação de git e egress de rede, o PORTICO executa 0/6 efeitos proibidos, enquanto o comparador não-revogável executa 6/6.
• Amplitude da Interface (RQ3): Um Comparador de Mesma Política Totalmente Visível (All-Visible Same-Policy) iguala o PORTICO em efeitos proibidos executados (0/20), mas gera significativamente mais propostas bloqueadas (84 vs. 67), indicando que uma interface mais ampla aumenta a pressão de planejamento, mesmo que a execução seja eventualmente negada.
• Repositórios Reais (RQ4): Em repositórios Python reais fixos (Flask, Requests, etc.), o PORTICO Full materializa com sucesso concessões temporárias e impõe o fechamento, mantendo a conformidade de escopo e zero violações em 14 contratos.

Significância e Alegações

O artigo alega que o PORTICO consegue isolar o "tempo de vida" da autoridade como uma variável de segurança distinta. A principal descoberta é que um sistema pode preservar o sucesso da tarefa e a conformidade de escopo antes do fechamento, mas ainda assim deixar capacidades temporárias disponíveis após o fechamento se a revogação não for aplicada.

Os autores posicionam o PORTICO não como um substitente para sandboxing ou defesas de conteúdo, mas como uma camada complementar que torna as capacidades temporárias explícitas, limitadas e auditáveis. A significância reside na demonstração de que a revogação é necessária para prevenir a autoridade remanescente, mesmo quando a política de execução e o tempo de concessão são idênticos aos de um sistema não-revogável.

O artigo permanece modesto quanto ao seu escopo:

• Assume um catálogo de ferramentas tipado e confiável e execução mediada; não afirma proteger contra comandos de shell não mediados ou bypass de sandbox.
• Reconhece que a qualidade do contrato é um dado de implantação; contratos ruins podem levar à concessão insuficiente (bloqueando o trabalho) ou concessão excessiva (expondo o risco).
• Observa um custo de utilidade: o PORTICO Full troca parte das taxas brutas de conclusão por um controle de escopo mais estrito, resultando em uma "incompletude segura" visível em vez de um sucesso oculto e excessivamente amplo.

Em última análise, o trabalho argumenta que, para agentes de codificação, a própria interface do planejador deve ser dinâmica, encolhendo conforme as justificativas expiram, em vez de permanecer como um menu estático e amplo de ferramentas admissíveis.