Alerta de Confiança Zero de Vishal Sharma: Agentes de IA Precisam de Prova de Controle

Vishal Sharma questiona uma promessa de segurança conhecida: dizer aos agentes de IA que sigam regras não estabelece que essas regras tenham realmente sido cumpridas. O alerta de confiança zero de Vishal Sharma diz respeito a agentes de IA, sistemas que usam modelos e ferramentas de software para agir em direção a um objetivo. O pesquisador da Queen’s University Belfast pergunta quais evidências permanecem quando um agente afirma ter excluído informações, respeitado uma restrição ou concluído uma tarefa autorizada.

O argumento pressiona compradores corporativos e desenvolvedores a distinguir cooperação de controle executável. Um agente que relata sucesso forneceu uma resposta. Um sistema que registra de forma independente a operação relevante forneceu algo que os compradores podem investigar. Esses resultados merecem níveis distintos de confiança.

A referência histórica é a arquitetura de confiança zero do NIST, uma abordagem de segurança que rejeita a confiança automática baseada na localização ou propriedade da rede. O desafio de Sharma diz respeito a como esse princípio se mantém quando agentes interpretam informações, delegam trabalho e carregam contexto entre tarefas. A troca central é concreta: autonomia útil exige acesso, enquanto autonomia responsável exige limites que permaneçam eficazes quando o modelo comete um erro.

O Alerta de Confiança Zero de Vishal Sharma Começa com a Falta de Evidências

A análise de segurança de agentes de Sharma, patrocinada pela universidade e publicada pela IEEE Spectrum, questiona como as organizações verificam o comportamento de agentes. Seu patrocínio importa: leitores devem tratá-la como uma contribuição institucional para o debate, e não como validação independente de um sistema comercial de segurança.

O artigo descreve agentes que operam sob um orquestrador, software que coordena suas tarefas. Ele levanta a possibilidade de prompts posteriores recuperarem informações que um agente havia sido instruído a esquecer. Também relata um experimento interno da Queen’s University Belfast no qual ataques de desautenticação orquestrados por agentes levaram de dois a três segundos. Ataques de desautenticação interrompem a conexão sem fio autenticada de um dispositivo.

A contribuição mais forte do artigo é sua exigência por evidências, enquanto suas alegações experimentais precisam de mais detalhes antes de sustentarem conclusões amplas.

O relato publicado não fornece metodologia suficiente para estabelecer um parâmetro geral de velocidade de ataque. Sua discussão sobre recuperação de contexto também não estabelece que informações apagadas fisicamente tenham sido reconstruídas. Informações que permanecem acessíveis em algum ponto de um fluxo de trabalho apresentam um problema diferente da recuperação de dados que já não existem.

Essa distinção deve orientar a resposta. Uma declaração sobre esquecimento precisa de um objeto definido: uma mensagem, um registro armazenado, um documento acessível ou o comportamento aprendido de um modelo. Sem essa definição, as organizações não conseguem concordar sobre como seria uma exclusão bem-sucedida.

Considere um assistente hipotético de criação de perfis de clientes. Um usuário retira a permissão para usar uma entrevista anterior. O assistente confirma que desconsiderará a entrevista e, depois, produz uma recomendação semelhante à sua avaliação anterior. Essa semelhança, por si só, não pode estabelecer se o assistente recuperou a entrevista, reteve um resumo ou chegou independentemente à mesma conclusão.

Uma investigação precisaria examinar o que o sistema de fato reteve e acessou. A explicação gerada poderia oferecer uma pista, mas a própria explicação não resolveria a questão. O comportamento em disputa diz respeito ao mecanismo em torno da resposta, incluindo quais registros permaneceram disponíveis.

Para compradores, isso muda quais evidências vale a pena solicitar. Uma demonstração bem produzida pode mostrar que um assistente responde corretamente durante uma sessão preparada. Um teste controlado de falha pode revelar se uma restrição sobrevive a uma solicitação inesperada. Essas demonstrações respondem a perguntas diferentes de aquisição.

O valor jornalístico está nessa mudança de ênfase. Sharma direciona a atenção para o ponto em que uma promessa verbal se torna uma alegação operacional. Quando um agente lida com informações sensíveis ou ações consequentes, esse ponto merece exame explícito.

Isso também cria um padrão mais justo para fornecedores. Um fornecedor não deveria precisar prometer que seu modelo nunca produz uma resposta indesejável. Deveria conseguir explicar os limites de sua implantação e fornecer evidências adequadas a esses limites.

