AWS detalha como reduzir riscos de prompt injection em agentes de IA
A AWS apresentou uma arquitetura voltada a limitar os impactos de ataques de *prompt injection* contra agentes de inteligência artificial. A proposta busca impedir que um agente manipulado consulte dados, bancos de dados ou sistemas corporativos além do nível de acesso concedido ao usuário autenticado.
A estratégia se apoia no Amazon Bedrock AgentCore para retirar do modelo a responsabilidade de decidir quais informações podem ser acessadas. Em vez de confiar exclusivamente no comportamento do agente, as permissões são aplicadas pela infraestrutura e pelos serviços conectados, onde as regras podem ser verificadas de forma independente.
Por que o prompt injection representa um risco
Agentes de IA são capazes de interpretar solicitações, consultar fontes externas e executar ações em nome de uma pessoa ou aplicação. Para realizar essas tarefas, normalmente recebem acesso a repositórios, plataformas SaaS, bancos de dados e ferramentas internas.
O problema surge quando as credenciais atribuídas ao agente são mais amplas do que as permissões reais do usuário. Caso o modelo seja induzido por uma instrução maliciosa, um documento contaminado ou uma falha na aplicação, ele pode tentar buscar informações que não deveriam estar disponíveis para aquela identidade.
Esse tipo de ataque não depende necessariamente da invasão direta de um sistema. Uma mensagem cuidadosamente elaborada pode levar o agente a ignorar instruções anteriores, revelar dados confidenciais, executar comandos ou consultar recursos fora do escopo original. Por isso, a proteção não deve ficar restrita ao prompt ou às regras internas do modelo.
Autenticação e validação antes da execução
Na arquitetura demonstrada pela AWS, o processo começa com a autenticação dos usuários por meio do Amazon Cognito. Depois do login, o serviço emite tokens JWT com atributos associados à identidade, como departamento, função ou grupo organizacional.
Antes de iniciar uma tarefa, o Amazon Bedrock AgentCore Runtime valida essas informações. A requisição só prossegue quando os dados presentes no token correspondem às políticas previamente configuradas. Se houver incompatibilidade, a operação é recusada antes que o agente consiga acessar os recursos solicitados.
Essa etapa cria uma separação importante entre a intenção interpretada pelo modelo e a autorização efetiva. O agente pode compreender uma solicitação e tentar executá-la, mas a infraestrutura verifica se aquele usuário realmente possui autorização para a ação.
Credenciais temporárias e controle no DynamoDB
Para consultas ao Amazon DynamoDB, a arquitetura utiliza credenciais temporárias obtidas por meio do mecanismo `AssumeRoleWithWebIdentity`. Dessa forma, o agente não opera com uma chave permanente e genérica capaz de acessar todos os dados da organização.
As políticas do AWS Identity and Access Management (IAM) restringem as operações às partições autorizadas para cada usuário ou grupo. Um funcionário de determinado departamento, por exemplo, pode ser limitado aos registros correspondentes à sua área, sem acesso automático às informações de outras divisões.
Mesmo que o agente receba uma instrução maliciosa para consultar registros adicionais, a tentativa encontra uma barreira no IAM. A decisão não depende da interpretação do modelo, mas da política aplicada ao recurso e da identidade que apresentou a solicitação.
O agente deve orquestrar, não autorizar
O princípio central da arquitetura é manter o agente no papel de orquestrador. Ele pode interpretar pedidos, escolher ferramentas e organizar etapas, mas não deve definir quem está autorizado a visualizar ou modificar determinada informação.
Essa distinção reduz o impacto de comportamentos inesperados. Um modelo pode ser enganado por conteúdo inserido em uma página, por um arquivo preparado para manipular sua interpretação ou por instruções conflitantes. No entanto, os controles de identidade, função e recurso permanecem ativos fora do contexto do agente.
A abordagem também evita que uma única camada concentre todas as responsabilidades. O modelo cuida da interação e da automação, enquanto os serviços de autenticação, autorização e armazenamento aplicam as restrições técnicas.
Boas práticas para implementar a proteção
Empresas que desenvolvem agentes de IA devem adotar o princípio do menor privilégio desde o desenho da solução. Cada agente precisa receber apenas as permissões indispensáveis para cumprir uma tarefa específica, evitando credenciais amplas para bancos de dados ou sistemas corporativos.
Também é recomendável utilizar credenciais temporárias, com validade curta e escopo limitado. Caso uma sessão seja comprometida, a janela de exploração será menor e a revogação do acesso poderá ser feita com mais rapidez.
Outro cuidado importante é separar permissões de leitura e escrita. Um agente destinado a consultar relatórios não deve ter autorização para excluir registros, alterar configurações ou publicar informações em nome do usuário.
Validação de entradas e saídas
A aplicação deve tratar documentos externos, páginas da internet, e-mails e resultados de ferramentas como conteúdo potencialmente não confiável. Instruções encontradas nesses materiais não podem ser automaticamente interpretadas como ordens legítimas.
Além disso, respostas geradas pelo agente precisam passar por verificações antes de serem encaminhadas ao usuário ou utilizadas em outra ação automatizada. Filtros podem identificar dados sensíveis, comandos perigosos, informações fora do escopo e tentativas de exfiltração.
Operações de maior impacto, como exclusão de dados, envio de mensagens, alteração de permissões ou publicação de conteúdo, devem exigir confirmação humana ou uma etapa adicional de aprovação.
Monitoramento e rastreabilidade
Registros detalhados são essenciais para identificar tentativas de abuso. A organização deve acompanhar quem solicitou a ação, qual agente foi utilizado, quais ferramentas foram acionadas, quais recursos foram consultados e qual decisão de autorização foi tomada.
Alertas podem ser configurados para detectar comportamentos atípicos, como consultas em sequência a departamentos diferentes, aumento repentino no volume de dados acessados ou tentativas repetidas de executar operações negadas.
A observabilidade também facilita auditorias e investigações. Com trilhas de auditoria consistentes, a empresa consegue diferenciar um erro de configuração, uma falha do agente e um ataque deliberado.
Defesa em camadas
Nenhuma medida isolada elimina completamente o risco de prompt injection. A proteção mais eficiente combina autenticação forte, autorização baseada em identidade, políticas de menor privilégio, isolamento entre ferramentas, validação de dados, monitoramento e intervenção humana.
A arquitetura apresentada pela AWS reforça justamente essa ideia: o agente pode ser útil e flexível, mas não deve ser considerado uma fronteira de segurança. As permissões precisam ser aplicadas por componentes externos, capazes de bloquear uma ação mesmo quando o modelo é enganado.
Com essa separação, a empresa reduz a possibilidade de que uma única instrução maliciosa transforme o agente em um caminho para acessar dados corporativos protegidos. O modelo continua responsável pela automação, enquanto a infraestrutura preserva os limites definidos para cada usuário, função e recurso.