Três Erros de Segurança em IA Colocam Empresas em Risco

O Google News destacou um alerta da InfoWorld sobre três conflitos que as empresas não podem mais tratar como riscos teóricos de IA. Modelos confiáveis podem processar instruções hostis, agentes podem herdar permissões excessivas e telas de aprovação humana podem ocultar a ação que está sendo autorizada.

A manchete importa porque as empresas estão passando de assistentes conversacionais para sistemas que leem arquivos, acionam aplicativos, modificam código e iniciam processos de negócios. Essa transição transforma uma resposta equivocada em um possível incidente de segurança. O conflito central agora está claro: implantação rápida de IA versus limites aplicáveis ao que cada sistema pode ver e fazer.

O problema não é que todos os modelos tenham se tornado maliciosos de repente. É que controles conhecidos frequentemente perdem o significado quando um software probabilístico se posiciona entre dados, usuários, credenciais e ferramentas. Incidentes recentes envolvendo Microsoft, Google, Amazon, Anthropic, Cursor e outros fornecedores mostram como essa lacuna pode se tornar operacional rapidamente.

O Alerta do Google News É Sobre Controle, Não Inteligência

O erro empresarial mais perigoso é tratar o comportamento do modelo como a principal fronteira de segurança.

A listagem do Google News aponta para uma manchete da InfoWorld sobre três erros de segurança que assombram as empresas. O sinal mais amplo é mais importante do que o enquadramento sazonal. As empresas estão conectando modelos de linguagem a sistemas valiosos antes de redefinir os limites em torno dessas conexões.

Antes, um chatbot produzia texto para uma pessoa revisar. Agora, um agente de IA pode decidir qual ferramenta chamar, montar argumentos, usar credenciais armazenadas e prosseguir por várias etapas. Esse alcance ampliado transforma erros do modelo em problemas de segurança de aplicações.

As organizações frequentemente respondem colocando mais instruções no prompt de sistema. Elas dizem ao modelo para não divulgar informações confidenciais, seguir comandos não confiáveis ou realizar ações perigosas. Essas instruções podem melhorar o comportamento, mas não criam uma fronteira de autorização aplicável.

A injeção de prompt explica o motivo. Uma injeção de prompt é um conteúdo malicioso ou enganoso que leva um modelo a seguir instruções não intencionais. Uma injeção indireta chega por meio de material recuperado pelo modelo, como um e-mail, página da web, documento, issue ou repositório.

O modelo precisa interpretar tanto instruções confiáveis quanto conteúdo não confiável pela mesma interface de linguagem natural. Ele pode reconhecer uma frase como dados em um contexto e depois tratar texto semelhante como um comando em outro. Nenhum prompt pode alterar as permissões concedidas pela aplicação ao redor.

A lista de riscos da OWASP coloca a injeção de prompt em primeiro lugar entre seus riscos de 2025 para aplicações de modelos de linguagem de grande porte. Ela também identifica separadamente a divulgação de informações sensíveis, fraquezas na cadeia de suprimentos, tratamento inadequado de saída e agência excessiva.

Essa separação oferece uma lição útil. A injeção de prompt costuma ser o gatilho, mas a arquitetura ao redor determina a consequência. Um assistente comprometido por injeção, sem segredos e sem acesso de escrita, tem um raio de impacto limitado. A mesma entrada se torna grave quando um agente pode ler e-mails, consultar dados privados, executar código ou alterar recursos de nuvem.

É por isso que um raciocínio melhor do modelo não cria automaticamente uma segurança melhor. Um modelo mais capaz pode seguir planos legítimos com maior confiabilidade. Ele também pode navegar por sistemas conectados com mais eficácia depois que um invasor redireciona seu plano.

Portanto, as empresas devem avaliar a IA como um componente de decisão não confiável dentro de um sistema de segurança maior. O modelo pode propor uma ação, mas controles determinísticos devem decidir se essa ação é permitida. Esses controles incluem verificações de identidade, aplicação de políticas, isolamento de entradas e validação de saídas.

Esse princípio também muda a forma como as equipes investigam falhas. Uma resposta estranha não é apenas um problema de qualidade quando o modelo tem ferramentas. Os revisores devem perguntar qual identidade executou a solicitação, quais dados entraram no contexto e qual estado externo foi alterado.

Os três erros da manchete estão conectados por essa ausência de um plano de controle. As empresas confiam no modelo, confiam nas permissões ao redor dele e confiam no processo de aprovação apresentado aos usuários. Cada camada pode falhar enquanto parece normal.

