Protegendo a Enterprise agêntica: o projeto em prática

Agentes são poderosos. Eles também são uma superfície de ataque.

Um agente de IA é tão útil quanto os sistemas aos quais se permite que ele acesse. Os funcionários que realmente agregam valor estão aprovando reembolsos, registrando transações e alterando cadastros de clientes nos sistemas que o senhor protege com mais cuidado, acessados através de conectores SaaS, servidores Model Context Protocol (MCP) e APIs. 

Para agir, um agente deve ser confiável pelos sistemas que nunca conheceu, em nome de outra pessoa, sem que haja qualquer supervisão humana no momento da decisão. Um único agente sob supervisão é fácil de entender e controlar (Figura 1). 

O problema começa quando os agentes passam de pilotos para produção e a adoção se expande por toda a empresa. Uma conexão supervisionada se torna milhares de conexões não supervisionadas. A autoridade concedida a cada um é definida uma vez e de forma abrangente, resultando em um caos de acesso (Figura 2).

Um agente. Muitas ferramentas e recursos.

Cada link alcança os dados de seus clientes, seu IP e os sistemas operacionais que executam seus negócios.

Usuários × agentes × conversas × ferramentas = Caos de acesso

Cada link é uma superfície de ataque. A autorização deve governar cada um, em cada chamada, em velocidade de máquina.

Esse caos parece uma ameaça à segurança, mas não chega da maneira usual. Os agentes não invadem. Eles são criados, conectados ou recebem acesso, e quando o tráfego chega a um firewall, o agente já está dentro dele.

A verdadeira questão é o que acontece a seguir: 

• Qual é o agente?
• Quem autorizou o senhor?
• O que ele pode alcançar? 
• O que poderia ser feito para esta tarefa? 
• Como podemos revogar o acesso?

Essas são questões de identidade e autorização e, embora escopos amplos possam ser determinados antecipadamente, elas não podem ser respondidas de antemão; decisões por tarefa devem ser tomadas em tempo de execução. A autoridade de um agente deve ser determinada no momento da ação, com base nas identidades humana e do agente. Isso garante que a autorização tenha o escopo preciso para a tarefa e que o responsável seja vinculado a cada solicitação. Este princípio fundamental serve como base para toda a arquitetura.

O projeto de segurança existe. O orçamento não permite.

A mudança já é visível na vanguarda. Recentemente, a Uber publicou um relato detalhado de como atribuiu uma identidade real aos seus agentes, optando por uma identidade criptográfica e uma troca de tokens por etapa que transporta a cadeia de atores desde o humano até a ferramenta. É uma forte validação de que o problema é real e a arquitetura é conhecida. Isso também exigiu uma organização de engenharia que a maioria das empresas jamais terá, construída e operada internamente. 

A lição que vale a pena tirar é sobre padrões: uma camada de identidade para agentes só se mantém se ela viajar pelas fronteiras de fornecedores e SaaS que os agentes cruzam constantemente, o que significa que ela deve ser construída usando padrões consistentes que cada parte implementa da mesma forma e entregue como uma camada, em vez de ser projetada empresa por empresa. Isso é o Okta for AI Agents.

Como a Okta protege a empresa agêntica

Okta for AI Agents transforma esse princípio em uma camada operacional: identidade verificável para cada agente, autorização decidida no momento da ação e o humano responsável mantido em toda a cadeia. O restante deste artigo explica a arquitetura usando uma Enterprise como exemplo.

Uma implementação típica de empresa agêntica 

Para tornar essa hipótese concreta, vamos pegar a Streamward Inc., uma composição das empresas com as quais trabalhamos. Um usuário faz uma solicitação por meio de um assistente de chat, e um orquestrador de agente mestre analisa a intenção e delega subtarefas pela malha por capacidade de negócios (Figura 3). Para acessar sistemas a jusante, APIs proprietárias e serviços de terceiros, os agentes usam uma combinação de tipos de recursos de tempo de execução: servidores MCP, endpoints REST governados por especificações OpenAPI e data warehouses nativos da nuvem.

Exemplo de arquitetura de malha multiagente

• Salesforce Agentforce: Lida com a análise do pipeline de CRM, pontuação de leads e pesquisas de contas.
  • Servidor MCP conectado: cruza informações dos IDs de contas do Salesforce com o faturamento em tempo real por meio de um servidor MCP de ERP corporativo, chamando get_customer_payment_history.
