Proteção para fluxos de trabalho multiagente com conexões entre agentes

O ponto cego da identidade em fluxos de trabalho multiagentes

Neste momento, dentro da sua empresa, um agente de IA pode estar acionando outro agente de forma autônoma. Um agente de vendas obtém o histórico de pagamentos de um cliente junto a um agente financeiro. Um agente de monitoramento aciona um agente de diagnóstico para investigar uma falha no serviço. Tarefas que antes exigiam dezenas de intervenções humanas agora são concluídas em segundos.

Eis o problema: cada uma dessas transferências é um evento de acesso que você precisa controlar. E a maioria das equipes de segurança não tem visibilidade sobre eles. Enquanto isso, as equipes de IA que desenvolvem esses fluxos de trabalho multiagentes estão criando códigos personalizados de autorização entre cada par de agentes, unindo soluções pontuais sem um local central para visualizar ou controlar o que está acontecendo.

Arquiteturas multiagentes, sejam elas iniciadas por humanos, por máquinas ou, cada vez mais, pelos próprios agentes, já estão em produção. Mas a camada de identidade subjacente a elas está ausente. Sem uma camada de identidade criada especificamente para interações entre agentes, essas conexões se tornam pontos cegos: não governadas, não atribuíveis e impossíveis de auditar.

Novidades: conexões seguras entre agentes

Para proteger e governar fluxos de trabalho multiagentes, o Okta for AI Agents utiliza o modelo da Okta para a empresa com agentes seguros, uma estrutura estratégica para descobrir, autorizar e governar agentes de IA autônomos. O segundo pilar deste plano questiona: "A que eles podem se conectar?", com foco em garantir a segurança das conexões entre agentes e recursos, fornecendo aos agentes acesso controlado e auditado aos dados e sistemas corporativos de que precisam.

Agora, estamos estendendo esse mesmo modelo de conectividade segura para abranger fluxos de trabalho multiagentes. Os mesmos mecanismos básicos que protegem humanos e aplicativos hoje, como identidades de agentes, credenciais com escopo definido e atribuição de auditoria, agora se estendem às conexões entre agentes.

No centro disso está a Conexão Agente-a-Agente, uma nova funcionalidade do Okta para Agentes de IA que permite definir: 

• Políticas de conexão por agente 
• Quais serviços e agentes upstream podem invocar um agente? 
• Escopo do agente (a que ele pode acessar)
• Duração da sessão (quanto tempo dura esse acesso)

A identidade é preservada em cada transferência, de modo que cada conexão permanece verificável ao longo do fluxo de trabalho.

Para as equipes de segurança, isso significa que cada chamada entre agentes é controlada, delimitada e totalmente auditável. Para os desenvolvedores, isso significa criar fluxos de trabalho multiagentes sem precisar programar a autorização para cada agente. Basta definir as políticas de autorização e acesso uma única vez no Okta, e todos os agentes na cadeia de delegação funcionarão automaticamente com essas políticas definidas.

Como funcionam as conexões entre agentes?

Sempre que um agente liga para outro, o Okta verifica se a conexão está autorizada, limita os dados apenas ao que a tarefa exige e registra quem agiu em nome de quem, garantindo que o fluxo de trabalho multiagente seja gerenciado de ponta a ponta.

Fluxo multiagente passo a passo

Para entender como isso funciona, vamos acompanhar uma única solicitação ao longo do fluxo de trabalho multiagente. Imagine uma tarefa rotineira de geração de relatórios sendo executada por dois agentes:

• Agente assistente do usuário: age em nome do funcionário.
• Agente de análise de dados: Extrai dados de bancos de dados confidenciais.

Eis o fluxo:

