OWASP SAMM ganha extensão Agentic SAMM para desenvolvimento seguro com agentes de IA

Em torno do OWASP SAMM surgiu um novo projeto em rascunho, o Agentic SAMM (ASAMM): uma extensão para equipes que constroem produtos com agentes de IA e usam modelos no desenvolvimento. O objetivo é cobrir riscos que o secure SDLC clássico enxerga mal: contexto malicioso, chamadas perigosas de ferramentas e janelas de autonomia longas demais.

Por que o SAMM antigo não basta

O OWASP SAMM clássico funciona bem quando os principais objetos de proteção são código, build, release e infraestrutura de entrega. Mas em sistemas agênticos a superfície de ataque vai além: chega a documentos, tarefas no tracker, descrições de ferramentas, resultados de busca na web, logs de CI e qualquer outro conteúdo que o modelo lê como parte do contexto de trabalho. Se esse contexto influencia o comportamento do agente, ele deixa de ser apenas dado de entrada e passa a fazer parte do control plane.

Por isso o autor do ASAMM propõe enxergar o desenvolvimento não como um ciclo fechado, mas como uma espiral. A equipe volta a passar por projeto, implementação e verificação, mas a cada volta mudam o sistema, as ferramentas e as próprias ameaças. Nesse esquema, já não basta checar se o agente recebeu as permissões corretas. Mesmo um agente totalmente autorizado pode executar uma ação que não corresponde à tarefa original se o contexto ou a lógica de delegação o desviarem do caminho.

O que o ASAMM propõe

O ASAMM foi concebido não para substituir o OWASP SAMM, mas como uma camada adicional para equipes que adotam agentes de IA, servidores MCP e automação com poderes delegados. O framework acrescenta uma camada própria de garantias onde terminam as verificações habituais de código: na fronteira das chamadas de ferramentas, no fluxo de contexto, nos approval checkpoints e no comportamento do sistema em execução. Ele não cancela as práticas básicas do SAMM, mas as estende ao comportamento em runtime e às ações delegadas.

• Uma taxonomia de ameaças para sistemas agênticos, em que o contexto é tratado como um comando em potencial
• Um modelo de confiança de dois eixos para agentes, ferramentas, servidores MCP e fontes de contexto
• Um conjunto de controles para as cinco funções do SAMM, com níveis de maturidade e cenários de adoção
• Dois caminhos de implantação: migrar de um programa de segurança existente ou começar do zero
• Um mapeamento para o NIST AI RMF e as recomendações do NCSC, para equipes que precisam de compatibilidade com frameworks já conhecidos

O material dá destaque especial ao ambiente de desenvolvimento. Plugins de IDE, hooks de pre-commit, agentes de CI e conectores MCP externos operam com privilégios de desenvolvedor, mas muitas vezes ficam fora de um threat model completo. Para o ASAMM, isso não é um elemento secundário, e sim um alvo pleno de análise: se o agente pode ler, chamar e alterar mais do que a equipe realmente acompanha, os status verdes nos dashboards deixam de garantir qualquer coisa. Na prática, o ambiente de desenvolvimento vira produção para o próprio agente.

Onde as equipes já erram

O material lista erros típicos, especialmente visíveis no desenvolvimento agêntico. A equipe pode considerar o threat model concluído, embora ele não inclua fontes de contexto nem caminhos de chamada de ferramentas. O code review pode cobrir todo o código de um PR, mas não alcançar prompts de sistema, esquemas de tool calls e configurações dos agentes. O DAST pode mostrar resultado limpo sem que ninguém tenha verificado como o agente se comporta diante de um contexto hostil. E o least privilege costuma ser implementado só no nível das contas de serviço, sem limitar as ações permitidas por meio das ferramentas.

"Nenhum plano sobrevive ao primeiro contato."

O autor usa essa ideia como princípio de projeto: o prompt de sistema deve definir a intenção, e não tentar descrever rigidamente todo o algoritmo de comportamento.

Daí vem mais um parâmetro de risco importante: o produto da janela de autonomia pelo blast radius das ferramentas disponíveis. Quanto mais tempo o agente age sem um ponto de controle humano e quanto mais amplo é seu conjunto de capacidades, maior o dano potencial, mesmo com direitos de acesso formalmente corretos. Por isso, as janelas de autonomia passam a ser aqui um parâmetro arquitetural, e não apenas operacional.

O que isso significa

O Agentic SAMM registra uma mudança que já aconteceu no desenvolvimento com IA: a segurança agora verifica não só o código, mas também o comportamento do sistema depois do release. Para equipes que constroem produtos sobre agentes e vibe coding, é um sinal para rever o threat model, o code review e o controle de ferramentas antes que o primeiro erro autônomo se transforme em um incidente de verdade.