Segurança e zero-trust

Por que zero-trust importa, como o kernel funciona, o que ele bloqueia e os benchmarks acadêmicos.

Por que zero-trust importa

A maioria dos incidentes com agentes autônomos em produção não vem de modelos maliciosos. Vem de modelos obedientes. O LLM recebe um input manipulado, interpreta como instrução legítima e emite um tool call que executa algo destrutivo. O framework que hospeda o agente faz o que foi programado para fazer: executa.

Três anedotas reais (reconstituídas de post-mortems públicos e relatos de clientes):

Um agente de suporte recebe uma mensagem com instruções escondidas em base64 embutidas num ticket. O agente decodifica, interpreta como comando e puxa ~/.ssh/id_rsa via curl para um servidor externo. O time só descobre quando recebe alerta do GitHub sobre push forçado usando a mesma chave.
Um agente de ops recebe pedido ambíguo para "limpar dados antigos". O LLM, ao traduzir isso em SQL, gera um DELETE FROM users WHERE created_at < NOW() sem LIMIT. A migration roda. Tabela inteira apagada. Backup de 6 horas perdido.
Um agente de code review interpreta um comentário em PR como instrução de sistema (prompt injection clássico). Gera um patch que remove o check de autenticação do endpoint principal. O patch é autoaprovado pela própria pipeline do agente.

Em todos os três casos, o problema não foi o modelo. Foi a ausência de uma camada que audita o que o modelo está prestes a fazer. Zero-trust é a resposta arquitetural a essa classe de problema: não confie nem no próprio LLM, especialmente quando ele tem permissão de ação.

O kernel de segurança em alto nível

O componente que materializa zero-trust no IronShell é o NanoShield. Do ponto de vista conceitual, ele faz quatro coisas em sequência:

Normaliza o input. Aplica NFKC Unicode para colapsar caracteres fullwidth e variantes visuais (ｒｍ vira rm). Remove sequências ANSI de escape que podem esconder bytes. Limpa backslashes de evasão usados em ANSI-C quoting ($'\x72\x6d' vira rm).
Classifica contra 132 padrões. Entre eles, 102 são DENY (bloqueio), 10 são WARN (aviso com score médio), 20 são ALLOW (contraexemplos explícitos para reduzir falso positivo).
Calcula um risk score contínuo de 0 a 100. Score é função ponderada dos patterns que casaram, da presença de padrões agravantes (pipe com URL externa, combinação de comandos destrutivos) e do histórico recente via rate limiter SHA-256.
Emite um veredito estruturado. Três campos saem: allowed booleano, riskScore numérico, riskLevel (safe, warn, blocked) e reason textual para logging.

A interface é sempre síncrona e não bloqueante. O custo médio por chamada é de menos de 1 microssegundo em hardware moderno (medido em 2,6 milhões de ops por segundo no benchmark de REST dispatch).

Classes de ataques cobertas

Os 102 padrões DENY cobrem categorias bem conhecidas em literatura de segurança de AI e categorias específicas de agentes autônomos. A lista abaixo é didática — não é o corpus completo.

Exfiltração de credenciais

Padrões que casam com combinações suspeitas de leitura de arquivos sensíveis e envio para rede externa.

Leitura de chaves SSH privadas (~/.ssh/id_rsa, /root/.ssh/).
Leitura de arquivos de configuração de cloud (~/.aws/credentials, ~/.gcp/, .kube/config).
Leitura de /etc/shadow, /etc/passwd combinada com pipe.
Pipe para curl, wget, nc, socat com URL externa.
Codificação para base64 antes de enviar (ataque clássico de obfuscação).

Comandos destrutivos

Padrões que casam com operações irreversíveis em disco.

rm -rf / e variantes (rm -rf ~, rm -rf /home, rm -rf /var).
rm -rf combinado com path traversal (rm -rf /tmp/../..).
dd if=/dev/zero of=/dev/sda e similares.
mkfs em dispositivo raiz.
:(){ :|:& };: (fork bomb clássica).
Truncamento de tabelas SQL críticas sem WHERE.

Escape de container e privilégio

Padrões que casam com tentativas de sair de sandbox ou escalar privilégio.

