O Desafio Único da IA Autônoma
A chegada da IA autônoma marca uma mudança qualitativa em como o software funciona. Diferentemente do software tradicional, que executa instruções determinísticas, ou da IA generativa, que responde a comandos humanos gerando saídas para revisão humana, a IA autônoma opera de forma fundamentalmente diferente.
Agentes de IA conectam-se a ferramentas de software e APIs, utilizando modelos de linguagem de grande escala (Large Language Models — LLMs) como mecanismos de raciocínio para planejar e executar sequências de ações de forma autônoma — à velocidade das máquinas — com consequências no mundo real. Essa transformação traz questões inéditas para a segurança da informação.
Em janeiro de 2026, o Centro para Padrões de IA e Inovação (CAISI, na sigla em inglês) do NIST emitiu um pedido de informações (Request for Information — RFI) buscando contribuições da indústria sobre como proteger esses sistemas. A AWS respondeu baseando-se em sua experiência construindo e operando serviços de IA autônoma, apresentando quatro princípios de segurança que formam o núcleo dessa abordagem.
Por Que Isso Importa
Uma análise conservadora de riscos e benefícios mostra claramente que os benefícios da IA autônoma superam os riscos em muitos domínios. A adoção acelerada dessa tecnologia em negócios e governo confirma essa conclusão. Porém, justamente porque os agentes são valiosos por sua autonomia e adaptabilidade, essas características criam desafios de segurança.
Um sistema autônomo que executa uma ação não intencional faz isso à velocidade da máquina, antes que qualquer intervenção humana seja possível. Diferentemente de pessoas que fazem pausas ou escalações quando algo parece incomum, agentes podem não reconhecer naturalmente ambiguidades evidentes para humanos, nem compreender intuitivamente fronteiras políticas não explicitadas.
A boa notícia é que a resposta de segurança para IA autônoma não precisa começar do zero. Frameworks de segurança consolidados — incluindo o NIST Cybersecurity Framework, o NIST AI Risk Management Framework e o Secure Software Development Framework — continuam relevantes. O desafio é estendê-los para considerações específicas de agentes, em vez de substituí-los.
Os Quatro Princípios de Segurança
Esses princípios partem da premissa de que IA autônoma não exige um novo paradigma de segurança, mas sim a evolução de práticas existentes. Os dois primeiros abordam o que continua válido; os dois últimos tratam do que é genuinamente novo.
Princípio 1: Práticas de Ciclo de Vida Seguro em Todos os Componentes
Sistemas de IA autônoma combinam componentes de software tradicional (APIs, bancos de dados, lógica de orquestração) com elementos de IA, como modelos fundamentais, templates de prompts e pipelines de recuperação de dados. Um ciclo de vida de desenvolvimento seguro deve cobrir ambos os conjuntos.
Para componentes tradicionais, práticas estabelecidas como revisão de código, análise estática, varredura de dependências e modelagem de ameaças permanecem essenciais, reconhecendo que essas próprias práticas estão evoluindo com o auxílio de ferramentas baseadas em IA.
Para componentes de IA, o desafio é diferente. Modelos fundamentais são probabilísticos, o que significa que testes de regressão tradicionais são necessários, mas insuficientes. Organizações devem complementar com testes comportamentais, avaliação adversarial e monitoramento contínuo para validar que componentes de IA operam dentro de parâmetros esperados.
A reavaliação regular é igualmente importante para lidar com deriva comportamental. Modelos recebem atualizações que podem alterar seu comportamento. Templates de prompts evoluem conforme equipes refinam capacidades do agente. Novas ferramentas e fontes de dados expandem a superfície operacional. Cada mudança pode introduzir novos modos de falha ou problemas de segurança.
Organizações devem tratar a avaliação como prática operacional contínua, não como uma barreira única no tempo. Isso inclui testes automatizados após atualizações de modelo, exercícios de red team contra agentes em produção e monitoramento que detecta deriva comportamental ao longo do tempo.
Princípio 2: Controles de Segurança Tradicionais Continuam Totalmente Aplicáveis
Embora IA autônoma introduza novas considerações, ela não torna obsoletos os riscos de segurança existentes. O conjunto completo de controles de segurança tradicionais permanece aplicável. Um sistema de IA autônoma combina software tradicional com o novo loop de processamento LLM-mais-ferramentas. Organizações devem proteger software, ferramentas e configurações existentes contra riscos conhecidos para prover uma base sólida para os elementos de IA.
Escalação de privilégio, problemas de deputy confuso, sequestro de sessão, injeção de código e riscos de cadeia de suprimentos estendem-se diretamente para sistemas autônomos. Alguns desses riscos aumentam em contextos de IA autônoma. Agentes operam em maior escala e velocidade que atores humanos, o que significa que privilégios excessivos carregam maior potencial para consequências não intencionais.
Aplicar princípios de menor privilégio (least privilege) à gestão de acesso em contexto autônomo é tão importante — se não mais — que em sistemas tradicionais. A superfície de cadeia de suprimentos também é mais ampla. Sistemas autônomos consomem não apenas dependências de código de terceiros, mas também modelos fundamentais, plugins, servidores de ferramentas e fontes de recuperação de dados.
Agentes que invocam APIs, consultam bancos de dados ou geram código criam novas superfícies potenciais de injeção nos limites das ferramentas. Controles específicos de IA devem ser adições a essa segurança fundamental, não substituições.
Princípio 3: Controles Determinísticos Externos como Ponto de Partida
Este é o princípio arquitetônico mais importante para segurança de IA autônoma. Organizações devem fazer cumprir segurança através de controles determinísticos e no nível de infraestrutura, externos ao loop de raciocínio do agente, e não através do próprio raciocínio do agente, guardrails internos ou instruções baseadas em prompts.
A lógica é simples: LLMs são mecanismos de raciocínio probabilístico, não mecanismos de execução de segurança. Desenvolvedores podem instruir um LLM a recusar certas solicitações, mas técnicas de prompt injection podem contornar essas instruções. Um LLM pode ser instruído a respeitar limites de acesso, mas não possui mecanismo confiável para mantê-los.
Tentar restringir comportamento de agentes apenas através de prompting ou alignment vai contra a própria proposta de valor dos agentes: sua capacidade de adaptar-se dinamicamente a situações novas. Segurança eficaz coloca controles totalmente especificados e determinísticos fora do agente, governando quais ferramentas ele pode acessar, quais operações pode realizar e quais dados pode alcançar. Manipulação de modelo não consegue contornar esses controles.
Isso é descrito como a caixa de segurança (security box). É externa ao agente, determinística em sua execução e abrangente em cobertura. Cada interação entre agente e o mundo externo passa por ela. O Agentic AI Security Scoping Matrix ajuda organizações a calibrar o rigor desses controles baseado no nível de autonomia do sistema. Os escopos variam desde sistemas que exigem aprovação humana explícita antes de cada ação até sistemas totalmente autônomos que iniciam suas próprias atividades baseados em eventos externos.
A caixa de segurança não é uma limitação ao valor do agente. É a precondição para alcançar esse valor responsavelmente. Conforme a tecnologia de IA autônoma amadurece, a própria caixa provavelmente evoluirá para incluir elementos de IA — agentes de IA especializados em controlar o escopo de outros agentes podem eventualmente substituir alguns constrangimentos determinísticos, usando novas informações e contexto para tomar decisões automatizadas mais apropriadas do que aquelas que poderiam ser alcançadas por humanos gerenciando controles determinísticos complexos.
Princípio 4: Maior Autonomia Deve Ser Conquistada Através de Avaliação Contínua
Organizações devem expandir autonomia de agentes progressivamente baseadas em desempenho demonstrado, não concedê-la por padrão. O ponto de partida é tomada de decisão humana para operações de alta consequência. Quando um agente encontra uma ação que poderia modificar dados críticos de produção, iniciar transações financeiras ou comunicar informações sensíveis externamente, um humano toma a decisão final. O agente recomenda, e um humano aprova ou rejeita.
Essa abordagem traz um risco conhecido: se toda ação de agente exigir aprovação humana, o volume de decisões pode sobrecarregar revisores. A aprovação torna-se reflexiva em vez de deliberada, mudando responsabilidade para humanos posicionados para falhar. Organizações devem limitar supervisão humana a operações genuinamente de alta consequência e resistir à tentação de exigir designs human-in-the-loop para ações rotineiras que carregam baixo risco.
O caminho da supervisão humana para autonomia expandida passa por avaliação. Conforme organizações sistematicamente registram o que o agente recomendou, o que o humano decidiu e o que realmente aconteceu, constroem base de evidências para expandir autonomia. Quando dados mostram alinhamento sustentado, organizações podem mudar de aprovação prévia para revisão pós-fato, e eventualmente para autonomia total para tipos de operação específicos.
Essa progressão deve acontecer no nível de operação ou fluxo de trabalho, não através de ampla gama de tarefas não relacionadas. Essa progressão não é unidirecional. Organizações devem estar preparadas para reintroduzir supervisão humana quando evidência justificar. Algumas fronteiras determinísticas provavelmente permanecem permanentes no futuro próximo — essas fronteiras existem não porque o agente não conquistou confiança, mas porque consequências de certas ações são inaceitáveis sob análise de risco razoável.
O modelo geral é autonomia conquistada através de competência demonstrada, governada por avaliação, limitada por constrangimentos permanentes e sujeita a revisão contínua.
Dos Princípios à Prática
Os quatro princípios definem os objetivos. Alcançá-los exige blocos arquitetônicos específicos que compõem a caixa de segurança e a arquitetura de segurança mais ampla. A AWS descreveu esses blocos em maior detalhe em sua resposta ao NIST e os implementou no Amazon Bedrock AgentCore, um framework para construir, implantar e operar sistemas de IA autônoma com segurança incorporada desde o início.
Isolamento de Computação
Ambientes de computação de agentes devem isolar execução, prevenir vazamento de dados entre agentes e conter agentes dentro de limites definidos. O Amazon Bedrock AgentCore executa agentes em Firecracker, um gerenciador de máquina virtual open source escrito em Rust. Firecracker fornece micro-VMs leves apoiadas por Linux KVM e virtualização baseada em hardware, entregando velocidade de containers com propriedades de isolamento de máquinas virtuais completas. Elementos críticos de segurança do Firecracker foram formalmente verificados por equipes AWS, adicionando garantia além da segurança de memória que Rust oferece.
Identidade e Gestão de Acesso
Agentes exigem suas próprias identidades, armazenamento seguro de credenciais e autorização com menor privilégio executada no nível de infraestrutura. O AgentCore Identity fornece identidades de máquina para agentes, gerencia fluxos OAuth e credenciais seguras, e integra-se com o AWS Identity and Access Management (IAM) para controle de acesso fino. Suporta controle de acesso baseado em atributos e mantém cadeias de delegação rastreáveis para que a relação entre ações de agente e o usuário invocador permaneça auditável.
Acesso a Ferramentas e Execução de Políticas
Cada ferramenta que um agente pode acessar expande tanto sua utilidade quanto seu risco potencial. Gerenciar acesso a ferramentas individualmente entre agentes cria uma explosão combinatória ingerenciável. O AgentCore Gateway atua como intermediário centralizado entre agentes e ferramentas, executando autenticação e autorização em um único ponto de controle. Consegue inspecionar chamadas de ferramentas até parâmetros individuais, não apenas no nível de API. O AgentCore Policy, construído sobre a linguagem de autorização open source Cedar, adiciona execução de política formalmente verificada. Equipes conseguem escrever políticas Cedar em linguagem natural e então revisá-las, combinando flexibilidade de LLMs com rigor de métodos formais.
Observabilidade
Infraestrutura de observabilidade deve capturar contexto suficiente para monitoramento em tempo real e investigação, e deve estar protegida dos agentes que monitora. Organizações não permitiriam que funcionários editassem seus próprios registros de auditoria, e o mesmo princípio aplica-se a agentes. O AgentCore oferece observabilidade através do AgentCore Gateway, telemetria em nível de sessão e rastreamentos detalhados que registram mudanças de estado interno. Essas capacidades conseguem estender-se a agentes rodando fora do AgentCore também.
Ambiente de Execução de Modelo
A segurança do ambiente de execução de modelo importa tanto quanto a segurança do agente em si. O Amazon Bedrock executa modelos em ambientes de rede isolados onde nem AWS nem provedores de modelo acessam prompts e respostas de clientes. Quando clientes ativam logging, esses logs são encriptados em repouso e protegidos por chaves de encriptação gerenciadas pelo cliente. Esse isolamento arquitetônico é razão-chave para adoção por clientes governamentais e corporativos.
Controles determinísticos externos são complementados por controles dentro do loop de processamento de IA. O Amazon Bedrock Guardrails inspeciona prompts e respostas usando pequenos modelos de IA chamados classificadores que lidam com desafios como prompt injection. Verificações de Raciocínio Automatizado vão além, permitindo desenvolvedores criar modelo formal de um domínio de conhecimento e verificar que saídas de LLM conformam com ele, produzindo resultados que são determinísticos e comprovadamente corretos.
Caminho Adiante
IA autônoma muda como software opera, mas a resposta de segurança constrói sobre décadas de prática estabelecida. Frameworks existentes oferecem a fundação certa. A tarefa é estender frameworks existentes para considerações específicas de agentes. Organizações devem aplicar práticas de ciclo de vida de desenvolvimento seguro a componentes de IA e manter controles de segurança tradicionais. Devem fazer cumprir segurança através de controles determinísticos externos ao agente e conquistar maior autonomia através de avaliação sistemática.
Esses princípios não são teóricos — refletem experiência operacional que a AWS conquistou construindo e operando serviços de IA autônoma. Estão embutidos em como a empresa desenha sua infraestrutura. Conforme NIST desenvolve orientação baseada em contribuições da indústria, a AWS continuará investindo em ajudar clientes a construir e operar sistemas de IA autônoma com confiança.
Para aprender mais sobre como a AWS ajuda clientes a proteger suas cargas de trabalho de IA, visite o AWS AI Security ou leia a resposta da Amazon ao Pedido de Informações do CAISI sobre Considerações de Segurança para Agentes de Inteligência Artificial.
Fonte
Four security principles for agentic AI systems (https://aws.amazon.com/blogs/security/four-security-principles-for-agentic-ai-systems/)
