Agentes de Navegador da Amazon e do Google Enfrentam um Problema de Prompt Injection Sem Solução Perfeita

Os agentes de navegador da Amazon e do Google agora enfrentam o mesmo conflito: mais autonomia dá aos ataques de prompt injection mais espaço para causar danos. Apesar das novas salvaguardas, pesquisadores continuam encontrando maneiras de direcionar agentes por meio de páginas da web comuns, e-mails, formulários e publicações em redes sociais. A fraqueza está se tornando uma limitação duradoura do design de navegadores com IA, e não mais um bug de navegador à espera de uma correção simples.

A preocupação imediata é o prompt injection indireto, em que instruções hostis ficam ocultas em conteúdos lidos por um agente de IA. Essas instruções podem competir com o pedido do usuário e influenciar a próxima ação do agente. Um navegador convencional exibe o conteúdo hostil. Um navegador agêntico pode interpretá-lo, atravessar para outro serviço e agir com a autoridade do usuário.

Essa distinção coloca Amazon e Google em uma disputa de segurança mais ampla que envolve Microsoft, OpenAI, Anthropic, Perplexity e fornecedores especializados de navegadores. Cada empresa quer agentes capazes de concluir tarefas úteis em toda a web. Porém, cada permissão adicional amplia as consequências quando um agente interpreta mal a quem deve obedecer.

A conclusão inquietante não é que os agentes de navegador sejam inutilizáveis. É que os fornecedores não podem tratar a detecção de prompt injection como uma fronteira de segurança completa. As empresas precisam presumir que algumas instruções maliciosas passarão e limitar o que um agente comprometido pode acessar, alterar ou divulgar.

O Que Mudou na Corrida de Segurança dos Navegadores da Amazon e do Google

O prompt injection passou de uma fraqueza teórica dos modelos a um problema operacional de segurança em navegadores.

Pesquisadores de segurança demonstraram repetidamente que conteúdo malicioso pode redirecionar um agente sem explorar a rota tradicional de execução de código do navegador. Em vez disso, o invasor ataca a interpretação do conteúdo pelo modelo. Uma instrução oculta pode aparecer em uma página da web, e-mail, documento ou até mesmo em um elemento de interface.

O ataque se torna grave quando o agente pode usar sessões autenticadas do navegador. Ele pode ler uma caixa de entrada, abrir outra aba, enviar um formulário ou recuperar informações de um serviço conectado. Ações que parecem convenientes durante uma tarefa normal tornam-se componentes úteis em uma cadeia de ataque.

Pesquisadores da Zenity descreveram essa classe mais ampla de fraquezas em navegadores agênticos como PleaseFix. Seus testes tiveram como alvo a forma como os agentes seguem objetivos em linguagem natural ao se moverem entre sites e recursos locais. De acordo com as descobertas sobre segurança de navegadores, os pesquisadores encontraram diferentes designs e salvaguardas, mas ainda identificaram caminhos de ataque em navegadores agênticos comerciais.

A mudança importante está na rota do invasor. Ataques tradicionais a navegadores geralmente dependem de uma vulnerabilidade de software, extensão maliciosa, credencial roubada ou clique enganoso. O prompt injection pode começar com conteúdo que o agente deveria processar durante uma solicitação comum.

Um usuário pode pedir a um assistente que resuma uma página de produto. A página pode conter instruções ocultas visualmente, mas ainda disponíveis para o modelo. Um invasor também pode inserir instruções em uma publicação pública, formulário de newsletter ou conteúdo recuperado por uma ferramenta de navegador.

Isso não garante que toda instrução injetada terá sucesso. Modelos, classificadores, sistemas de permissão e verificações de ação podem interromper muitas tentativas. O problema é que esses controles operam contra um adversário adaptativo, capaz de revisar texto, apresentação, momento e contexto.

As próprias medições do Google reforçam essa mudança. Suas equipes de segurança analisaram conteúdo público da web em busca de padrões conhecidos de prompt injection indireto e relataram um aumento relativo de 32% nas detecções maliciosas entre novembro de 2025 e fevereiro de 2026. A empresa também encontrou uma quantidade substancial de texto benigno semelhante a ataques, o que dificulta uma classificação confiável.

Essa pesquisa sobre ameaças na web é relevante porque uma defesa de navegador precisa lidar com dois erros concorrentes. Se não detectar conteúdo hostil, um agente pode ser manipulado. Se bloquear de forma excessiva, páginas rotineiras e instruções legítimas se tornam inutilizáveis.