Erro Um: Tratar Barreiras do Modelo Como Controles de Segurança

Uma recusa do modelo é uma preferência comportamental, enquanto uma regra de controle de acesso é uma decisão aplicável.

As empresas frequentemente iniciam revisões de segurança de IA testando se um modelo recusa solicitações proibidas. Esse trabalho tem valor, especialmente para prevenção de abuso e conformidade com políticas. Ele não responde se a aplicação completa consegue proteger segredos ou resistir a contextos manipulados.

Uma barreira de proteção do modelo normalmente opera por treinamento, filtragem, classificação ou instruções escritas. Essas medidas influenciam as respostas. Elas não podem revogar uma permissão de banco de dados, reduzir a duração de um token ou impedir que uma aplicação passe registros confidenciais para o contexto.

A distinção se torna importante quando a geração aumentada por recuperação está envolvida. A geração aumentada por recuperação, ou RAG, fornece documentos empresariais selecionados a um modelo antes que ele responda. O modelo só pode raciocinar sobre o material que a camada de recuperação fornece, tornando as permissões de recuperação parte da fronteira de segurança.

Se essa camada retorna documentos apenas com base em relevância semântica, ela pode cruzar limites organizacionais. Uma passagem aparentemente útil pode pertencer a outro departamento, cliente ou assunto jurídico. O resumo fluente do modelo pode então ocultar o erro de autorização subjacente.

O mesmo risco aparece quando aplicações recuperam conteúdo de fora da empresa. Um agente de pesquisa pode ler páginas da web, anexos, tickets de suporte e documentos compartilhados. Qualquer uma dessas fontes pode conter instruções destinadas ao agente, em vez de informações úteis para o funcionário.

A descrição da Microsoft sobre a vulnerabilidade EchoLeak corrigida mostra a gravidade dessa via. A empresa afirma que o ataque utilizou uma injeção de prompt entre vários estágios, sob certas condições, para exfiltrar dados limitados disponíveis para uma vítima. A Microsoft tratou o problema como CVE-2025-32711.

A importância das orientações sobre EchoLeak vai além de um único produto. Elas demonstraram que um assistente em produção pode combinar conteúdo externo, acesso interno e comportamento do modelo em uma via de exfiltração de dados.

Uma defesa baseada apenas em prompt pede que o modelo perceba a manipulação. Uma defesa em nível de sistema pressupõe que a detecção pode falhar. Em seguida, ela limita os dados recuperados, bloqueia canais de saída perigosos e verifica toda operação sensível fora do modelo.

O National Institute of Standards and Technology adota uma visão igualmente ampla. Seu perfil de IA generativa aborda riscos em design, desenvolvimento, implantação, avaliação e uso. Ele não reduz a segurança de IA à filtragem de modelos.

Essa abordagem de ciclo de vida importa porque aplicações empresariais contêm muitos componentes. Elas incluem fornecedores de modelos, bancos de dados vetoriais, sistemas de identidade, plugins, APIs, ferramentas de monitoramento e interfaces de usuário. Uma revisão de segurança que testa apenas o modelo deixa a maior parte dessa cadeia intocada.

Um teste prático deve começar com premissas de contexto comprometido. Os revisores podem inserir instruções hostis em documentos que a aplicação normalmente recupera. Em seguida, podem observar se o agente expõe dados, altera seu objetivo ou tenta uma chamada de ferramenta não autorizada.

As equipes devem repetir esses testes após alterar modelos, prompts, conectores, configurações de recuperação ou descrições de ferramentas. O comportamento da IA pode mudar mesmo quando o código da aplicação parece inalterado. Uma avaliação bem-sucedida no trimestre anterior não garante que o fluxo de trabalho atual se comporte de forma idêntica.

Atualizações de modelos criam outra fonte de falsa confiança. Um fornecedor pode melhorar o comportamento de recusa ao mesmo tempo em que introduz diferentes padrões de planejamento. Uma aplicação que dependia de uma recusa não documentada pode se tornar menos previsível sem qualquer mudança formal de permissão.

A arquitetura mais segura trata os prompts como uma camada defensiva. Ela os combina com controles de acesso que o modelo não pode reescrever. Dados sensíveis devem permanecer indisponíveis, a menos que o usuário, a tarefa e o recurso atendam a uma política explícita.

As saídas também exigem inspeção antes de se tornarem ações. Uma consulta de banco de dados gerada deve passar por autorização e validação. Um e-mail proposto deve passar por verificações de destinatário. O código deve ser executado em um ambiente isolado, com acesso restrito ao sistema de arquivos e à rede.

