O Desafio de Segurança em Agentes de IA
Implantar agentes de inteligência artificial com segurança em indústrias reguladas representa um dos maiores desafios da computação moderna. Sem limites bem definidos, um agente capaz de acessar dados sensíveis ou executar transações financeiras se torna um vetor de risco significativo.
O que torna os agentes de IA tão poderosos é justamente aquilo que os torna arriscados: sua autonomia. Diferentemente de software tradicional que segue um fluxo predeterminado, um agente de IA seleciona ações para atingir um objetivo, invocando ferramentas, acessando dados e adaptando seu raciocínio com base em informações do ambiente e do usuário. Essa flexibilidade é essencial para sua efetividade, mas exige controles de segurança rigorosos.
Um modelo mental útil para compreender a segurança de agentes é imaginar “muros” ao seu redor que definem exatamente o que o agente pode acessar, com o que pode interagir e que efeitos pode ter no mundo externo. Sem esses muros bem definidos, um agente autorizado a enviar emails, consultar bancos de dados, executar código ou disparar transações financeiras representa um risco real de exfiltração de dados, acesso não intencional a infraestrutura ou ataques de injeção de prompts.
Por Que Agentes Precisam de Enforcement Externo de Políticas
Proteger agentes de IA é mais complexo que proteger software tradicional. As características que os tornam poderosos — raciocínio aberto, uso flexível de ferramentas e adaptabilidade a novas situações — também criam comportamentos imprevisíveis e difíceis de controlar com segurança.
Agentes dependem de inferência com Grandes Modelos de Linguagem (LLM), que podem alucinar e carecem de separação clara entre instruções confiáveis e texto incidental. Isso os torna vulneráveis a ataques adversariais como injeção de prompts, que exploram essas fraquezas para contornar salvaguardas.
Historicamente, essas vulnerabilidades são gerenciadas através de restrições programadas no código da aplicação. Esse método funciona, mas com custos ocultos: o comportamento seguro depende da corretude do código wrapper, que se torna uma fronteira de segurança implícita. Auditar se as políticas corretas estão em lugar requer análise cuidadosa de potencialmente grande base de código. Equipes de segurança precisam revisar código de aplicação em vez de ter uma definição de política clara e auditável.
A AWS introduziu uma abordagem diferente: movendo a política completamente para fora do agente. Agora o enforcement ocorre antes da invocação da ferramenta, através do AgentCore Gateway. Isso significa que a política é enforçada independentemente do que o agente faz, como é manipulado ou que bugs possam existir no código do agente. Com essa separação, equipes podem focar em capacidade sem tratar cada linha de código como uma fronteira de segurança.
Cedar: Linguagem para Enforcement Determinístico de Políticas
Para tornar o enforcement externo de política prático, é necessária uma linguagem que seja simultaneamente eficiente para máquinas e auditável para humanos. Cedar é a linguagem de autorização utilizada no Policy do Amazon Bedrock AgentCore, projetada especificamente para ser tanto uma linguagem de autorização prática quanto um alvo para análise matemática automatizada.
Cada política Cedar especifica um principal (quem), uma ação (o que) e um recurso (onde), com condições opcionais na cláusula when. Um exemplo simples mostra como permitir que apenas Alice visualize uma foto:
permit(
principal == User::"alice",
action == Action::"view",
resource == Photo::"VacationPhoto94.jpg"
);Além de atributos em principals, recursos e ações, Cedar permite passar um objeto de contexto com atributos que podem ser referenciados em políticas para condicionar decisões a informações de tempo de execução. Isso permite criar políticas sofisticadas que combinam identidade, função, contexto e dados da requisição.
A semântica de Cedar — incluindo negação como padrão, “forbid vence permit” e avaliação independente de ordem — torna razoável raciocinar sobre políticas de forma composicional. A latência de avaliação é mínima graças à estrutura sem loops. Politicas Cedar não têm efeitos colaterais como acesso a sistema de arquivos ou chamadas de rede, permitindo avaliação segura sem sandboxing mesmo quando escritas por autores não confiáveis.
Policy no Amazon Bedrock AgentCore
O Policy no Amazon Bedrock AgentCore fornece o mecanismo concreto que avalia cada requisição agente-para-ferramenta contra políticas Cedar explicitamente definidas. Um motor de política é uma coleção de políticas expressas em Cedar.
Para tornar a autoria de políticas acessível, elas podem ser criadas de duas maneiras: authored diretamente como Cedar para controle programático fino-granular, ou geradas a partir de enunciados em linguagem natural que são automaticamente formalizados em Cedar. A partir de linguagem natural, o serviço gera código Cedar sintaticamente correto, valida contra o schema do gateway e analisa para identificar políticas excessivamente permissivas, restritivas ou problemáticas antes da aplicação.
Uma vez definidas, as políticas no Policy no AgentCore interceptam tráfego do agente através dos Gateways do Amazon Bedrock AgentCore, avaliando cada requisição agente-para-ferramenta contra as políticas do motor antes de conceder ou negar acesso à ferramenta.
Caso de Uso: Agente de Agendamento de Consultas em Saúde
Para concretizar esses conceitos, consideremos um agente de agendamento de consultas que funciona em um ambiente de saúde. Este sistema de IA ajuda a verificar status de imunização, consulta slots disponíveis e agenda consultas. O objetivo é proteger o sistema usando Policy para prevenir acesso não autorizado a registros de pacientes, exposição inadvertida de informações de saúde protegidas (PHI) ou cancelamento de consultas por pacientes não autorizados.
O Policy no Amazon Bedrock AgentCore adota postura de negação por padrão: se nenhuma política de permissão coincide com uma requisição, ela é bloqueada. Combinado com o princípio de que “forbid vence permit”, essas duas semânticas estabelecem uma base sólida para construir um conjunto coeso de regras Cedar legíveis e auditáveis que melhorem a segurança do agente em produção.
Ferramentas do Agente de Saúde
O agente de agendamento possui as seguintes ferramentas:
getPatient: GET /get_patient_emr — Obtém um registro de paciente pelo parâmetro de query obrigatório patient_id (string)searchImmunization: POST /search_immunization_emr — Procura registros de imunização com parâmetro obrigatório search_value (string; ID do paciente)bookAppointment: POST /book_appointment — Agenda uma consulta fornecendo date_string (string; formato “YYYY-MM-DD HH:MM”)getSlots: GET /get_available_slots — Obtém slots disponíveis pelo parâmetro de query obrigatório date_string (string; “YYYY-MM-DD”)
Políticas Baseadas em Identidade
Uma regra fundamental em um agente de saúde é que pacientes devem conseguir agir apenas em seus próprios registros. Criar uma política que permita um paciente ler seus próprios registros de paciente e imunização requer que o parâmetro da ferramenta (patient_id para getPatient, search_value para searchImmunization) coincida com o ID autenticado do usuário.
Separação de Leitura e Escrita
Um padrão comum em sistemas de saúde é permitir acesso amplo de leitura enquanto restringe firmemente operações de escrita. Uma exemplo de política seria permitir leituras apenas para usuários autenticados com escopo apropriado (por exemplo, fhir:read) e manter escritas sob controle separado. Similar, um escopo appointment:write pode ser usado para controlar acesso a operações de escrita.
Controles de Risco em Agendamento
Além de controle de acesso, Policy pode enforçar regras de negócio ou padrões perigosos que ajudam a prevenir abuso. Ao usar “forbid” explícitos para barrar padrões de entrada perigosos nas ferramentas, é possível proteger a aplicação mesmo que o agente seja comprometido.
Por exemplo, criar uma política que bloqueie a exibição de slots de consulta fora de horários limitados. Uma declaração em linguagem natural como “Permitir que usuários vejam slots apenas entre 9h e 21h UTC” pode ser convertida em uma política Cedar que garante isso automaticamente.
Começando a Usar
Para experimentar esse exemplo, comece clonando o repositório de amostras do Amazon Bedrock AgentCore e navegando até a pasta do agente de consultas médicas:
git clone https://github.com/awslabs/amazon-bedrock-agentcore-samples.git
cd amazon-bedrock-agentcore-samples/02-use-cases/healthcare-appointment-agentA partir daí, siga as instruções de configuração e implantação no README para configurar seu ambiente AWS, implantar a stack de exemplo e invocar o agente end-to-end.
Pré-requisitos
Para usar Policy no Amazon Bedrock AgentCore com sua aplicação de agentes, verifique se atende aos seguintes pré-requisitos:
- Uma conta AWS ativa
- Confirmação das regiões AWS onde Policy no AgentCore está disponível
- Permissões IAM apropriadas para criar, testar e anexar motor de política ao seu AgentCore Gateway
Para produção, limpe os ARNs de recurso para IDs específicos de motor de política e gateway em vez de usar wildcards. Para o conjunto completo de permissões incluindo configuração do execution role do Gateway, consulte as permissões IAM do AgentCore Gateway e Policy.
Testando Enforcement de Políticas
Dois casos de teste ilustram como políticas de acesso escopo-identidade funcionam quando o agente invoca a ferramenta getPatient em nome de um usuário. Em ambos os casos, o usuário autenticado é patient adult-patient-001.
Caso 1: PERMITIR — Paciente acessando seu próprio registro
O agente envia uma requisição tools/call ao gateway para invocar getPatient com o parâmetro patient_id definido como adult-patient-001. Como o patient_id na entrada da ferramenta coincide com o patient_id autenticado do usuário, a política Cedar permite a requisição:
Prompt: "Get my patient information for patient ID adult-patient-001"
Policy decision: ALLOW
Result: Patient record returned successfullyCaso 2: NEGAR — Paciente tentando acessar registro de outro paciente
Agora o agente envia a mesma requisição tools/call para getPatient, mas com patient_id definido como pediatric-patient-001. A política Cedar compara a entrada contra o patient_id autenticado do usuário, encontra uma desconexão e nega a requisição porque não há política de permissão coincidente:
Prompt: "Get patient information for patient ID pediatric-patient-001"
Policy decision: DENY
Result: Tool execution denied by policy enforcementO mesmo código do agente, o mesmo modelo e a mesma ferramenta são usados em ambos os casos. A única diferença é a avaliação de política na fronteira do gateway. A ferramenta é protegida da requisição negada porque o gateway intercepta antes da execução.
Um segundo padrão de enforcement demonstra uma regra “forbid” que bloqueia operações de agendamento fora de horários permitidos. Se o agente fizer a mesma requisição mas às 3h UTC, a regra “forbid” coincide porque a hora está abaixo de nove, e como “forbid vence permit” em Cedar, a requisição é bloqueada independentemente de outras políticas de permissão:
Prompt: "Show me available appointment slots for 2025-08-15" (requested at 03:00 UTC)
Policy decision: DENY
Result: Tool execution denied by policy enforcementPróximos Passos
Pronto para adicionar enforcement determinístico de política aos seus próprios agentes? Estes recursos ajudarão você a começar rapidamente:
- O Policy Developer Guide cobre autoria de política Cedar, formalização de linguagem natural para Cedar, criptografia com AWS KMS e construtos CDK para implantações Infrastructure as Code (IaC)
- O workshop Getting Started do AgentCore guia você através da construção e proteção de um agente end-to-end, incluindo integração de Policy com AgentCore Gateway
- Dúvidas sobre implementar essas políticas em seu caso de uso específico? Compartilhe seus pensamentos na comunidade de fóruns AWS
Conclusão
Agentes de IA são tão confiáveis quanto os limites que os contêm. Esses limites devem ser enforçados de forma determinística, não deixados à mercê do raciocínio interno do modelo. O Policy no Amazon Bedrock AgentCore oferece um caminho principiado para definir esses limites e enforçá-los na camada de gateway em cada requisição agente-para-ferramenta. Essas políticas são enforçadas independentemente do raciocínio do agente e são auditáveis por qualquer membro da equipe de segurança.
Para empresas implantando agentes em indústrias reguladas, essa separação entre capacidade e enforcement é o fundamento que torna possível sistemas agentic de nível produção. Ao combinar flexibilidade de IA com controles determinísticos, organizações podem inovar com confiança.
Fonte
Secure AI agents with Policy in Amazon Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/secure-ai-agents-with-policy-in-amazon-bedrock-agentcore/)
Leave a Reply