A Confiança Zero Ainda se Aplica, mas a Identidade Não Pode Determinar a Intenção

A arquitetura de confiança zero do NIST, publicada em agosto de 2020, concentra a proteção nos recursos em vez de presumir uma rede interna confiável. Sua abordagem separa autenticação, o estabelecimento de identidade, de autorização, a determinação do acesso permitido.

Essa estrutura não se torna obsoleta porque o software consegue interpretar linguagem natural. Ela fornece um ponto de partida útil: a localização de um agente dentro de uma organização não justifica automaticamente o acesso aos seus recursos.

O problema analítico é quanta autoridade um agente autenticado deve receber para a tarefa em andamento.

Imagine um assistente autorizado a preparar uma comparação de fornecedores. Ler propostas aprovadas se encaixa nessa atribuição. Enviar um resumo confidencial de negociação a um fornecedor levanta uma questão separada, mesmo que o mesmo assistente possua a capacidade técnica de enviar e-mails.

Uma autenticação bem-sucedida estabeleceria qual conta tentou realizar o envio. Não estabeleceria, por si só, que o usuário pretendia aquela divulgação específica. Portanto, a discussão sobre segurança precisa examinar a ação solicitada e a autoridade que a sustenta.

É aqui que implantações de agentes complicam decisões corporativas conhecidas. Uma instrução humana pode descrever um resultado sem enumerar todas as operações intermediárias. “Prepare a comparação” deixa espaço para interpretação. A organização ainda precisa decidir quais operações essa interpretação pode autorizar.

Surge uma pergunta razoável de aquisição: o que acontece quando o assistente escolhe uma etapa desnecessária? A resposta deve identificar o componente responsável por permitir ou rejeitar a operação. Uma promessa de que o assistente normalmente escolhe etapas sensatas aborda o comportamento, enquanto o comprador pergunta sobre autoridade.

O mesmo raciocínio se aplica à delegação. Suponha que um assistente coordenador peça a outro agente que pesquise o histórico de um fornecedor. Essa solicitação concede permissão para inspecionar contratos confidenciais? Permite delegação posterior? Qual restrição original permanece visível para o serviço receptor?

Estas são questões hipotéticas de design, não conclusões de que todas as plataformas de agentes lidam incorretamente com a delegação. Seu propósito é expor pressupostos antes que compradores concedam acesso amplo. Uma implantação pode parecer organizada enquanto deixa seu modelo de autoridade mal especificado.

Como consequência, as equipes de segurança enfrentam um problema de escopo. Avaliar um agente como uma única aplicação pode deixar passar diferenças relevantes entre ler, editar, enviar e excluir. Avaliar manualmente cada operação inofensiva criaria outra carga. A avaliação útil fica entre esses extremos.

As equipes de produto devem, portanto, esperar perguntas sobre a relação entre a intenção da tarefa e a permissão executável. Um cliente que solicita essa relação está pedindo uma propriedade do sistema, não apenas outra instrução para o modelo.

O alerta de confiança zero de Vishal Sharma é mais útil quando lido por essa lente. Ele desafia as organizações a tornarem seus pressupostos inspecionáveis sem afirmar que todos os princípios existentes de controle de acesso falharam.

A Memória Torna Mais Difícil Ignorar a Troca

A orientação de segurança de agentes de IA da OWASP aborda isolamento de memória, expiração, tratamento de dados sensíveis e autorização fora do contexto de um agente. Contexto significa as informações fornecidas ao modelo enquanto ele gera uma resposta.

A orientação também identifica o envenenamento de memória, a persistência de informações maliciosas que influenciam comportamentos posteriores. Essa preocupação conecta informações retidas a ações futuras, em vez de tratar cada resposta como um evento isolado.

Para compradores corporativos, a troca não resolvida é quanto histórico útil um assistente deve reter e sob qual autoridade contínua.

Considere um fluxo de trabalho hipotético de pesquisa que transforma entrevistas em um resumo de projeto. Notas históricas ajudam o assistente a evitar repetir perguntas e preservar decisões. Esses benefícios criam uma razão legítima para reter informações. Também tornam os pedidos de retirada mais complicados de avaliar.