Essa estrutura não elimina a injeção de prompt. Ela impede que uma injeção bem-sucedida se transforme automaticamente em uma violação. Esse é o objetivo mais realista para a segurança empresarial.

Erro Dois: Dar a Agentes de IA Permissões do Tamanho de um Humano

Um agente deve receber a menor permissão temporária necessária para uma tarefa, e não o acesso permanente detido por seu usuário.

O segundo erro aparece quando uma empresa conecta um agente de IA às credenciais existentes de funcionários. Essa abordagem é conveniente porque as aplicações já entendem essas identidades. Ela também dá à automação probabilística o alcance acumulado em torno de uma conta humana.

Os funcionários frequentemente precisam de acesso amplo porque suas responsabilidades variam ao longo da semana. Um agente que executa uma solicitação restrita não precisa da mesma amplitude. Se ele herda todas as caixas de e-mail, repositórios, registros de clientes e ferramentas de nuvem acessíveis, seu raio de impacto se torna desnecessariamente grande.

A OWASP descreve esse problema como agência excessiva. A vulnerabilidade surge quando um sistema de IA recebe funcionalidade demais, permissões demais ou autonomia demais. Uma saída manipulada pode então produzir ações prejudiciais à confidencialidade, integridade e disponibilidade.

A palavra “agência” pode fazer o risco parecer abstrato. Na prática, ela significa permissões comuns vinculadas a um planejador imprevisível. Um modelo escolhe uma chamada de ferramenta, a aplicação fornece credenciais e outro sistema aceita a solicitação como autorizada.

O princípio tradicional do menor privilégio continua sendo o ponto de partida correto. Cada agente precisa de uma identidade distinta, uma tarefa definida e uma lista curta de recursos permitidos. Essa identidade não deve tomar silenciosamente emprestado o acesso ao shell de um desenvolvedor ou todo o acervo de documentos de um executivo.

As credenciais também devem expirar rapidamente. Chaves de longa duração permitem que um erro ou comprometimento persista depois que a sessão original termina. Tokens de curta duração reduzem essa janela e criam registros de auditoria mais claros para cada tarefa.

O acesso de escrita merece tratamento separado do acesso de leitura. Muitos assistentes podem fornecer resumos úteis sem modificar sistemas de origem. As empresas devem começar por aí e, depois, adicionar ações de escopo restrito apenas após testar o caminho completo.

Operações de alto impacto precisam de limites transacionais. Um agente que prepara o reembolso de um cliente pode reunir evidências e recomendar um valor. Um serviço determinístico separado deve verificar política, autorização, destino e limites antes de emitir qualquer coisa.

O mesmo padrão se aplica ao desenvolvimento de software. Um agente pode propor um patch dentro de um espaço de trabalho temporário. Ele não deve herdar automaticamente acesso a credenciais de produção, sistemas de implantação, arquivos pessoais de configuração ou repositórios não relacionados.

O acesso à rede também merece restrições por tarefa. Um agente de programação que precisa apenas de documentação de pacotes não deve alcançar servidores externos arbitrários. Um assistente de pesquisa pode operar por meio de um mecanismo de busca aprovado que bloqueie endereços privados, protocolos perigosos e downloads não confiáveis.

Descrições de ferramentas não são controles de permissão. Dizer a um agente que uma função deve ser usada apenas para uma finalidade específica não impede invocações não autorizadas. O serviço que a recebe precisa impor quem pode chamá-la, quais argumentos são válidos e quais recursos permanecem no escopo.

É nesse ponto que muitos programas corporativos de IA colidem com a velocidade de implantação. Equipes de produto querem um conector que funcione em muitos casos de uso. Equipes de segurança precisam de escopos, identidades, logs e regras de aprovação separados para cada ação relevante.

A tensão é real, mas o acesso amplo não é o único desenho viável. Empresas podem emitir capacidades para tarefas individuais. Uma capacidade é uma permissão estritamente definida que autoriza uma ação contra um recurso por um período limitado.

Essa abordagem também melhora as investigações. Os logs podem mostrar que uma instância específica de agente leu três registros aprovados para uma solicitação de suporte. Credenciais compartilhadas de usuários, por outro lado, produzem um fluxo de ações que pode ser difícil de atribuir.

A minimização de dados faz parte do mesmo desenho. Um agente não precisa de um documento inteiro quando um campo filtrado responde à pergunta. Ele não precisa de todas as contas de clientes quando a tarefa nomeia apenas uma conta.