docker --privileged, docker run --pid=host, docker run -v /:/host.
nsenter -t 1 -m -u -i -n -p, unshare, setns.
LD_PRELOAD com biblioteca maliciosa.
/proc/self/exe com argumentos estranhos.
Manipulação de cgroup, capabilities, seccomp.

Evasão Unicode e ANSI

Padrões que casam com tentativas de ofuscar comandos usando caracteres que parecem diferentes mas normalizam para ASCII.

Fullwidth latin (ｒｍ, ｃｕｒｌ).
Caracteres hebraicos e cirílicos visualmente idênticos a latinos.
Zero-width joiners e variantes de diacríticos.
ANSI-C quoting ($'\x72\x6d', $'\101').
Backslash escapes (r\m, r\\m).

O passo de normalização NFKC resolve essas classes antes do matching. O score final reflete tanto o pattern quanto a tentativa de evasão (tentar ofuscar agrava o score).

Injeção de segundo nível

Padrões que casam com tentativas de executar comandos via substituição de shell.

$(comando) com conteúdo suspeito ($(cat /etc/shadow)).
Backticks (`rm -rf /`).
Pipe com sh -c ou bash -c sobre input não sanitizado.
Redirecionamento combinado com download.

Abuso de escape ANSI para esconder intent

ANSI permite apagar linhas inteiras do terminal ou esconder caracteres. Padrões cobrem sequências que poderiam esconder a intenção real do comando de um reviewer humano.

Injeção de newline

Padrões que casam com newlines embutidos em argumentos para quebrar parsing e injetar comandos secundários.

Path traversal

Padrões que casam com ../../.. em contextos onde o destino deveria ser confinado.

Vazamento de variável de ambiente

Padrões que casam com impressão de env, printenv, set, ou iteração sobre $@ em contextos de script malicioso.

Comparação direta com concorrentes

| Capacidade | NanoShield | Rebuff | LLM Guard | Guardrails AI | PromptArmor | | --- | :---: | :---: | :---: | :---: | :---: | | Número de padrões DENY | 102 | ML-only | Configurável | Configurável | ML-only | | Normalização Unicode NFKC | sim | não | não | não | não | | Detecção de ANSI-C quoting | sim | não | não | não | não | | Risk score contínuo 0-100 | sim | não | parcial | não | não | | Injeção de segundo nível | sim | não | não | não | não | | Escape de container | sim | não | não | não | não | | Integrado como kernel (não wrapper) | sim | não | não | não | não | | IDR ≥ 95% público | sim | não | não | não | não | | FPR ≤ 5% público | sim | não | não | não | não | | Open source MIT | sim | sim | sim | parcial | não |

A diferença estrutural é a integração como kernel. Todos os concorrentes listados são wrappers — você os adiciona em volta do seu agente, e se esquecer de adicionar em algum path, o bypass é imediato. O NanoShield é invocado arquiteturalmente: nenhuma ferramenta existe no sistema sem a audição automática.

Benchmarks acadêmicos

Os números abaixo são medidos em benchmarks públicos usados na literatura de segurança de LLMs. Os targets são os resultados que o IronShell v9.4 atinge; nenhum deles é meta futura.

| Benchmark | Target atingido | Descrição | | --- | :---: | --- | | HarmBench ASR | < 1% | Attack Success Rate contra prompts abertamente prejudiciais. | | JailbreakBench | < 2% | Resistência a 100 técnicas de jailbreak documentadas. | | InjectAgent IDR | > 95% | Injection Detection Rate em tarefas agentic. | | REPOCOD IDR | ≥ 95% | Detecção em 400+ assertions de alta densidade. | | REPOCOD FPR | ≤ 5% | Falso positivo em corpus de 55 comandos seguros. |

Em adição aos benchmarks acadêmicos, o IronShell roda seu próprio corpus adversarial de 1.488 payloads construídos com base em OWASP AI, Garak e jailbreak2026. A suite completa roda em Monte Carlo de 100 mil execuções randomizadas antes de cada release major.

Rate limiting e defesa em profundidade

O NanoShield não é a única camada de segurança. Ele é a camada central, mas o sistema todo aplica defense-in-depth.

