AWS Impõe Limites Rígidos aos Agentes de IA à Medida que a Disputa de Segurança entre Amazon e Google se Intensifica

A AWS estabeleceu limites aplicáveis para agentes de IA, apesar do risco de invasores ou dados contaminados manipularem seu raciocínio. A iniciativa acirra a disputa entre Amazon e Google sobre qual nuvem pode conectar agentes com segurança a sistemas empresariais valiosos.

O Amazon Bedrock AgentCore Policy verifica as ações de ferramenta solicitadas por um agente antes que elas cheguem ao serviço subjacente. Um agente manipulado ainda pode produzir uma solicitação perigosa, mas ela deve falhar quando entrar em conflito com uma política externa.

Essa distinção é importante porque filtros de prompt nunca forneceram uma fronteira de segurança completa. Os modelos processam instruções e dados não confiáveis por meio do mesmo mecanismo probabilístico. A AWS agora trata esse modelo como um tomador de decisões não confiável, em vez de autoridade final.

Google Cloud e Microsoft seguem a mesma direção mais ampla por meio de seus próprios controles de identidade, gateways e fluxo de informações. A competição emergente já não se limita à qualidade dos modelos. Os provedores de nuvem precisam demonstrar que agentes podem agir sem herdar acesso irrestrito a todos os sistemas conectados.

AWS Transfere a Autorização para Fora do Agente

A AWS está separando o que um agente quer fazer do que a infraestrutura permite que ele faça.

A política no Amazon Bedrock AgentCore cria uma fronteira de proteção em torno das interações entre agentes e ferramentas. O serviço intercepta solicitações encaminhadas por meio de um AgentCore Gateway e avalia cada uma antes de permitir a invocação da ferramenta.

Um AgentCore Gateway conecta agentes a APIs, funções e outras ferramentas por meio de uma interface gerenciada. O mecanismo de políticas fica ao lado dessa conexão, e não dentro do prompt ou do código de orquestração do agente.

Esse posicionamento muda o modelo de segurança. Um prompt de sistema pode instruir um agente a nunca recuperar registros restritos de clientes. No entanto, a injeção de prompt pode persuadir o modelo a ignorar essa instrução ou interpretá-la de outra forma.

Um mecanismo externo de autorização não precisa que o modelo concorde. Ele avalia a ação proposta usando regras explícitas, identidade autenticada, parâmetros da ferramenta e o contexto disponível da solicitação.

A AWS usa Cedar, sua linguagem de autorização de código aberto, para expressar essas regras. Uma política Cedar identifica o principal que faz uma solicitação, a ação solicitada, o recurso protegido e quaisquer condições exigidas.

O serviço segue uma semântica de negação por padrão. Uma ação não recebe acesso a menos que uma política o permita explicitamente. Uma proibição correspondente também substitui qualquer permissão mais ampla que poderia, de outra forma, permitir a solicitação.

A AWS explica esses mecanismos em seu guia de políticas do AgentCore. O guia afirma que toda solicitação de agente encaminhada é avaliada antes da concessão de acesso à ferramenta.

Os desenvolvedores podem escrever Cedar diretamente ou descrever requisitos em inglês simples. O serviço de criação em linguagem natural traduz esses requisitos em políticas Cedar candidatas.

A AWS afirma que o serviço valida as políticas geradas em relação ao esquema de ferramentas do gateway. Ele também verifica regras que pareçam excessivamente permissivas, excessivamente restritivas ou impossíveis de satisfazer.

Esse processo de geração não torna requisitos vagos seguros. A AWS alerta que políticas em linguagem natural ainda exigem redação precisa e inequívoca. As equipes de segurança devem revisar o Cedar resultante, em vez de tratar a política gerada como código inquestionável.

O modelo que cria uma política também é separado do mecanismo que a aplica. Depois de implantada, a política formal controla a decisão de autorização em vez de pedir a opinião de outro modelo.

Considere um agente interno de suporte com ferramentas para consultar contas e emitir reembolsos. Uma empresa poderia permitir que todos os representantes de suporte consultassem as contas atribuídas, ao mesmo tempo em que permitiria apenas a supervisores aprovar reembolsos maiores.

Se um e-mail contiver instruções maliciosas exigindo um reembolso, o agente poderá tentar a operação. O gateway ainda poderá rejeitá-la quando o funcionário autenticado não tiver a função exigida ou quando o valor exceder a política.