Suponha que um participante de uma entrevista solicite a remoção de uma declaração sensível. O comprador precisa saber qual promessa o produto oferece. Remover a transcrição original, excluí-la de buscas futuras e revisar um resumo derivado são resultados distintos.

Um contrato significativo especificaria o resultado aplicável. Uma demonstração então testaria esse resultado diretamente. Perguntar ao assistente se ele se lembra da declaração forneceria evidência mais fraca, porque a pergunta depende da mesma interface cujo comportamento está em disputa.

Essa distinção também importa para o trabalho cotidiano com conhecimento. Alguém que escolhe uma base de conhecimento pessoal precisa entender como coleta, recuperação e remoção se relacionam. Conveniência não responde a essas perguntas, e uma categoria de produto não estabelece uma garantia de segurança.

Há também uma tensão entre investigação e minimização. Uma organização pode querer histórico suficiente para explicar uma recomendação consequente. Ao mesmo tempo, pode querer evitar manter informações pessoais desnecessárias. Nenhum desses objetivos desaparece porque um assistente realiza o trabalho.

Uma investigação hipotética ilustra a dificuldade. Um cliente contesta uma recomendação após a entrevista subjacente ter sido removida. Os investigadores precisam de um relato de quais evidências autorizadas embasaram a decisão. Manter todos os registros brutos para sempre enfraqueceria a promessa de remoção; não manter nada frustraria a investigação.

A implicação editorial é que “memória” merece uma linguagem de produto mais precisa. Os compradores devem esperar descrições dos registros envolvidos e das garantias associadas a cada um. Um único botão rotulado “esquecer” deixa espaço demais para expectativas incompatíveis.

A pressão comercial recai sobre fornecedores que vendem continuidade entre projetos. Quanto mais útil essa continuidade se torna, mais importantes seus limites se tornam para um cliente que avalia trabalho sensível. O valor de um recurso de memória e seus requisitos de governança crescem juntos.

A pergunta de Sharma, portanto, vai além de um cenário de ataque incomum. Ela expõe uma questão básica de compra: se uma organização consegue verificar o tratamento das informações depois que a conversa avançou.

A Pesquisa em Navegadores Mostra Por Que a Arquitetura Eleva os Riscos

Os pesquisadores da University of Washington Franziska Roesner e David Kohlbrenner examinaram os limites de origem de navegadores em sete navegadores agênticos. Seu trabalho trata da política de mesma origem, uma regra de navegador que separa sites mutuamente não confiáveis.

O relato de abril de 2026 descreve experimentos realizados no fim de janeiro e início de fevereiro. Ele relata uma demonstração de ataque de origem cruzada envolvendo o ChatGPT Atlas no Modo Agente. Para vários outros produtos, identifica pré-condições de ataque, e não ataques equivalentes já concluídos.

O cenário depende de condições específicas, incluindo uma injeção de prompt bem-sucedida — uma tentativa de fazer um agente tratar conteúdo não confiável como instruções. As versões e configurações testadas importam. Essas conclusões não devem se transformar em uma afirmação sem respaldo sobre todas as versões atuais de navegadores.

A questão arquitetural mais ampla é se o acesso de um assistente cria um caminho que o código comum de um site não teria.

Para compradores, essa pergunta oferece uma comparação mais útil do que um ranking genérico de inteligência de modelos. Um assistente capaz pode operar dentro de limites estreitos de acesso. Outra implantação pode expor informações mais amplas, ao mesmo tempo que depende mais do julgamento do assistente.

Essas configurações representam decisões de compra diferentes, mesmo quando suas demonstrações parecem semelhantes. Ambas podem resumir uma página com sucesso. Apenas uma análise mais detalhada revelaria quais informações adicionais cada assistente consegue acessar durante essa tarefa.

Considere um funcionário hipotético que solicita um resumo de uma página pública de fornecedor. O resultado pretendido diz respeito a essa página. Se o fluxo de trabalho também permitir acesso a material empresarial privado, os avaliadores precisam entender por que esse acesso existe e o que limita seu uso.

A solicitação do funcionário fornece um ponto de referência útil. Ela define a finalidade comercial em relação à qual o acesso adicional pode ser avaliado. Um resumo bem-sucedido não responde se o sistema expôs mais informações do que a tarefa exigia.

Essa também é a razão pela qual as comparações exigem linguagem cuidadosa. Pesquisadores que identificam uma possível via de dano estabeleceram algo que merece investigação. Eles não necessariamente estabeleceram um ataque bem-sucedido contra todos os produtos que compartilham uma característica de design.