A Amazon aborda o problema por meio de sua plataforma de agentes em nuvem, e não de um navegador para o mercado de massa. O Bedrock AgentCore Browser oferece aos desenvolvedores um ambiente isolado para agentes que navegam por sites, preenchem formulários e extraem informações. Essas capacidades ainda expõem agentes a conteúdo não confiável, mesmo quando a sessão subjacente do navegador é isolada.

A comparação entre Amazon e Google, portanto, reflete dois modelos de distribuição diferentes. O Google está adicionando recursos agênticos a um navegador usado diretamente por pessoas. A Amazon fornece infraestrutura que empresas usam para criar sua própria automação de navegador. Ambas precisam administrar a mesma colisão entre conteúdo da web aberta e ações privilegiadas de agentes.

Por Que os Agentes de Navegador Enfraquecem uma Antiga Fronteira de Segurança

A fraqueza central surge quando um modelo recebe instruções confiáveis e dados não confiáveis por meio de um processo de raciocínio compartilhado.

Os navegadores da web passaram décadas separando sites uns dos outros. A política de mesma origem geralmente impede que uma origem leia livremente informações sensíveis de outra. Sandboxes, solicitações de permissão, isolamento de processos e políticas de segurança de conteúdo acrescentam outras barreiras.

Um agente de IA pode atravessar essas fronteiras porque o usuário o autoriza a realizar uma tarefa. Ele pode ler uma página, consultar outro serviço e combinar os resultados. Essa capacidade é o principal benefício do produto, mas também cria uma ponte que conteúdo hostil pode tentar controlar.

O modelo não precisa violar diretamente a política de mesma origem. Ele pode usar funções legítimas do navegador disponíveis ao usuário. Se uma página maliciosa convencer o agente a abrir uma caixa de entrada, ler uma mensagem e transmitir informações, cada etapa individual poderá parecer autorizada.

Isso às vezes é chamado de problema do deputado confuso. Um componente confiável tem autoridade legítima, mas um invasor o manipula para usar essa autoridade com a finalidade errada. Agentes de navegador tornam o deputado conversacional, probabilístico e capaz de planejar várias etapas.

Pesquisas sobre agentes de navegador de código aberto demonstraram como esse padrão pode levar à exposição de credenciais e a ações não autorizadas. Um estudo acadêmico relatou prompt injection, bypass de validação de domínio e exfiltração de credenciais em uma estrutura de automação de navegador. Sua análise de agente de navegador também incluiu uma vulnerabilidade divulgada e uma prova de conceito funcional.

O problema cresce quando um agente carrega memória entre tarefas. Uma instrução hostil nem sempre precisa causar dano imediato. Ela pode tentar alterar o contexto armazenado, criar uma preferência enganosa ou influenciar uma decisão posterior quando recursos sensíveis se tornarem disponíveis.

A compreensão visual introduz outra rota. Um agente que interpreta capturas de tela pode encontrar instruções incorporadas em imagens ou elementos de interface. Filtrar apenas o texto bruto da página não detectará todas as mensagens que um modelo multimodal pode perceber.

Os invasores também podem evitar frases óbvias como “ignore as instruções anteriores”. Eles podem apresentar etapas maliciosas como partes necessárias do objetivo original do usuário. Um pedido para se inscrever em uma newsletter, por exemplo, pode tornar-se um pretexto para recuperar dados ou abrir outra ferramenta.

Essa técnica importa porque muitas defesas procuram um conflito entre o objetivo do usuário e a instrução hostil. Um invasor pode, em vez disso, fazer a ação maliciosa parecer coerente com esse objetivo. O texto se torna menos suspeito, enquanto a capacidade solicitada continua perigosa.

O prompt injection difere da injeção de SQL em um aspecto crítico. O software pode separar comandos SQL de dados por meio de sintaxe rígida e consultas parametrizadas. Agentes de linguagem natural dependem de interpretação contextual, portanto instruções e informações nem sempre têm uma fronteira técnica clara.

Mensagens estruturadas e rótulos de procedência podem melhorar essa separação. Desenvolvedores podem indicar qual conteúdo veio do usuário, de uma página da web, de uma ferramenta ou do aplicativo. No entanto, o modelo ainda precisa interpretar conteúdo externo quando a tarefa depende de seu significado.