A solicitação negada nunca precisa chegar ao sistema de pagamentos. Esse resultado é mais robusto do que pedir ao agente que reconheça todas as variações de uma instrução maliciosa.

O AgentCore Policy está disponível de forma geral em 13 regiões da AWS, segundo a documentação de lançamento da AWS. Políticas centralizadas podem ser aplicadas de maneira consistente a vários agentes e ferramentas conectados por meio de gateways associados.

A integração com o CloudWatch registra decisões de autorização para monitoramento e auditorias. Esses registros dão às equipes de segurança uma visão mais clara das ações que os agentes solicitaram, tiveram permitidas ou tiveram negadas.

A mudança imediata é, portanto, arquitetural, e não cosmética. A AWS está inserindo um ponto de controle determinístico entre o comportamento incerto do modelo e sistemas empresariais de alto impacto.

Por que a Injeção de Prompt Muda a Disputa entre Amazon e Google

A disputa entre Amazon e Google na nuvem agora depende de conter agentes comprometidos, e não apenas de melhorar suas respostas.

Os agentes de IA se tornam úteis quando podem recuperar informações privadas, chamar APIs, enviar mensagens ou alterar registros. Essas mesmas permissões determinam o dano possível após uma manipulação.

A injeção de prompt insere instruções hostis em conteúdo que um modelo processa. A injeção direta vem de uma solicitação do usuário, enquanto a injeção indireta pode se ocultar em sites, documentos, e-mails ou respostas de ferramentas.

Um agente que pesquisa um fornecedor pode encontrar instruções incorporadas em uma página da web. Essas instruções poderiam orientá-lo a recuperar arquivos confidenciais e enviá-los por outra ferramenta conectada.

Um filtro de conteúdo pode detectar um padrão de ataque conhecido. Ele também pode deixar passar uma formulação incomum, um comando codificado ou uma sequência distribuída por diversas interações.

O problema subjacente vai além de prompts maliciosos. Um modelo pode alucinar uma ação, compreender mal uma regra de negócios ou combinar ferramentas individualmente aceitáveis em um fluxo de trabalho inaceitável.

A OWASP descreve essa condição como agência excessiva. O risco surge quando um LLM recebe funcionalidade ou permissão suficiente para causar efeitos prejudiciais após uma saída inesperada.

A autorização limita o raio de impacto resultante. O sistema pressupõe que um agente eventualmente tomará uma decisão ruim e, então, impede que essa decisão se transforme em uma ação irrestrita.

Essa abordagem se assemelha a práticas consolidadas de segurança na nuvem. As aplicações devem receber apenas as permissões necessárias para uma tarefa, enquanto operações sensíveis devem enfrentar verificações adicionais.

Os agentes complicam esse princípio porque selecionam ferramentas dinamicamente. Eles também podem encadear muitas chamadas, transportar contexto entre etapas e operar por períodos mais longos sem supervisão direta.

Uma conta de serviço estática com permissões amplas pode, portanto, se tornar uma séria vulnerabilidade. O agente efetivamente ganha todas as capacidades associadas a essa credencial, independentemente do usuário ou da tarefa envolvida.

A AWS pode conectar solicitações do AgentCore a usuários OAuth ou entidades do AWS Identity and Access Management. As políticas podem então considerar a identidade por trás de uma solicitação, em vez de depender apenas da função de serviço compartilhada do agente.

O Google enfrenta a mesma questão à medida que expande agentes baseados em Gemini e conexões do Model Context Protocol. MCP é uma interface padrão que permite aos modelos descobrir e invocar ferramentas externas.

A orientação de segurança para MCP do Google recomenda políticas de negação para acesso em produção, permissões estritamente delimitadas, sanitização de entradas e monitoramento. Ela também alerta que, caso contrário, a segurança pode depender inteiramente da programação do agente.

Essa convergência é importante. A competição entre Amazon e Google frequentemente se concentrou na disponibilidade de modelos, infraestrutura, plataformas de dados e ferramentas para desenvolvedores. A autorização de agentes está se tornando mais um critério importante de compra.

Clientes empresariais raramente implantam um agente como um chatbot isolado. Eles querem agentes conectados a bancos de dados, repositórios de código, plataformas de suporte, consoles de nuvem e repositórios internos de conhecimento.

Cada conexão cria tanto utilidade quanto exposição. Um provedor de nuvem que facilita a conexão, mas oferece autorização fraca, transfere o risco operacional de volta ao cliente.

