Segurança Zero-Trust para Agentes

license: Apache-2.0 name: agentic-zero-trust-security description: | Segurança criptográfica para sistemas de agentes autônomos — redes de agentes com confiança zero, envelopes de mensagens assinados (JWS/JWE), segurança baseada em capacidades (ocaps), trilhas de auditoria com Merkle tree, sandboxing WASM e verificação formal. Abrange segurança de ferramentas CLI, mTLS entre agentes, limites de permissão (menor privilégio para agentes de IA) e segurança de cadeia de suprimentos para skills/plugins. Ativar com: "segurança de agente", "agentes de confiança zero", "comunicação segura entre agentes", "segurança baseada em capacidades", "ocap", "mensagens assinadas entre agentes", "trilha de auditoria de agente", "execução em sandbox de agente", "permissões de agente", "mTLS agentes", "verificação criptográfica", "cadeia de suprimentos de agente", "OWASP agentic", "provar que o agente fez X", "logs de agente à prova de adulteração". NÃO PARA: varredura SAST em nível de aplicação (use security-auditor), regras de firewall de rede (use infraestrutura), conformidade SOC2/HIPAA (organizacional) ou defesa contra injeção de prompt (use prompt-engineer). allowed-tools: Read,Write,Edit,Bash,Glob,Grep,WebSearch,WebFetch metadata: category: Segurança & Confiança tags: - confiança-zero - criptografia - segurança-agente - segurança-capacidade - mTLS - trilha-auditoria - sandboxing - WASM - ocap - verificação-formal pairs-with: - skill: coordenação-multi-agente reason: Protege os canais de comunicação dos quais sistemas multi-agente dependem - skill: protocolos-de-conversa-entre-agentes reason: Assinatura e verificação de envelopes de mensagens para protocolos de agente - skill: auditor-de-segurança reason: Complementa a varredura SAST em nível de código com padrões arquitetônicos de segurança category: Segurança tags:

• confiança-zero
• segurança
• agentes
• autenticação
• autorização

---

O que Segurança Zero-Trust para Agentes faz?

Arquitetura de segurança criptográfica para sistemas de agentes de IA autônomos. Esta skill cobre a interseção entre engenharia de segurança tradicional e os desafios únicos de agentes que planejam, persistem, delegam e executam através de limites de confiança.

Princípio central: Nunca confie, sempre verifique — aplicado a cada mensagem agente-para-agente, cada skill carregada, cada ferramenta invocada e cada resultado retornado.

Pontos de Decisão

1. Nível de Ameaça → Estratégia de Verificação

Avaliação do Nível de Ameaça:
├── PÚBLICO (agentes da internet, skills desconhecidas)
│   ├── Ações: mTLS completo + JWS + tokens de capacidade + sandbox WASM
│   ├── Auditoria: Cada ação registrada com prova Merkle
│   └── TTL: Máx. 5min de vida útil da capacidade
├── INTERNO (cluster de agentes confiáveis)
│   ├── Ações: mTLS + JWS + capacidades (TTL maior)
│   ├── Auditoria: Logs agregados com publicação raiz diária
│   └── TTL: Máx. 1h de vida útil da capacidade
└── DEV/TEST (localhost, desenvolvimento)
    ├── Ações: mTLS opcional + capacidades básicas
    ├── Auditoria: Logs de arquivo local (sem Merkle tree)
    └── TTL: Máx. 24h de vida útil da capacidade

2. Solicitação do Agente → Verificação de Capacidade → Lógica de Concessão/Negação

Processamento de Solicitação de Agente Recebida:
├── 1. Verificar cadeia de certificados mTLS
│   ├── Assinatura CA válida? → Continuar
│   └── Inválida/expirada? → REJEITAR imediatamente
├── 2. Analisar envelope de mensagem JWS
│   ├── Assinatura válida + não expirada? → Continuar
│   ├── Repetição detectada (cache jti)? → REJEITAR
│   └── Assinatura inválida? → REJEITAR + registrar evento de segurança
├── 3. Verificar capacidades necessárias
│   ├── Agente possui a capacidade exata? → CONCEDER
│   ├── Agente possui capacidade mais ampla? → ATENUAR + CONCEDER
│   ├── Capacidade expirada? → REJEITAR + forçar atualização
│   └── Nenhuma capacidade correspondente? → REJEITAR + sugerir concessão mínima
└── 4. Executar com restrições de sandbox
    ├── Skills WASM: Limites de CPU/memória aplicados
    ├── Operações de arquivo: Validação de caminho contra capacidades
    └── Chamadas de rede: Validação de destino contra capacidades

3. Cadeia de Delegação → Decisão de Profundidade de Confiança