Um comprador deve aplicar a mesma disciplina às respostas dos fornecedores. Um exemplo corrigido pode fechar uma via demonstrada sem estabelecer que todas as vias relacionadas desapareceram. Por outro lado, uma descoberta de pesquisa mais antiga não deve ser automaticamente apresentada como uma vulnerabilidade não resolvida hoje.

A lição para o debate atual é metodológica. As alegações de segurança tornam-se mais informativas quando identificam o limite testado, as condições envolvidas e o resultado observado. Apenas os nomes dos produtos não conseguem sustentar essa explicação.

Isso apoia a exigência de Sharma por provas, ao mesmo tempo que acrescenta uma limitação importante. As evidências devem permanecer vinculadas ao sistema e às circunstâncias que as produziram. Estendê-las além disso exige testes adicionais, não uma retórica mais forte.

Um Melhor Comportamento do Modelo Não Resolve a Questão da Contenção

O relato da Anthropic, de novembro de 2025, sobre defesas contra injeção de prompt descreve treinamento, sistemas de detecção e testes adversariais para uso em navegadores. A empresa reconhece explicitamente que agentes de navegador continuam vulneráveis.

A discussão da empresa, de maio de 2026, sobre contenção de agentes distingue as defesas do modelo das restrições sobre o ambiente em que um agente opera. Contenção significa limitar o que um sistema pode acessar ou fazer. A Anthropic descreve o uso de limites ambientais juntamente com medidas destinadas a melhorar o comportamento do modelo.

Esses são relatos do fornecedor sobre sua abordagem. Eles estabelecem a justificativa de segurança declarada pela empresa, e não uma prova independente de que cada implantação alcança a proteção pretendida.

A comparação importante está entre reduzir a chance de um erro e limitar as consequências quando um erro ocorre.

Um assistente hipotético de documentos torna essa distinção concreta. Um julgamento melhor pode ajudá-lo a rejeitar uma instrução enganosa dentro de uma proposta. Uma restrição de acesso pode impedi-lo de obter um documento confidencial não relacionado, independentemente de como interprete essa instrução.

Esses resultados respondem a perguntas distintas. O cliente quer um comportamento sensato durante o trabalho legítimo. O cliente também quer uma resposta defensável sobre o que acontece durante uma falha. Uma avaliação completa deve examinar ambos.

Isso cria um desafio prático para apresentações de compras. Demonstrações de modelos são fáceis de entender porque exibem comportamento visível. Restrições ambientais podem parecer menos impressionantes até que um avaliador peça ao sistema que atravesse um limite proibido.

Uma demonstração convincente tornaria visível a tentativa de transgressão. Os avaliadores poderiam então examinar o que a bloqueou, quais evidências permaneceram e se a tarefa legítima pôde continuar. A rejeição em si seria apenas parte do resultado.

A avaliação também deve considerar o custo das restrições. Um assistente rigidamente limitado pode exigir informações adicionais do usuário ou deixar de concluir uma tarefa que, de outro modo, seria razoável. Isso não torna a restrição errada. Torna seu efeito operacional parte da decisão de compra.

Da mesma forma, interrupções frequentes não são automaticamente evidência de segurança superior. Uma interrupção merece atenção quando ajuda uma pessoa a compreender e autorizar uma consequência significativa. Um pedido de aprovação vago pode deixar a decisão subjacente igualmente pouco clara.

Portanto, a pergunta útil para o comprador é específica: qual ação proposta aguarda a autoridade de quem, e o que exatamente muda após a aprovação? A resposta deve continuar compreensível para alguém responsável pelo resultado comercial.

Esse enquadramento evita uma disputa artificial entre modelos mais inteligentes e limites mais fortes. Os clientes se beneficiam de ambos, mas devem pedir aos fornecedores que expliquem a contribuição de cada um. A melhoria em uma área não estabelece melhoria em todas as demais.

Isso também intensifica a pressão competitiva. Fornecedores que vendem autonomia mais ampla precisam de evidências proporcionais à autoridade que seus produtos solicitam. O ônus cresce com as consequências de uma ação equivocada.

O alerta de confiança zero de Vishal Sharma se encaixa nesse debate sem resolvê-lo. A questão é se a implantação oferece uma explicação confiável de controle quando o comportamento cooperativo deixa de ser suficiente.

