Nota do editor: Aprenda como desbloquear isso no episódio mais recente do streamcast, "O projeto para a empresa agente segura", onde passamos da teoria à prática. Você aprenderá exatamente como o projeto para uma empresa com agentes seguros se transforma em controles práticos para ferramentas como Claude Code e Cursor.
Suas equipes de IA não podem se dar ao luxo de deixar que lacunas de governança atrasem a implementação. Eles precisam colocar agentes de IA para trabalhar agora.
Segundo uma pesquisa realizada em 2026 com líderes seniores de tecnologia, 90% das organizações não têm como controlar o que os agentes em produção estão realmente fazendo. Aproximadamente 54% já sofreram um incidente de segurança relacionado a um agente que agiu de forma inesperada.
Esses agentes acessam APIs, leem registros confidenciais, delegam tarefas a outros agentes e tomam decisões sem esperar pela intervenção humana. A questão não é se sua organização tem agentes operando dessa forma; é se você tem algum controle significativo sobre o que eles estão fazendo e quando estão fazendo. Para a maioria das empresas hoje em dia, a resposta honesta é não.
O motivo pelo qual a resposta é não é quase sempre um problema de governança de identidade. Todo agente de IA em produção opera por meio de uma camada de identidade governada ou em torno de uma. A maioria está correndo em torno de um.
Onde a governança de identidade agora alcança mais longe
Para ser uma empresa autônoma segura, você precisa de um plano que o ajude a responder a três perguntas cruciais:
- Onde estão os meus agentes?
- O que eles podem acessar?
- O que eles podem fazer?
As funcionalidades abordadas neste blog são novos aprimoramentos que impulsionam ainda mais o projeto para a empresa agente segura, respondendo exatamente às duas últimas perguntas. Elas ajudam as equipes de IA a lançar produtos mais rapidamente e as equipes de segurança a obter a aplicação de políticas em tempo real, os controles de resposta e a auditabilidade de que precisam para dizer sim.
O que eles podem acessar?
Em algum lugar da sua organização neste exato momento, um agente de IA pode estar silenciosamente repassando tarefas para outro agente.
Eis o problema: cada uma dessas transferências é um evento de acesso que a empresa precisa controlar. E, sem uma camada de identidade, a maioria das equipes de segurança não tem visibilidade sobre eles.
A maioria das empresas está criando fluxos de trabalho multiagentes de duas maneiras:
- Fluxos de trabalho iniciados pelo usuário: Um funcionário solicita a um assistente executivo que crie uma apresentação para a revisão trimestral dos negócios. O agente orquestra um conjunto de agentes, cada um agindo em nome do usuário e com escopo definido de acordo com o que o usuário tem permissão para acessar. O ser humano é a âncora, enquanto a identidade flui através de cada transição.
- Fluxos de trabalho iniciados por máquina: Um serviço de monitoramento detecta uma anomalia e aciona um agente de diagnóstico, que delega a um agente de análise de logs para investigar mais a fundo. Mantenha as pessoas no processo A autoridade do serviço flui através de todos os agentes na cadeia.
Ambos os padrões compartilham a mesma necessidade de governança: cada transferência de responsabilidade é um evento de acesso que deve ser autorizado, delimitado e registrado. Quando agentes de IA se comunicam sem uma camada de identidade dedicada, as organizações correm o risco de perder a capacidade de verificar a identidade do agente por trás de cada solicitação, aplicar políticas de forma consistente ou rastrear as ações até sua origem.
Conexões entre agentes: Proteja seus fluxos de trabalho com múltiplos agentes.
A funcionalidade de Conexões Agente-a-Agente, um novo recurso do Okta para Agentes de IA, preenche essa lacuna. Ele permite definir políticas de conexão por agente, quais serviços e agentes upstream podem invocar esse agente, seu escopo e por quanto tempo a permissão permanece válida. A identidade é preservada em todas as etapas de transferência, de modo que cada conexão permanece verificável ao longo de todo o fluxo de trabalho.
Três princípios fazem com que isso funcione:
- Listas de permissão explícitas definem quais agentes podem chamar quais outros agentes.
- Permissões com escopo concedem a cada agente subsequente apenas o que ele precisa para sua tarefa.
- Uma cadeia verificável acompanha cada token, de forma que o registro de auditoria capture quem autorizou o quê.
Isso significa governar a que os agentes podem se conectar na camada de agente para agente: quais agentes podem chamar quais outros agentes, sob quais condições, com qual escopo e com evidências que possam ser produzidas para qualquer auditor ou equipe de resposta a incidentes que as solicite.
Disponibilidade: O acesso antecipado às Conexões Agente-a-Agente já está disponível. Saiba mais sobre como proteger seus fluxos de trabalho multiagentes com conexões agente a agente.
Assistentes de codificação de IA seguros, como Claude Code, Microsoft 365 Copilot e Cursor.
As conexões entre agentes representam apenas um lado do problema de conectividade. Outra lacuna importante são as ferramentas de IA não regulamentadas que seus desenvolvedores já estão usando para se conectar aos seus sistemas. Isso inclui assistentes de codificação com IA, como Claude Code, Cursor, Microsoft 365 Copilot, GitHub Copilot e Glean.
Essas ferramentas estão integradas aos fluxos de trabalho diários e conectadas a sistemas internos como Jira, ServiceNow, GitHub e suas APIs internas.
O problema é como eles estão entrando. A maioria dessas ferramentas não foi criada para autenticar por meio de um provedor de identidade. Eles obtêm acesso por meio de tokens embutidos no código, credenciais ad hoc e chaves de API armazenadas em arquivos de configuração. Não existe autorização centralizada. Não há registro de auditoria. As equipes de segurança geralmente não têm visibilidade sobre quais agentes acessaram quais sistemas, em nome de quem ou o que fizeram quando chegaram lá.
A ponte MCP resolve isso sem exigir alterações nos próprios agentes. Um proxy auto-hospedado e com reconhecimento de identidade fica entre seus agentes e as ferramentas do Protocolo de Contexto de Modelo (MCP) às quais eles se conectam. Todas as chamadas são encaminhadas através da ponte. Cada agente se autentica por meio do seu provedor de identidade. Cada ação é registrada no seu log de auditoria. O agente não precisa ser reescrito. O desenvolvedor também não precisa alterar seu fluxo de trabalho.
A ponte funciona no ambiente do cliente, portanto os dados permanecem dentro do perímetro. Nenhum serviço externo vê o que passa. O cliente controla a implantação, a configuração e os dados.
Disponibilidade: O MCP Bridge é um serviço profissional oferecido e requer uma Declaração de Trabalho (SOW).
O que eles podem fazer?
Controlar o que os agentes podem fazer exige que a camada de identidade vá além do acesso inicial. Um token de acesso permite que um agente entre pela porta; ele não determina o que o agente faz depois de entrar.
Autorização do agente de IA: Imponha autorização em tempo de execução para cada ação do agente de IA.
As permissões de um usuário podem ser alteradas após a emissão de um token. Um empreiteiro pode abandonar um projeto. O paciente pode retirar o seu consentimento. Um gerente pode sair de férias. Funções estáticas e tokens de acesso não conseguem acompanhar essas mudanças. Em vez de perguntar: "Este usuário ou agente tem acesso ao sistema?" A autorização de agentes de IA faz uma pergunta mais precisa: "Este agente, agindo em nome deste usuário, pode realizar esta ação neste recurso neste momento?"
Essa distinção é importante porque as condições de autorização mudam constantemente. A Autorização Granular (FGA, na sigla em inglês) é uma autorização que considera o contexto em vez de apenas a função. Verifica se o usuário em nome de quem um agente está agindo possui o relacionamento, os atributos atuais e as condições de política necessários para executar uma ação específica em um recurso específico, em tempo de execução.
Isso inclui relacionamentos diretos e herdados, atributos dinâmicos como nível de autorização ou status de serviço, e limites de política, como limites de quantidade, valores em dólares ou regras de classificação de dados.
Por exemplo, um agente de compras pode aprovar faturas de até US$ 10.000 para o usuário em nome de quem está atuando, mas não acima desse limite. O FGA verifica o limite de aprovação do usuário em tempo de execução, e não apenas sua função.
Controlar o que os agentes podem fazer exige mais do que permissões estáticas definidas na implantação. Isso exige a avaliação contínua de cada ação, em todos os agentes, em tempo real. É assim que você controla o que um agente realmente faz.
Disponibilidade: Este é um exemplo de implementação de caso de uso do FGA e do Okta para Agentes de IA.
Botão de desativação: Elimine um agente malicioso no momento exato em que precisar.
A implementação de uma governança desde o início reduz a probabilidade de que algo dê errado, mas isso não significa que não dará. Os agentes são imprevisíveis por natureza. Eles tomam decisões, transitam entre sistemas e podem realizar ações que ninguém previu. Quando isso acontece, as equipes de segurança precisam responder imediatamente.
Muitas implementações de agentes de IA atuais não possuem uma maneira de desligar um agente quando ele se comporta de forma inesperada. Quando a diretoria pergunta qual é o plano de resposta caso um agente se comporte de forma desonesta, a maioria dos CISOs não tem uma resposta.
Isso muda com um interruptor de segurança. Para agentes que se conectam através do Okta, revogar o acesso interrompe o acesso a todos os recursos conectados com uma única ação no Console de Administração do Okta. Você não precisa confirmar se um agente foi comprometido para usá-lo. Uma configuração incorreta, uma ação fora do escopo ou um comportamento que levanta dúvidas. Qualquer um desses motivos é suficiente para desativar o agente imediatamente, enquanto você investiga mais a fundo o que aconteceu.
O resultado? As equipes de IA podem lançar seus produtos sabendo que existe uma rede de segurança em vigor. As equipes de segurança podem aprovar implantações sabendo que poderão responder caso algo dê errado. Quando você sabe que pode impedir, você pode aprovar.
Disponibilidade: O recurso de kill switch está disponível para o público em geral e incluído no Okta para Agentes de IA. Em breve: Detecção que lê sinais de risco de todo o ecossistema Okta, aumenta a pontuação de risco do agente e aciona o mecanismo de desativação automaticamente.
Todo agente precisa de uma camada de identidade
Essas funcionalidades abordam diferentes partes do problema de governança de agentes, mas compartilham uma premissa comum. Os elementos básicos de identidade que protegem seus funcionários e aplicativos também precisam ser estendidos aos agentes. Isso inclui governar as conexões entre eles, as ações que tomam, as ferramentas que utilizam e a sua capacidade de impedi-los quando algo dá errado.
Para governar agentes dessa forma, é necessário uma camada de identidade autorizada e em tempo real que já abranja sua força de trabalho e seus aplicativos. Okta está localizada nessa camada.
As empresas que acertarem nesse ponto desde o início não apenas reduzirão os incidentes. Eles se moverão mais rápido. A descoberta, a segurança e a governança integradas desde o início não atrasam a implementação da IA. Essa dupla função é o que torna a orquestração possível. Construa a base agora, e sua equipe de segurança deixará de ser o gargalo na implementação de agentes e passará a ser o motivo do sucesso.
Para saber mais sobre essas atualizações, incluindo demonstrações, assista ao webinar transmitido ao vivo.
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.