• Amazon Bedrock AgentCore: Executa a geração aumentada de recuperação (RAG) sobre o conhecimento corporativo.
  • Servidor MCP conectado: Conecta-se a um banco de dados de vetores AWS Aurora PostgreSQL através do MCP para executar pesquisas semânticas, chamando query_knowledge_base e fetch_unstructured_contract_pdf.
• Google Vertex AI: Runtimes de baixo código impulsionando fluxos de trabalho autônomos do cliente.
  • Gateway OpenAPI conectado: direciona chamadas por meio de um gateway Workday e ServiceNow compatível com OpenAPI, chamando read_latest_incident_tickets e acionando create_workday_expense_claim.

As quatro falhas de segurança comuns na implementação

Agora, vamos traçar uma solicitação comum através desta malha para destacar as lacunas de segurança comuns: uma consulta de base de conhecimento corporativa que deve alcançar o banco de dados. Sem uma estrutura de identidade central, ele falha de quatro maneiras, como visto no token que o agente carrega (Figura 4). A lacuna está no que falta ao token.

Shadow IA 

Agentes internos ou de terceiros em execução no Amazon Bedrock AgentCore são frequentemente configurados ou implementados por equipes sem registrá-los por meio do provedor de identidade (IdP). Como um SDK de segurança não é injetado nesses ambientes, os agentes são iniciados dinamicamente e se conectam a recursos internos nas bordas das políticas de acesso corporativo. Seus tokens brutos mostram um cliente de máquina, mas carecem de uma declaração iss (emissor), sem validação humana por trás deles e nenhum proprietário responsável por seu ciclo de vida. Simplesmente não se pode governar um agente Bedrock que nunca foi emitido.

Over-privileged Access 

A declaração scope no token de um agente não gerenciado expõe um risco excessivo. Para permitir que o agente Bedrock se conecte ao banco de dados de destino sem interromper constantemente o fluxo de execução para reautenticar através das fronteiras do sistema, os desenvolvedores tendem a atribuir o agente a uma conta de serviço ampla e de longa duração. O escopo do token abrange uma área administrativa permanente e ampla, muito além do que uma consulta de texto específica precisa. Cada escopo superdimensionado cria um caminho de acesso vulnerável à injeção de prompts ou exfiltração de dados, mas revogar o agente interrompe todos os outros fluxos de trabalho automatizados que compartilham essa única conta de serviço.

Representação, não delegação

À medida que a pesquisa cruza do Bedrock AgentCore para o servidor Aurora DB MCP de destino, a identidade entra em colapso completo em um principal de máquina genérico. O mecanismo de banco de dados registra uma conta de serviço chamando query_knowledge_base(), sem a identidade do operador humano que iniciou a tarefa e o subagente específico que executa a consulta. Sem a linhagem de delegação criptográfica dentro do token, o limite do recurso não pode impor permissões de dados no nível do usuário, resultando em apagamento completo da identidade e uma trilha de auditoria comprometida.

Sem governança

Quando o agente aciona a invocação de uma ferramenta ou uma leitura inesperada do banco de dados, o token de máquina não gerenciada não carrega nem a identidade da transação nem o contexto de consentimento humano. A ação é executada perfeitamente, sem pausa no tempo de execução para aprovação, deixando as equipes de segurança totalmente desinformadas. Após o ocorrido, torna-se impossível vincular criptograficamente a transação automatizada a um controlador humano, o que significa que não se pode provar legalmente quem autorizou qual movimentação de dados.

A maioria das empresas corrige um ou dois desses.

As quatro falhas de segurança comuns observadas no token

Tenha essa solicitação em mente. O passo a passo mais adiante nesta postagem mostra o agente Agentcore acessando a ferramenta Aurora DB MCP, desta vez com o Okta no caminho, e obtém sucesso sem nenhuma das quatro falhas.

O Okta for AI Agents aborda as falhas de segurança 

Okta transforma o limite de confiança em uma camada de governança incorporada no caminho de execução (Figura 5). O Streamward encaminha todo o tráfego MCP por meio de um Gateway de Agente de Tempo de Execução embutido, o ponto de aplicação de políticas (PEP), com o Okta como ponto de decisão de políticas (PDP) em segundo plano. O agente nunca possui uma credencial bruta para as ferramentas MCP. Esta é a ideia de plano de controle materializada: cada solicitação para em um ponto que conhece as identidades envolvidas e decide, no momento, o que é permitido.

