Proteger agentes IA em produção: identidade e controle de acesso

Os primeiros assistentes IA implantados em empresas tinha um papel relativamente passivo. Respondiam a perguntas, resumiam documentos ou geravam conteúdo. Seu impacto se limitava à produção de informações.

As arquiteturas agentivas mudam completamente essa lógica.

Hoje, um agente pode abrir um ticket Jira, modificar um CRM, disparar um workflow CI/CD, enviar um e-mail, acionar um reembolso Stripe ou encadear várias chamadas de API de forma autônoma.

A partir do momento em que um agente age sobre sistemas reais, uma questão se torna inevitável:

Quem realmente está agindo?

Não é uma questão de provedor de modelo, framework ou protocolo. É uma questão de arquitetura.

---

Uma nova categoria de identidade

Durante anos, as arquiteturas de segurança se basearam em duas categorias de identidades:

• usuários humanos;
• identidades técnicas (aplicações, serviços, microsserviços).

Agentes IA não pertencem completamente a nenhuma dessas categorias.

Eles raciocinam, escolhem ferramentas, adaptam suas ações ao contexto e às vezes executam dezenas de operações sucessivas.

Constituem uma nova categoria de identidade que chamaremos neste artigo de identidade agentiva.

Definição

Uma identidade agentiva é o conjunto de informações que permite identificar um agente, determinar em nome de quem ele age, conhecer os limites de sua autonomia e reconstruir cada uma de suas decisões.

Esta definição servirá como fio condutor para o resto do artigo.

---

Uma chave API não é uma identidade

As primeiras implementações de agentes frequentemente seguem essa arquitetura.

Aplicação
      │
      ▼
 Chave API LLM
      │
      ▼
  Agente IA

Esta representação é prática.

Também é enganosa.

A chave API identifica sua aplicação junto ao provedor do modelo.

Não identifica o agente que age dentro do seu sistema de informações.

Dois agentes podem compartilhar a mesma chave API enquanto têm responsabilidades totalmente diferentes.

A identidade do agente pertence portanto à sua arquitetura, não ao provedor de modelos.

---

O modelo nunca realiza diretamente uma ação

Frequentemente ouve-se:

"Claude deletou um pedido."

ou

"GPT criou um reembolso."

Na realidade, um modelo de linguagem apenas emite uma proposta.

Sua infraestrutura então decide:

• se essa ação é autorizada;
• com quais permissões;
• para qual usuário;
• em quais recursos.

Usuário
      │
      ▼
Aplicação
      │
      ▼
Agent Runtime
      │
propõe uma ação
      ▼
Policy Engine
      │
      ▼
Ferramenta de negócio
      │
      ▼
Sistema alvo

Esta separação entre raciocínio e execução constitui um dos princípios fundamentais das arquiteturas agentivas modernas.

---

A verdadeira questão é a responsabilidade

Uma empresa deve poder responder, várias semanas após um incidente:

• Qual agente agiu?
• Para qual usuário?
• Em qual tenant?
• Qual política autorizou essa operação?
• Qual ferramenta foi invocada?

Um log indicando apenas:

"O modelo chamou updateCustomer()"

não traz praticamente nenhum valor.

Uma arquitetura moderna deve permitir reconstruir a integridade da cadeia de decisão.

---

Uma identidade é sempre contextual

O mesmo agente pode intervir:

• para vários usuários;
• em várias organizações;
• em vários ambientes;
• com permissões diferentes de acordo com a tarefa.

Sua identidade nunca se resume a um simples identificador.

Agente
 ├ identidade
 ├ usuário representado
 ├ tenant
 ├ ambiente
 ├ sessão
 └ permissões temporárias

O contexto é parte integrante da identidade.

---

As arquiteturas históricas não respondem a essa problemática

OAuth, OpenID Connect, Kubernetes Service Accounts ou identidades de workloads respondem principalmente a uma questão:

Qual componente está solicitando acesso a um recurso?

Agentes IA adicionam uma dimensão adicional:

Por que essa ação está sendo realizada, em nome de quem e dentro de quais limites?

É essa diferença que justifica uma nova camada de governança.

---

Antes de falar de JWT ou rbac

A maioria dos artigos começa imediatamente com as tecnologias:

• JWT;
• OAuth;
• RBAC;
• Vault;
• rotação de secrets.

Todas são importantes.

Mas chegam cedo demais.

Antes de escolher uma tecnologia, é preciso definir o que é a identidade de um agente e quais informações ela deve conter.

Este é precisamente o objetivo do capítulo seguinte, que introduz um Agent Identity Reference Model independente de fornecedores, frameworks e modelos de linguagem.

Para reter

