NCCoE publica dez princípios de identidade para agentes de IA, seis já verificáveis na AWS

O NCCoE lançou dez tenets de design para identidade de agentes de IA. Um artigo da comunidade dev.to mapeou seis deles contra IAM e logging que times de AWS já operam, e o buraco não é tecnologia nova: é prova.

O que o NCCoE publicou

O National Cybersecurity Center of Excellence (NCCoE), braço do NIST, publicou dez "Design Tenets for Agentic Identity" dentro do projeto Accelerating the Adoption of Software and AI Agent Identity and Authorization. São princípios de design para como agentes de IA deveriam se identificar, receber autorização e deixar rastro de auditoria.

Um post no dev.to, assinado por bala_paranj, faz uma pergunta prática que o documento do NCCoE não responde diretamente: quais desses dez princípios dá para checar numa configuração de nuvem HOJE, sem esperar um protocolo novo? A resposta do autor é seis de dez. E o recorte interessa direto a quem desenha trust policy, Service Control Policy (SCP) e trilha de auditoria todo dia.

A linha que separa o que já dá para verificar

O critério do autor é simples: um tenet é verificável se existir um predicado booleano que uma ferramenta de configuração consiga checar contra o estado atual da conta. Os outros quatro tenets descrevem infraestrutura de runtime que a maioria das organizações ainda não construiu, como assinatura criptográfica de mandatos de tarefa ou gates de aprovação humana.

Os seis verificáveis caem quase todos em propriedades de IAM, trust policy e logging que arquiteto, DevOps e SRE já mexem em revisão de segurança e em pós-mortem. Vale passar por cada um.

Delegação e atenuação: o confused deputy de sempre

O tenet 2 do NCCoE diz que, à medida que autoridade é delegada a sub-agentes, os escopos precisam se atenuar, de forma que a entidade downstream nunca reivindique mais autoridade do que a entidade pai:

À medida que a autoridade é delegada a sub-agentes ou serviços downstream, os escopos se atenuam, de forma que entidades downstream nunca possam reivindicar mais autoridade do que a entidade pai.

As authority is delegated down to sub-agents or downstream services, scopes attenuate so that downstream entities can never claim more authority than the parent.NCCoE, Design Tenets for Agentic Identity

O artigo aponta que esse é, ponto a ponto, o confused deputy problem, e que ele já é endêmico em cross-account trust na AWS, sem precisar de nenhum agente de IA no meio. Uma role que confia num account root principal de terceiro sem sts:ExternalId ou aws:SourceAccount fica exposta a qualquer cliente desse mesmo vendor. O autor cita o caso Midnight Blizzard, de 2024, contra a Microsoft: uma trust cross-tenant legada, sem binding por cliente, usada para pivotar de um tenant de teste até caixas de e-mail do Exchange em produção.

As propriedades que dá para checar direto na conta:

• Trust com terceiros tem proteção contra confused deputy: toda role que confia num root principal externo precisa ter sts:ExternalId ou aws:SourceAccount.
• Trust com service principal tem binding de origem: role que confia em um serviço da AWS precisa de aws:SourceArn ou aws:SourceAccount, senão qualquer conta que use aquele serviço pode assumi-la.
• Federação OIDC valida claim imutável: a trust policy precisa checar o sub, não só o issuer.
• ExternalId é único por relação de confiança: valor coringa não protege nada.

Privilégio mínimo: o ponto onde quase todo mundo falha

O tenet 3 pede zero standing privilege, o que exige provisionamento just-in-time que a maioria das empresas não tem. Mas o componente de least privilege, o escopo mínimo para a tarefa, já é verificável hoje, segundo o artigo, e é onde a maioria falha na prática.

Um exemplo concreto do próprio texto: uma execution role de Lambda com AmazonS3FullAccess numa função que só lê de um bucket. Combinada com uma function URL pública ou uma dependência comprometida, essa role vira o caminho de um comprometimento isolado para movimento lateral na conta inteira.

O autor chama atenção para uma categoria que a maioria das revisões de IAM ignora: enumeração de caminho de escalada de privilégio. Existem mais de vinte vetores conhecidos na AWS, combinando ações como iam:AttachRolePolicy, iam:PutRolePolicy, iam:CreatePolicyVersion e iam:PassRole com permissões específicas de serviço. Um dos exemplos citados: codebuild:StartBuild combinado com permissão de escrita no repositório fonte do projeto permite injetar um buildspec malicioso que roda sob a service role do CodeBuild, sem precisar de iam:PassRole nenhum, porque a role já está anexada ao projeto.

Credenciais curtas, decisão determinística, monitoramento e evidência

