Da identidade cloud à comprovação dinâmica de workloads: como uma arquitetura apresentada pela Netflix aponta para uma nova geração de segurança de identidades não humanas.

Durante décadas, a segurança de identidades corporativas concentrou-se principalmente em pessoas. Funcionários, parceiros e fornecedores precisavam ser identificados, autenticados e autorizados antes de acessar sistemas e informações.

Com a expansão da computação em nuvem, dos microsserviços, das arquiteturas distribuídas e, mais recentemente, dos agentes de inteligência artificial, esse modelo começou a enfrentar um desafio muito maior.

Hoje, uma parcela crescente das interações entre sistemas acontece sem qualquer intervenção humana.

Aplicações conversam com APIs, containers executam processos automaticamente, pipelines acessam dados sensíveis e agentes de IA começam a tomar decisões e executar operações em nome de usuários e organizações.

Nesse cenário, surge uma pergunta fundamental:

Como garantir que uma máquina, aplicação ou agente de IA é realmente quem afirma ser?

Uma arquitetura de Workload Attestation apresentada pela Netflix oferece uma perspectiva importante sobre como responder a essa questão.

O problema: possuir uma credencial não significa comprovar uma identidade

Tradicionalmente, aplicações e serviços utilizam mecanismos como API Keys, certificados digitais, secrets, service accounts e credenciais de provedores cloud para acessar recursos corporativos.

Esses mecanismos são essenciais, mas apresentam uma limitação importante: muitas vezes, a autenticação comprova apenas que determinada entidade possui uma credencial válida.

Isso não significa necessariamente que a organização tenha confirmado o contexto completo daquela execução.

Imagine um serviço executado na AWS utilizando uma IAM Role com permissão para acessar determinados recursos.

A AWS consegue identificar o principal associado à credencial utilizada. Entretanto, essa informação pode não ser suficiente para responder a perguntas corporativas mais amplas:

• Qual aplicação está executando?
• Quem é o responsável por essa aplicação?
• Qual processo de negócio justificou sua execução?
• A identidade utilizada corresponde à execução autorizada?
• Quais recursos internos essa aplicação deveria acessar?

A diferença é importante.

Uma identidade de infraestrutura não representa necessariamente uma identidade corporativa completa.

E, à medida que sistemas se tornam mais autônomos, essa distinção passa a ser um requisito fundamental de segurança.

O que a Netflix fez de diferente?

Em outubro de 2026, uma publicação do InfoQ destacou uma arquitetura utilizada pela Netflix para conectar identidades da AWS ao seu ecossistema interno de identidade.

O desafio envolvia workloads de processamento de dados executados em ambientes gerenciados, como o Amazon EMR, utilizando Apache Spark.

Esses workloads possuíam identidades AWS, mas também precisavam acessar serviços internos protegidos por mecanismos próprios de autenticação.

Em vez de depender exclusivamente das credenciais fornecidas pela infraestrutura, a Netflix desenvolveu um mecanismo para comprovar a correspondência entre a identidade AWS e o contexto autorizado da execução.

A solução combina duas evidências principais.

A primeira é uma prova associada à identidade AWS, utilizando o serviço AWS Security Token Service (STS).

A segunda consiste em metadados assinados pelo plano de controle da Netflix, representando informações autorizadas sobre o workload.

O serviço de identidade valida essas evidências e verifica se a identidade AWS apresentada corresponde à identidade esperada para aquela execução.

Somente após essa validação é possível obter uma identidade corporativa, materializada em um certificado digital temporário emitido pela infraestrutura interna de PKI da Netflix, conhecida como Metatron.

Esse certificado permite que o workload se autentique perante serviços internos, utilizando mecanismos como mutual TLS (mTLS).

A mudança conceitual é significativa.

O workload não recebe simplesmente uma identidade porque está executando em determinada infraestrutura. Ele precisa apresentar evidências verificáveis de que corresponde à execução autorizada.

Workload Attestation: uma nova camada de confiança

O conceito de Workload Attestation representa uma evolução importante na forma como organizações estabelecem confiança entre sistemas.

Em uma arquitetura tradicional, uma aplicação pode receber credenciais durante sua implantação e continuar utilizando-as durante longos períodos.

Em uma arquitetura baseada em atestação, a emissão de identidade pode depender de uma validação dinâmica do contexto de execução.

Isso permite separar três elementos que frequentemente são tratados como uma única coisa:

Identidade de infraestrutura: representa o ambiente ou principal técnico sob o qual determinado processo executa.

Identidade corporativa: representa a aplicação, serviço ou workload reconhecido pela organização.