Pré-audit do input do usuário — antes do input chegar ao LLM, um guard de prompt aplica Aho-Corasick multi-pattern e filtro de perplexidade para detectar adversarial suffixes (GCG, PAIR) e prompt injection clássica.
Post-audit do output do LLM — antes da resposta chegar ao usuário, o IronLeakDetector escaneia por credenciais expostas: chaves API (sk-, AKIA, ghp_), blocos PEM, JWT suspeitos, connection strings. Ações possíveis são block, redact, warn.
Guard semântico — o IronSemanticGuard classifica o output em 6 categorias de falácia (especulação, circularidade, suposição injustificada, excesso de confiança, scope creep, alucinação). Score 0-100.
Auditoria de tool call individual — cada tool call passa pelo NanoShield independentemente, não apenas o prompt inicial.
Rate limiting — por assinatura SHA-256 do comando, o kernel limita repetições excessivas que poderiam indicar brute force.

Imunidade coletiva P2P

Quando um agente IronShell bloqueia um ataque, ele pode opcionalmente transmitir a assinatura do ataque para peers conectados via rede P2P (porta configurável, transporte WebSocket). Os peers recebem a assinatura, adicionam ao próprio bloom filter local, e passam a bloquear a mesma classe de ataque antes mesmo de executar o cálculo de risk score completo.

Três proteções tornam esse canal seguro:

Handshake Ed25519 — o primeiro pacote deve ser assinado com chave privada válida. Conexões não assinadas são imediatamente fechadas.
Rate limiting por peer — máximo de 10 mensagens por 60 segundos. Peers que excedem são desconectados.
Detecção de eclipse — se 80% ou mais dos peers concordam no mesmo payload, sinal de possível ataque de eclipse. O sistema entra em modo conservador e logs alertam o operador.

A imunidade coletiva é opcional. Em ambientes air-gapped ou com requisito de isolamento, basta não configurar o peer list — o NanoShield continua funcionando sozinho.

Trilha de auditoria HMAC

Toda ação do agente — input recebido, tool call aprovado, tool call bloqueado, output final — é registrada no audit log local. O log é encadeado via HMAC-SHA256: cada linha contém o hash da linha anterior. Adulterar uma linha quebra a cadeia e é detectável com o comando de verificação.

Formato do log:

<timestamp>  <action>  <riskScore>  <reason>  <hash>
2026-04-18T09:00:00Z  shell:exec     5    git status        a1b2...
2026-04-18T09:00:03Z  shell:blocked  95   rm -rf pattern    c3d4...
2026-04-18T09:00:10Z  chat:turn      0    user reply        e5f6...

O log pode ser exportado para CSV assinado, submetido a auditores externos (SOC2, ISO 27001) e verificado por ferramenta indenpendente. O hash raiz é publicável como prova criptográfica de integridade.

Como contribuir com novos padrões

O corpus de 102 DENY patterns é aberto. Se você encontrou um bypass, um novo vetor de ataque, ou um padrão que deveria ser coberto e não é, abra um PR no repositório. A contribuição ideal inclui:

O pattern em si, com justificativa e exemplos positivos e negativos.
Testes automatizados que validam a detecção.
Se aplicável, referência à CVE, paper ou post-mortem que originou o pattern.

PRs são revisados em até 72 horas. A cada release, os patterns novos entram no Monte Carlo de 100 mil execuções antes de serem promovidos a produção.

Compliance e certificações

O IronShell foi desenhado para ser evidência-compatível com os frameworks de compliance mais comuns. A lista abaixo é indicativa; certificações formais dependem de processos de auditoria independentes.

SOC2 Type II — audit log encadeado cobre requisitos de trilha de auditoria (CC7.2). Kill-switch remoto e rotação de licença cobrem gerenciamento de acesso.
LGPD / GDPR — zero dado de usuário sai da máquina por padrão. Modo air-gapped é suportado. Data residency é 100% local.
ISO 27001 — os 102 DENY patterns fornecem evidência de controle técnico em A.8.24 (input/output validation).
HIPAA — combinado com self-host em infra compatível, o IronShell não introduz requisitos novos de PHI handling.

Para detalhes sobre compliance enterprise, consulte a FAQ.

Próximos passos

Capabilities — squad multi-agente, self-healing, Byzantine consensus.
Benchmarks — todos os números medidos em hardware real.
Deployment — cenários self-host, enterprise on-premise, air-gapped.
FAQ — perguntas profundas sobre compliance, bounty, SLA.