1. O usuário pede ao assistente virtual para "gerar um relatório do quarto trimestre para mim".
2. O agente assistente do usuário precisa de dados, então ele chama o agente analista de dados "em nome de [usuário]".
3. Okta verifica a política: o agente assistente do usuário tem permissão para chamar o agente analista de dados? O agente analista de dados pode compartilhar esses dados com o usuário?
4. Em caso afirmativo, a Okta emite um token temporário que diz: "Agente analista de dados, esta solicitação é de [usuário] por meio de [agente assistente do usuário]". Você pode compartilhar X, Y e Z."
5. O agente de análise de dados valida o token, compartilha apenas o que é permitido e registra a solicitação.
6. O assistente de usuário utiliza os dados para gerar o relatório e o retorna ao usuário.
7. Tudo é auditável. O registro mostra: Usuário → agente assistente do usuário → agente analista de dados.

Três princípios fazem com que isso seja possível:

•  Listas de permissão explícitas: Defina quais agentes podem chamar quais outros agentes.
•  Permissões com escopo: conceda a cada agente subsequente apenas o que ele precisa para sua tarefa.
•  Cadeias de delegação verificáveis: Acompanham cada token, de forma que o registro de auditoria capture quem autorizou o quê.

O resultado: as equipes de segurança obtêm visibilidade completa de todas as ações dos agentes. Os desenvolvedores param de escrever códigos de autorização entre agentes e começam a implementar fluxos de trabalho multiagente mais rapidamente.

Por que a cadeia de delegação multiagente continua sendo confiável?

Duas coisas mantêm a cadeia de delegação confiável: 

1. Cada agente pode atuar tanto como cliente quanto como recurso. 
2. Cada token contém um registro completo e verificável de quem autorizou o quê. A autorização ocorre em tempo de execução e a ação é armazenada no log de auditoria.

Agentes que atuam tanto como clientes quanto como recursos.

Na Okta, cada agente é simultaneamente um cliente e um recurso. Isso é importante porque, em um fluxo de trabalho multiagente real, os agentes não ficam apenas em uma extremidade da chamada; eles ficam no meio. Cada agente pode iniciar solicitações para outros agentes ou serviços, e também pode receber solicitações deles. Essa dupla função é o que torna a orquestração possível.

• Como cliente: O agente pode contatar outros agentes ou serviços.
• Como recurso: Outros agentes podem chamar este agente (se a política permitir).

Um único agente pode ser especializado e, ao mesmo tempo, orquestrador, sem quebrar a cadeia de confiança.

Preservação do contexto por meio de registros de delegação baseados em tokens

Quando a Okta emite um token para uma chamada de agente para agente, ela inclui um registro de todo o caminho:

• "Isto é para o Usuário A"
• "Usuário A delegado ao agente assistente"
• "O agente assistente delegou ao agente analista de dados"
• "O agente analista de dados tem permissão para fazer X, Y e Z."

A Okta inclui a cadeia de delegação completa no token para que o agente receptor possa verificar a autorização antes de agir. O registro de auditoria da Okta captura a cadeia de delegação para cada chamada, preservando-a mesmo depois que o token expira. 

Se algo der errado, como um incidente de segurança, uma questão de auditoria ou uma revisão de conformidade, você pode acessar o registro de auditoria e ver exatamente o que aconteceu, quem autorizou e se estava em conformidade com a política. Sem necessidade de escavação manual de toras. Não há correlação entre os trabalhos.

Analisando padrões de fluxo conduzidos por humanos versus conduzidos por máquinas

Independentemente de um fluxo de trabalho começar com um humano ou uma máquina, uma identidade ancora toda a cadeia. Todos os agentes subsequentes atuam sob essa autoridade, e cada etapa é atribuível a ela. As conexões agente-a-agente lidam com ambos os padrões atualmente.

Padrão 1: Um humano inicia a cadeia

Um usuário faz login e solicita a um agente que execute uma ação. Esse agente pode chamar outros agentes para concluir o trabalho, mas a identidade do ser humano é o ponto de referência.

Exemplo: O funcionário pergunta: "Poderia me dar um resumo das métricas do quarto trimestre?"

1. O agente de resumo chama o agente do painel de controle (em nome do funcionário).
2. O agente do painel de controle chama o agente do banco de dados (em nome do funcionário).

