Segurança e autonomia como problemas de engenharia

8.1. Autonomia útil exige um perímetro efetivo

Autonomia amplia o trabalho realizado sem acompanhamento contínuo. Para sustentá-la, é necessário controlar quais ações podem acontecer e quais consequências podem alcançar.

O catálogo OWASP para aplicações com agentes inclui riscos relacionados a desvio de objetivos, uso indevido de ferramentas, privilégios, cadeia de suprimentos e contaminação de memória e contexto. É um framework de especialistas para análise de risco, não uma garantia de segurança obtida por completar uma lista. F24

A competência prática consiste em modelar o caminho entre informação recebida, decisão do agente, ferramenta acionada, credencial utilizada e efeito produzido. Esse caminho revela onde a confiança muda e onde um controle precisa existir.

8.2. Conteúdo não confiável pode influenciar ações privilegiadas

Uma issue, um log, um documento ou a resposta de uma ferramenta pode conter texto que tenta redirecionar o agente. É preciso tratar esse material como dado a interpretar dentro da tarefa, preservando a autoridade das instruções e políticas legítimas.

O projeto de segurança deve combinar orientação ao modelo com controles externos: autorização no serviço, isolamento de execução, restrição de arquivos, proteção de segredos e controle de saída de rede. A Anthropic descreve a contenção como forma de limitar consequências mesmo quando uma decisão do modelo falha. F23

Um comentário dizendo “não exponha segredos” não impede um processo de ler uma credencial que já está no ambiente. O desenho mais forte evita disponibilizar essa credencial quando ela não é necessária e limita o que pode ser feito com ela.

8.3. Competências técnicas que precisam entrar no repertório

• Identidade e autorização: diferenciar usuário, agente, subagente e ferramenta; conceder escopos adequados à tarefa.
• Ambientes isolados: separar investigação e execução de recursos de produção, conforme a consequência das operações.
• Gestão de dados: classificar o que pode ser enviado a cada serviço, registrar finalidade e limitar retenção e exposição.
• Cadeia de suprimentos: verificar procedência de dependências, scripts, extensões e skills; controlar atualizações.
• Rastreabilidade: relacionar solicitação, ações, mudanças e responsável; preservar evidências úteis para investigar.
• Recuperação: interromper execução, revogar acesso, reverter mudanças reversíveis e tratar efeitos que exigem compensação.

Esses itens constituem uma síntese prática. As decisões concretas dependem dos dados, do sistema e das políticas da organização.

A documentação de segurança do MCP aborda problemas como repasse inadequado de tokens, confusão de autoridade e escopos de acesso. Integrar por um protocolo padronizado não elimina a necessidade de compreender a autorização de cada componente. F25

8.4. Verificar o alcance real dos controles

Controles têm escopo. A documentação do firewall do GitHub Copilot, por exemplo, distingue processos iniciados pelo agente via Bash, servidores MCP, etapas de configuração e processos externos ao ambiente. Na versão consultada, o firewall não cobre diretamente todas essas rotas. Esse detalhe demonstra por que o engenheiro deve verificar a proteção efetiva, em vez de inferi-la pelo nome da funcionalidade. F26

O mesmo raciocínio vale para isolamento de arquivos, restrições de rede e proteção de branches. O que impede efetivamente a operação? Quem pode alterar essa regra? O controle se aplica também aos subprocessos e integrações utilizados?

8.5. Uma matriz de autonomia

O modelo abaixo é uma proposta de trabalho, não uma classificação normativa.

Aprovar cada comando pode transformar o engenheiro em operador de confirmações. O projeto deve concentrar decisões humanas onde elas mudam o risco ou resolvem uma ambiguidade material. Nos demais pontos, controles claros permitem continuidade.