Se você é um CISO, provavelmente já deva ter ouvido alguém da diretoria fazer uma pergunta do tipo: "Qual é nossa estratégia de segurança para IA?"
E você provavelmente deva ter respondido algo do tipo: "Estamos trabalhando nisso. A política de IA ainda está sendo definida. Assim que soubermos o que vamos implantar, garantiremos a segurança."
Essa resposta parecia segura seis meses atrás. Mas agora não é mais.
Os agentes de IA que você planeja implantar não são os que representam um risco para você neste momento. Ao contrário, os que já estão em execução no seu ambiente é que representam um risco.
Resumo executivo
- A lacuna na governança de IA: o relatório IA no trabalho 2025 da Okta revelou que, embora 91% das organizações implementem agentes de IA, apenas 10% possuem uma estratégia de gerenciamento, o que torna os agentes com privilégios excessivos um risco imediato.
- O ponto cego da visibilidade: as ferramentas tradicionais de rede e endpoint não conseguem rastrear as ações específicas, os proprietários e as permissões dos agentes de IA comprometidos.
- Identidade como o plano de controle: a identidade é a única camada de segurança capaz de responder qual agente realizou qual ação, em nome de quem, e se a ação foi permitida.
- Uma abordagem unificada: o Okta for AI Agents permite descobrir, integrar, proteger e administrar seus agentes de IA.
A transição empresarial para a IA agêntica deixou de ser um estado futuro e tornou-se uma realidade em produção. O Relatório de IA no trabalho 2025 da Okta descobriu que, atualmente, 91% das organizações já estão usando agentes de IA para automatizar fluxos de trabalho complexos e impulsionar a produtividade. No entanto, o mesmo relatório destaca uma perigosa lacuna de governança: embora a implementação esteja aumentando, apenas 10% dos líderes relatam ter uma estratégia bem desenvolvida ou um roteiro para gerenciar identidades não humanas, incluindo agentes de IA.
O risco da IA paralela: gerenciando a força de trabalho invisível
O impulso de adiar a avaliação de identidade ignora uma verdade fundamental: o risco não está apenas na IA que será implantada amanhã; está nos agentes com privilégios excessivos que já estão em operação hoje.
Por um momento, esqueça a definição completa da sua política de IA. Tente responder a estas perguntas sobre seu ambiente hoje:
- Onde estão meus agentes de IA?
- O que eles podem acessar?
- O que eles podem fazer?
A maioria dos líderes de segurança não consegue responder a nenhuma dessas perguntas com confiança, e isso não significa que seu programa de segurança esteja falhando. Trata-se de uma lacuna estrutural. Os agentes já estão aqui, e seus controles de identidade existentes provavelmente ainda não se estendem a eles.
Embora os rollouts formais sejam debatidos, os funcionários frequentemente conectam ferramentas de IA de terceiros a contas corporativas por meio de concessões OAuth, como o Cursor ao GitHub, o Claude ao Google Workspace e aplicativos de anotações de reuniões com IA aos calendários, em um ritmo que a governança não consegue acompanhar.
Cada concessão cria uma identidade não humana (NHI) com direitos delegados aos dados empresariais, muitas vezes sem um proprietário verificado ou um "raio de impacto" claro.
A realidade da IA paralela
Um incidente recente em uma plataforma de desenvolvedores bem conhecida não envolveu vulnerabilidades ou falhas de infraestrutura, mas sim uma conexão OAuth entre a conta corporativa de um funcionário e uma ferramenta de IA de terceiros, concedida completamente fora do campo de visão do setor de TI. Quando essa ferramenta de IA foi comprometida, a confiança pré-concedida tornou-se o caminho de ataque: uma linha direta para sistemas internos, chaves de API, tokens e variáveis de ambiente. É assim que a IA paralela realmente se apresenta na prática: uma concessão OAuth não sancionada, não aprovada por ninguém e sem supervisão de TI.
A verdade incômoda: se você esperar para proteger seus agentes de IA até que sua política de IA esteja finalizada, estará aplicando governança sobre um risco que já está acumulado.
Identifique as falhas de segurança de sua IA com nosso simulador de ataque de 5 minutos.
Por que a identidade é a camada essencial para a governança da IA?
Os modelos de segurança tradicionais costumam priorizar a proteção da rede ou dos endpoints. Embora sejam camadas vitais, elas são fundamentalmente incapazes de identificar quais agentes autônomos estão acessando o quê e por qual motivo.
- Ferramentas de rede monitoram o tráfego; um agente de IA que age em nome de um usuário parece tráfego legítimo de API.
- Ferramentas de endpoint monitoram processos; um agente de IA assemelha-se a um processo padrão autorizado que está sendo executado na sessão de um usuário legítimo.
Ambas as camadas são essenciais, mas nenhuma consegue responder às perguntas que são relevantes quando ocorre um incidente: "Qual agente fez isso? Em nome de quem? Com qual escopo? Isso foi permitido?"
Na era agêntica, a identidade é a única camada de segurança que compreende a intenção e o escopo. É por isso que 85% dos líderes agora classificam o gerenciamento de identidade e acesso (IAM) como o componente mais crítico de sua estratégia de IA (Okta, Relatório IA no trabalho 2025).
O incidente na plataforma de desenvolvedores que descrevemos anteriormente ajuda a ilustrar a questão: não foi uma falha de endpoint nem de rede. No nosso entendimento, trata-se de uma falha de identidade, especificamente: como apps de terceiros e ferramentas de IA recebem acesso, o que podem fazer e por quanto tempo.
É por isso que desenvolvemos o Okta for AI Agents, uma solução desenvolvida especificamente que expande a Okta Platform para descobrir, integrar, proteger e governar seus agentes de IA no seu ambiente. O Okta for AI Agents descobre e integra agentes de IA em qualquer plataforma, protege conexões com acesso de menor privilégio e os governa por meio de revisões de acesso, trilhas de auditoria completas e a capacidade de desativar manualmente um agente de IA instantaneamente com um botão de desligamento para impedir novas solicitações de tokens e autorizações futuras quando um agente se comportar de forma inesperada.
Quatro capacidades essenciais para garantir a visibilidade e o controle completo dos agentes
Quando a identidade é o plano de controle para os agentes, quatro possibilidades tornam-se viáveis de maneira unificada:
- Identidade de agente de primeira classe: seus agentes, sejam eles desenvolvidos internamente, incorporados em uma ferramenta SaaS ou executados no laptop de um funcionário, são registrados como entidades principais de carga de trabalho com credenciais, um proprietário humano atribuído e um ciclo de vida gerenciado. É isso que você pode dizer ao seu CIO quando ele perguntar: “Quem é o proprietário deste agente e quem será responsabilizado se algo der errado?”
- Atribuição criptográfica: cada ação carrega a identidade humana e a do agente, assinadas criptograficamente. Isso é o que você pode mostrar ao seu auditor quando ele perguntar: "Qual agente fez isso e em nome de quem?"
- Aplicação do menor privilégio: os tokens têm escopo limitado a uma única chamada, não a uma sessão ou a um app. O privilégio permanente desaparece. É isso que você pode dizer à diretoria quando perguntarem: "Qual é nosso risco se um desses agentes for comprometido?"
- Governança integrada: as solicitações de acesso de agentes e as certificações de acesso são incorporadas à plataforma de identidade, e não adicionadas posteriormente. Isso é o que você pode mostrar ao seu auditor quando ele perguntar: "Comprove que o acesso do seu agente de IA foi revisado por um humano nos últimos 90 dias."
Mas as capacidades só importam se forem aplicáveis em todos os locais onde seus agentes são executados, o que significa que a estratégia de agentes precisa estar ancorada no ecossistema. Seus agentes podem estar sendo executados no Salesforce Agentforce, Amazon Bedrock, ServiceNow AI e em qualquer plataforma que suas equipes venham a adotar depois. Sempre que um agente cruza um ecossistema, a governança da plataforma na qual ele foi desenvolvido fica para trás. O que resta é a lacuna.
E a Okta foi criada para preencher essa lacuna. O Okta for AI Agents foi projetado para ser independente de fornecedores, abstraindo a intermediação de identidades no Azure, AWS e Google Cloud, de forma que as mesmas políticas se apliquem uniformemente em todos os lugares, sem integrações pontuais.
Projetado para estender seu IdP, não para substituí-lo
Uma das principais preocupações dos arquitetos de TI é a "proliferação de identidades", o receio de adicionar um segundo silo de identidade para IA. A governança moderna de IA não deve exigir uma "substituição completa" da identidade atual da sua força de trabalho.
Seu provedor de identidade (IdP) é o sistema de registro da sua força de trabalho. É onde residem suas políticas de login, onde a autenticação multifatorial é aplicada, onde o acesso condicional é ajustado e onde anos de trabalho de integração garantiram o bom funcionamento da governança de identidade humana. Nada disso deve mudar só porque você está adicionando agentes ao cenário.
O Okta for AI Agents foi concebido para complementar. Ele se integra ao seu IdP existente por meio de protocolos padrão (OIDC, SAML), herdando a confiança do IdP sem duplicar credenciais ou exigir um segundo login. Quando um humano invoca um agente, o Okta valida a afirmação de identidade do seu IdP e emite um token assinado criptograficamente contendo informações tanto do humano quanto do agente. Os humanos ficam onde estão. Os agentes adquirem a governança desenvolvida para eles.
O resultado: você amplia a base de identidade na qual já investiu para abranger uma nova classe de identidade, sem precisar migrar para outra plataforma, duplicar diretórios ou adicionar complexidade operacional.
Saiba mais sobre a abordagem da Okta para fornecer uma camada independente de fornecedores que protege todas as conexões sem exigir que você substitua seu IdP atual.
Comece aqui: três perguntas para responder hoje
Sua política de IA pode esperar, mas os agentes no seu ambiente não podem.
Comece fazendo três perguntas:
Onde estão meus agentes de IA?
O que eles podem acessar?
O que eles podem fazer?
A identidade é a única camada capaz de responder às três perguntas e constitui a base sobre a qual se erguerá sua política futura.
Experimente a governança de IA em primeira mão. Veja a demonstração interativa do Okta for AI Agents.
Perguntas frequentes
Como os funcionários introduzem a IA paralela em uma rede corporativa?
Normalmente, os funcionários introduzem a IA paralela concedendo a ferramentas de IA de terceiros acesso direto à API em ambientes corporativos usando permissões OAuth. Essas integrações, como conectar um assistente de IA a um calendário corporativo ou a um repositório de código, ocorrem de forma integrada no nível do usuário, ignorando a supervisão tradicional de TI e criando identidades não humanas que não são monitoradas.
Por que as ferramentas de segurança de rede e de endpoints são indiferentes às ações dos agentes de IA?
As ferramentas de rede tradicionais consideram a atividade de agentes de IA autônomos como tráfego legítimo de API, enquanto as ferramentas de endpoint a interpretam como processos padrão executados dentro de uma sessão de usuário autorizada. Como esses perímetros não possuem contexto de identidade em nível de aplicativo, eles não conseguem determinar qual agente específico iniciou uma ação, em nome de quem agiu ou qual é seu raio de impacto.
É possível garantir a segurança dos agentes de IA antes de finalizar uma política corporativa formal de IA?
Sim. Aguardar uma política formal de governança corporativa deixa vulnerabilidades de segurança ativas sem solução. As equipes de segurança podem mitigar riscos estendendo sua arquitetura IdP existente para descobrir, autorizar e governar cargas de trabalho autônomas por meio de protocolos de identidade não humana (NHI), em vez de esperar pela aprovação de políticas estruturais.
A implementação da segurança de agentes de IA requer um diretório de identidade completamente separado?
Não. Uma governança eficaz de IA deve evitar a "proliferação de identidades" por meio da integração complementar com seu IdP principal. Usando padrões de federação abertos, como OpenID Connect (OIDC) e SAML, plataformas como a Okta podem emitir tokens com escopo que associam identidades de agentes de máquina às regras de autenticação humana existentes, sem duplicar credenciais de usuário.
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.
Este material tem caráter meramente informativo e não constitui aconselhamento jurídico, comercial, de privacidade, de segurança ou de conformidade.
O conteúdo pode não refletir os desenvolvimentos mais recentes nas áreas de segurança, legislação e/ou privacidade. É de sua inteira responsabilidade obter aconselhamento de seu próprio consultor jurídico e/ou profissional. Não se baseie neste material como orientação legal.
A Okta não faz representações ou garantias em relação a este conteúdo e não se responsabiliza por qualquer perda ou dano resultante da sua implementação destas recomendações. Informações sobre as garantias contratuais da Okta aos seus clientes podem ser encontradas em okta.com/agreements.