Os modelos evoluirão.

Os frameworks mudarão.

Os protocolos aparecerão e desaparecerão.

Em contrapartida, toda arquitetura agentiva sempre terá que responder à mesma questão:

Quem realmente está agindo, em nome de quem, com quais permissões e sob qual controle?

Definição

Um Agent Identity Reference Model é um modelo conceitual descrevendo as informações mínimas que uma plataforma deve conhecer para identificar um agente, determinar em nome de quem ele age, decidir as ações que pode realizar e garantir a rastreabilidade completa de sua atividade.

Uma vez que se considera um agente como uma verdadeira identidade de software, uma nova questão aparece imediatamente:

De quais informações uma plataforma realmente precisa para autorizar um agente a agir?

A maioria das implementações responde com uma lista de mecanismos técnicos: um JWT, uma chave API, algumas permissões e às vezes um papel RBAC.

Na realidade, esses mecanismos apenas expressam parte da identidade. Para que um agente possa agir com segurança, é preciso responder a várias questões independentes.

Visão geral

Camada	Pergunta	Exemplos de tecnologias
Identity	Quem é esse agente?	UUID, SPIFFE ID
Authentication	Ele consegue provar sua identidade?	JWT, OAuth 2.0, mTLS
Delegation	Em nome de quem ele age?	OAuth, OIDC
Authorization	O que ele pode fazer?	RBAC, ABAC, Cedar, OPA
Secrets	Como ele acessa recursos?	Vault, AWS Secrets Manager
Observability	Pode-se explicar cada decisão?	OpenTelemetry
Revocation	Pode-se pará-lo imediatamente?	Token revocation

As camadas são independentes

Um erro frequente é misturar várias responsabilidades.

Um JWT não decide as permissões. Um motor de políticas não prova a identidade. Um gestor de secrets não autoriza nenhuma ação.

Cada camada responde a uma responsabilidade única. Esta separação permite substituir uma tecnologia sem questionar a arquitetura geral.

Esquema do modelo

                         Identity
                              │
            ┌─────────────────┴─────────────────┐
            │                                   │
    Authentication                    Delegation
            │                                   │
            └─────────────────┬─────────────────┘
                              ▼
                      Authorization
                              │
             ┌────────────────┴────────────────┐
             │                                 │
         Secret Access                 Observability
             │                                 │
             └────────────────┬────────────────┘
                              ▼
                         Revocation

Identity não é authentication

Esses dois conceitos são frequentemente confundidos.

A identidade descreve quem é o agente.

A autenticação verifica que ele é realmente quem pretende ser.

Estar autenticado nunca significa estar autorizado.

As seis camadas

1. Identity

Cada agente possui um identificador estável, uma versão, um proprietário e um ambiente de execução.

agent:
  id: support-agent
  version: 2.3.1
  owner: customer-support
  environment: production

2. Authentication

A autenticação permite provar essa identidade por meio de um JWT, OAuth, mTLS ou uma identidade de workload.

3. Delegation

Um agente raramente age por sua própria conta. Ele age por um usuário, um tenant ou um processo de negócio.

4. Authorization

As autorizações modernas dependem cada vez mais de motores de políticas.

Os principais modelos são:

• RBAC
• ABAC
• PBAC
• ReBAC

As arquiteturas agentivas geralmente privilegiam PBAC, capaz de avaliar o contexto de execução.

Exemplo Node.js:

const decision = await policyEngine.evaluate({
  identity,
  tool: "refundOrder",
  amount: 75,
  tenant: "acme",
});

if (!decision.allow) {
  throw new ForbiddenError(decision.reason);
}

await refundOrder();

5. Secrets

O modelo nunca manipula diretamente os secrets.

Ele expressa uma intenção; a aplicação recupera os secrets junto a um gerenciador dedicado.

6. Observability

Cada decisão deve ser rastreável: identidade, usuário representado, política aplicada, resultado e duração de execução.

7. Revocation

Toda identidade deve ser desativável imediatamente para impedir qualquer nova ação.

Para reter

Os modelos mudam.

Os frameworks evoluem.

Os protocolos aparecem e desaparecem.

Em contrapartida, uma arquitetura sempre terá que responder às mesmas questões:

• Quem está agindo?
• Em nome de quem?
• O que pode fazer?
• Como proteger os recursos?
• Como explicar as decisões?
• Como parar imediatamente esse agente?

Contanto que essas questões encontrem uma resposta, sua arquitetura permanecerá válida independentemente do provedor de modelos ou do framework utilizado.

O Agent Identity Reference Model apresentado no capítulo anterior é intencionalmente independente das tecnologias.

Ele responde a uma questão de arquitetura:

Quais informações precisam ser manipuladas para proteger um agente?

Este capítulo responde a outra questão:

Como implementar concretamente esse modelo em uma aplicação moderna?

A boa notícia é que não é necessário inventar uma nova pilha de segurança. A maioria das empresas já possui os componentes necessários.

Uma arquitetura de referência

                  Usuário
                        │
                        ▼
              Identity Provider
                        │
                        ▼
             Aplicação de negócio
                        │
                        ▼
                 Agent Runtime
        ┌───────────────┼────────────────┐
        ▼               ▼                ▼
 Policy Engine   Secret Manager    Observability
        │
        ▼
    Tool Gateway
        │
   ┌────┼───────────────┐
   ▼    ▼               ▼
 CRM PostgreSQL      Stripe

O modelo de linguagem não é intencionalmente o centro do esquema.

Ele produz propostas.

O runtime aplica as políticas de segurança.

O runtime se torna o ponto de controle

Cada chamada de ferramenta deve ser tratada como uma decisão de segurança.

Antes de executar uma ação, o runtime deve responder a várias questões:

• Quem é o agente?
• Para qual usuário ele age?
• Qual tenant está envolvido?
• Essa ação é autorizada?
• Os limites de segurança estão sendo respeitados?

Em outras palavras, o runtime se torna um Policy Enforcement Point (PEP).

Um middleware node.js em vez de lógica dispersa

Uma boa prática é centralizar os controles.

export async function authorizeTool(ctx, toolName) {

  const decision = await policyEngine.evaluate({
    identity: ctx.identity,
    tool: toolName,
    tenant: ctx.tenant,
    delegatedUser: ctx.user.id
  });

  if (!decision.allow) {
    throw new ForbiddenError(decision.reason);
  }

  return decision;
}

Então cada ferramenta usa esse middleware.

server.registerTool({
  name: "refundOrder",

  async execute(args, ctx) {

    await authorizeTool(ctx, "refundOrder");

    return refundService.execute(args);
  }
});

Desta forma, as regras de segurança permanecem independentes do modelo e do prompt.

Um JWT transporta uma identidade, não decide nada

Um JWT pode conter informações úteis:

{
  "agent":"support-agent",
  "tenant":"acme",
  "delegatedUser":"user-482",
  "scope":["orders.read","orders.update"]
}

Mas um JWT nunca responde à questão:

Essa operação é autorizada agora?

Esta decisão sempre pertence ao motor de políticas.

As permissões são avaliadas a cada ação

Em uma arquitetura agentiva, as permissões não são fixadas no momento da conexão.

Cada chamada de ferramenta constitui uma nova decisão.

Por exemplo, um reembolso pode depender de:

• do montante;
• do tenant;
• do papel do usuário representado;
• do ambiente;
• da política de risco.

O runtime deve portanto consultar um motor de políticas antes de cada operação sensível.

As ferramentas representam capacidades de negócio

Evite expor primitivas técnicas diretamente.

A evitar:

executeSQL()
executeShell()
deleteCustomer()

Prefira ferramentas que expressem uma intenção de negócio.

findCustomer()
refundOrder()
updateShippingAddress()
generateInvoice()

Esta abordagem reduz significativamente a superfície de ataque e simplifica as políticas de autorização.

Os secrets nunca saem da infraestrutura

O modelo nunca deveria receber uma chave Stripe, uma senha PostgreSQL ou um token AWS.

O runtime recupera esses secrets junto a um gerenciador dedicado.

import Stripe from "stripe";

const stripe = new Stripe(
  await secretManager.get("stripe-API-key")
);

O modelo expressa uma intenção.

A aplicação realiza a chamada técnica.

MCP não substitui os controles

O Model Context Protocol (MCP) padroniza a descoberta e invocação de ferramentas.

Nunca decide se uma ferramenta pode ser usada.

Mesmo que um servidor MCP exponha:

deleteAllCustomers()

a decisão final sempre pertence a:

• ao runtime;
• ao motor de políticas;
• à sua arquitetura.

MCP descreve as capacidades.

Sua plataforma decide quais são realmente acessíveis.

Build ou buy?

Nem todas as equipes têm as mesmas necessidades.

Tamanho do projeto	Recomendação
Protótipo	Regras codificadas no runtime
Alguns agentes	RBAC simples
Multi-tenant	Policy Engine
Organização regulada	Cedar, OPA ou solução equivalente

A transição para um motor de políticas se justifica quando as regras se tornam numerosas, evolutivas ou compartilhadas entre vários agentes.

Uma arquitetura duradoura

Um dos principais benefícios dessa abordagem é sua independência em relação aos fornecedores.