Arquitetura de malha multiagente de amostra com Okta para Agentes de IA

O fluxo de acesso seguro, passo a passo

A solicitação final que chega a qualquer ferramenta de back-end inclui uma identidade verificável que contém tanto o contexto humano (a declaração sub) quanto o principal da carga de trabalho do agente (a declaração act). 

Aqui está a mesma consulta da base de conhecimento de antes, agora executada através do Okta. O diagrama abaixo traça o processo de ponta a ponta, e os saltos que se seguem percorrem cada etapa, mostrando como o token é construído e trocado ao longo do caminho (Figura 6).

O fluxo de acesso seguro de ponta a ponta

A solicitação final que chega a qualquer ferramenta de back-end carrega uma identidade verificável, contendo tanto o contexto humano (a declaração sub) quanto o principal da carga de trabalho do agente (a declaração cid). 

Salto 1: usuário humano para o front-end

O usuário faz login no portal da Streamward através de um fluxo OpenID Connect (OIDC), e o Okta emite um token de acesso de usuário padrão.

Etapa 2: do front-end para o orquestrador

O front-end lida com o prompt em linguagem natural e passa o contexto da tarefa para o orquestrador do agente mestre, carregando o token de acesso do usuário como token bearer.

Etapa 3: orquestrador para Okta, troca A2A

O orquestrador determina que a tarefa precisa de processamento analítico no Bedrock AgentCore por meio do agente Corp-Knowledge-Agent. Ele envia o token do usuário e o escopo solicitado para o endpoint de token do Okta (/oauth2/v1/token) e inicia o fluxo de Acesso entre Aplicativos (XAA) (Concessão de Autorização de Declaração de Identidade). Okta avalia a política de acesso do agente e retorna um token ID-JAG de curta duração e uso único (urn:ietf:params:oauth:token-type:id-jag), com escopo restrito à tarefa.

Etapa 4: Orquestrador para Okta, troca de token

O orquestrador cria uma afirmação do cliente com a chave privada do orquestrador e troca o token ID-JAG no servidor de autorização personalizado atribuído ao agente Agentcore de destino. O Okta avalia a política de acesso do usuário ali e retorna um token de acesso com escopo destinado ao agente Corp-Knowledge-Agent.

Salto 5: Orquestrador para Bedrock AgentCore

O orquestrador passa o token com escopo definido como parte da chamada real agente para agente (A2A) para o agente AgentCore Corp-Knowledge-Agent. O AgentCore verifica o token e permite que a chamada prossiga no contexto do agente orquestrador e da identidade humana originadora.

Salto 6: AgentCore para o gateway

Corp-Knowledge-Agent invoca a ferramenta query_knowledge_base no servidor Aurora DB MCP através do gateway, passando o token de entrada e a permissão (escopo) desejada para a ferramenta de saída.

Salto 7: gateway para Okta, Cross-App Access 

O gateway inicia o fluxo XAA novamente, enviando o token de entrada e o escopo solicitado para o endpoint de token da Okta (/oauth2/v1/token). O Okta avalia a política de acesso do agente e retorna um token ID-JAG de uso único e curta duração, com escopo reduzido para a tarefa.

Hop 8: gateway para Okta, troca de token 

O gateway cria uma afirmação de cliente com a chave privada do Agentcore Corp-Knowledge-Agent e troca o token ID-JAG no servidor de autorização personalizado atribuído ao servidor Aurora DB MCP de destino. O Okta avalia a política de acesso do usuário ali e retorna um token de acesso com escopo destinado ao servidor MCP.

A ferramenta no final recebe uma solicitação que pode ser totalmente atribuída: quem é o humano, qual agente agiu, seu escopo e uma alegação de cadeia de custódia (act) que vincula toda a cadeia a um único registro. A autoridade era decidida em tempo de execução, com escopo para a tarefa e nunca separada do humano responsável por ela.

As quatro falhas de segurança principais resolvidas pela arquitetura

Ao rotear o fluxo de execução do Bedrock AgentCore por meio desta arquitetura padronizada, a Streamward neutraliza com sucesso os quatro erros de identidade comuns que quebram as configurações de agente não gerenciadas:

Remediação de Shadow IA 

Em vez de permitir que o Corp-Knowledge-Agent do Bedrock seja executado cegamente no IdP central sem um emissor verificável, o agente é registrado diretamente no Universal Directory como uma entidade de carga de trabalho distinta. A governança de TI mantém clara propriedade sobre seu ciclo de vida e visibilidade sobre suas conexões de rede.