Os outros quatro tenets verificáveis completam o quadro:

• Tenet 4 (credenciais de vida curta): acesso serviço a serviço deve usar tokens STS temporários, certificados do IAM Roles Anywhere ou federação OIDC, nunca access key de longa duração. Sessão de SSO de 12 horas para uma tarefa de 30 minutos é standing privilege disfarçado de boa prática.
• Tenet 8 (decisões de acesso determinísticas): o NCCoE recomenda explicitamente não usar LLM para decidir autorização via raciocínio probabilístico, porque isso é manipulável por prompt injection. A camada determinística que sustenta isso já existe em SCP e trust policy; o que se verifica é se ela está protegida contra alteração pelas próprias entidades que ela deveria restringir.
• Tenet 9 (monitoramento contínuo): é o tenet mais extensamente verificável, porque cobre CloudTrail, API Gateway, ECS, Lambda, CodeBuild, Bedrock, S3, RDS, EKS, VPC Flow Logs e mais de uma dezena de outros serviços, cada um com logging que pode ser desligado de forma independente. O artigo destaca que o risco real está em estados compostos: uma trail parada, somada a ausência de Object Lock e à falta de alarme de StopLogging, cria um ponto cego de detecção que nenhum controle isolado revela sozinho.
• Tenet 10 (evidência imutável): é o de cobertura mais profunda. Validação de digest de log do CloudTrail, retenção além dos 90 dias padrão do Event History, replicação cross-account de logs e SCP negando StopLogging, DeleteTrail e UpdateTrail para qualquer role que não seja de breakglass.

A organização mantém uma cadeia de custódia ininterrupta e à prova de adulteração, além de um corpo de evidências somente para anexação.

The enterprise maintains an unbroken, tamper-evident chain of custody and append-only body of evidence.NCCoE, Design Tenets for Agentic Identity

Os quatro que ainda exigem infraestrutura nova

Nem tudo cabe em configuração hoje. O artigo lista quatro tenets fora do alcance de um verificador de IAM:

• Tenet 1, identificação distinta do agente: IAM de nuvem hoje não distingue uma role assumida por um agente de uma assumida por um serviço comum.
• Tenet 5, gatilhos de humano no loop: aprovação condicionada a risco exige camada de orquestração de workflow que nenhuma configuração de nuvem representa sozinha.
• Tenet 6, mandatos e restrições: artefatos assinados criptograficamente que delimitam o escopo da tarefa são infraestrutura nova; nenhum serviço de nuvem hoje consome esse tipo de documento.
• Tenet 7, separação arquitetural entre política e raciocínio: é sobre arquitetura de LLM, garantir que o pipeline de prompt não manipule a camada de credencial. É o mais importante dos dez para agentes, e o mais distante de uma checagem de configuração.

O que muda para quem responde por IAM, compliance e LGPD

Para quem desenha a conta AWS e responde por conformidade, a leitura prática do artigo é que a maior parte do trabalho de preparar a organização para agentes de IA não é esperar um padrão novo: é fechar lacunas de IAM e logging que já deveriam estar fechadas para humanos. Checar se toda trust policy tem condição de origem (sts:ExternalId, aws:SourceAccount ou aws:SourceArn), e aplicar uma SCP negando DeleteTrail e StopLogging para tudo que não for breakglass, é configuração de hoje, não roadmap.

O tenet 10 (evidência imutável) tem peso direto em obrigações de compliance e LGPD: cadeia de custódia de log, retenção além do padrão e replicação cross-account são exatamente o que um incidente envolvendo dado pessoal processado por um agente autônomo vai exigir na hora de provar, para um regulador ou auditor, o que o agente acessou e quando. Sem trilha, não há resposta a incidente defensável, só reconstrução.

O que fica em aberto

O artigo é claro sobre o limite: calibrar threshold de alerta para velocidade de máquina é problema de runtime, não de configuração. Um agente gera ordens de grandeza a mais de eventos que um humano; alerta calibrado para padrão humano ou satura de ruído ou perde o sinal. Isso nenhuma checagem estática resolve. A pergunta que o autor deixa para quem já roda IAM na AWS é direta: a configuração atual já satisfaz os seis tenets que ela poderia satisfazer, ou isso ainda está pendente de revisão?

Fonte

DEV Community, #aws: "The NCCoE Published 10 Design Tenets for Agentic Identity. Six of Them are Already Verifiable." Disponível em: https://dev.to/bala_paranj_059d338e44e7e/the-nccoe-published-10-design-tenets-for-agentic-identity-six-of-them-are-already-verifiable-21f8.

Fonte: DEV Community — #aws