IAM e SSO: quem acessa o quê, inclusive o agente de IA

Uma analista de compras sai da empresa numa quarta-feira. O RH avisa a TI por e-mail. A TI bloqueia o e-mail corporativo no mesmo dia. No mês seguinte, alguém descobre que ela ainda tinha login no portal do fornecedor, no sistema de cotação e na ferramenta de assinatura de contratos. Cada um desses sistemas tinha senha própria e um dono diferente, e nenhum estava ligado a um programa de IAM e SSO.

Agora troque a analista por um agente de IA de atendimento ligado ao CRM, ao ERP e ao WhatsApp, com uma conta de serviço que alguém criou com acesso de administrador "só para o piloto". Quem desliga esse acesso quando o piloto acaba?

IAM e SSO resolvem os dois casos. O IAM organiza quem acessa o quê, por quanto tempo e com aprovação de quem. O SSO concentra o login num lugar só, o que acelera o desligamento e multiplica o estrago se esse lugar cair. O agente de IA entra nessa conta como mais uma identidade, com dono, escopo e prazo.

Por que identidade virou o perímetro

O DBIR 2025 da Verizon registrou o uso de credenciais roubadas como o vetor de acesso inicial mais frequente, presente em 22% das violações analisadas. Com login e senha válidos, vindos de phishing, de senha reaproveitada ou de infostealer, o atacante não precisa quebrar firewall nenhum.

A pergunta útil passa a ser quantas credenciais existem, onde funcionam e quanto tempo levam para morrer. É a lógica do Zero Trust: cada acesso é avaliado pela identidade e pelo contexto, porque estar dentro da rede já não prova nada.

IAM e SSO ao lado de MFA, PAM e IGA

As cinco siglas costumam aparecer juntas e parecem sinônimos. IAM e SSO formam a base, e as outras três se apoiam nelas.

IAM (Identity and Access Management) é o guarda-chuva: o diretório, as regras de quem acessa o quê e os processos de criar, alterar e remover acesso.

SSO (Single Sign-On) é o login único. A pessoa se autentica uma vez no provedor de identidade (Entra ID, Okta, Google Workspace e similares) e os outros sistemas confiam nisso.

MFA (autenticação multifator) é o segundo fator no login, tema do post sobre MFA. Nem todo MFA resiste a phishing.

PAM (Privileged Access Management) cuida das contas que podem derrubar a empresa, como administrador de domínio e console da nuvem. Guarda a senha em cofre e libera o acesso só pelo tempo da tarefa.

IGA (Identity Governance and Administration) é a governança: quem aprovou cada acesso e se ele ainda faz sentido. Inclui a recertificação periódica, em que o gestor confirma ou retira o que o time tem.

A ordem que mais vejo dar resultado é SSO com MFA forte primeiro, PAM para as contas críticas e IGA quando os acessos já não cabem numa planilha. Começar por IGA antes de ter IAM e SSO funcionando gera relatórios sobre um ambiente que ninguém consegue desligar.

O ciclo joiner, mover, leaver

Toda identidade passa por três eventos, e o IAM existe para que cada um aconteça sem depender de memória.

Joiner: a entrada

O cadastro no RH gera a conta no diretório e o pacote de acesso da função. Se a TI cria contas a partir de e-mail do gestor, o pacote varia conforme quem atendeu o chamado.

Mover: a mudança de área

É o evento mais negligenciado. A pessoa sai do financeiro para o comercial, ganha os acessos novos e mantém os antigos, porque ninguém pediu para tirar. Esse acúmulo é o que a recertificação do IGA procura.

Leaver: a saída

Aqui IAM e SSO pagam o investimento: desativar a conta no provedor de identidade corta o login em todos os sistemas ligados a ele. A analista do começo perderia os três acessos assim que o RH registrasse a saída.

Sessões abertas e contas locais em cada sistema podem seguir vivas, e é aí que entra o SCIM.

SAML, OIDC, OAuth 2.0 e SCIM em linguagem simples

São eles que fazem IAM e SSO funcionarem entre sistemas de fornecedores diferentes.

• SAML: o provedor de identidade entrega ao sistema um atestado assinado de quem é a pessoa e de que ela já se autenticou. É antigo e está em quase toda aplicação corporativa.
• OIDC (OpenID Connect) faz o mesmo papel sobre OAuth 2.0 e é o padrão em aplicações web e mobile recentes.
• OAuth 2.0 trata de autorização, e não de login: define o que um aplicativo pode fazer em nome de alguém, por meio de tokens com escopo e prazo. É a base da seção sobre agentes de IA.
• SCIM é o protocolo de provisionamento: quando o RH admite, transfere ou desliga alguém, o provedor cria, altera ou remove a conta nos sistemas conectados, sem chamado.

Antes de assinar com um fornecedor de SaaS, eu perguntaria: o plano contratado tem SSO via SAML ou OIDC e provisionamento via SCIM? Muitos só oferecem os dois no plano mais caro, e essa diferença entra na conta.

O risco do SSO: a chave mestra

