A Linux Foundation publicou um Pedido de Comentários sobre o Shared AI Findings Exchange, ou SAFE, um framework proposto para coletar e compartilhar informações sobre incidentes de cibersegurança envolvendo agentes de IA. A iniciativa está sendo desenvolvida pela Open Secure AI Alliance à medida que as empresas passam de testes de modelos para sistemas que podem acessar ferramentas, dados e aplicativos corporativos.

NVIDIA, Cisco, CrowdStrike, Hugging Face e Red Hat estão entre as organizações que contribuem para a proposta, segundo uma postagem de blog da NVIDIA. A aliança diz que agora inclui mais de 120 organizações. A ideia central é transformar relatórios confidenciais sobre incidentes e quase incidentes em orientações baseadas em evidências que possam ajudar outros desenvolvedores a evitar as mesmas falhas.

SAFE mira a camada operacional da segurança em IA

A proposta SAFE vai além da divulgação convencional de vulnerabilidades. As diretrizes descritas pela NVIDIA pedem a coleta e análise confidenciais de incidentes relacionados à IA, a notificação das partes afetadas, a identificação de falhas de controle recorrentes e a publicação de recomendações operacionais destinadas a reduzir o risco sistêmico.

Esse escopo reflete uma mudança na forma como os sistemas de IA estão sendo construídos. Um agente não é apenas um modelo; ele também pode incluir um harness de orquestração, controles de identidade, ferramentas, restrições de tempo de execução, guardrails, sistemas de logging e avaliação. Uma fraqueza em qualquer uma dessas camadas pode afetar o que um agente é capaz de ver, acessar ou alterar.

Para os desenvolvedores, um formato compartilhado de incidentes poderia facilitar a comparação de falhas de segurança de agentes entre produtos e implantações. Hoje, informações sobre prompt injection, uso indevido de ferramentas, credenciais vazadas ou ações autônomas inseguras podem permanecer dentro de empresas individuais. A abordagem proposta pelo SAFE pretende criar um mecanismo para compartilhar lições sem expor imediatamente detalhes operacionais sensíveis.

A proposta continua sendo um rascunho. O anúncio disponível não especifica a taxonomia completa de relatórios, o modelo de governança, os requisitos de participação ou o cronograma para finalizar as diretrizes.

A aliança combina relatórios com ferramentas abertas

A NVIDIA apresentou o SAFE ao lado de um conjunto mais amplo de contribuições de segurança de membros da Open Secure AI Alliance. Seus próprios exemplos incluem o harness de pesquisa NVIDIA Labs Object-Oriented Agent, que a empresa diz ter sido projetado para facilitar o teste, o rastreamento e a auditoria do comportamento de agentes, e o NVIDIA OpenShell, um runtime destinado a limitar o que um agente pode acessar e fazer.

A NVIDIA também destacou o Garak, seu scanner de vulnerabilidades de código aberto para modelos de linguagem de grande porte, que verifica problemas como vazamento de dados, prompt injection e comportamento de jailbreak. Outras ferramentas nomeadas incluem NeMo Guardrails, NeMo Anonymizer e NeMo Safe Synthesizer, cobrindo aplicação de políticas, proteção de dados sensíveis e geração de dados sintéticos orientada à privacidade.

Vários membros da aliança estão contribuindo com ferramentas em diferentes pontos da pilha. A Okta está desenvolvendo implementações de referência para identidade e acesso de agentes usando Cross App Access. A Palo Alto Networks contribuiu com Agent Guard e Agent Watch de sua plataforma de segurança de identidade Idira. A Red Hat introduziu o asago, um projeto de código aberto que mapeia requisitos de governança para permissões de runtime e registros de auditoria, segundo a NVIDIA.

A Amazon, descrita como nova membro da aliança na postagem, está contribuindo com Strands Agents e Cedar. Strands Agents é um kit de ferramentas de código aberto para construir agentes, enquanto Cedar é uma linguagem de autorização projetada para definir e impor limites de acesso. Esses projetos abordam questões de implementação que o SAFE sozinho não pode resolver: o que um agente pode fazer, qual identidade ele usa e como essas decisões são registradas.

As evidências atualmente se baseiam em relatos dos participantes