A pesquisa publicada como BrowseSafe avaliou riscos de prompt injection em agentes de navegador e examinou defesas em ambientes realistas. Esse trabalho reflete um consenso emergente: a detecção ajuda, mas a arquitetura do navegador e o design das permissões determinam o impacto final.

É por isso que um classificador perfeito não resolveria toda a questão. Classificadores também processam linguagem ambígua, e invasores podem testar novas variações. Os defensores precisam de vários controles independentes para que um único julgamento equivocado não desbloqueie toda a sessão de navegador do usuário.

Defesas da Amazon e do Google Priorizam Controle em Vez de Detecção Perfeita

Amazon e Google estão construindo defesas em camadas porque nenhuma das empresas pode depender de um único filtro de prompt injection.

O Google descreveu uma arquitetura que verifica as ações do agente antes que elas cheguem ao navegador. Seu User Alignment Critic é um componente separado, projetado para avaliar se uma ação proposta corresponde ao objetivo declarado pelo usuário. A separação ajuda a impedir que o agente principal aprove sua própria interpretação arriscada.

O Google também usa informações de origem, confirmações de ação, treinamento de modelos e sistemas de detecção. Operações sensíveis podem exigir aprovação explícita do usuário. O navegador pode restringir quais informações chegam ao agente e preservar fronteiras de segurança em torno das credenciais.

Em seu design de Chrome agêntico, o Google reconhece que a exposição a conteúdo não confiável da web cria um risco inerente de prompt injection indireto. Essa formulação é significativa. A empresa apresenta o problema como uma ameaça arquitetural que exige mitigação contínua.

A confirmação de ação é útil porque restaura o julgamento humano antes de uma etapa consequente. Um usuário pode rejeitar uma compra, mensagem, login ou transferência de dados inesperados. No entanto, solicitações frequentes também podem se tornar rotineiras, criando a mesma fadiga observada com avisos de cookies e diálogos de permissão.

As confirmações, portanto, precisam se concentrar em transições significativas. Enviar dados para um novo domínio merece mais escrutínio do que rolar uma página. Abrir um gerenciador de senhas implica maior risco do que extrair uma manchete pública. Um modelo de aprovação uniforme trata ações desiguais como se fossem equivalentes.

A Amazon enfatiza a aplicação de políticas em torno de seu ambiente gerenciado de navegador. Desenvolvedores que usam Bedrock AgentCore podem aplicar políticas empresariais do Chrome que restringem por onde um agente navega. Essas regras operam na camada do navegador, independentemente do prompt ou do raciocínio do agente.

A distinção é importante. Um modelo pode ser manipulado, mas uma política determinística de rede ou navegador ainda bloqueia um destino proibido. Os controles de política de navegador da Amazon permitem que criadores definam locais permitidos e bloqueados antes que o agente inicie seu trabalho.

Uma lista de permissões pode reduzir drasticamente a exposição em fluxos de trabalho empresariais restritos. Um agente de compras pode precisar acessar apenas um pequeno conjunto de portais aprovados de fornecedores. Um agente de atendimento ao cliente pode exigir somente a plataforma de suporte e um sistema interno de conhecimento.

Esses limites se tornam mais difíceis de manter em pesquisas gerais. Um agente encarregado de comparar produtos ou acompanhar notícias precisa de amplo acesso à web. Quanto mais aberta a tarefa, menos útil se torna uma lista rígida de destinos permitidos.

O isolamento oferece outra camada. Uma sessão de navegador gerenciada pode separar a atividade do agente do perfil de navegador cotidiano do funcionário. Se o agente for comprometido, ele não deve herdar automaticamente todos os cookies, abas abertas, credenciais salvas e extensões disponíveis para o usuário.

O isolamento não decide se uma instrução é maliciosa. Ele limita os recursos disponíveis após uma decisão equivocada. Essa é a mesma lógica prática por trás de contêineres, máquinas virtuais e contas de serviço restritas.

O princípio do menor privilégio estende essa abordagem a ferramentas e dados. Um agente que só precisa ler páginas públicas não deveria receber permissão para enviar e-mails. Um agente que redige uma transação não deveria poder aprová-la. Um agente que lê documentos não deveria obter automaticamente acesso a todas as pastas conectadas.

