Sandbox, capability e identidade: segurança por tarefa em sistemas agentic

Dois agentes trabalham em branches diferentes. Nenhum sobrescreve o arquivo do outro. O time conclui que a execução está isolada.

Mas os dois ainda podem usar a mesma credencial, consultar a mesma base, chamar a mesma ferramenta e alcançar a mesma rede. A separação de arquivos resolveu uma colisão de trabalho; não resolveu a fronteira de segurança.

Em sistemas agentic, segurança precisa acompanhar a tarefa inteira: quem executa, em qual ambiente, com quais capabilities, sobre quais dados, durante quanto tempo e sob qual autoridade.

Resumo executivo

Um worktree protege concorrência no repositório. Um sandbox limita execução. Identidade atribui ações. Capabilities restringem o que cada identidade pode fazer. Policy decide quando a combinação é válida.

Nenhuma camada substitui as outras. Segurança por tarefa nasce da interseção entre elas.

Worktree não é sandbox

Worktrees são excelentes para isolar mudanças concorrentes. Cada sessão recebe uma árvore de trabalho, branch e histórico próprios. Isso reduz colisões e facilita revisão.

O sistema operacional, porém, não interpreta uma branch como fronteira de permissão. Um processo pode continuar lendo caminhos externos, variáveis, keychains, sockets ou serviços de rede se o ambiente permitir.

O contrato correto é:

worktree = isolamento de mudança
sandbox  = isolamento de execução
policy   = isolamento de autoridade

Documentação pública de agentes de código descreve sandbox, acesso ao workspace e rede como controles distintos. A FORGE usa essa separação como princípio de projeto; a existência de um sandbox específico não certifica o produto que o adota. [R2-C3]

Identidade precisa chegar à ação

“O agente fez” é uma frase operacionalmente fraca. Qual agente? Em nome de quem? Em qual sessão? Com qual papel? Qual versão do workflow concedeu a permissão?

Uma identidade útil deve permitir ligar:

1. pessoa ou sistema que iniciou a tarefa;
2. sessão que recebeu o objetivo;
3. papel ou especialidade assumida;
4. grant efetivo;
5. ação executada;
6. artefato ou efeito produzido;
7. decisão de revisão ou aceite.

Isso não exige expor raciocínio interno. Exige registrar fatos operacionais suficientes para atribuir, investigar e revogar.

Capability é mais precisa do que “acesso”

Permitir “GitHub” diz pouco. Uma tarefa pode precisar ler uma issue, criar uma branch e abrir um PR, sem poder alterar secrets, regras de proteção ou releases.

Modele grants como verbos sobre recursos:

issue:read
branch:create
repository:write@worktree
pull_request:create
secret:read = denied
release:publish = denied

O mesmo vale para banco, CRM, arquivos e infraestrutura. A capability deve ser mínima, vinculada à tarefa e revogável. Modelos e adapters podem sugerir operações; o enforcement precisa estar fora do texto que o próprio executor controla. Fontes públicas mostram implementações diferentes de agents, workspaces e permissões, não um padrão universal de autorização. [HARNESS31-C4]

Uma matriz de cinco dimensões

Antes de iniciar uma execução com efeito material, responda:

O grant não deveria sobreviver à razão pela qual foi criado. Uma sessão concluída não precisa manter acesso de escrita; um preview não precisa de credencial de produção; um reviewer não precisa executar o código que avalia.

Rede é parte do contrato

Agentes que navegam, instalam dependências ou consultam serviços externos ampliam a superfície de prompt injection, exfiltração e supply chain.

Três políticas são mais úteis do que o binário “internet ligada”:

• deny: nenhuma saída; dependências e dados entram por artefatos aprovados;
• allowlist: somente destinos e métodos necessários;
• escalate: domínio novo exige decisão antes da primeira chamada.

Também importa controlar retorno: baixar um pacote, enviar conteúdo, criar uma transação e publicar um comentário são efeitos diferentes.

Segredos não pertencem ao prompt

Uma credencial inserida no contexto pode reaparecer em transcript, tool call, erro ou artefato. O modelo não precisa conhecer o segredo para usar uma capability.

Prefira:

• broker ou vault que troca identidade por token curto;
• escopo mínimo e ambiente explícito;
• injeção somente no processo autorizado;
• logs com valor mascarado;
• revogação observável;
• teste negativo que prove acesso negado fora da tarefa.

O resultado esperado não é “o agente prometeu não mostrar”. É “a arquitetura não entregou o valor ao contexto e o efeito fora do grant falhou”.

Segurança por tarefa na prática

Considere um agente encarregado de corrigir documentação pública:

1. recebe uma issue pública e um worktree exclusivo;
2. lê somente o repositório e fontes allowlisted;
3. não recebe secrets de deploy;
4. pode editar arquivos do escopo e executar validadores locais;
5. pode abrir PR, mas não aprová-lo nem publicar release;
6. o CI usa identidade separada para verificar;
7. o deploy usa outra identidade, depois do merge;
8. todos os grants da sessão expiram no fechamento.

Separar identidades reduz autoridade circular. Também torna incidentes mais localizáveis: uma falha de pesquisa, implementação, revisão ou publicação deixa evidência em um plano diferente.

O teste mais importante é o negativo

Configuração declarada não basta. Verifique que:

• o agente não lê arquivo fora do workspace;
• rede para destino não autorizado falha;
• token de desenvolvimento não alcança produção;
• reviewer não escreve no asset;
• grant expirado deixa de funcionar;
• uma sessão não acessa memória ou dado de outra;
• logs identificam subject, recurso e decisão sem vazar conteúdo sensível.

Uma arquitetura pode parecer restrita e ainda carregar um bypass. O teste negativo transforma a fronteira em propriedade observável.

O que este artigo prova — e o que não prova

As fontes elegíveis sustentam que sandbox, rede, identidade e autorização são controles separados e que o perfil exato depende do ambiente. Elas não demonstram que uma ferramenta específica é segura em qualquer configuração, nem que isolamento elimina prompt injection, erro humano ou risco de cadeia de suprimentos.

Este artigo propõe um contrato de segurança por tarefa. Threat model, testes e operação continuam específicos de cada produto.

Conclusão

Um agente não deveria receber “acesso ao sistema”. Deveria receber uma capacidade pequena, em um ambiente delimitado, por um tempo curto, ligada a uma identidade e a uma evidência.

Worktree organiza concorrência. Sandbox reduz alcance. Identidade atribui. Capability limita. Policy decide. A segurança aparece quando todas essas camadas concordam sobre a mesma tarefa.

Leitura anterior: Graph, loop ou híbrido?. Próxima leitura sugerida: Taste, responsabilidade e clareza.