User's blog

Como aplicar autorização de menor privilégio em cadeias de agentes de IA com Cedar

Written by

Make.com Service User

in

O problema: escopo de autorização que se expande silenciosamente

Quem está construindo sistemas de IA com múltiplos agentes precisa lidar com um risco pouco discutido: à medida que agentes delegam tarefas entre si em cadeia, o escopo de autorização pode se expandir silenciosamente — mesmo quando há políticas de controle de acesso baseado em papel (RBAC) em vigor. Um agente pode acabar agindo além do que o usuário humano que iniciou a cadeia realmente autorizou.

O OWASP Top 10 para Aplicações Agênticas classifica esse risco como ASI03: Abuso de Identidade e Privilégio. Para endereçar esse problema de forma prática, a AWS publicou uma implementação de referência que usa um modelo de três camadas de políticas construído com Cedar, linguagem open source de políticas de autorização, implantado na AWS.

Visão geral da implementação de referência

A implementação usa OAuth 2.0 para autenticação e Cedar para autorização. Um provedor de identidade confiável autentica o usuário originador, e as políticas Cedar aplicam a autorização em três camadas usando as claims verificadas do token.

Para aplicar a autorização em cada salto da cadeia de delegação, a solução utiliza duas funções AWS Lambda em sequência:

  • Uma função adaptadora do Protocolo de Contexto de Modelo (MCP) normaliza as requisições de entrada e assina criptograficamente o contexto do usuário originador, impedindo adulterações downstream.
  • Uma função avaliadora Cedar executa as três camadas de política de forma sequencial, parando na primeira negação.

As três camadas do modelo de avaliação Cedar são:

  • Camada 1 (Agente → Ferramenta): verifica se o agente invocador tem pontuação de confiança suficiente (escala de 1 a 5), pertence ao namespace correto e está no estágio de ciclo de vida de produção.
  • Camada 2 (Agente → Agente): verifica se o número de saltos de delegação está dentro do limite máximo de cinco e se as tarefas solicitadas são um subconjunto das capacidades registradas do agente de destino.
  • Camada 3 (Autorização do usuário originador): verifica se o humano que iniciou a cadeia tem o papel exigido (por exemplo, admin), completou autenticação multifator (MFA) e está dentro da profundidade de delegação permitida.

Arquitetura: autenticação antes da autorização

O Cedar avalia a autorização, mas não estabelece identidade. Antes que as políticas possam verificar atributos como context.originating_user.role ou context.originating_user.mfa_verified, uma camada de autenticação confiável precisa estabelecer a identidade do usuário e produzir claims verificáveis.

Imagem original — fonte: Aws

O fluxo de autenticação (passos 1 a 3) funciona da seguinte forma: o usuário originador se autentica em um provedor de identidade compatível com OIDC — na implementação de referência, o Amazon Cognito com MFA via TOTP. O provedor emite um Token Web JSON (JWT) assinado contendo claims como sub, role, amr e session_id. O usuário passa o JWT e a requisição de tarefa ao agente de IA (cliente MCP), que carrega o contexto do usuário originador no envelope _meta do MCP.

O pipeline de autorização (passos 4 a 10) segue esta sequência:

Integridade do contexto ao longo dos saltos de delegação

Dois mecanismos trabalham juntos para proteger a identidade ao longo dos saltos:

  • HMAC-SHA256 garante integridade e autenticidade. Todo avaliador downstream verifica essa assinatura antes de confiar no contexto.
  • OAuth 2.0 Token Exchange (RFC 8693) define o escopo de delegação usando o padrão on-behalf-of (OBO). Quando o orquestrador delega a um agente downstream, ele troca o token original por um token OBO com escopo reduzido, registrando quem está agindo em nome de quem e com qual autoridade.

O OAuth rastreia quem age em nome de quem e com qual escopo. O HMAC verifica que o contexto não foi adulterado e veio de uma fonte confiável. Para implantações corporativas, a recomendação é usar os dois mecanismos em conjunto.

Definindo o esquema Cedar e as políticas

O esquema define dois tipos de entidade (Agent e Tool) e duas ações (invoke_tool e delegate_task) no namespace AgentAuthz. Importante: não existe entidade User. A identidade do usuário originador é carregada no registro de contexto passado junto a cada requisição de autorização.