Os caminhos de defesa da Amazon e do Google, portanto, convergem para um princípio compartilhado. Os modelos continuarão falíveis, portanto a segurança precisa existir fora do modelo. Políticas de navegador, limites de identidade, barreiras de aprovação, registros e sessões isoladas podem conter um erro que a detecção não conseguiu interromper.

A Verdadeira Troca É Entre Capacidade e Contenção

Toda defesa que reduz de forma confiável o impacto da injeção de prompt também limita alguma parte da autonomia do agente.

Um agente de navegador se torna mais útil quando pode transitar livremente entre serviços, reter contexto e concluir tarefas com várias etapas. Essas mesmas capacidades ampliam o número de decisões que um invasor pode influenciar. A troca de segurança está embutida na proposta de valor do produto.

Considere um agente encarregado de organizar uma viagem. Ele pode pesquisar voos, comparar hotéis, verificar um calendário, recuperar informações de fidelidade e preparar uma reserva. Se conteúdo externo redirecionar o plano, o agente poderá expor dados pessoais ou selecionar um destino controlado por um invasor.

Um sistema rigidamente contido poderia impedir esse resultado ao limitar o agente à pesquisa somente para leitura. No entanto, ele deixaria de concluir a reserva. Acrescentar autoridade de compra restaura a conveniência, ao mesmo tempo que aumenta o impacto de uma ação equivocada.

O mesmo padrão se aplica dentro das empresas. Um agente de vendas poderia pesquisar uma conta e redigir uma abordagem sem grande risco. Dar a ele permissão para enviar mensagens, atualizar registros de clientes e anexar documentos internos cria uma automação mais valiosa e um raio de falha maior.

É por isso que a injeção de prompt deve ser avaliada como um problema de segurança de capacidades. As equipes devem perguntar o que o agente pode fazer depois de aceitar uma instrução maliciosa. A taxa de sucesso de ataque contra um modelo importa, mas a consequência permitida importa mais.

Um resumidor somente para leitura apresenta um risco diferente de um agente conectado a sistemas de pagamento. Ambos podem produzir resultados enganosos. Apenas um pode transformar uma interpretação equivocada em uma transação externa sem outro controle.

Fornecedores às vezes promovem taxas de detecção mais altas como evidência de maior segurança. Esses resultados podem ser valiosos, mas dependem do conjunto de testes, do conhecimento do invasor, da versão do modelo e das ferramentas permitidas. Um ataque adaptativo pode visar casos que um benchmark não incluiu.

Falsos positivos também geram custos operacionais. Um modelo defensivo pode recusar conteúdo legítimo que se pareça com uma tentativa de injeção. As equipes de segurança podem reduzir falhas elevando a sensibilidade, mas os usuários então enfrentam mais tarefas bloqueadas e confirmações desnecessárias.

O problema de design não tem um ponto final fixo porque as capacidades dos agentes continuam mudando. Uma salvaguarda testada contra a sumarização de páginas não cobre automaticamente navegação visual, downloads de arquivos, diálogos do sistema operacional ou interações com um novo protocolo de ferramentas.

Atualizações de navegador podem introduzir comportamentos adicionais. Atualizações de modelo podem alterar a forma como o agente interpreta instruções ambíguas. Um serviço conectado pode expor novas ações sem que o fornecedor do navegador controle sua interface. Os testes de segurança devem acompanhar o sistema completo, e não apenas um retrato de um modelo.

Extensões e integrações de terceiros complicam ainda mais o cenário. Elas podem ampliar o conteúdo visível ao agente ou oferecer novos caminhos de execução. Uma empresa pode configurar cuidadosamente o navegador principal e, ainda assim, ignorar uma extensão com amplo acesso a páginas.

Por isso, uma visão cética é necessária. Defesas em camadas reduzem o risco, mas alegações públicas sobre “agentes seguros” não devem ser interpretadas como imunidade. As empresas devem divulgar o ambiente testado, as ações bloqueadas, as regras de confirmação do usuário e a superfície de ataque residual.

Ao mesmo tempo, declarar que todo navegador com IA é categoricamente inseguro simplifica demais a decisão. O risco depende das permissões do agente, dos dados acessíveis, do isolamento e da tarefa. Um assistente de pesquisa restrito pode se adequar a um ambiente de menor risco mesmo quando um agente de compras não pode.

