Identidade de agentes de IA: a pergunta que todas as empresas pularam

A resposta curta: quando você coloca um agente de IA para rodar dentro da sua empresa, ele precisa de uma identidade própria, exatamente como um funcionário precisa de uma conta. A prática comum hoje — embutir uma chave de API estática dentro do agente para que ele acesse seus sistemas — é a coisa mais perigosa que você pode fazer, porque essa chave nunca expira, ninguém sabe quem a está usando e ela não pode ser revogada rapidamente quando você precisa. A abordagem correta é dar a cada agente uma identidade registrada, permissões delimitadas e tokens de curta duração que expiram automaticamente.

Foi exatamente isso que a Okta, uma das maiores fornecedoras de gestão de identidades do mundo, anunciou em 24 de agosto de 2026, com um novo recurso chamado Agent SSO. A ideia parece simples na superfície e tem consequências profundas: registrar o agente de IA como uma identidade de primeira classe dentro do diretório da empresa, ao lado dos funcionários humanos, para que ele fique sujeito às mesmas ferramentas de concessão, monitoramento e revogação de acesso.

Por que essa questão ficou urgente agora

Nos últimos dois anos, a IA corporativa passou de "um bot que responde perguntas" para "um agente que faz o trabalho". O agente de hoje abre seu CRM, lê pedidos, atualiza um registro de estoque, envia mensagem a um cliente e pode até preparar uma fatura. Cada uma dessas etapas significa fazer login em um sistema real com dados reais.

O problema é que as ferramentas de segurança da maioria das empresas foram construídas sobre uma única premissa: a de que quem faz login nos sistemas é um ser humano. Um número marcante que a Okta citou em seu anúncio resume a lacuna: apenas 34% das organizações aplicam aos agentes de IA os mesmos controles de segurança que aplicam aos trabalhadores humanos. Em outras palavras, cerca de dois terços das empresas têm entidades automatizadas operando dentro de seus sistemas sem o mesmo nível de governança.

Quando um agente não tem uma identidade clara, os problemas se acumulam e são todos do mesmo tipo: você não sabe quantos agentes operam dentro do seu negócio, não sabe quem autorizou cada um, não consegue responder à pergunta simples de um auditor — "quem executou esta ação?" — e não tem um único botão para apertar e parar um agente que saiu do rumo.

O que o Agent SSO realmente faz

O serviço funciona sobre um protocolo aberto chamado Cross App Access (XAA), uma extensão do conhecido padrão OAuth, que foi adotado como a extensão oficial de autorização gerenciada pela empresa para o MCP — o protocolo que se tornou a linguagem comum entre agentes e sistemas. Em resumo, quando um agente de IA compatível com esse protocolo tenta se conectar a um dos seus aplicativos de negócio, acontece o seguinte:

  • Registro: o agente é registrado como uma identidade nomeada no diretório da empresa, e não como uma chave anônima.
  • Autorização: ele recebe um token de acesso de curta duração que expira automaticamente, em vez de uma chave estática guardada em um arquivo de configuração.
  • Governança: um administrador gerencia as permissões do agente no mesmo console usado para as permissões dos funcionários.
  • Revogação instantânea: o acesso do agente pode ser cortado com uma única ação no momento em que o comportamento parecer errado.

Vale notar que a Okta incluiu o Agent SSO em sua oferta principal de login único sem custo adicional — um sinal de que quer que esse padrão se espalhe como norma, em vez de vendê-lo como recurso premium. O anúncio também citou empresas que trabalham com ela nessa abordagem, entre elas Anthropic, Atlassian, Slack, Notion, Datadog e Figma.

A nova regra: todo agente de IA que roda dentro da sua empresa deve ter um nome, um responsável humano que responda por ele, permissões delimitadas e uma data de expiração. Exatamente como um funcionário.

O que isso significa para um empresário na Arábia Saudita

Em um ano que o Reino designou como o Ano da Inteligência Artificial, as empresas estão avançando rápido para colocar agentes de IA no atendimento ao cliente, nas vendas e nas operações. E a passagem do piloto para a produção real é exatamente o ponto em que identidade e permissões deixam de ser um detalhe técnico e se tornam uma preocupação central.

Há também uma dimensão regulatória. A Lei de Proteção de Dados Pessoais (PDPL) exige que uma organização controle quem acessa dados pessoais e com que finalidade, e que seja capaz de demonstrar isso em uma auditoria. Se o seu agente de IA lê dados de clientes por meio de uma chave compartilhada que não pertence a ninguém em particular, na prática você não consegue responder à pergunta "quem acessou estes dados?" — e isso não é apenas uma fraqueza técnica, é uma lacuna de conformidade.

Passos práticos para começar hoje

Você não precisa de uma plataforma global para começar. Os mesmos princípios se aplicam a qualquer sistema interno bem construído:

  • Faça o inventário dos seus agentes: liste todas as ferramentas de IA conectadas hoje aos seus sistemas — o número vai surpreender você.
  • Uma conta separada por agente: nunca compartilhe a conta de um funcionário ou uma chave de uso geral entre várias ferramentas.
  • Privilégio mínimo: se o agente só precisa ler, não dê a ele permissão para modificar ou excluir.
  • Tokens de curta duração: substitua chaves permanentes por tokens que expiram e se renovam automaticamente.
  • Uma trilha de auditoria completa: toda ação que o agente executa é registrada com seu nome, o horário e o sistema afetado.
  • Um responsável humano: cada agente tem um funcionário responsável que revisa suas permissões periodicamente e pode pará-lo.
  • Aprovação humana para operações sensíveis: transferências financeiras, exclusão de dados e mensagens em massa para clientes precisam de um ponto de controle humano.

Como vemos isso na Origami

Quando construímos um sistema sob medida para um cliente e conectamos um agente de IA a ele, tratamos esse agente desde o primeiro dia como um usuário com conta, permissões e registro — e não como um script rodando com a chave do administrador. Essa simples decisão de arquitetura poupa o cliente de uma reconstrução depois e deixa o sistema pronto para auditoria desde o início, em vez de ser remendado na primeira pergunta de um auditor ou no primeiro incidente de segurança.

O anúncio da Okta é importante porque transforma o que antes era uma decisão tomada por cada desenvolvedor em um padrão do setor apoiado por grandes fornecedores de ferramentas. Quem construir sobre essa base hoje estará automaticamente alinhado com o que se tornará um requisito básico daqui a um ou dois anos.

Resumindo: a IA dentro da sua empresa não é mais uma ferramenta que você usa, é uma parte que age em seu nome. E qualquer parte que age em seu nome precisa de uma identidade e de limites claros — caso contrário, você está gerenciando um risco que não consegue ver.

Fontes