A AWS está posicionando o AgentCore Policy como uma camada de aplicação reutilizável entre frameworks e modelos. Os desenvolvedores podem usar o AgentCore com agentes criados por diversos frameworks populares de orquestração.

Essa abertura permite que a AWS defenda que a política de segurança deve permanecer estável mesmo quando uma empresa muda de modelo. Uma organização pode substituir um modelo fundacional sem reescrever todas as regras de permissão.

O Google pode apresentar argumento semelhante por meio de seus controles de identidade na nuvem, Model Armor e permissões em nível de recurso. Sua vantagem é a proximidade com Google Workspace, Gemini e uma extensa plataforma de dados.

A Microsoft adiciona pressão por meio da identidade Entra, Copilot e sua pilha de desenvolvimento de agentes. O mercado está se tornando uma disputa tripla sobre quem controla a fronteira entre o raciocínio de IA e a execução empresarial.

Para compradores, a questão relevante entre Amazon e Google não é qual modelo sempre recusa um prompt malicioso. Nenhum fornecedor pode prometer de forma crível uma recusa perfeita em todas as combinações de entrada e ferramentas.

A melhor pergunta é o que acontece depois que a recusa falha. Uma plataforma segura deve limitar as ferramentas, os registros, os parâmetros, os destinos e as sequências de ações disponíveis para o agente comprometido.

Estratégias de Segurança de Amazon e Google se Encontram na Fronteira das Ferramentas

AWS, Google e Microsoft estão convergindo para uma aplicação determinística, mas organizam essa aplicação de maneiras diferentes.

A AWS posiciona o AgentCore Policy diretamente no caminho do gateway. Toda solicitação coberta de agente para ferramenta chega ao mecanismo de políticas antes que a invocação solicitada prossiga.

O Cedar fornece à AWS uma linguagem formal que as equipes podem inspecionar, validar e analisar. A AWS utilizou conceitos do Cedar além dos agentes, o que ajuda a conectar a autorização de agentes a práticas consolidadas de segurança de aplicações.

Os pesquisadores de segurança da empresa fazem uma suposição direta sobre o próprio modelo. Sua análise de segurança do Cedar afirma que as organizações devem tratar um LLM como um ator não confiável em um projeto de defesa em profundidade.

Isso não significa que o modelo seja malicioso. Significa que o sistema de autorização não pode depender de comportamento previsível do modelo, porque ele é probabilístico e suscetível a contexto manipulado.

A orientação publicada pelo Google atualmente enfatiza controles em camadas em torno de servidores MCP e recursos do Google Cloud. Esses controles incluem políticas de negação, credenciais restritas, ambientes de teste separados, entradas sanitizadas e acesso limitado à produção.

O Google também recomenda impedir que ferramentas de leitura e escrita alcancem recursos de produção, a menos que o fluxo de trabalho exija isso. Recursos de recuperação continuam importantes porque até mesmo uma ação autorizada pode produzir um resultado indesejado.

A diferença prática pode aparecer na experiência do desenvolvedor. A AWS oferece um mecanismo dedicado de políticas do AgentCore, com avaliação respaldada por Cedar em seu gateway gerenciado.

O Google pode recorrer ao maduro Cloud IAM e a políticas específicas de produtos. No entanto, os desenvolvedores ainda precisam garantir que cada caminho de ferramenta relevante realmente passe pelo controle pretendido.

Essa ressalva também se aplica à AWS. O AgentCore Policy controla o tráfego roteado por um AgentCore Gateway associado. Um agente com outro caminho de execução pode contornar esse ponto de controle específico.

Por exemplo, uma política poderia bloquear uma operação no S3 por meio de uma ferramenta MCP gerenciada. A restrição não cobriria automaticamente uma ferramenta de shell separada capaz de emitir um comando equivalente.

As revisões de arquitetura devem, portanto, enumerar capacidades, e não apenas ferramentas nomeadas. As equipes de segurança precisam perguntar se um agente consegue alcançar o mesmo recurso por meio de um SDK, linha de comando, navegador, função ou agente secundário.

A Microsoft está desenvolvendo outra variação por meio do controle de fluxo de informações. Seu middleware FIDES rotula o conteúdo por integridade e confidencialidade e, em seguida, mantém esses rótulos nas chamadas de ferramentas.