As equipes de segurança precisam de classes de implantação, e não de uma aprovação ampla única. Agentes de baixo risco podem operar em sessões isoladas e somente para leitura. Sistemas de risco médio podem redigir ações para revisão humana. Fluxos de trabalho de alto risco devem exigir autorização determinística fora do modelo.

Essa estrutura aceita a troca central em vez de fingir que ela desapareceu. Os usuários ainda obtêm automação, mas a autonomia só aumenta quando os controles ao redor podem absorver uma falha do modelo.

Quem Sofre Pressão com o Problema da Injeção de Prompt

Os fornecedores de navegadores enfrentam as manchetes, mas as equipes corporativas de identidade e aplicações carregam grande parte do ônus prático.

O Google precisa proteger usuários cujos perfis de navegador já contêm sessões valiosas. O Chrome pode conectar um agente a e-mail, calendários, documentos, contas de compras e ferramentas de trabalho. Uma única interface pode, portanto, expor muitos domínios de confiança diferentes.

Os clientes da Amazon enfrentam uma responsabilidade diferente. O Bedrock AgentCore fornece componentes e controles gerenciados, mas os desenvolvedores ainda decidem quais destinos, identidades, ferramentas e dados um agente pode acessar. Um serviço seguro pode sustentar uma configuração de aplicação insegura.

Microsoft, OpenAI, Anthropic e Perplexity enfrentam a mesma pressão competitiva. Os usuários esperam que agentes de navegador realizem mais trabalho, enquanto pesquisadores de segurança testam cada nova capacidade. Um design restritivo pode parecer menos útil ao lado de um rival que permite automação mais ampla.

Esse ciclo competitivo pode incentivar fornecedores a expandir permissões mais rapidamente do que as empresas atualizam sua governança. Novos recursos de agentes podem chegar por navegadores e ferramentas de produtividade conhecidos, evitando a análise de aquisição exigida para uma aplicação separada.

As equipes de segurança devem inventariar recursos agênticos como capacidades, e não como nomes de produtos. As perguntas relevantes dizem respeito ao acesso a sessões autenticadas, arquivos locais, aplicações conectadas, memória, mensagens, downloads e execução de código.

Os responsáveis por aplicações também precisam reconsiderar o conteúdo das páginas web. Um painel interno antes era projetado principalmente para leitores humanos. Se os agentes consomem seu texto tanto como informação quanto como instrução potencial, a procedência do conteúdo passa a fazer parte da segurança da aplicação.

As equipes de identidade precisam decidir se os agentes compartilham credenciais humanas ou recebem identidades de serviço distintas. Sessões compartilhadas são convenientes, mas enfraquecem a responsabilização. Identidades separadas favorecem permissões mais restritas, registros mais claros e revogação mais rápida.

Os desenvolvedores precisam de registros de eventos que expliquem o que o agente viu e por que agiu. O histórico convencional do navegador mostra páginas visitadas, mas pode não capturar o conteúdo exato, a decisão do modelo, a chamada de ferramenta e a autorização por trás da ação de um agente.

As equipes de resposta a incidentes enfrentam outra dificuldade. Uma injeção de prompt bem-sucedida pode se parecer com atividade normal do usuário porque o agente usa credenciais válidas e funções legítimas do navegador. A detecção deve examinar intenção, sequência, destino e movimentação de dados.

Os funcionários também precisam de sinais mais claros. Eles devem saber quando um agente lê uma página, passa para outro serviço, acessa informações privadas ou prepara uma ação irreversível. Um pequeno ícone animado não comunica toda a transição de confiança.

Compradores corporativos devem perguntar aos fornecedores como as defesas funcionam quando o conteúdo é visual, ofuscado, multilíngue ou distribuído por várias etapas. Também devem perguntar se as verificações de segurança são executadas de forma independente do agente principal e se as políticas continuam aplicáveis após mudanças no modelo.

A avaliação mais robusta inclui testes adversariais contra os fluxos de trabalho reais da organização. Um benchmark genérico não consegue reproduzir todas as aplicações internas, fontes de dados e combinações de permissões. Equipes de red team devem testar objetivos realistas enquanto variam o conteúdo malicioso.

Contratos de aquisição também precisam de termos claros sobre incidentes. Os compradores devem entender a retenção de registros, a divulgação de vulnerabilidades, as práticas de atualização de modelos e a responsabilidade por configurações inseguras. A injeção de prompt atravessa os limites entre o comportamento do fornecedor e o design do cliente.