Autorização: determina quais recursos e operações aquela identidade pode acessar ou executar.

Essa separação permite criar arquiteturas mais flexíveis e reduzir a dependência de credenciais estáticas.

Também aproxima a segurança de workloads dos princípios de Zero Trust, nos quais a confiança não deve ser concedida exclusivamente com base na localização de rede ou no ambiente de execução.

Entretanto, é importante observar que a atestação não substitui controles de autorização, monitoramento ou análise de comportamento.

Ela estabelece uma base mais confiável para identificar o workload que está solicitando acesso.

O impacto sobre Non-Human Identity

O crescimento das identidades não humanas, conhecidas como Non-Human Identities (NHI), está transformando o escopo tradicional do Identity and Access Management.

Durante muitos anos, plataformas IAM e IGA foram desenvolvidas principalmente para administrar identidades humanas e suas relações com aplicações corporativas.

O universo NHI apresenta características diferentes.

Uma única organização pode possuir milhares de service accounts, aplicações, certificados, workloads, pipelines, integrações e processos automatizados.

Essas identidades podem surgir e desaparecer rapidamente, executar em diferentes ambientes e acessar recursos com elevados níveis de privilégio.

O problema não é apenas descobrir quantas identidades existem.

É compreender quais estão efetivamente em utilização, quem responde por elas, como são autenticadas e se seus privilégios continuam adequados.

Nesse contexto, Workload Attestation adiciona uma capacidade importante ao ecossistema IAM.

Em vez de considerar apenas a existência de uma credencial ou de uma identidade cadastrada, a organização passa a ter condições de exigir evidências sobre a execução que pretende utilizar aquela identidade.

Isso não elimina a necessidade de inventário, gestão do ciclo de vida, revisões de acesso ou segregação de funções.

Pelo contrário, torna essas capacidades ainda mais relevantes.

A atestação fortalece a autenticação, enquanto a governança continua responsável por definir quais identidades deveriam existir e quais permissões deveriam possuir.

A próxima evolução: identidade para agentes de inteligência artificial

A relevância dessa arquitetura torna-se ainda maior quando consideramos a evolução dos agentes de IA.

Diferentemente de uma aplicação tradicional, que normalmente executa operações previamente definidas, um agente de inteligência artificial pode interpretar objetivos, selecionar ferramentas, consultar informações e executar diferentes ações durante uma mesma sessão.

Imagine um agente responsável por investigar incidentes de segurança.

Durante uma investigação, ele pode precisar consultar logs, acessar plataformas IAM, verificar alterações de privilégios, consultar sistemas de tickets e produzir recomendações.

Em cenários mais avançados, esse agente também poderia executar determinadas ações corretivas, desde que devidamente autorizadas.

Isso cria um problema de identidade e governança que não pode ser resolvido apenas com uma API Key.

A organização precisa responder a questões como:

• Qual agente está executando determinada operação?
• Quem é o proprietário ou responsável pelo agente?
• Em qual ambiente ele foi iniciado?
• Quais ferramentas está autorizado a utilizar?
• Quais permissões são necessárias para sua tarefa?
• Como comprovar que uma chamada foi realizada por uma execução legítima?
• Como revogar rapidamente o acesso em caso de comprometimento?

Uma arquitetura inspirada em Workload Attestation poderia ajudar a estabelecer essa base de confiança.

Antes de receber credenciais para acessar ferramentas corporativas, a execução do agente poderia apresentar evidências sobre sua identidade técnica, seu ambiente e sua autorização de execução.

Após a validação, um serviço de identidade poderia emitir credenciais temporárias associadas àquela execução.

Um mecanismo independente de autorização continuaria responsável por decidir quais operações seriam permitidas.

Essa distinção é fundamental.

Comprovar quem é o agente não significa autorizar tudo o que ele deseja fazer.

A autenticação estabelece a identidade. A autorização determina os limites de atuação.

A relação com MCP e ferramentas corporativas

O crescimento do Model Context Protocol (MCP) amplia a importância dessa discussão.

O MCP facilita a integração entre aplicações de inteligência artificial e ferramentas externas, permitindo que agentes interajam com diferentes fontes de dados e serviços.

Entretanto, disponibilizar uma ferramenta por meio de MCP não resolve automaticamente os desafios de identidade, autorização e governança.

Um servidor MCP pode oferecer acesso a informações financeiras, plataformas de identidade, sistemas de atendimento ou ambientes de infraestrutura.

Antes de permitir determinadas operações, a organização precisa compreender não apenas qual usuário está associado à solicitação, mas também qual aplicação ou agente está realizando a chamada e sob qual contexto.