{
  "AgentAuthz": {
    "entityTypes": {
      "Agent": {
        "shape": {
          "type": "Record",
          "attributes": {
            "trust_level": { "type": "Long", "required": true },
            "namespace": { "type": "String", "required": true },
            "registered_capabilities": {
              "type": "Set",
              "element": { "type": "String" },
              "required": true
            },
            "lifecycle_stage": { "type": "String", "required": true }
          }
        }
      },
      "Tool": {
        "shape": {
          "type": "Record",
          "attributes": {
            "namespace": { "type": "String", "required": true },
            "risk_level": { "type": "String", "required": true }
          }
        }
      }
    },
    "actions": {
      "invoke_tool": {
        "appliesTo": {
          "principalTypes": ["Agent"],
          "resourceTypes": ["Tool"]
        }
      },
      "delegate_task": {
        "appliesTo": {
          "principalTypes": ["Agent"],
          "resourceTypes": ["Agent"]
        }
      }
    }
  }
}

Topologia de agentes e ferramentas

A implementação de referência registra três agentes: orchestrator (nível de confiança 5, namespace orchestration, capacidades: delegate_task e route_request), finance-agent (nível 3, namespace payments, capacidades: process_payment e refund) e data-bot (nível 4, namespace data, capacidades: query_records e delete_records). As ferramentas registradas são process_payment (risco médio), delete_records (risco alto) e query_records (risco baixo).

Políticas das três camadas

Camada 1 (agente → ferramenta): permite que o finance-agent invoque a ferramenta process_payment apenas quando o nível de confiança for pelo menos 3, o namespace for payments e o estágio de ciclo de vida for production.

// L1-001: Finance agent can invoke payment tools
permit(
  principal == AgentAuthz::Agent::"finance-agent",
  action == AgentAuthz::Action::"invoke_tool",
  resource == AgentAuthz::Tool::"process_payment"
)
when {
  principal.trust_level >= 3 &&
  principal.namespace == "payments" &&
  principal.lifecycle_stage == "production"
};

Camada 2 (agente → agente): o orquestrador delega tarefas ao data-bot apenas quando a cadeia tem no máximo três saltos e as capacidades solicitadas são subconjunto das capacidades registradas do data-bot. Uma política forbid separada (L2-004) impõe um limite absoluto de cinco saltos para todo o sistema.

// L2-002: Orchestrator can delegate to data agent
permit(
  principal == AgentAuthz::Agent::"orchestrator",
  action == AgentAuthz::Action::"delegate_task",
  resource == AgentAuthz::Agent::"data-bot"
)
when {
  context.delegation_depth <= 3 &&
  context.target_capabilities.containsAll(context.requested_capabilities)
};

Camada 3 (autorização do usuário originador): o data-bot invoca a ferramenta delete_records apenas quando o usuário originador tem papel admin, MFA verificado e a cadeia tem no máximo dois saltos. Sem essa camada, um agente com as capacidades certas poderia invocar ferramentas destrutivas independentemente de quem iniciou a requisição.

// L3-001: High-risk tool (delete_records) requires admin + MFA
permit(
  principal == AgentAuthz::Agent::"data-bot",
  action == AgentAuthz::Action::"invoke_tool",
  resource == AgentAuthz::Tool::"delete_records"
)
when {
  context.originating_user.role == "admin" &&
  context.originating_user.mfa_verified == true &&
  context.delegation_depth <= 2
};

Implantação com AWS CDK

Antes de começar, clone o repositório:

git clone https://github.com/aws-samples/sample-cedar-agentic-ai-authorization.git
cd sample-cedar-agentic-ai-authorization

Os pré-requisitos são: conta AWS com o AWS Cloud Development Kit (AWS CDK) inicializado na região alvo, Python 3.12 ou superior, Node.js 20 ou superior, CLI do AWS CDK (npm install -g aws-cdk) e credenciais AWS com permissões de AWS Identity and Access Management (IAM) com escopo para Lambda, API Gateway, Verified Permissions, Secrets Manager, Amazon Virtual Private Cloud (Amazon VPC) e CloudWatch.

A implementação implanta cinco stacks do CloudFormation: KmsStack, VerifiedPermissionsStack, LambdaStack, SecurityLakeStack e MonitoringStack. Os comandos de implantação seguem a ordem de dependência:

cdk deploy KmsStack -c account_id=YOUR_ACCOUNT_ID -c guardrail_id=YOUR_GUARDRAIL_ID
cdk deploy VerifiedPermissionsStack -c account_id=YOUR_ACCOUNT_ID -c guardrail_id=YOUR_GUARDRAIL_ID
cdk deploy LambdaStack -c account_id=YOUR_ACCOUNT_ID -c guardrail_id=YOUR_GUARDRAIL_ID
cdk deploy SecurityLakeStack -c account_id=YOUR_ACCOUNT_ID -c guardrail_id=YOUR_GUARDRAIL_ID
cdk deploy MonitoringStack -c account_id=YOUR_ACCOUNT_ID -c guardrail_id=YOUR_GUARDRAIL_ID

Cenários de teste

Três cenários de ponta a ponta validam o modelo de avaliação:

  • Cenário A — Aplicação da Camada 3: um usuário com papel support (sem MFA) solicita exclusão de registros via orchestrator e data-bot. L1 e L2 permitem, mas L3 nega porque o papel é support e o MFA não está verificado. Resultado geral: NEGADO.
  • Cenário B — Requisição admin autorizada: um usuário admin com MFA solicita a mesma operação. As três camadas permitem. Resultado geral: PERMITIDO.
  • Cenário C — Limite de profundidade de delegação: um admin com MFA solicita a mesma operação, mas a cadeia tem seis saltos. L1 permite, L2 nega (seis saltos excedem o limite de cinco). L3 nem é avaliada. Resultado geral: NEGADO.

Alinhamento com os princípios de segurança para IA agêntica

O Escritório do CISO da AWS publicou os quatro princípios de segurança para sistemas de IA agêntica. A solução mapeia diretamente para cada um deles: testes baseados em propriedades com Hypothesis para fuzzing de entradas adversariais; controles tradicionais como AWS WAF, isolamento via Amazon VPC, criptografia com AWS Key Management Service (AWS KMS) e MFA; avaliação Cedar determinística rodando fora do loop de raciocínio do agente em uma função Lambda separada; e atributos trust_level e lifecycle_stage que calibram as capacidades dos agentes com base em evidências de auditoria do Amazon CloudWatch.

Escalando para ambientes multi-conta

Para implantações corporativas, a recomendação é implantar o policy store Cedar em uma conta de segurança centralizada e usar funções IAM cross-account para que as contas de carga de trabalho chamem verifiedpermissions:IsAuthorized. As políticas de controle de serviço (SCPs) do AWS Organizations podem impedir que contas de carga de trabalho criem seus próprios policy stores.

Para implantações em produção, a implementação pode ser estendida com escalação com humano no loop para negações borderline, isolamento de políticas Cedar multi-tenant e recarga dinâmica de políticas via Amazon Simple Storage Service (Amazon S3) para desligamentos de emergência de ferramentas.

Limpeza dos recursos

cdk destroy MonitoringStack SecurityLakeStack
cdk destroy LambdaStack
cdk destroy VerifiedPermissionsStack
cdk destroy KmsStack
aws logs delete-log-group --log-group-name /cedar-evaluator/audit # if RETAIN policy

Conclusão

Sistemas de IA multi-agente precisam de fronteiras de autorização em cada salto de delegação. O modelo de três camadas Cedar com autenticação OAuth 2.0 fornece essa proteção mantendo o acesso de menor privilégio. A combinação de um provedor de identidade confiável (autenticação) com avaliação de políticas Cedar (autorização) cria uma fronteira de autorização em torno de cada invocação de ferramenta, verificando a capacidade do agente (L1), o caminho de delegação (L2) e a autoridade do usuário originador (L3). O padrão funciona com qualquer provedor de identidade compatível com OIDC e uma plataforma de computação capaz de chamar o Amazon Verified Permissions. A implementação de referência está disponível para clonagem e adaptação às necessidades de cada organização. Para mais detalhes, consulte a documentação da linguagem de políticas Cedar e o Guia do Usuário do Amazon Verified Permissions.

Fonte

Enforce least-privilege authorization in multi-agent AI chains using Cedar (https://aws.amazon.com/blogs/security/enforce-least-privilege-authorization-in-multi-agent-ai-chains-using-cedar/)

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

More posts