Equipes que criam sistemas internos pesquisáveis enfrentam essa questão cedo. Uma base de conhecimento técnica segura precisa preservar as permissões das fontes, em vez de transformar todos os arquivos em um único índice sem restrições.

A comparação importante não é entre agentes e humanos. É entre acesso humano permanente e acesso de máquina específico para a tarefa. Máquinas operam mais rápido, repetem ações com consistência e podem escalar um único erro para muitos registros.

As empresas devem projetar seus sistemas de acordo. Um sistema capaz de agir centenas de vezes em uma sessão precisa de limites mais rígidos do que uma pessoa realizando uma única alteração deliberada. A velocidade amplia tanto a produtividade quanto o dano.

Erro Três: Presumir que a Aprovação Humana Torna uma Ação Segura

O envolvimento humano acrescenta pouca proteção quando a interface oculta o alvo, o momento ou a consequência da ação proposta.

Muitos produtos corporativos de IA colocam uma pessoa no ciclo antes de operações relevantes. O agente apresenta uma caixa de confirmação, e o usuário escolhe se deseja continuar. Esse desenho parece tranquilizador porque a responsabilidade continua visivelmente humana.

A proteção depende do que a pessoa realmente consegue ver. Um aviso vago, como “permitir esta alteração”, não sustenta uma decisão informada. Tampouco uma tela de aprovação construída a partir de conteúdo que um atacante pode influenciar.

A pesquisa GhostApproval da Wiz expôs esse problema em seis assistentes de programação com IA de destaque. O grupo afetado incluía Amazon Q Developer, Anthropic Claude Code, Augment, Cursor, Google Antigravity e Windsurf.

Segundo as constatações do GhostApproval, um repositório malicioso poderia usar links simbólicos para redirecionar uma alteração aparentemente local de arquivo para fora do espaço de trabalho. Um link simbólico é uma referência no sistema de arquivos que aponta um caminho para outro local.

A aprovação visível poderia citar um arquivo inocente do projeto, enquanto o caminho resolvido apontava para um arquivo sensível do sistema. Em alguns produtos testados, a Wiz relatou que gravações ocorriam antes de uma autorização significativa. Isso transformava a interface de uma barreira de segurança em um mecanismo de desfazer.

As conclusões não significam que todas as versões atuais continuem vulneráveis. A Wiz relatou correções ou respostas de diversos fornecedores, e o comportamento dos produtos pode mudar rapidamente. A questão duradoura é o modelo de confiança exposto pela pesquisa.

A aprovação humana funciona apenas quando o sistema apresenta detalhes canônicos e verificados de forma independente. Para uma operação de arquivo, esses detalhes incluem o caminho resolvido, o tipo de operação, a diferença de conteúdo, a identidade do processo e se o alvo está fora do espaço de trabalho autorizado.

Para uma mensagem, os usuários precisam ver o destinatário real, os dados anexados e a identidade de envio. Para um pagamento, precisam ver o destino, o valor, a fonte da autorização e o resultado da política. Para uma alteração na nuvem, precisam ver a conta, o recurso, a região e o efeito esperado.

O aplicativo deve gerar esses fatos a partir de um estado confiável do sistema. Ele não deve depender do resumo em linguagem natural do agente. O mesmo modelo que solicita permissão tem um incentivo, intencional ou não, para apresentar a ação como útil.

O momento importa tanto quanto. A aprovação deve ocorrer antes de o sistema alterar o estado externo. Um botão que aparece depois de uma gravação de arquivo, chamada de API ou transmissão de mensagem não pode impedir o evento.

As empresas também precisam evitar a fadiga de aprovação. Se os usuários recebem solicitações frequentes para operações inofensivas, aprendem a aceitá-las sem inspecionar os detalhes. Atacantes podem então ocultar uma solicitação perigosa entre avisos familiares.

A aprovação baseada em risco oferece um padrão melhor. Ações de baixo impacto podem prosseguir dentro de limites rígidos. Operações sensíveis recebem divulgação mais detalhada, autenticação mais forte e verificações independentes de política.

Algumas ações nunca deveriam depender de um único clique. Excluir dados de produção, alterar políticas de acesso, exportar grandes conjuntos de dados ou modificar credenciais de implantação pode exigir uma segunda identidade ou uma revisão fora de banda.