O modelo de segurança FIDES da Microsoft pode impedir que conteúdo não confiável influencie uma operação sensível. Ele também pode restringir o fluxo de dados privados para um destino público.

Essa abordagem trata uma fraqueza da autorização de ação única. Uma consulta a banco de dados pode ser permitida, e o envio de um e-mail também pode ser permitido. O comportamento perigoso surge quando os resultados privados da consulta fluem para um e-mail externo.

A AWS vem ampliando suas políticas em direção à avaliação com reconhecimento de sessão. Controles temporais podem examinar as ações recentes de um agente em vez de julgar cada solicitação como um evento isolado.

Essa direção importa porque invasores podem dividir um objetivo nocivo em várias etapas aparentemente legítimas. Uma sequência pode revelar um risco que nenhuma ação individual expõe.

Um agente pode primeiro ler um portfólio confidencial, depois calcular um resumo e, por fim, tentar uma transmissão externa. Cada chamada de ferramenta pode parecer válida sem que se conecte a trajetória entre elas.

Para clientes que comparam os designs de segurança da Amazon e do Google, a cobertura importa mais do que a terminologia. Uma linguagem formal de políticas oferece pouca proteção quando rotas de execução de alto risco permanecem fora da aplicação das regras.

A propagação de identidade também importa. O mecanismo de políticas precisa ter conhecimento confiável sobre o usuário, a carga de trabalho, o recurso, a ação e o contexto comercial relevante.

Uma identidade genérica de “agente” é insuficiente quando o agente atende muitos funcionários. Ela pode conceder a cada usuário o conjunto máximo de permissões do agente e eliminar a responsabilização que os controles de acesso normais oferecem.

As organizações devem preservar a identidade humana ou de carga de trabalho por trás de cada solicitação delegada. Elas também devem atribuir ao agente sua própria identidade restrita, em vez de ocultá-lo em uma credencial compartilhada.

Essa separação ajuda a responder duas perguntas diferentes. A primeira é se o usuário pode solicitar a ação. A segunda é se esse agente pode executar essa ação por meio dessa ferramenta específica.

Uma política centralizada também reduz a inconsistência entre equipes. Sem ela, cada desenvolvedor pode implementar autorização em prompts, middleware personalizado ou manipuladores de ferramentas individuais.

Essas verificações dispersas se tornam difíceis de auditar. Elas também se desviam à medida que os agentes ganham novas ferramentas, modelos e ramificações de fluxo de trabalho.

Um gateway compartilhado não pode substituir todas as permissões no nível do recurso. Ele pode fornecer um ponto consistente em que as organizações aplicam políticas antes que a intenção do agente alcance os serviços downstream.

A Política Só É Tão Forte Quanto Sua Cobertura

O AgentCore Policy reduz riscos, mas não prova que um agente hospedado na AWS é seguro.

O serviço controla solicitações que passam por seu gateway configurado e mecanismo de políticas. Ele não pode controlar ferramentas, credenciais ou rotas de rede que os desenvolvedores deixam fora desse limite.

Isso cria um problema de cobertura. Uma equipe de segurança pode acreditar que bloqueou uma ação perigosa enquanto uma ferramenta alternativa oferece outra rota para o mesmo recurso.

Permissões amplas de IAM podem agravar essa lacuna. Se a função de runtime de um agente puder chamar serviços diretamente, as restrições do gateway deverão ser combinadas com políticas de recursos que bloqueiem caminhos não autorizados.

O design de políticas também continua difícil. A criação em linguagem natural reduz a barreira de sintaxe, mas não resolve requisitos de negócio vagos nem premissas de segurança ausentes.

“Permitir que analistas visualizem relatórios apropriados” não é uma regra de autorização precisa. A organização deve definir quais analistas, relatórios, classificações, regiões, clientes e condições operacionais são considerados apropriados.

O Cedar gerado exige revisão, testes e controle de mudanças. As equipes devem testar aprovações esperadas, negativas esperadas, solicitações malformadas, contexto ausente e combinações de parâmetros deliberadamente adversariais.

Uma política que nega tudo provoca falhas operacionais. Uma regra que silenciosamente permite tudo cria o problema oposto. Ambos os resultados podem parecer sintaticamente válidos.

Os desenvolvedores também precisam considerar o contexto de autorização fornecido pelo agente. Atributos sensíveis à segurança devem vir de tokens de identidade confiáveis, metadados de recursos ou infraestrutura controlada.