As Próximas Evidências Devem Vir de Testes de Falha

Nos próximos três meses, os sinais mais úteis estarão relacionados à reprodutibilidade, à aplicação de controles e ao comportamento em condições realistas de falha. Estes são pontos editoriais de acompanhamento, não compromissos de lançamento anunciados.

As evidências mais fortes explicarão o que falhou, o que permaneceu protegido e se o trabalho legítimo ainda foi concluído.

Primeiro, acompanhe a busca por um relato reproduzível do experimento da Queen’s University Belfast. Uma publicação mais completa idealmente identificaria o equipamento, a configuração, o método de medição de tempo e a linha de base usados para avaliar a velocidade de ataque relatada.

Essa evidência fortaleceria a alegação experimental se equipes independentes obtivessem resultados comparáveis sob condições declaradas. Um resultado mais restrito ainda seria informativo. Ele ajudaria os leitores a separar uma observação específica de laboratório de uma afirmação geral sobre ataques assistidos por agentes.

O mesmo padrão se aplica à recuperação de contexto. Um teste útil definiria quais informações foram removidas, onde elas existiam e quais caminhos de recuperação permaneciam. Sem esses detalhes, uma aparente lembrança deixa explicações demais em aberto.

Segundo, acompanhe lançamentos de produtos que tornem os limites de autoridade mais fáceis de inspecionar. O sinal relevante é uma mudança documentada vinculada a uma restrição testável. Um novo rótulo de segurança, por si só, não fornece essa evidência.

Por exemplo, um lançamento hipotético poderia demonstrar que um assistente consegue preparar uma mensagem externa enquanto um componente separado controla seu envio. Os avaliadores ainda precisariam examinar o destinatário, o conteúdo e as condições de autorização abrangidas por essa restrição.

Essas evidências fortaleceriam o argumento de que os fornecedores estão traduzindo princípios gerais de segurança em controles que podem ser implantados. Um lançamento que apenas acrescentasse outra instrução ofereceria menos respaldo a alegações sobre limites aplicados de forma independente.

Terceiro, acompanhe avaliações independentes que testem a recuperação juntamente com a resistência a ataques. Bloquear uma operação indesejada é valioso. Os compradores também precisam saber se o sistema consegue se recuperar sem repetir a tentativa, perder trabalho autorizado ou exigir intervenção excessiva.

Uma avaliação hipotética poderia comparar a mesma tarefa antes e depois de uma restrição de acesso. O resultado deveria descrever tanto as ações proibidas quanto a conclusão legítima. Caso contrário, um sistema que realiza pouco poderia parecer seguro por um motivo pouco útil.

Resultados que mostrem danos limitados e trabalho autorizado concluído com sucesso fortaleceriam o argumento em favor de uma autonomia prática. Resultados que mostrem que uma conclusão útil exige acesso amplo e mal explicado exporiam uma concessão persistente.

Esses sinais importam porque, caso contrário, o argumento atual pode se tornar circular. Pesquisadores pedem verificação. Fornecedores descrevem salvaguardas. Compradores recebem garantias sem uma explicação comum sobre o que essas garantias abrangem.

Evidências mais precisas permitiriam uma divergência mais restrita e produtiva. Uma implantação pode ser adequada para redação e pesquisa, enquanto outra oferece suporte a operações de maior consequência. A justificativa deve identificar o que cada sistema consegue estabelecer sobre seu comportamento.

Para desenvolvedores, a implicação imediata é tornar as alegações de segurança testáveis antes de expandir as responsabilidades de um agente. Para compradores empresariais, é conectar as evidências solicitadas a uma consequência comercial específica. Para trabalhadores do conhecimento, é entender a autoridade atribuída a um assistente antes de delegar trabalho sensível.

Antes do seu próximo piloto com agentes, escolha uma ação contestada e defina a evidência que a resolveria. Considere um destinatário não autorizado, um documento retirado ou uma solicitação que ultrapasse a tarefa original. Peça ao fornecedor que mostre o que acontece, onde a restrição opera e qual registro permanece depois. Em seguida, avalie se a tarefa autorizada ainda é concluída. Trate a demonstração como evidência sobre essa implantação e configuração, com as limitações claramente declaradas. O alerta de confiança zero de Vishal Sharma fornece uma pergunta inicial útil para essa conversa: quando um assistente diz que seguiu as regras, o que outra pessoa realmente consegue verificar?