Solicitação de Delegação de Capacidade:
├── Capacidade pai delegável=true?
│   ├── Sim → Verificar profundidade restante
│   │   ├── Profundidade > 0 → Permitir com profundidade-1
│   │   └── Profundidade = 0 → REJEITAR (delegação máxima atingida)
│   └── Não → REJEITAR (não delegável)
├── Ações solicitadas ⊆ ações pai?
│   ├── Sim → Permitir subconjunto
│   └── Não → REJEITAR (não é possível escalonar privilégios)
└── Limite de confiança cruzado?
    ├── Mesmo domínio do orquestrador → Permitir
    └── Domínio diferente → Exigir capacidade explícita entre domínios

Modos de Falha

1. Vazamento de Autoridade Ambiente

Detecção: grep -r "process.env" agent_code/ mostra acesso a variáveis de ambiente sem verificação de capacidade Sintoma: Agente acessa recursos para os quais não deveria ter permissões Correção: Substituir por tokens de capacidade explícitos com escopo para os recursos exatos necessários

2. Ataque de Repetição de Mensagem

Detecção: Múltiplas entradas de log de auditoria com jti (ID da mensagem) idêntico ou timestamps dentro da janela de repetição Sintoma: Agente recebe e processa o mesmo comando várias vezes Correção: Implementar cache de deduplicação jti com TTL correspondente ao prazo de validade da mensagem

3. Escalonamento de Capacidade Através de Delegação

Detecção: Capacidade filha tem mais ações que a pai, ou profundidade de delegação excede o máximo configurado Sintoma: Subagentes obtêm mais privilégios do que o delegador pai pretendia Correção: Aplicar invariante de atenuação: capacidades filhas ⊆ capacidades pai no momento da delegação

4. Fuga da Sandbox Através de Exaustão de Recursos

Detecção: Uso de CPU do agente >95% por >30 segundos, ou uso de memória se aproximando dos limites da sandbox Sintoma: Agente tenta loops infinitos ou alocação excessiva de memória para escapar das restrições Correção: Matar o processo do agente nos limites de recursos, implementando medição de execução baseada em combustível

5. Aceitação de Certificado Trust-on-First-Use (TOFU)

Detecção: Agente aceita certificado sem verificação CA na primeira conexão Sintoma: Ataques man-in-the-middle têm sucesso ao apresentar qualquer certificado Correção: Pré-provisionar todos os certificados de agente, manter armazenamento de confiança explícito, rejeitar CAs desconhecidas

Exemplos Trabalhados

Exemplo 1: Pipeline de Assinatura de Mensagens Multi-Agente

Cenário: Agente de pesquisa precisa passar análise para agente de geração de código, depois para agente de revisão.

Fase de Configuração:

// Orquestrador cria capacidades
const researchCap = mint.mint('fs:/tmp/research/**', ['read','write'], 'agent-research-001');
const codegenCap = mint.mint('fs:/workspace/src/**', ['read','write'], 'agent-codegen-001'); 
const reviewCap = mint.mint('fs:/workspace/**', ['read'], 'agent-review-001');

Fluxo de Mensagem:

1. Pesquisa → Codegen: Agente de pesquisa cria mensagem assinada com JWS:

   Header: {alg: 'EdDSA', kid: 'agent-research-001/v1'}
   Payload: {
     iss: 'agent-research-001',
     sub: 'agent-codegen-001', 
     dag_id: 'proj-alpha-v1',
     action: 'task',
     body: {analysis: "API precisa de fluxo OAuth2", output_path: "/tmp/research/api_analysis.json"}
   }
   

2. Verificação Codegen: Agente Codegen recebe mensagem:

   • Verifica assinatura JWS contra chave pública do agente de pesquisa
   • Verifica TTL da mensagem (não expirada)
   • Valida se jti não está em cache de repetição
   • Confirma se dag_id corresponde ao contexto de execução atual
   • Captura de especialista: Verifica se agente de pesquisa tinha capacidade para output_path

3. Codegen → Revisão: Codegen cria resultado assinado:

   {
     "iss": "agent-codegen-001",
     "sub": "agent-review-001",
     "action": "result", 
     "body": {"generated_files": ["/workspace/src/auth.ts"], "confidence": 0.87}
   }
   

Erro de iniciante: Pularia a proteção de repetição jti, permitindo processamento duplicado. Insight de especialista: A trilha de auditoria mostra a cadeia de mensagens completa com prova criptográfica de custódia.

Exemplo 2: Emissão de Token de Capacidade com Atenuação

Cenário: Agente principal precisa delegar análise de arquivos a um subagente especializado, mas restringir o acesso a diretórios confidenciais.

Concessão Inicial:

// Orquestrador concede acesso amplo ao sistema de arquivos
const mainCap = mint.mint('fs:/project/**', ['read','write','execute'], 'agent-main', {
  delegatable: true,
  maxDepth: 2,
  ttlSeconds: 3600
});

Árvore de Decisão de Atenuação:

Agente principal avaliando solicitação de delegação:
├── Subagente solicita: fs:/project/src/** [read]
│   ├── /project/src/** ⊂ /project/** ? SIM
│   ├── [read] ⊂ [read,write,execute] ? SIM  
│   ├── Profundidade de delegação 2 > 0 ? SIM
│   └── CONCEDER: Criar capacidade atenuada
├── Subagente solicita: fs:/project/secrets/** [read]  
│   ├── Caminho contém "secrets" → Violação de política de segurança
│   └── REJEITAR: Exclusão de caminho confidencial
└── Subagente solicita: fs:/etc/passwd [read]
    ├── /etc/passwd ⊂ /project/** ? NÃO
    └── REJEITAR: Fora do escopo autorizado

Capacidade Atenuada Gerada:

const subCap = mint.attenuate(mainCap, 'agent-analyzer-001', ['read']);
// Resulta em: fs:/project/src/** [read] delegatable=true maxDepth=1 ttl=3600s

Erro de iniciante: Concederia capacidade pai completa sem restrição. Insight de especialista: A atenuação aplica "nunca escalonar privilégios" no nível criptográfico.

Exemplo 3: Detecção de Violação de Política de Sandbox com Análise de Trade-off

Cenário: Agente de geração de código tenta acessar a rede durante a execução, violando a política da sandbox.

Configuração da Sandbox:

const codegenSandbox = {
  fileRead: ['/workspace/src/**', '/workspace/package.json'],
  fileWrite: ['/workspace/src/**'], 
  netConnect: false,  // SEM acesso à rede
  maxExecutionMs: 300000,
  maxMemoryMb: 512
};

Fluxo de Detecção de Violação:

1. Ação do Agente: Codegen tenta fetch('https://api.github.com/repos/...')

2. Interceptação da Sandbox: Runtime WASM captura chamada de sistema para socket de rede

3. Verificação de Política: netConnect: false → VIOLAÇÃO DETECTADA

4. Análise de Trade-off:

   Compensações entre Segurança e Funcionalidade:
   ├── ESTRITO (atual): Bloquear rede, encerrar agente
   │   ├── Pró: Superfície de ataque de rede zero
   │   ├── Contra: Não pode buscar dependências/documentação externas
   │   └── Decisão: APLICAR (ambiente segurança-primeiro)
   ├── MODERADO: Permitir domínios específicos na lista de permissões
   │   ├── Pró: Funcional para APIs conhecidas e confiáveis  
   │   ├── Contra: Riscos de envenenamento de DNS, sequestro de subdomínio
   │   └── Decisão: Considerar apenas para ambientes dev
   └── PERMISSIVO: Registrar mas permitir
       ├── Pró: Funcionalidade total preservada
       ├── Contra: Agente pode exfiltrar dados, baixar malware
       └── Decisão: REJEITAR (viola modelo zero-trust)
   

5. Resposta: Encerrar agente, registrar evento de segurança:

   {
     "event": "sandbox_violation",
     "agent_id": "agent-codegen-001", 
     "violation_type": "unauthorized_network_access",
     "attempted_url": "api.github.com",
     "policy_matched": "netConnect: false",
     "action_taken": "terminate_agent"
   }
   

Erro de iniciante: Permitiria o acesso à rede "só desta vez" ou não detectaria a violação. Insight de especialista: Violações de sandbox indicam possível comprometimento ou deriva de modelo — sempre aplicar estritamente.

Portões de Qualidade

• Cada agente tem identidade criptográfica única (par de chaves Ed25519 + certificado)
• Todos os canais agente-para-agente usam TLS mútuo com verificação de certificado
• Todas as mensagens carregam assinaturas JWS com TTL <5min e proteção de repetição jti
• Tokens de capacidade seguem o modelo ocap (nenhuma autoridade ambiente em lugar nenhum)
• Delegação de capacidade preserva o invariante de atenuação (filho ⊆ privilégios pai)
• Trilha de auditoria usa Merkle tree somente para anexar com raízes publicadas
• Toda execução de skill ocorre em sandbox WASM ou contêiner
• Limites de recursos aplicados (CPU, memória, tempo de execução, rede)
• Pacotes de skill são endereçados por conteúdo e assinados pelo autor
• Nenhum agente aceita skills/entradas não assinadas ou não verificadas
• Rotação de certificados automatizada com <24h de vida útil do certificado
• Cache de detecção de repetição operacional com TTL correspondente ao prazo de validade da mensagem
• Todas as violações de segurança registradas com timestamp + identidade do agente + ação tomada

Limites NÃO-PARA

Esta skill NÃO deve ser usada para:

• Varredura de vulnerabilidades em nível de aplicação → Use security-auditor
• Configuração de firewall de rede/WAF → Use infrastructure-engineer
• Documentação de conformidade SOC2/HIPAA → Use processos de compliance organizacionais
• Defesa contra injeção de prompt → Use a skill prompt-engineer
• Limitação de taxa ou proteção DDoS → Use configuração de API Gateway
• Segurança de orquestração de contêineres → Use a skill devops-automator

Limites de delegação:

• Para problemas de segurança em nível de código → security-auditor
• Para fortalecimento de infraestrutura → infrastructure-engineer
• Para práticas de codificação segura → software-engineer
• Para resposta a incidentes → security-incident-response