O modelo não deve ter permissão para declarar que uma transação é de baixo risco ou que um documento é público. Essas alegações precisam ser verificadas fora do processo de raciocínio do modelo.

Os logs de auditoria introduzem outra obrigação. Registrar cada decisão ajuda nas investigações, mas as equipes precisam monitorar ativamente os registros e preservar o contexto útil.

Uma ação negada pode indicar um controle de segurança bem-sucedido. Negativas repetidas também podem revelar um fluxo de trabalho comprometido, um erro de política ou um agente tentando continuamente repetir um objetivo proibido.

As ações permitidas também merecem atenção. Um invasor pode abusar de permissões que são individualmente legítimas, especialmente quando as políticas não consideram o histórico da sessão ou a movimentação de dados.

A aprovação humana continua útil para operações irreversíveis ou de alto impacto. No entanto, uma tela de aprovação pode falhar quando o agente fornece uma descrição enganosa da ação solicitada.

A interface deve apresentar detalhes confiáveis da solicitação real da ferramenta. Os revisores precisam ver o destino, o recurso, os parâmetros, a classificação dos dados e o efeito esperado.

As equipes de segurança também devem proteger o plano de administração de políticas. Um agente não deve conseguir editar suas próprias regras, associar um mecanismo de políticas mais fraco ou obter credenciais com acesso mais amplo.

A separação de responsabilidades ajuda nesse caso. Os desenvolvedores podem propor alterações de políticas, enquanto os responsáveis pela segurança revisam e implantam as mudanças por meio de fluxos de trabalho controlados.

A mesma disciplina se aplica a sistemas internos de conhecimento. As equipes que constroem uma base de conhecimento pesquisável devem preservar as permissões dos documentos antes de expor esse conteúdo a um agente.

A recuperação deve filtrar registros de acordo com a autorização do usuário solicitante. O modelo deve receber apenas o subconjunto de informações que o usuário poderia acessar diretamente.

Esse design evita um modo crítico de falha. Mesmo um modelo manipulado com sucesso não pode revelar informações que nunca entraram em seu contexto acessível.

As organizações devem evitar depositar toda a confiança na detecção de injeção de prompt. A detecção acrescenta uma defesa útil, mas ataques desconhecidos e instruções aparentemente inofensivas podem escapar dos classificadores.

A AWS oferece suporte ao Bedrock Guardrails na camada de políticas para avaliar entradas e saídas do gateway. Esse recurso complementa a aplicação do Cedar, em vez de substituí-la.

A diferença é direta. Um guardrail estima se o conteúdo parece perigoso, enquanto a autorização decide se uma operação solicitada é permitida.

A detecção probabilística e a aplicação determinística resolvem problemas diferentes. Combiná-las reduz a superfície de ataque sem fingir que qualquer uma das camadas captura todas as falhas.

A corrida de segurança entre Amazon e Google recompensará os fornecedores que tornarem essas camadas difíceis de contornar. Alegações de marketing sobre agentes seguros importam menos do que uma cobertura de aplicação demonstrável.

Os clientes devem testar essas alegações com exercícios de red team que envolvam injeção indireta, ferramentas comprometidas, rotas alternativas de execução e movimentação de dados em várias etapas.

Eles também devem verificar o comportamento em caso de falha. Uma chamada de ferramenta negada deve interromper a operação protegida sem expor detalhes sensíveis por meio de erros ou caminhos alternativos.

A AWS estabeleceu um padrão padrão mais forte ao colocar a política fora do código do agente. A questão restante é se os clientes configurarão as identidades e rotas ao redor com o mesmo cuidado.

O Que Compradores Empresariais Devem Observar a Seguir

A próxima fase testará a cobertura das políticas, a percepção de sessão e a portabilidade entre plataformas de agentes concorrentes.

O primeiro sinal é a rapidez com que os clientes adotam políticas temporais. Regras de solicitação única funcionam bem para restrições claras, mas muitos ataques contra agentes surgem por meio de sequências de ações autorizadas.

A avaliação temporal pode detectar que um agente leu dados sensíveis antes de tentar uma transferência externa. Ela também pode exigir aprovação adicional após uma sequência específica de operações.

A parte difícil envolve estado e interpretação. Os sistemas precisam rastrear histórico suficiente para reconhecer trajetórias perigosas sem bloquear fluxos de trabalho comuns ou adicionar latência excessiva.