Remediação de acesso com privilégios excessivos 

Em vez de ser executado em uma conta de serviço ampla e permanente, com permissões fixas que expõem toda a camada de banco de dados a ameaças de injeção de prompts, o agente recebe um token de curta duração gerado dinamicamente em tempo de execução. Seus escopos são matematicamente intersectados e reduzidos estritamente para a operação de banco de dados necessária para aquele bloco de execução específico (Aurora-DB:read).

Prevenção de falsificação 

Ao incorporar a cadeia de delegação act multi-hop diretamente no contexto do token, a identidade não se resume a uma credencial de máquina genérica. O limite de recursos pode rastrear com precisão a linhagem de custódia, prevenindo a eliminação de identidade e aplicando controles de dados de acordo com as permissões reais do usuário responsável.

Aplicação da governança

Cada etapa da troca de token gera eventos estruturados e explícitos (app.oauth2.token.grant.id_jag) vinculado a um identificador de transação imutável. Este histórico de auditoria permanente fornece às equipes de conformidade e resposta a incidentes evidências de qual pessoa autorizou qual ação automatizada.

Os componentes do Okta for AI Agents

Vamos analisar os componentes do Okta for AI Agents envolvidos na solução acima.

Registro e descoberta de agentes  

Este componente transforma agentes autônomos desconhecidos em principais de carga de trabalho conhecidos e verificáveis, registrando-os no Universal Directory, onde cada um recebe um ciclo de vida, um proprietário humano nomeado e um lugar na política. 

Como os agentes não gerenciados aparecem mais rápido do que qualquer pessoa pode registrá-los manualmente, o gerenciamento da postura de segurança de identidade (ISPM) os descobre em nuvens e redes MCP, incluindo os agentes no-code que, de outra forma, permaneceriam invisíveis, e mapeia cada um de volta a um proprietário. Um agente que o senhor não pode ver é aquele que o senhor não pode autorizar ou responsabilizar.

Integração automática de agentes

Agentes criados no Salesforce, AWS, Microsoft e ServiceNow são importados diretamente para o Universal Directory, para que o registro acompanhe sua presença.

Cross-App Access 

O XAA usa a Concessão de Autorização de Declaração de Identidade para evitar a eliminação de identidade em fluxos de trabalho de múltiplos saltos. Em vez de um agente atuando como uma conta de serviço anônima, o humano (a declaração sub) e o agente (a declaração act) viajam juntos no token (Figura 7), produzindo uma declaração de ator que é uma cadeia em vez de um único principal. XAA é o que mantém a autorização vinculada a um ser humano real à medida que uma solicitação cruza as fronteiras do fornecedor.

O fluxo XAA

Consentimento intermediado

Para o primeiro acesso agente-para-SaaS em nome de um usuário, o serviço de token seguro (STS) da Okta intermedia o consentimento de forma dinâmica. O agente faz uma pausa enquanto o usuário autoriza o acesso uma única vez, fora do canal, antes que a chamada prossiga. O consentimento é estabelecido na camada de identidade, em vez de ser integrado em cada agente; portanto, mesmo um agente que você não pode modificar herda o controle.

Autorização de agente para agente  

Em uma malha de agentes, a Okta faz a mediação de cada transferência. Uma única etapa configura a conexão entre dois agentes (Figura 8), e a permissão efetiva é a interseção dos direitos do usuário e do agente chamador, o que significa que um subagente nunca excede a combinação de menor privilégio. A declaração de ator aninhado estende-se do ser humano por meio de cada agente até o serviço final, com autoridade controlada por políticas em cada etapa, mantendo o ser humano responsável na cadeia.

Configurando a conexão de recurso agente a agente no Okta

Auditoria centralizada

Como um agente não é uma pessoa jurídica e não pode responder por si próprio, a pessoa responsável deve ser identificável no final de cada cadeia. Uma trilha captura cada transação com eventos de concessão explícitos que comprovam quem agiu e em nome de quem (Figura 9), que é o registro que um regulador, um tribunal ou um conselho solicitará.

Registro do Sistema Okta para auditoria centralizada

Controle seguro em tempo de execução

A Okta implementa o gateway do agente de tempo de execução embutido como o ponto central de aplicação de políticas (PEP) em frente aos recursos downstream, com a Okta atuando como o ponto de decisão de políticas (PDP) para cada solicitação (Figura 10).

