OWASP lança Enterprise Adoption Maturity Model para governança de agentic AI

A OWASP apresentou nesta semana um novo framework de maturidade de segurança para agentic AI, batizado de “Enterprise Adoption Maturity Model”. Apresentado por Ariel Fogel, da Pillar Security, durante a OWASP GenAI Security Summit na Infosecurity Europe 2026, o modelo nasce de um diagnóstico incômodo: a maioria das organizações está implantando agentes autônomos em ritmo muito superior à sua capacidade de governá-los — e ainda opera com controles desenhados para a era dos copilotos.

O que aconteceu

O framework está descrito no novo paper do OWASP GenAI Security Project, “State of Agentic AI Security and Governance”, publicado em 3 de junho. Ao contrário de outras iniciativas no espaço, ele não é apresentado como mais um catálogo de regras em crescimento contínuo, mas como uma ferramenta prática de decisão: ajuda equipes a saber, agente por agente, se a governança atual cabe no risco que está sendo aceito.

O lançamento ocorre em um momento em que ataques específicos contra fluxos de LLMs e agentes — prompt injection persistente, abuso de ferramentas conectadas, tool poisoning e exfiltração via memória — saíram do território acadêmico e começaram a aparecer em incidentes reais reportados por equipes de resposta. O OWASP afirma que poucas organizações têm sequer um inventário confiável dos agentes que rodam em produção.

O documento é assinado por co-leads do projeto e, segundo Fogel, foi escrito a partir de feedback de operadores que já enfrentam o problema concreto de auditar pipelines envolvendo múltiplos agentes em interação.

Como o framework funciona

O modelo organiza a discussão em duas dimensões. A primeira mede o que está sendo implantado: vai do shadow AI — uso não autorizado por colaboradores — passando por ferramentas single-vendor e agentes customizados, até chegar a sistemas multi-agente e arquiteturas federadas. São seis níveis de adoção de agentic AI, com complexidade e superfície de ataque crescentes.

A segunda dimensão mede a maturidade de governança, em quatro patamares que vão de processos ad hoc até continuous monitoring com enforcement automatizado e adaptativo. Combinando os dois eixos, cada workflow recebe uma posição em uma matriz que pode aparecer em verde (governança compatível com a implantação), amarelo (oversight parcial) ou vermelho (implantação sem o nível de controle necessário).

“A maioria das organizações está implantando agentes mais rápido do que consegue governá-los. A governança ainda opera nos níveis de maturidade desenhados para copilotos de IA, enquanto as equipes estão entregando e operando sistemas customizados e multi-agente.”

Ariel Fogel, Pillar Security

A lógica operacional é direta: colocar cada agente no eixo de deployment e verificar se a maturidade de governança bate com aquele nível. Se a governança for insuficiente, o framework dá dois caminhos práticos — investir em controles desenhados especificamente para sistemas agentic, ou reduzir permissões e autonomia do agente até que os controles existentes sejam suficientes. Em outras palavras: ou sobe-se o nível de proteção, ou desce-se o nível do risco.

O paper insiste que os controles necessários não são apenas versões reforçadas de medidas tradicionais. Como os agentes operam em velocidade e escala de máquina, o monitoramento precisa rodar no mesmo ritmo: behavior analytics ao vivo, telemetria por chamada de ferramenta e capacidade de intervir em tempo real, não em revisão pós-fato.

Quem é afetado

O escopo do modelo é amplo, mas alguns perfis ficam particularmente expostos:

• Empresas que já têm múltiplas iniciativas de agentes em produção sem inventário centralizado.
• Times de produto que conectam agentes a ferramentas externas (e-mail, bancos de dados, APIs internas) sem revisão de segurança a cada nova ferramenta.
• Organizações reguladas — finanças, saúde, setor público — onde a falta de visibilidade sobre decisões automatizadas vira risco de compliance.
• Áreas que operam pipelines multi-agente para tarefas internas (RH, jurídico, suporte) sem segregação entre agentes que leem e agentes que executam.
• Empresas que dependem de copilotos third-party como porta de entrada para automação, mas não testam regularmente prompt injection nos canais de input.

Análise

O modelo da OWASP chega tarde para muita gente — e isso é parte do mérito. Em vez de propor mais uma “Top 10 de ameaças agentic”, o framework reconhece que a maior fonte de risco hoje não é exotismo técnico, mas descompasso organizacional. Equipes de produto ganharam capacidade de implantar agentes em horas; equipes de segurança seguem operando em ciclos de revisão de semanas. A matriz verde-amarela-vermelha é, antes de tudo, uma ferramenta para forçar essa conversa interna.

A escolha de chamar de “shadow AI” o nível mais baixo de deployment dialoga com um problema conhecido: assim como o shadow IT de uma década atrás, agentes não-autorizados rodam hoje em laptops corporativos via extensões de browser, plugins de IDE e ferramentas de produtividade. O OWASP está deixando claro que ignorar essa camada significa começar a matriz em terreno crítico.

O ponto mais incômodo do framework, e provavelmente o mais útil, é a recomendação de reduzir permissões e autonomia quando o controle não acompanha. Isso conflita com a narrativa de mercado de “agentes autônomos end-to-end”, mas alinha-se com o princípio de menor privilégio que orientou décadas de boa engenharia de segurança. Se a organização não pode monitorar o que o agente faz a cada passo, então o agente não deveria poder fazer cada passo. É uma tese simples, e politicamente difícil dentro das empresas.

Recomendações práticas

• Construa um inventário formal de agentes em produção, incluindo ferramentas conectadas, escopos de credenciais e dados acessados.
• Classifique cada agente nos dois eixos do framework (deployment e governança) e identifique as células vermelhas antes que um incidente o faça.
• Reduza autonomia onde a governança não acompanha — exija aprovação humana para ações irreversíveis (envio externo, escrita em produção, modificações de IAM).
• Implemente tool-call logging centralizado, com retenção compatível com investigação de incidente.
• Trate prompts de sistema, ferramentas e memória persistente como ativos versionados, sujeitos a code review e detecção de mudança.
• Execute red teaming focado em prompt injection multi-turn e tool poisoning antes de cada release relevante.
• Treine o time de SOC para reconhecer indicadores de comportamento agentic anômalo (loops, exfiltração lenta, escalada de ferramentas).

Fonte: Infosecurity Magazine