Você pode substituir:

• Claude por GPT;
• GPT por Gemini;
• LangGraph por CrewAI;
• MCP por outro protocolo.

A arquitetura de segurança permanece inalterada.

Seu runtime, suas políticas, seus secrets e seus logs de auditoria pertencem ao seu sistema de informações.

Constituem a verdadeira camada de confiança de sua plataforma.

Para reter

O modelo de linguagem nunca é a autoridade de segurança.

Ele propõe ações.

Sua infraestrutura decide se podem ser executadas.

Neste ponto, uma arquitetura moderna dispõe de:

• uma identidade para cada agente;
• um mecanismo de autenticação;
• um motor de políticas;
• uma gestão centralizada de secrets.

Esses componentes são necessários, mas não são suficientes.

Uma arquitetura é realmente segura apenas se puder ser auditada, explicada e interrompida a qualquer momento.

A auditoria não é mais um simples arquivo de logs

Em um sistema agentivo, não basta registrar que um endpoint foi chamado.

Cada decisão importante deveria produzir um evento rastreando:

• a identidade do agente;
• o usuário representado;
• o tenant;
• a ferramenta solicitada;
• a política aplicada;
• a decisão (ALLOW ou DENY);
• o resultado da execução.

Exemplo:

{
  "timestamp": "2026-07-17T10:48:31Z",
  "agent": "support-agent",
  "delegatedUser": "user-482",
  "tenant": "acme",
  "tool": "refundOrder",
  "decision": "ALLOW",
  "policy": "refund-policy-v3",
  "durationMs": 91
}

Esses eventos permitem reconstruir uma decisão várias semanas após sua execução.

Os anti-padrões mais frequentes

1. Uma chave API compartilhada

Todos os agentes usam a mesma identidade.

Consequência: impossível saber qual é responsável.

2. Secrets transmitidos ao modelo

Uma chave Stripe ou uma senha SQL nunca devem aparecer no contexto enviado ao LLM.

3. Permissões definidas no prompt

Um prompt não constitui um mecanismo de segurança.

As regras de autorização devem ser implementadas no lado da infraestrutura.

4. Ferramentas muito genéricas

Evite:

executeSQL()
executeShell()

Prefira:

createInvoice()
updateShippingAddress()

As ferramentas devem representar intenções de negócio.

Uma checklist de auditoria

Antes de uma implantação em produção, verifique em particular:

• Cada agente possui uma identidade única?
• Os usuários representados são identificados?
• As autorizações são avaliadas antes de cada chamada de ferramenta?
• Os secrets estão armazenados em um Secret Manager?
• Cada decisão é registrada em log?
• Um agente pode ser revogado imediatamente?
• As ferramentas expõem capacidades de negócio em vez de primitivas técnicas?

Se uma resposta for negativa, a arquitetura provavelmente merece ser revisada.

Zero trust aplicado aos agentes

Os princípios Zero Trust permanecem perfeitamente adequados para arquiteturas agentivas.

Cada requisição deve ser:

• autenticada;
• autorizada;
• rastreada;
• limitada ao estritamente necessário.

Nenhum agente deveria ser considerado implicitamente confiável.

Perguntas frequentes

É necessário um JWT por agente?

Não necessariamente.

O importante é que cada execução tenha uma identidade autenticável e contextualizada.

Rbac é suficiente?

Para um protótipo, geralmente sim.

Para vários agentes, vários tenants ou regras dinâmicas, um motor de políticas rapidamente se torna preferível.

MCP protege as ferramentas?

Não.

MCP descreve as ferramentas disponíveis.

Os controles de acesso continuam a cargo de sua plataforma.

O modelo deve conhecer os secrets?

Nunca.

O modelo formula uma intenção.

O runtime realiza as chamadas técnicas com suas próprias identidades.

Conclusão

Durante muito tempo, a segurança das aplicações se organizou em torno de usuários e serviços.

As arquiteturas agentivas introduzem uma terceira categoria de identidade: o agente autônomo.

Esta evolução impõe repensar várias fundações:

• a identidade;
• a delegação;
• a autorização;
• a gestão de secrets;
• a observabilidade;
• a revogação.

As tecnologias continuarão a evoluir.

Os modelos de linguagem serão substituídos.

Os frameworks mudarão.

Em contrapartida, as questões fundamentais permanecerão as mesmas:

• Quem está agindo?
• Em nome de quem?
• Com quais permissões?
• Como explicar cada decisão?
• Como interromper imediatamente um agente?

As organizações capazes de respondê-las terão uma arquitetura duradoura, independente dos provedores de modelos e suficientemente robusta para evoluir seus sistemas agentivos ao longo do tempo.