Gateway do Agente Runtime

• Servidor MCP virtual: O gateway se apresenta como um servidor MCP, permitindo que as Organizações protejam agentes de low-code e no-code que acessam recursos Enterprise sem que esses agentes precisem se comunicar diretamente com a troca de tokens.
• Isolamento de credenciais: O gateway abstrai tokens XAA de curta duração e tokens SaaS intermediários de maior duração, para que essas credenciais de recurso nunca sejam expostas aos agentes.
• Segurança integrada de chamadas de ferramentas: Plataformas de baixo código encaminham cada chamada de ferramenta de saída através do gateway, que intercepta a chamada, verifica a relação com políticas detalhadas em alta velocidade e injeta um segredo de backend de curta duração na borda antes da execução. O token emitido é criado no momento da solicitação, tem escopo para a tarefa, é vinculado ao público-alvo e pode ser revogado em segundos, o oposto de uma credencial permanente que pode ser encontrada em um arquivo e reutilizada.

Para onde isso vai em seguida: recursos avançados do Okta for AI Agents

O que esta arquitetura oferece hoje é a base: cada agente recebe uma identidade verificável, e sua autoridade é determinada em tempo de execução e limitada à tarefa. 

A primeira fase de um kill switch global já está em vigor, usando o Shared Signals Framework (SSF) para transformar um sinal de risco em revogação, que se expandirá para o encerramento coordenado e em tempo real em todos os sistemas conectados, o controle que tokens de curta duração sozinhos não podem fornecer.

O que vem a seguir é o mesmo princípio do plano de controle, alcançando as partes da vida de um agente que ainda não atinge, as questões que as equipes de governança já fazem sobre o acesso humano, agora feitas sobre os agentes:

• Certificação de acesso do agente: Garante que a autoridade de cada agente seja submetida à mesma comprovação e revisão que qualquer outro acesso, com os proprietários de recursos confirmando o que deve ser retido e revogando o que está desatualizado. 
• Gráfico de acesso identidade-recurso: Traça o caminho completo de uma pessoa, através de cada agente que atua por ela, até os recursos e escopos que cada um pode alcançar, para que o raio de explosão seja visível antes que algo dê errado e o alvo da revogação seja óbvio quando acontecer. 
• Aprovação HITL (human-in-the-loop): no momento de provisionar e ao executar uma ação sensível, mantém uma pessoa no processo de tomada de decisão onde é mais importante. 
• Autoridade não supervisionada: Os agentes começam a obter autoridade não supervisionada com base em seu comportamento, em vez de terem a confiança concedida antecipadamente.

Nada disso é um novo plano de controle. É o mesmo, estendido desde o momento em que um agente é criado até o momento em que sua autoridade é revisada, reduzida ou retirada.

O plano para uma empresa agêntica segura

Dê um passo para trás, e a arquitetura responderá às três perguntas que toda equipe de segurança está fazendo (Figura 11):

1. Onde estão os meus agentes? (Aqueles que a empresa construiu e aqueles que chegaram por conta própria.) 
2. A que eles podem se conectar? (De servidores MCP e apps SaaS a outros agentes, contas de serviço e sistemas de registro legados.) 
3. O que eles têm permissão para fazer? (Decidido em tempo de execução, escalado para um humano onde importa e revogável quando não sai como planejado.)

Essas três perguntas são a disciplina operacional por trás do Agentic Enterprise Blueprint.

O blueprint da Okta para proteger agentes de IA em escala

Empresas como a Uber demonstraram a necessidade de criar esse tipo de governança para agentes de IA.  Mas nem toda empresa precisa arquitetar isso sozinha.

O fio condutor em todas as camadas é o mesmo: a identidade é o plano de controle, a autorização é decidida em tempo de execução e limitada à tarefa, o humano responsável acompanha a solicitação, e tudo funciona com padrões abertos, de modo que se mantém em todos os fornecedores que um agente utiliza. 

Tratar agentes como identidades de primeira classe nesses termos é a maneira correta de proteger a empresa agêntica, e o Okta for AI Agents torna isso uma camada que se adota, em vez de um sistema que se leva um ano para construir.  A arquitetura neste artigo é algo que se adota, não algo que se constrói. 

Veja como a Okta e a Auth0 protegem agentes de IA, ou entre em contato com nossa equipe.