Isso não remove as pessoas do processo. Dá a elas uma decisão que podem avaliar de maneira realista. Humanos são mais úteis para exercer julgamento, não para verificar um estado técnico oculto sob pressão de tempo.

As equipes de segurança devem testar telas de aprovação de forma adversarial. Podem perguntar se nomes longos de arquivos ocultam o destino, se a formatação pode obscurecer avisos e se um documento comprometido pode influenciar o texto exibido.

Também devem inspecionar condições de corrida. O estado revisado precisa permanecer inalterado entre a aprovação e a execução. Se um atacante puder substituir um arquivo, destino ou argumento após a aprovação, a decisão visível deixará de cobrir a ação real.

A atenção do Google News à segurança corporativa de IA reflete uma correção mais ampla. “Humano no ciclo” não é uma descrição completa de controle. Revisores precisam saber qual humano, quais informações, qual momento e qual limite aplicado de forma independente.

Por Que as Empresas Continuam Repetindo Esses Três Erros

Os incentivos de implantação recompensam capacidades visíveis de IA, enquanto limites confiáveis continuam mais lentos e menos visíveis para os compradores.

Os três erros persistem porque cada um oferece um atalho conveniente. Instruções em prompts são mais fáceis do que redesenhar controles de acesso. Credenciais compartilhadas são mais fáceis do que criar identidades específicas para cada tarefa. Botões de confirmação são mais fáceis do que criar fluxos de autorização verificáveis.

As demonstrações reforçam esses atalhos. Uma demonstração bem-sucedida recompensa o acesso amplo porque o agente consegue encontrar mais informações e concluir mais etapas. O acesso restrito produz mais recusas, trabalho de configuração e atrito aparente.

A produção inverte esse cálculo. Cada sistema conectado introduz outra relação de confiança. Cada permissão adicionada aumenta o impacto potencial. Cada etapa automatizada reduz o tempo disponível para que um defensor perceba um comportamento anormal.

A propriedade organizacional acrescenta outro problema. Equipes de produto escolhem modelos e conectores. Equipes de identidade gerenciam credenciais. Equipes de segurança monitoram eventos. Equipes jurídicas definem restrições de dados. Unidades de negócio decidem quais fluxos de trabalho importam.

Um agente pode atravessar todos esses domínios durante uma única tarefa. Se nenhuma equipe for responsável por toda a cadeia de execução, cada grupo pode presumir que outro controle impedirá a falha.

As garantias dos fornecedores podem aprofundar essa lacuna. Contratos corporativos podem abordar retenção de dados, treinamento de modelos e criptografia. Essas proteções são importantes, mas não corrigem permissões excessivamente amplas concedidas pelos clientes nem fluxos de trabalho inseguros.

Um provedor pode proteger prompts armazenados enquanto o cliente expõe registros internos por meio de recuperação. Pode isolar a infraestrutura do modelo enquanto uma empresa concede a um agente acesso excessivo à nuvem. A responsabilidade permanece compartilhada por toda a pilha.

Produtos de segurança também têm dificuldades quando a atividade de IA se parece com trabalho legítimo. Um funcionário autorizado pode pedir a um assistente aprovado que resuma um contrato. O mesmo fluxo de trabalho se torna perigoso quando o contrato contém uma instrução oculta que redireciona o agente.

O monitoramento tradicional vê um usuário autenticado, um aplicativo aprovado e uma solicitação de dados permitida. O sinal ausente é a relação entre o contexto não confiável e a ação que se seguiu.

As empresas precisam de rastros mais ricos dessa relação. Logs úteis registram fontes recuperadas, decisões do modelo, chamadas de ferramentas, resultados de políticas, aprovações e alterações de estado resultantes. Conteúdo sensível pode ser protegido, preservando evidências suficientes para investigação.

O objetivo não é a vigilância ilimitada dos funcionários. É automação responsável. As pessoas devem entender quando um sistema de IA acessa dados da empresa e quais ações ele realiza em seu nome.

A IA paralela complica esse trabalho. IA paralela significa o uso, por funcionários, de modelos, agentes ou conectores não aprovados fora da governança normal. Bloquear todas as ferramentas públicas pode levar a atividade para contas pessoais e dispositivos não gerenciados.

Uma resposta melhor combina alternativas aprovadas com controles aplicáveis nas camadas de identidade, navegador, endpoint e dados. Funcionários precisam de um caminho prático para trabalho legítimo. Equipes de segurança precisam de visibilidade sobre para onde informações protegidas se movem.