Com o login concentrado, quem sequestra a sessão do provedor herda tudo o que está atrás dele.

A primeira defesa é MFA resistente a phishing. A CISA chama esse tipo de MFA de padrão-ouro e reconhece duas formas: FIDO/WebAuthn (chaves físicas e passkeys) e MFA baseado em certificado (PKI). Código por SMS e aprovação por push simples continuam vulneráveis a página falsa que repassa o código em tempo real e a troca de chip. A revisão 4 da NIST SP 800-63B vai na mesma direção. No nível AAL2, o verificador precisa oferecer ao menos uma opção resistente a phishing, e no AAL3 ela é obrigatória. O uso de telefone (SMS e ligação) como canal de verificação fica classificado como restrito.

A segunda é acesso condicional: o provedor avalia dispositivo, país e risco do login antes de liberar. Um administrador num notebook desconhecido em outro continente deveria ser barrado, mesmo com senha e MFA corretos.

Minha posição: SSO bem protegido é mais seguro do que quarenta senhas independentes. SSO com MFA por SMS é um atalho para o atacante. Num projeto de IAM e SSO, comprar o SSO e exigir MFA resistente a phishing dos administradores deveriam ser uma decisão só.

Identidades não humanas e o agente de IA

A maior parte das identidades de uma empresa não é gente: são contas de serviço, chaves de API e tokens, tema do post sobre identidade de máquina. O agente de atendimento tem uma diferença que muda o risco: lê texto de fora (a mensagem do cliente) e decide sozinho qual ferramenta chamar.

Uma injeção de prompt escondida numa mensagem executa com as permissões do agente. O desenho de identidade define o tamanho do estrago.

Identidade própria, com dono

Nada de conta pessoal de quem configurou nem conta genérica compartilhada. O agente precisa de identidade registrada no provedor, com finalidade e um responsável humano. Sem isso, o log do incidente mostra que "a integração" fez algo, sem dizer qual.

Escopo mínimo por ferramenta

Cada ferramenta do agente recebe permissão própria e estreita. Consultar status de pedido é leitura numa tabela; emitir segunda via de boleto é outra permissão; alterar cadastro é outra, que talvez nem devesse existir sem confirmação humana. O erro comum é dar o papel de "usuário do CRM" inteiro porque permissão fina dava trabalho. Vale em dobro com ferramentas via servidor MCP, em que cada servidor carrega as próprias credenciais.

Tokens de curta duração

Token que vale minutos limita a janela de quem copiá-lo. Chave estática na configuração vale até alguém trocá-la, o que raramente acontece.

Agir em nome do usuário

Quando o agente consulta os dados de um cliente, o ideal é usar um token obtido por delegação, que carrega a autorização daquele cliente. O OAuth 2.0 prevê esse fluxo pela troca de tokens descrita no RFC 8693, e alguns provedores o chamam de on-behalf-of. Assim, o agente que atende o cliente A não lê os pedidos do cliente B, porque o token não permite.

Uma conta de serviço que enxerga a base inteira e confia no prompt para filtrar deixa a segurança na mão do modelo. O modelo segue instruções escritas, e quem escreve a mensagem pode ser o atacante.

Revisão periódica

O agente entra na mesma recertificação do IGA que as pessoas. A cada trimestre, o dono revisa as permissões, e a que não apareceu nos logs no período sai. Quando o piloto acaba, a identidade é desativada como a de um funcionário desligado. O tema continua no post sobre segurança de IA no atendimento, já que o agente trabalha 24 horas e lê mensagens de estranhos.

Por onde começar

Uma sequência de IAM e SSO que cabe em um trimestre numa empresa média:

1. Meça o desligamento hoje. Pegue a última pessoa que saiu e conte quantos sistemas ainda tinham conta dela uma semana depois. Esse número justifica o projeto.
2. Ligue os dez sistemas mais críticos ao SSO. E-mail, ERP, CRM, nuvem, VPN, financeiro. Ative SCIM onde o sistema suportar.
3. Exija MFA resistente a phishing para administradores do provedor de identidade e das contas privilegiadas. Passkey ou chave FIDO2, sem SMS.
4. Configure acesso condicional básico: bloqueio por país inesperado e exigência de dispositivo gerenciado para acesso administrativo.
5. Inventarie as identidades dos agentes e integrações de IA, com dono, escopo e validade de token. As de acesso amplo vão primeiro para revisão.
6. Faça a primeira recertificação só das contas privilegiadas.

Nada disso exige uma plataforma de IGA no primeiro dia. Boa parte dos itens 2 a 4 vem na licença do provedor de identidade que a empresa já paga e não configurou.

A pergunta para a próxima reunião

Se a pessoa com mais acesso na sua empresa pedisse demissão hoje, em quanto tempo todos os acessos dela estariam revogados, e quem saberia confirmar? Agora pergunte o mesmo sobre o agente de IA que responde seus clientes. Se a segunda resposta for mais vaga que a primeira, é por ela que o projeto de IAM e SSO deveria começar.