Segurança a fundo: sandbox, cadeia de dependências e auditoria

O Rui faz o site da escola nas horas vagas. Pediu ao agente para «pôr a funcionar o envio de PDFs». O agente instalou três pacotes, o envio funcionou e o Rui fez commit. Um dos nomes tinha uma letra trocada em relação a um pacote conhecido. Ninguém reparou. Este caso é inventado, mas o padrão existe e tem nome.

Nada disto é motivo para pânico. É motivo para três hábitos: saber onde o agente pode mexer, saber o que entra no projecto e saber, depois, o que aconteceu.

O conceito: permissões, sandbox e registo

As permissões decidem quando o agente pergunta. A sandbox decide o que os comandos dele conseguem fazer, mesmo quando ninguém pergunta. São camadas diferentes, e queres as duas.

Uma sandbox isola três coisas:

• a pasta: onde pode escrever;
• a rede: se pode ligar-se à internet, e a que sítios;
• o sistema: o que consegue ler do resto do computador, como chaves e configurações.

O registo é a terceira camada: quando algo corre mal, é o que te diz o quê, quando e porquê.

Como se faz hoje: Codex

Isto é como está a 6 de Outubro de 2026; se o ecrã for diferente, procura o botão com o mesmo nome. Guia: learn.chatgpt.com/docs/agent-approvals-security.

O Codex tem duas peças. A sandbox (--sandbox) tem três modos: read-only, workspace-write e danger-full-access. A aprovação (--ask-for-approval) diz quando pergunta: on-request pergunta quando precisa de sair dos limites, never nunca pergunta.

O habitual é workspace-write com on-request: escreve na pasta, sem rede, e pergunta antes de sair. Mesmo assim, as pastas .git e .codex dentro do projecto ficam só de leitura. Se uma tarefa precisar mesmo de rede, liga-a no ficheiro de configuração com network_access = true, na secção [sandbox_workspace_write]. /permissions muda o modo e /status mostra o que está activo.

Como se faz hoje: Claude Code

Os modos de permissão são: Manual (default), acceptEdits, plan, auto, dontAsk e bypassPermissions. As regras deny bloqueiam em todos eles. Guia: code.claude.com/docs/en/permission-modes.

A sandbox vem desligada. Liga-a com /sandbox. Guia: code.claude.com/docs/en/sandboxing. Com ela ligada:

• os comandos só escrevem na pasta do projecto e em pastas temporárias;
• a rede passa por um filtro, e a lista de sítios permitidos começa vazia;
• os comandos ainda lêem quase todo o computador. Para fechar pastas como ~/.ssh, usa filesystem.denyRead.

A sandbox aplica-se aos comandos (Bash). Ler, editar e ir à web seguem as regras de permissão. No Windows sem WSL2 não há sandbox; no Linux precisa de dois programas, bubblewrap e socat.

A cadeia de dependências

Cada pip install traz código de outra pessoa, que corre com os teus direitos. Dois riscos aparecem muito:

• Typosquatting: alguém publica um pacote com um nome quase igual a um conhecido e espera por um erro de escrita.
• Nomes inventados: o modelo às vezes sugere um pacote que não existe. Se alguém registar esse nome mais tarde com código malicioso, o próximo que seguir a sugestão instala-o. Há quem chame a isto «slopsquatting».

As defesas são simples:

1. Lê o que o agente instala. Põe "Bash(pip install *)" na lista ask do .claude/settings.json, para ele perguntar sempre. A regra é literal: não apanha python -m pip install, pip3 install nem uv pip install. Acrescenta uma regra por cada forma que o agente usar, ou pede-lhe que instale sempre com pip install.
2. Instala só o que conheces. Pacote novo? Abre a página dele no PyPI: o nome exacto, o projecto ligado, o histórico de versões.
3. Fixa as versões. python -m pip freeze > requirements.txt grava cada pacote com ==. Para ir mais longe, o pip aceita --require-hashes.
4. Audita. O pip-audit compara as tuas dependências com uma base de vulnerabilidades conhecidas:

python -m pip install pip-audit
pip-audit -r requirements.txt

Se não encontrar nada, diz «No known vulnerabilities found» e sai com código 0; se encontrar, sai com 1. Por isso cabe num workflow de CI, como na lição 02.

Registo e auditoria

• O Git é o primeiro registo. Commits pequenos, um por mudança. O git log --stat mostra o que mudou em cada um.
• Um hook guarda os comandos. Este exemplo do guia oficial, no .claude/settings.json, junta cada comando Bash a um ficheiro. Precisa do programa jq.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.command' >> ~/.claude/command-log.txt"
          }
        ]
      }
    ]
  }
}

• No Codex, o codex exec --json escreve cada passo em linhas JSON, que podes guardar num ficheiro.

E a regra da lição 1/06 não muda: segredos nunca no pedido nem no repositório.