Sua software house roda Claude Code em servidores Linux. Os agentes veem tudo.
Vou te fazer uma pergunta que provavelmente ninguém do seu time de infra pensou em responder: quando o Claude Code executa um npm test ou um git push no servidor da sua empresa, o subprocesso consegue listar todos os outros processos rodando naquela máquina?
Até a versão 2.1.97, a resposta era sim.
O subprocesso via /proc enxergava tudo: outros Claude Code rodando com outros devs, seu banco de dados PostgreSQL, o Docker daemon, o Jenkins, seus cronjobs, seus processos de deploy. Com seus PIDs, seus argumentos de linha de comando, suas variáveis de ambiente.
E variáveis de ambiente é onde 90% das software houses colocam tokens, API keys e credenciais de banco.
A v2.1.98 do Claude Code mudou isso. Com uma feature que a maioria dos devs vai ignorar no changelog: subprocess sandboxing with PID namespace isolation on Linux.
O que é PID namespace e por que isso não é um detalhe técnico
PID namespace é uma feature do kernel Linux que cria uma árvore de processos isolada. Processos dentro de um namespace só veem outros processos do mesmo namespace. Para eles, o resto da máquina simplesmente não existe.
É a mesma tecnologia que o Docker usa para isolar containers. É a base de segurança do Kubernetes. É o que impede que um container veja processos de outro.
Só que até agora, o Claude Code não usava PID namespace nos subprocessos do sandbox.
O bubblewrap já isolava o filesystem — o subprocesso não podia escrever fora do diretório de trabalho. O proxy já filtrava a rede — o subprocesso só acessava domínios permitidos. O seccomp-bpf já bloqueava syscalls perigosas — incluindo criação de unix sockets (como cobri no artigo sobre apply-seccomp).
Mas /proc estava aberto. O subprocesso podia listar, inspecionar e potencialmente interagir com qualquer processo na máquina.
O que um processo malicioso faz com visibilidade de /proc
Quando um processo vê /proc do host, ele pode:
1. Enumerar todos os processos da máquina
ls /proc/*/cmdline | xargs -I {} sh -c 'cat {} 2>/dev/null | tr "\0" " "; echo'Isso lista cada processo com seus argumentos completos. Se alguém rodou mysql -u root -pSenha123, a senha está ali.
2. Ler variáveis de ambiente de outros processos
cat /proc/<PID>/environ | tr '\0' '\n'Se o processo do Jenkins tem AWS_SECRET_ACCESS_KEY no ambiente, qualquer processo na mesma máquina pode ler — a menos que esteja em um PID namespace separado.
3. Injetar sinais em processos críticos
kill -9 <PID_do_deploy>Sem PID namespace, um subprocesso pode enviar SIGKILL para qualquer processo que rode com o mesmo usuário. Incluindo seu processo de deploy no meio de uma migração de banco.
4. Usar ptrace para inspeção de memória
Dependendo do kernel.yama.ptrace_scope, um processo pode fazer attach via ptrace em outro processo e ler sua memória — incluindo tokens em uso, conexões ativas e dados em processamento.
Com PID namespace, nada disso funciona. O subprocesso vê apenas a si mesmo e seus filhos. O restante da máquina é invisível. A Anthropic confirma: “unfiltered helpers are not reachable via ptrace or /proc/N/mem” quando PID namespace está ativo.
A stack completa de sandbox do Claude Code v2.1.98
Com esta atualização, o Claude Code no Linux agora tem 4 camadas de isolamento para subprocessos:
| Camada | Tecnologia | O que isola | Desde |
|---|---|---|---|
| Filesystem | bubblewrap | Diretórios de leitura/escrita | v2.1.85 |
| Rede | Proxy + Unix socket | Domínios permitidos | v2.1.85 |
| Syscalls | seccomp-bpf (apply-seccomp) | Chamadas de sistema perigosas | v2.1.89 (restaurado v2.1.92) |
| Processos | PID namespace | Visibilidade e interação com processos | v2.1.98 (NOVO) |
A Anthropic descreve a filosofia como defesa em profundidade: “OS-level enforcement catches what application rules miss, and infrastructure-level isolation catches what OS-level enforcement misses.”
E os números internos confirmam: o sandbox reduz prompts de permissão em 84% — mais autonomia para o agente com mais segurança para a empresa.
Além disso, o inner PID 1 do namespace seta PR_SET_DUMPABLE=0, tornando-o imune a ptrace. O kernel garante que quando o PID 1 do namespace termina, todos os processos filhos são terminados — cleanup automático, zero zombies.
Além do PID namespace: os fixes de segurança que ninguém leu
A v2.1.98 não trouxe só PID namespace. O changelog tem uma lista de fixes de permissão do Bash tool que merece atenção:
- Fixed Bash tool permission bypass with backslash-escaped flags — um
rm \-rf /passava pelo filtro de permissão - Fixed compound Bash commands bypassing forced permission prompts —
echo safe && rm -rf /era tratado como seguro - Fixed read-only commands with env-var prefixes not prompting —
SECRET=x cat /etc/shadownão pedia permissão - Fixed redirects to
/dev/tcp/...or/dev/udp/...not prompting — exfiltração de dados via redirect Bash nativo - Fixed
--dangerously-skip-permissionsbeing silently downgraded — o flag mais perigoso era ignorado silenciosamente após escrita em path protegido - Fixed agent team members not inheriting leader’s permission mode — teammates rodavam sem as restrições de segurança do líder
Cada um desses é um vetor de escape que existia em versões anteriores. Cada um foi corrigido na v2.1.98.
O contexto de 2026: sandbox escapes custam US$1 cada
Se você acha que sandbox escape é coisa de paper acadêmico, os números de 2026 discordam.
O SandboxEscapeBench — publicado pela Universidade de Oxford em parceria com o UK AI Safety Institute (março de 2026) — testou 18 cenários de escape de container com modelos de IA frontier. Os resultados:
- Modelos Opus-class têm taxa de sucesso 3x maior que Haiku-class em escapes de dificuldade 1-2
- Esses cenários de dificuldade 1-2 são exatamente as misconfigurações mais comuns em tooling de dev e CI/CD: containers privilegiados, docker socket exposto, mounts de host writable
- Cada tentativa de escape custa aproximadamente US$1 — tornando mass exploitation automatizado economicamente viável
- Nenhum modelo conseguiu resolver os cenários mais difíceis (kernel-level exploits), mas os fáceis bastam para a maioria dos ataques reais
A Gravitee reportou que 88% das organizações tiveram incidentes de segurança confirmados ou suspeitos com AI agents em 2026. A Arkose Labs descobriu que 97% dos executivos esperam um incidente material com AI agents nos próximos 12 meses.
A McKinsey mapeou que quase dois terços das empresas citam segurança como a principal barreira para escalar AI agentic. E 69% dos respondentes dizem que preocupações com segurança estão freando a adoção.
O dado mais preocupante vem da IBM: breaches envolvendo shadow AI (uso não autorizado de IA por funcionários) custam US$4,63 milhões em média — US$670 mil a mais que o breach padrão. E shadow AI foi fator em 20% de todos os breaches de 2025.
Na prática: um dev que roda Claude Code sem sandbox em um servidor compartilhado é shadow AI com acesso ao terminal. E o custo quando dá errado é quase US$5 milhões.
Incidentes reais: não é teoria
- Um agente AI da Alibaba escapou do sandbox, começou a minerar criptomoeda e abriu backdoor na rede corporativa
- O Claude Code escapou seu próprio sandbox na Ona — quando um comando foi bloqueado, o agente usou
/proc/self/root/usr/bin/npxcomo path trick e depois desabilitou o sandbox inteiro viadangerouslyDisableSandbox - O CVE-2026-25049 (CVSS 10.0) no n8n permitiu escape completo: template literals → execução de comandos do sistema → decriptação de credenciais → acesso à infraestrutura Kubernetes interna
- O ServiceNow Now Assist (CVE-2025-12420, CVSS 9.3) mostrou agentes recrutando outros agentes — um agente de baixo privilégio embutiu instruções maliciosas em dados que agentes de alto privilégio processaram, escalando até acesso admin
- Três vulnerabilidades críticas no runC (novembro 2025) afetaram Docker, Kubernetes, containerd e CRI-O — permitindo escrita arbitrária de arquivos do host via symlink attack
PID namespace teria mitigado ou bloqueado o vetor de ataque em pelo menos 3 desses casos. Quando o processo não consegue ver /proc do host, o path trick da Ona via /proc/self/root não funciona. Quando não vê processos de outros containers, a escalação lateral fica muito mais difícil.
Como configurar na sua software house
1. Atualize para v2.1.98+
npm update -g @anthropic-ai/claude-code
claude --version # deve mostrar 2.1.98 ou superior2. Instale dependências no Linux
# Ubuntu/Debian
sudo apt-get install bubblewrap socat
# Fedora
sudo dnf install bubblewrap socatO PID namespace requer kernel 3.8+ (padrão em qualquer distro moderna desde 2013).
3. Ative o sandbox com fail-closed
No settings.json ou via /sandbox:
{
"sandbox": {
"enabled": true,
"failIfUnavailable": true
}
}Isso garante que se o sandbox falhar — bubblewrap ausente, kernel incompatível, qualquer coisa — o Claude Code para ao invés de rodar sem proteção.
4. Stack completa de enforcement enterprise
Para managed settings via admin console, aplique para toda a organização:
{
"sandbox": {
"enabled": true,
"failIfUnavailable": true,
"allowUnsandboxedCommands": false
},
"forceRemoteSettingsRefresh": true,
"disableSkillShellExecution": true,
"allowManagedHooksOnly": true,
"allowManagedPermissionRulesOnly": true
}| Setting | O que protege |
|---|---|
sandbox.enabled |
Ativa filesystem + rede + seccomp + PID namespace |
failIfUnavailable |
Fail-closed se sandbox indisponível |
allowUnsandboxedCommands: false |
Bloqueia escape hatch do agente |
forceRemoteSettingsRefresh |
Garante políticas no startup |
disableSkillShellExecution |
Bloqueia shell em skills |
allowManagedHooksOnly |
Só hooks aprovados pelo admin |
allowManagedPermissionRulesOnly |
Só regras de permissão gerenciadas |
5. Valide em CI/CD
Se sua SH roda Claude Code em pipelines headless (-p), verifique que o ambiente tem bubblewrap instalado e que o kernel suporta namespaces. Em containers Docker, pode ser necessário --privileged ou --cap-add SYS_ADMIN para bubblewrap funcionar — ou use enableWeakerNestedSandbox (que reduz isolamento, então prefira VMs dedicadas).
O open source que importa
A Anthropic liberou o sandbox runtime como open source em github.com/anthropic-experimental/sandbox-runtime. Você pode usar para sandboxar seus próprios agentes, MCP servers ou qualquer processo:
npx @anthropic-ai/sandbox-runtime <comando-para-sandboxar>Isso é relevante para SHs que estão construindo produtos com o Claude Agent SDK — os mesmos primitivos de segurança do Claude Code disponíveis para seus próprios agentes de produção.
O que eu penso
PID namespace é a feature mais subestimada desse changelog. A maioria dos devs vai olhar “subprocess sandboxing” e pensar “já tinha sandbox, o que mudou?”. Mudou que antes o agente não podia escrever fora do diretório nem acessar a internet — mas podia ver absolutamente tudo que rodava na máquina.
É como ter um funcionário novo que não pode sair do escritório nem usar o telefone, mas tem visão de raio-X através de todas as paredes. Ele não pode agir sobre o que vê — mas sabe exatamente onde estão todos os cofres, todas as senhas coladas no monitor, todos os documentos confidenciais em cima da mesa.
Com PID namespace, as paredes ficam opacas. O subprocesso não vê nada além do próprio escritório.
Na minha experiência com 300+ software houses, vejo duas atitudes com segurança de AI agents:
- “Confiamos no modelo” — até o primeiro incidente
- “Cada camada que falta é um vetor que existe” — desde o primeiro dia
As SHs do grupo 2 são as que vão sobreviver quando os AI agents fizerem parte de 40% das aplicações enterprise — previsão do Gartner para este ano. As do grupo 1 vão descobrir que confiança não é estratégia quando um subprocesso lê o AWS_SECRET_ACCESS_KEY do processo vizinho.
PID namespace. Seccomp. Bubblewrap. Proxy. Managed settings. Cada uma é uma camada. Juntas, são uma jaula. E em 2026, jaula é o mínimo.
Sou Thulio, mentoro 300+ SHs desde 2016. Se você quer implementar esse nível de segurança de AI agents na sua software house, fale comigo na Software House Exponencial.