Nenhuma empresa pode resolver esse problema de responsabilidade compartilhada apenas com uma atualização de modelo. Os fornecedores precisam oferecer controles aplicáveis, enquanto os clientes precisam configurá-los em torno de tarefas específicas. Ambos os lados precisam de evidências de que os controles funcionam em conjunto.

O Que Observar a Seguir da Amazon, do Google e dos Fornecedores de Navegadores com IA

A próxima fase será julgada por evidências de contenção, e não por promessas de que a injeção de prompt foi eliminada.

O primeiro sinal é se os fornecedores publicam avaliações reproduzíveis que cubram fluxos completos de navegador. Os testes devem incluir texto oculto em páginas, imagens, ações entre abas, memória armazenada, contas conectadas e manipulação de intenção em várias etapas. Um único benchmark de recusa oferece uma visão estreita demais.

Os resultados devem separar detecção de impacto. Um ataque que influencia um resumo difere de outro que envia dados ou conclui uma compra. Os compradores precisam saber tanto com que frequência um agente segue conteúdo hostil quanto quais controles interrompem a ação resultante.

O segundo sinal é um uso mais amplo de restrições determinísticas. As políticas de navegador da Amazon oferecem um exemplo porque podem bloquear destinos independentemente do raciocínio do modelo. As verificações de ação e barreiras de permissão do Google cumprem um papel relacionado em torno do alinhamento com o usuário.

Observe se esses controles se tornam mais fáceis de configurar em nível granular. As empresas precisam de políticas baseadas em destino, sensibilidade dos dados, tipo de ação, identidade e tarefa. Um único interruptor de liga-desliga para todo o navegador não pode representar essas diferenças.

O terceiro sinal é como os fornecedores lidam com cadeias de ataque recém-divulgadas. Correções rápidas continuam importantes, mesmo quando a classe de vulnerabilidade persiste. As notas de versão devem explicar se uma correção altera a detecção, o escopo de permissões, o isolamento ou a arquitetura subjacente do agente.

Pesquisadores continuarão encontrando variações porque o comportamento dos agentes é não determinístico. Uma correção que bloqueia uma frase ou padrão de página web não resolve a colisão de intenções em contextos diferentes. Melhorias duradouras devem remover capacidades de caminhos não confiáveis ou adicionar autorização independente.

O aumento relatado pelo Google em padrões maliciosos na web dá urgência a esse trabalho. A sofisticação dos ataques ainda era limitada na varredura da empresa, mas o aumento da atividade oferece aos invasores mais oportunidades de testar produtos implantados. A adoção mais ampla de agentes de navegador torna técnicas bem-sucedidas mais valiosas.

A concorrência entre Amazon e Google também revelará quais compromissos de segurança os usuários aceitam. O Google pode inserir confirmações diretamente no Chrome, onde os indivíduos as veem. A Amazon pode fornecer políticas de infraestrutura aos desenvolvedores, mas cada cliente precisa decidir quão restritivas essas políticas devem ser.

Para implantações corporativas, o padrão de curto prazo deve ser simples. Isole o agente, dê a ele uma identidade distinta, restrinja destinos, minimize ferramentas e exija aprovação antes de ações consequentes. Registre toda transição entre conteúdo não confiável e comportamento privilegiado.

Os trabalhadores do conhecimento devem manter contas sensíveis fora de sessões experimentais de agentes sempre que possível. Também devem inspecionar mensagens, transações, downloads e transferências de dados propostos. Atualizar o navegador é importante, mas isso não elimina o problema subjacente de interpretação.

Os desenvolvedores devem tratar toda página da web, e-mail, documento enviado e nota recuperada como entrada não confiável. Devem pressupor que o modelo principal acabará classificando incorretamente parte desse conteúdo. Os controles externos a esse modelo devem determinar o que acontece em seguida.

A conclusão de que não existe uma solução perfeita é desconfortável porque muda a questão da implantação. As equipes devem deixar de perguntar se um agente de navegador é imune à injeção de prompt. Devem perguntar se uma única injeção bem-sucedida pode alcançar algo que realmente importa.

Antes de habilitar o próximo recurso autônomo, mapeie sua pior ação permitida e decida se o benefício justifica essa exposição. Se a resposta não estiver clara, mantenha o agente somente para leitura ou exija aprovação humana. A corrida entre Amazon e Google produzirá defesas melhores, mas a adoção responsável ainda depende de contenção.