Os compradores devem procurar documentação técnica pública que descreva exatamente quanto histórico de sessão é avaliado. Eles também devem perguntar como o estado é isolado entre usuários, agentes e tarefas simultâneas.

O segundo sinal é como Google e Microsoft expõem controles equivalentes por meio de suas plataformas gerenciadas de agentes. Os três provedores reconhecem que instruções de prompt, por si só, não podem proteger sistemas conectados.

A resposta do Google será importante porque os agentes Gemini podem ficar próximos ao conteúdo do Workspace, aos dados em nuvem e à infraestrutura de desenvolvimento. Já existem permissões fortes para recursos, mas a composição específica para agentes continua essencial.

A Microsoft pode combinar a identidade Entra com Copilot, Agent Framework e rótulos de fluxo de informações. Sua vantagem dependerá de aplicação consistente entre ferramentas da Microsoft e de terceiros.

A comparação entre Amazon e Google deve se concentrar em caminhos de ponta a ponta. Os compradores precisam de evidências de que a política acompanha uma ação desde a identidade do usuário, passando pelo raciocínio do agente e pela execução no gateway, até o acesso final ao recurso.

O terceiro sinal é o teste de segurança independente. A documentação dos fornecedores descreve o comportamento pretendido, enquanto as equipes de red team revelam rotas ausentes, identidades confundidas, padrões inseguros e combinações inesperadas de ferramentas.

Os testes devem incluir uma página web maliciosa, um ticket de suporte contaminado, uma resposta MCP comprometida e um documento hostil dentro de um repositório aprovado. Cada fonte pode transportar instruções indiretas para o contexto de um agente.

Pesquisadores também devem testar se os agentes conseguem transformar solicitações proibidas em ações tecnicamente diferentes. Uma exportação bloqueada pode se tornar um upload no navegador, um comando de shell, uma mensagem codificada ou uma solicitação a outro agente.

Os resultados determinarão se uma política externa produz contenção significativa ou apenas mais uma camada de configuração. A evidência mais forte virá de ataques que alteram o comportamento do modelo, mas ainda assim não conseguem cruzar os limites de autorização.

As empresas não precisam esperar por esses resultados antes de melhorar sua arquitetura. Elas podem começar inventariando cada agente, ferramenta, credencial, fonte de dados e destino de saída.

Cada ferramenta deve receber o escopo de ação mais restrito possível. O acesso somente leitura deve permanecer separado de modificação, exclusão, compartilhamento externo ou execução financeira.

As equipes devem remover credenciais permanentes quando a delegação de curta duração puder funcionar. Elas devem preservar a identidade do usuário nas chamadas de ferramentas e registrar operações tentadas e concluídas.

Ações de alto impacto devem exigir um contexto de aprovação confiável. As equipes de segurança devem testar regularmente caminhos alternativos para recursos protegidos, em vez de validar apenas a rota de gateway pretendida.

Para a decisão entre Amazon e Google Cloud, os benchmarks de modelos já não são suficientes. Os compradores devem comparar o comportamento de negação por padrão, a propagação de identidade, a análise de políticas, o nível de detalhe das auditorias, os controles de sessão e a cobertura de aplicação.

Também devem perguntar como as políticas resistem a mudanças de modelo e de framework. Uma autorização estreitamente vinculada a uma única implementação de agente se torna cara de manter e mais fácil de contornar durante migrações.

A AWS fez uma aposta arquitetural clara. Ela parte do princípio de que o raciocínio dos agentes continuará sendo manipulável e, então, limita as consequências por meio de controles determinísticos externos ao agente.

Essa premissa é mais crível do que prometer obediência perfeita do modelo. Ela aceita que erros e ataques ocorrerão, preservando ao mesmo tempo uma autoridade separada sobre ferramentas e dados.

A abordagem ainda depende de uma configuração rigorosa. Uma política de gateway restrita não pode compensar um ambiente de execução com privilégios excessivos, um shell não gerenciado ou dados recuperados antes da filtragem de autorização.

As equipes empresariais devem agora testar um fluxo de trabalho concreto de ponta a ponta. Manipulem o agente, observem as ações solicitadas por ele e confirmem que operações protegidas falham em uma fronteira externa.

Esse teste oferece um padrão prático para Amazon Google e todas as demais plataformas de agentes: o modelo pode ser enganado, mas a infraestrutura ainda precisa dizer não.