As empresas também devem separar a experimentação da produção. Um sandbox pode fornecer dados sintéticos, credenciais descartáveis, redes isoladas e ferramentas limitadas. Experimentos bem-sucedidos podem então passar por modelagem explícita de ameaças antes de receberem acesso real.

Esse processo exige mais do que uma lista de verificação de conformidade. Cada fluxo de trabalho precisa de um caso de abuso. Revisores devem perguntar o que acontece quando o conteúdo recuperado mente, um modelo seleciona a ferramenta errada ou um usuário aprova uma solicitação enganosa.

Em seguida, devem testar a recuperação. A empresa consegue revogar imediatamente a identidade do agente? Consegue identificar registros alterados? Consegue reverter ações sem confiar no mesmo modelo que as causou?

O contra-argumento mais forte é que esses controles desacelerarão a adoção. Isso é verdade para algumas implantações. No entanto, falhas não resolvidas de permissão e aprovação geram atrasos posteriormente por meio de resposta a incidentes, restrições emergenciais e perda de confiança.

Outra incerteza diz respeito aos próprios modelos. Os fornecedores continuam aprimorando o tratamento de instruções e a detecção de ataques. Essas melhorias podem reduzir a manipulação bem-sucedida, mas não justificam a remoção de limites determinísticos.

A segurança corporativa deve melhorar à medida que os modelos mudam, e não depender dessas mudanças. Um aplicativo bem projetado se torna mais seguro com um modelo melhor, permanecendo limitado quando esse modelo falha.

O Que os Líderes de Segurança Devem Observar em Seguida

A próxima fase será medida pelo desenho de permissões, testes independentes e transparência sobre incidentes, e não por pontuações de recusa do modelo.

O primeiro sinal é se os fornecedores publicam postmortems relevantes sobre incidentes de segurança de agentes. Divulgações úteis descrevem a entrada inicial, as ferramentas disponíveis, as credenciais, a falha de contenção e o impacto final. Referências vagas a “comportamento inesperado” oferecem pouca orientação.

Os relatórios pós-incidente também devem esclarecer o que mudou após o incidente. Um novo prompt é uma evidência mais fraca do que uma permissão revogada ou uma barreira de autorização redesenhada. Líderes de segurança devem distinguir o ajuste comportamental da correção arquitetural.

O segundo sinal é a adoção de controles de identidade específicos para agentes. As empresas precisam de identidades de máquina separadas, credenciais de curta duração, escopos por recurso e revogação de emergência. Produtos que apenas se passam pelo usuário deixam questões importantes sem resposta.

Os compradores devem perguntar se um agente pode acessar aplicações não relacionadas durante uma tarefa. Devem solicitar evidências de que a política acompanha cada chamada de ferramenta. Também devem verificar se os logs vinculam as ações ao usuário e à sessão de origem.

O terceiro sinal é a realização repetível de testes de regressão de segurança. Os testes de regressão de IA verificam se ataques conhecidos reaparecem após mudanças em modelos, prompts, ferramentas, recuperação de dados ou permissões. Eles devem ser executados antes da implantação e após cada atualização relevante.

Esses testes precisam incluir conteúdo hostil realista. As equipes devem inserir ataques em e-mails, páginas da web, documentos, repositórios e respostas de ferramentas. Prompts diretos dos usuários cobrem apenas uma parte da superfície de entrada da aplicação.

A pesquisa independente continuará essencial. As avaliações de fornecedores frequentemente enfatizam o uso normal e ataques conhecidos. Pesquisadores externos abordam os limites de confiança de forma diferente, como ilustram EchoLeak e GhostApproval.

As equipes de compras podem apoiar esse trabalho perguntando sobre programas de divulgação, prazos de resposta e correções publicadas. A reação de um produto à pesquisa revela tanto quanto seu marketing de segurança.

O Google News continuará exibindo incidentes alarmantes de IA porque os agentes estão alcançando sistemas mais sensíveis. A resposta útil não é o pânico nem uma proibição generalizada. É uma mudança na forma como as empresas definem uma implantação segura.

Trate o modelo como não confiável. Dê ao agente menos acesso do que à pessoa que o orienta. Faça com que as telas de aprovação revelem fatos verificados de forma independente antes que qualquer coisa seja alterada.

Os líderes de segurança devem agora escolher um fluxo de trabalho de IA conectado e rastreá-lo desde a entrada até a ação final. Qual controle ainda funciona se o modelo seguir uma instrução hostil? A resposta mostrará se a empresa tem uma arquitetura de segurança de IA ou apenas uma promessa de segurança de IA.