A notícia central é confirmada pela fonte da NVIDIA: a Linux Foundation emitiu um RFC para o SAFE, e um grupo de trabalho da Open Secure AI Alliance está contribuindo para ele. A contagem de membros e as descrições das ferramentas participantes também vêm da NVIDIA, um membro da aliança com interesse direto em promover uma infraestrutura aberta de segurança em IA.

A fonte disponível não inclui testes independentes do SAFE, evidência de que o framework tenha sido adotado por empresas, ou prova de que as ferramentas listadas reduzam as taxas de incidentes em produção. Alegações sobre as capacidades dos produtos da NVIDIA e as contribuições de outros membros devem, portanto, ser tratadas como descrições de fornecedores ou participantes, e não como resultados de desempenho verificados independentemente.

Também não há indicação ainda de que o SAFE tenha se tornado um padrão formal. Um RFC cria uma oportunidade de revisão e ajuste, mas seu valor prático dependerá de as organizações concordarem sobre o que reportar, como anonimizar incidentes e quão rapidamente os insights úteis chegam a desenvolvedores e operadores.

Por que a proposta importa para equipes de IA

Para equipes de produto que implantam agentes, o benefício potencial mais importante é o aprendizado operacional. Uma estrutura comum de relatórios poderia ajudar engenheiros de segurança a distinguir comportamento isolado do modelo de falhas causadas por permissões, integrações de ferramentas, lógica de orquestração ou monitoramento fraco. Essa distinção importa porque mudar o modelo pode não corrigir uma vulnerabilidade que exista no sistema ao redor.

Compradores corporativos também podem olhar para um processo SAFE maduro ao avaliar fornecedores. Eles podem perguntar se um provedor de IA participa da divulgação de incidentes, como lida com quase incidentes e se seus controles estão mapeados para evidências concretas. Mas esses benefícios só se materializarão se o framework produzir relatórios consistentes e acionáveis, em vez de alertas amplos difíceis de aplicar.

A iniciativa também destaca uma tensão competitiva na infraestrutura de IA. Ferramentas de segurança de código aberto podem melhorar a inspeção e a portabilidade, enquanto os relatórios compartilhados podem expor fragilidades repetidas entre fornecedores. Ao mesmo tempo, as empresas podem hesitar em divulgar incidentes envolvendo dados de clientes, sistemas proprietários ou risco reputacional. As regras de confidencialidade e governança do SAFE serão centrais para resolver essa tensão.

O que observar a seguir

O próximo sinal será o conteúdo do processo de feedback da Linux Foundation: especificamente, se o SAFE define um esquema de incidente utilizável, proteções claras para informações sensíveis e responsabilidades para notificar organizações afetadas.

Os desenvolvedores também devem observar evidências de implementação, e não apenas anúncios adicionais de adesão. Indicadores úteis seriam relatórios de incidentes anonimizados publicados, integrações com ferramentas de observabilidade e avaliação de agentes, e exemplos mostrando como uma descoberta compartilhada levou a uma mudança em permissões, controles de runtime ou política de implantação.

Por fim, o mercado precisará ver se o SAFE se conecta com estruturas existentes de segurança e governança, incluindo orientações do NIST e do OWASP, sem criar outra camada de conformidade desconectada. A adoção por organizações fora da aliança fundadora seria um teste mais forte do que a contagem atual de participantes.

Perspectiva da Creati.ai

O SAFE enfrenta uma fraqueza real na segurança de agentes: as equipes estão sendo solicitadas a gerenciar sistemas que podem agir entre modelos, ferramentas e recursos corporativos, enquanto grande parte do conhecimento disponível permanece fragmentada. Um processo compartilhado para incidentes e quase incidentes poderia tornar a engenharia defensiva mais cumulativa, em vez de obrigar cada empresa a redescobrir os mesmos modos de falha.

Mas a credibilidade da proposta dependerá da execução. O framework precisa de regras de reporte precisas, incentivos para participação franca e detalhes técnicos suficientes para produzir controles que os desenvolvedores realmente possam implantar. Até que esses elementos estejam visíveis, o SAFE é melhor entendido como um esforço importante de padronização — ainda não como uma solução de segurança demonstrada.