Nesse cenário, uma arquitetura madura poderia combinar:

• Workload Identity para identificar a execução técnica.
• Workload Attestation para validar evidências sobre essa execução.
• OAuth 2.0 e tokens de curta duração para delegação e acesso a APIs.
• Políticas de autorização para controlar operações e recursos.
• Identity Governance para administrar proprietários, responsabilidades, permissões e ciclo de vida.
• Auditoria para registrar decisões e ações realizadas.

A atestação não substitui o modelo de autorização do MCP nem seus mecanismos de autenticação.

Ela pode funcionar como uma camada complementar, permitindo que sistemas corporativos estabeleçam maior confiança sobre as aplicações e agentes que solicitam acesso.

Tecnologias abertas podem acelerar essa transformação

Embora a implementação apresentada pela Netflix utilize componentes de sua própria infraestrutura, o conceito pode ser aplicado utilizando tecnologias disponíveis no mercado.

Projetos como SPIFFE e SPIRE oferecem mecanismos padronizados para estabelecer identidades de workloads em ambientes distribuídos.

Soluções de PKI e gerenciamento de secrets podem participar da emissão e renovação de credenciais temporárias.

Ferramentas de autorização, como Open Policy Agent (OPA) e Cerbos, podem ajudar a centralizar decisões de acesso baseadas em políticas.

Plataformas de IAM e IGA, por sua vez, podem administrar o relacionamento entre workloads, proprietários, aplicações e permissões.

O desafio está em integrar essas capacidades em uma arquitetura coerente.

Não basta implementar certificados temporários ou substituir API Keys por outro mecanismo de autenticação.

É necessário estabelecer um modelo de confiança que considere a identidade, o contexto de execução, a autorização e a rastreabilidade.

Também será necessário lidar com desafios operacionais, como disponibilidade dos serviços de identidade, renovação de credenciais, revogação, proteção das chaves privadas e comprometimento dos ambientes de execução.

O IAM precisa evoluir de contas para identidades de execução

Talvez a principal transformação esteja na própria definição de identidade corporativa.

Historicamente, grande parte dos processos de IAM foi organizada em torno de contas persistentes.

Uma identidade era criada, recebia permissões, passava por revisões periódicas e eventualmente era desativada.

Esse modelo continua válido para muitas situações, especialmente identidades humanas e contas técnicas tradicionais.

Mas workloads modernos podem existir durante poucos minutos.

Um container pode ser criado para executar uma tarefa específica e destruído logo em seguida.

Um pipeline pode receber acesso temporário apenas durante determinada etapa.

Um agente de IA pode executar centenas de operações em uma sessão e nunca mais ser utilizado.

Nesse contexto, governar somente contas persistentes é insuficiente.

O IAM precisa incorporar conceitos como identidade efêmera, contexto de execução, credenciais de curta duração, autorização dinâmica e comprovação de identidade.

Isso não significa abandonar os fundamentos de Identity Governance.

Significa aplicar esses fundamentos a um universo de identidades muito mais dinâmico.

Conclusão: a confiança precisa ser comprovada

A arquitetura apresentada pela Netflix demonstra que a integração entre identidade cloud e identidade corporativa pode ir além do simples compartilhamento de credenciais.

Ao exigir evidências verificáveis antes de emitir uma identidade interna, a organização estabelece uma fronteira de confiança mais explícita entre infraestrutura e aplicações.

Essa abordagem é especialmente relevante em um momento em que workloads, automações e agentes de inteligência artificial assumem responsabilidades cada vez maiores dentro das empresas.

O futuro do IAM não será definido apenas pela capacidade de criar, modificar ou remover contas.

Será definido também pela capacidade de reconhecer identidades não humanas, validar suas execuções, limitar seus privilégios e acompanhar continuamente suas atividades.

Em um ambiente onde máquinas começam a executar ações com crescente autonomia, possuir uma credencial válida já não deveria ser considerado suficiente para estabelecer confiança.

A próxima geração do IAM precisará responder não apenas quem está solicitando acesso, mas também como essa identidade foi comprovada, em qual contexto está operando e por que aquela execução deveria ser autorizada.

Essa é uma das bases para construir ambientes digitais mais seguros, auditáveis e preparados para a era dos agentes de inteligência artificial.

Referências

• InfoQ — Netflix Bridges AWS IAM and Internal Identity with Workload Attestation (outubro de 2026).
• Netflix Technology Blog — Trading a Cloud Identity for Your Own: Workload Attestation on Managed Compute.
• SPIFFE / SPIRE — Padrões e infraestrutura para identidade de workloads.
• IETF WIMSE — Workload Identity in Multi-System Environments.