A identidade do funcionário permeia toda a cadeia produtiva, e cada etapa é registrada em seu nome.

O que a Okta registra no log de auditoria: "O funcionário autorizou o Agente de Resumo a chamar o Agente do Painel de Controle." O Agente do Painel de Controle recuperou métricas do Agente do Banco de Dados dentro do escopo de acesso do Funcionário.

Padrão 2: Um serviço inicia a cadeia 

As empresas possuem décadas de aplicativos de serviço, pipelines ETL, tarefas agendadas e microsserviços executando cargas de trabalho determinísticas. Esses sistemas agora estão incorporando IA.

Exemplo: Um serviço de monitoramento detecta um pico de uso da CPU.

1. O serviço de monitoramento aciona o agente de diagnóstico.
2. O agente de diagnóstico chama o agente de análise de logs.

Nenhum usuário iniciou a solicitação. O serviço de monitoramento é o cliente e o agente de diagnóstico é o seu recurso, e a autoridade do serviço flui por toda a cadeia.

O que a Okta registra no log de auditoria: "O serviço de monitoramento autorizou o agente de diagnóstico a chamar o agente de análise de logs." O agente de análise de logs pode analisar os logs de produção para o serviço de monitoramento.

Principais diferenças entre os dois padrões

O resultado: um modelo de governança único, independentemente de onde a cadeia de delegação comece. As equipes de segurança obtêm rastreabilidade completa em fluxos de trabalho iniciados por humanos e por máquinas, com cada transferência de informações registrada. As equipes de IA obtêm autorização que funciona da mesma forma, independentemente de um usuário ou serviço estar na raiz, portanto, não há lógica separada para criar e manter para cada padrão.

Padrão 3: Um agente autônomo inicia a cadeia (em breve)

Um terceiro padrão está chegando em breve: "Em nome de si mesmo", onde um agente autônomo pode agir inteiramente por sua própria autoridade, sem qualquer delegação, sob uma política pré-aprovada por um administrador. Utilizando esse padrão, você poderá executar agentes autônomos dentro de uma política predefinida, totalmente auditada e controlada. 

Centralizar a governança de fluxos de trabalho multiagentes.

Os agentes já estão ligando para outros agentes no seu ambiente, mas nada controla essas chamadas. A questão nunca foi se os agentes ligariam para outros agentes; a questão é se você pode responder pelo que acontece quando isso acontece.

É isso que o Okta para Agentes de IA torna possível. Ao estender os mesmos elementos básicos de identidade que protegem seus funcionários, aplicativos e agentes às conexões entre agentes, você tira o fluxo de trabalho multiagente do ponto cego e o coloca sob governança. As Conexões Agente-a-Agente fornecem as listas de permissões, as permissões com escopo e a cadeia verificável que tornam os fluxos de trabalho autônomos seguros para escalabilidade.

À medida que as arquiteturas multiagentes se tornam mais complexas, as empresas que saírem vitoriosas não apenas se adaptarão rapidamente, mas também serão capazes de demonstrar, a qualquer momento, quem fez o quê, em nome de quem e dentro de qual política.

Quer governar seus fluxos de trabalho multiagente?

O acesso antecipado às Conexões Agente-a-Agente já está disponível para clientes da Okta. Entre em contato com nossa equipe de vendas

Veja como esses controles de agentes de IA funcionam na prática. Participe da nossa transmissão ao vivo da Okta para saber mais sobre como funciona a governança de agentes quando a identidade é o ponto de controle. 

Estes materiais são destinados apenas para fins informativos gerais e não constituem aconselhamento jurídico, de privacidade, conformidade com a segurança ou de negócios. Você é responsável por obter aconselhamento de segurança, privacidade, conformidade ou negócios dos seus próprios consultores profissionais. Qualquer menção a produtos, recursos, funcionalidades ou certificações futuras neste blog tem caráter meramente informativo. Esses itens não representam compromissos de entrega e não devem ser considerados para fins de decisão de compra. © Okta, Inc. e suas afiliadas. 2026.