Segurança de Agentes de IA Acessando Recursos AWS
A inteligência artificial generativa trouxe uma nova categoria de aplicações: os agentes de IA e assistentes de codificação. Diferente das aplicações tradicionais com fluxos de código previsíveis, esses agentes raciocinam dinamicamente, escolhendo diferentes ferramentas e acessando diferentes dados conforme o contexto. Essa característica fundamental muda completamente a abordagem de segurança necessária.
O acesso desses agentes aos recursos da AWS acontece frequentemente através do Model Context Protocol (MCP). A AWS publicou orientações técnicas focadas especificamente em como garantir que esse acesso seja seguro, apresentando três princípios de segurança para construir controles determinísticos em sistemas não-determinísticos de IA.
Entendendo o Problema de Segurança
O desafio fundamental é que você deve assumir que um agente pode fazer qualquer coisa dentro de suas permissões concedidas, independentemente da intenção original. Diferente de uma aplicação tradicional onde você revisa o código e entende exatamente quais APIs serão chamadas, um agente pode invocar diferentes ferramentas em diferentes contextos.
Agentes operam em velocidade de máquina, o que significa que o impacto de permissões mal configuradas escala rapidamente. Um agente pode fazer milhares de chamadas de API em segundos. Se receber permissões excessivas, pode causar danos significativos antes de qualquer detecção humana.
A AWS Identity and Access Management (IAM) é a camada de autorização para acesso aos recursos AWS. O foco da orientação é em como usar IAM de forma adequada, considerando a natureza não-determinística dos agentes de IA.
Padrões de Implantação do MCP
Onde os Agentes Executam
Os agentes acessam recursos AWS de três locais distintos. O primeiro padrão é em máquinas de desenvolvimento, como assistentes de IA (ex: Kiro e Claude Code) executando localmente. Neste caso, as credenciais vêm do ambiente local do desenvolvedor, e o desenvolvedor controla qual principal IAM o agente usa.
O segundo padrão é em ambientes de hospedagem gerenciados pela organização, como Amazon Bedrock AgentCore, Amazon EC2 ou Amazon EKS. Aqui, o agente usa um papel IAM de execução configurado pela organização.
O terceiro padrão é em plataformas de agentes de terceiros, onde a organização não controla a infraestrutura. Este artigo se concentra nos dois primeiros padrões.
Tipos de Servidores MCP
Existem dois tipos de servidores MCP. Os servidores gerenciados pela AWS, como o AWS MCP Server, Amazon EKS MCP Server e Amazon ECS MCP Server, rodam na infraestrutura AWS sem necessidade de instalação.
Os servidores auto-gerenciados são aqueles que você instala e mantém você mesmo, incluindo servidores fornecidos pela AWS no AWS MCP GitHub repository ou servidores customizados que você constrói do zero.
A diferença de segurança é importante: os servidores gerenciados pela AWS adicionam automaticamente chaves de contexto IAM a cada chamada de serviço AWS downstream. Os servidores auto-gerenciados não fazem isso automaticamente; você precisa configurá-los para adicionar tags de sessão ao assumir papéis IAM.
Princípio 1: Assuma que Todas as Permissões Concedidas Podem Ser Usadas
Este é o princípio fundamental. Qualquer permissão que você conceda a um agente pode ser exercida, regardless da sua intenção original. Se você concede s3:DeleteObject, deve assumir que o agente pode deletar qualquer objeto S3 ao qual tem acesso.
As aplicações tradicionais seguem caminhos de código determinísticos. Você revisa o código-fonte e identifica exatamente quais APIs serão chamadas. Agentes de IA operam diferente. Eles tomam decisões em tempo de execução baseadas em raciocínio e contexto.
Cenários de Risco
Alucinação: O agente interpreta mal uma solicitação e realiza a ação errada. Um agente designado para limpar arquivos temporários pode alucinar que dados de produção são temporários e deletá-los.
Injeção de prompt: Um terceiro malicioso elabora entrada inesperada que influencia o raciocínio do agente. Um agente designado para consultar tabelas Amazon DynamoDB poderia ser direcionado a chamar operações de escrita em recursos fora de seu escopo.
Erros de lógica: O raciocínio do agente leva a uma conclusão incorreta. Um agente analisando custos de armazenamento S3 pode concluir que dados frequentemente acessados são não utilizados e deletá-los para economizar.
Envenenamento de ferramentas: Um servidor MCP comprometido ou dependência realiza operações não intencionais usando as credenciais do agente.
Implementação Prática
Aplique o princípio de menor privilégio rigorosamente. Se um agente precisa apenas ler objetos S3, conceda apenas s3:GetObject, não s3:*. Use condições de política IAM para limitar permissões a recursos específicos.
Considere implementar perímetros de dados como camada adicional de defesa. Use alarmes do CloudWatch para monitorar ações inesperadas do agente. Conduza auditorias regulares de permissões para identificar e remover acessos que não são mais necessários.
Princípio 2: Orientação Organizacional sobre Uso de Papéis
Este princípio aborda governança organizacional. Quando desenvolvedores usam assistentes de IA e configuram servidores MCP, frequentemente escolhem papéis existentes que foram designados para uso humano com permissões muito mais amplas que os agentes realmente precisam.
Para Agentes que Você Controla
Quando você controla o código do agente, pode implementar gerenciamento de credenciais dinâmico. Este é o modelo de execução mais forte. O papel IAM define o teto máximo de permissões, mas você usa políticas de sessão para restringir permissões por operação específica.
Quando o agente invoca uma ferramenta específica, chama AssumeRole com uma política de sessão que restringe permissões apenas ao que essa ferramenta requer. As permissões efetivas são a interseção das políticas do papel e da política de sessão.
import boto3
sts = boto3.client('sts')
response = sts.assume_role(
RoleArn='arn:aws:iam::111122223333:role/AgentDataRole',
RoleSessionName='agent-data-reader',
PolicyArns=[
{'arn': 'arn:aws:iam::aws:policy/ReadOnlyAccess'}
],
DurationSeconds=3600
)
credentials = response['Credentials']
s3 = boto3.client(
's3',
aws_access_key_id=credentials['AccessKeyId'],
aws_secret_access_key=credentials['SecretAccessKey'],
aws_session_token=credentials['SessionToken']
)Para Assistentes de IA Configurados
Quando você usa assistentes de IA com configuração fixa (como Kiro ou Claude Code), seus controles de segurança devem estar em lugar antes do agente executar. Crie papéis específicos para agentes com permissões mais restritas que papéis equivalentes de humanos.
Use limites de permissão IAM para estabelecer governança organizacional. Um limite de permissão é uma política gerenciada que sua equipe de segurança anexa a um papel IAM para definir as permissões máximas que esse papel pode conceder. As permissões efetivas são a interseção das políticas de identidade do papel e do limite de permissão.
Para ambientes multi-conta, use AWS Organizations e políticas de controle de serviço (SCPs) para estabelecer limites máximos de permissões em toda a organização.
Princípio 3: Diferenciar Ações Orientadas por IA de Ações Iniciadas por Humanos
Este terceiro princípio adiciona um nível complementar de controle. Enquanto o princípio 2 governa quais permissões um agente tem, este princípio governa o que o agente pode fazer com essas permissões baseado em se a ação é orientada por IA ou iniciada por humano.
Sem mecanismo de diferenciação, políticas IAM não podem distinguir entre ações de IA e iniciadas por humano. Se um desenvolvedor tem permissão s3:DeleteObject e usa um agente com suas credenciais, o agente também tem essa permissão sem forma de restringir.
Servidores MCP Gerenciados pela AWS
Os servidores gerenciados pela AWS oferecem diferenciação por padrão. Eles adicionam automaticamente as chaves de contexto IAM aws:ViaAWSMCPService (booleano true quando a solicitação vem através de um servidor MCP gerenciado) e aws:CalledViaAWSMCP (string contendo o nome do servidor MCP) a cada chamada de serviço AWS downstream.
Você precisa apenas escrever políticas IAM que verifiquem essas chaves. A seguinte política nega operações de delete quando acessadas através de qualquer servidor MCP gerenciado:
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "AllowS3ReadOperations",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": "*"
}, {
"Sid": "DenyDeleteWhenAccessedViaMCP",
"Effect": "Deny",
"Action": [
"s3:DeleteObject",
"s3:DeleteBucket"
],
"Resource": "*",
"Condition": {
"Bool": {
"aws:ViaAWSMCPService": "true"
}
}
}]
}Servidores MCP Auto-Gerenciados
Servidores auto-gerenciados não adicionam chaves de contexto automaticamente. Para implementar diferenciação, você deve configurar o servidor MCP para adicionar tags de sessão ao assumir papéis IAM. Isso requer modificar seu servidor MCP para chamar AssumeRole com tags anexadas:
import boto3
sts = boto3.client('sts')
response = sts.assume_role(
RoleArn='arn:aws:iam::111122223333:role/MCPServerRole',
RoleSessionName='mcp-server-session',
Tags=[
{'Key': 'AccessType', 'Value': 'AI'},
{'Key': 'Source', 'Value': 'AgentRuntime'},
{'Key': 'MCPServer', 'Value': 'org-data-server'}
]
)
credentials = response['Credentials']Você então escreve políticas IAM que verificam essas tags usando a chave de condição aws:PrincipalTag para diferenciar ações de agentes:
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "AllowS3ReadOperations",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": "*"
}, {
"Sid": "DenyDeleteWhenAccessedViaAI",
"Effect": "Deny",
"Action": [
"s3:DeleteObject",
"s3:DeleteBucket"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:PrincipalTag/AccessType": "AI"
}
}
}]
}Monitoramento através de CloudTrail
Ambos os mecanismos de diferenciação geram logs no AWS CloudTrail. Para servidores gerenciados, chamadas originadas de MCP aparecem com identificadores de serviço MCP nos campos da solicitação. Para servidores auto-gerenciados, as tags de sessão aparecem no campo requestParameters.principalTags do evento AssumeRole.
Com esses logs, você pode consultar CloudTrail para encontrar todas as ações orientadas por IA e analisar padrões de comportamento do agente. Configure alarmes para detectar ações de agentes em recursos sensíveis ou padrões incomuns.
Considerações Importantes
Quando agentes usam ferramentas de propósito geral como bash ou shell para executar comandos AWS CLI ou scripts Python, a solicitação vai direto para AWS, contornando completamente os servidores MCP. Nestes casos, as chaves de contexto de diferenciação não são aplicadas.
Os controles de diferenciação garantem o caminho de acesso MCP. Para caminhos de acesso direto, os princípios 1 e 2 são seus controles primários. Se o papel não tem permissão s3:DeleteObject, o agente não pode deletar objetos, independentemente do caminho.
Você pode usar frameworks de agentes e ambientes de hospedagem para limitar quais ferramentas um agente pode acessar, removendo capacidades de execução de propósito geral para agentes que interagem com AWS exclusivamente através de servidores MCP.
Síntese Prática
Comece com o Princípio 1: audite as permissões atuais do agente e padrão para acesso somente leitura quando possível. Em seguida, implemente o Princípio 2 estabelecendo limites de permissão e selecionando papéis específicos para agentes. Finalmente, adicione diferenciação do Princípio 3 baseada no tipo de seu servidor MCP.
Para servidores gerenciados pela AWS, use as chaves de contexto automáticas em suas políticas IAM. Para servidores auto-gerenciados, configure tags de sessão e refira-se a elas em suas políticas.
Fonte
Secure AI agent access patterns to AWS resources using Model Context Protocol (https://aws.amazon.com/blogs/security/secure-ai-agent-access-patterns-to-aws-resources-using-model-context-protocol/)
Leave a Reply