Amarrar o acesso do agente ao crachá da pessoa

Cada pessoa que sai da empresa pode deixar para trás dezenas de acessos de agente ainda abertos, espalhados pelos sistemas de fornecedores. Hoje esse acesso é concedido pessoa a pessoa e servidor a servidor, e o desligamento no sistema de login não fecha nenhum deles. O resultado é um passivo de auditoria que cresce a cada contratação e só aparece no dia da saída.

O gargalo aparece primeiro como incômodo, e depois como passivo

Quando o time começa a ligar agentes a sistemas, cada pessoa autoriza cada servidor à mão. Abre a tela de consentimento, lê uma lista de permissões que ninguém lê e clica em permitir. A documentação oficial faz a conta: numa empresa de 50 funcionários com 10 servidores conectados, são 500 autorizações individuais antes de qualquer trabalho começar.

Todo mundo reclama do incômodo, que é visível. O passivo ninguém vê, porque ele só aparece no desligamento. Cada uma daquelas 500 autorizações criou uma concessão guardada no servidor de autorização de um terceiro, fora do alcance do seu provedor de identidade (o sistema que controla login, grupos e papéis, como a portaria central do prédio). Desligar o crachá não desliga nenhuma delas.

A pergunta que abre este capítulo tem resposta hoje na sua casa, e a resposta costuma ser que ninguém sabe. Se um gerente comercial sair amanhã, quantos acessos de agente ficam abertos e quem executa a revogação? Sem resposta, o processo de desligamento está incompleto, e isso é achado de auditoria antes de ser problema técnico.

Como funciona o acesso que segue o crachá

A extensão chama-se io.modelcontextprotocol/enterprise-managed-authorization, ficou estável em 18/06/2026 e entrou como extensão formal na revisão 2026-07-28. A ideia é curta. Durante o login único da manhã, o cliente obtém do provedor de identidade uma asserção assinada (um atestado com carimbo, como a declaração do RH) dizendo quem é a pessoa e a que ela tem direito.

Essa asserção é trocada por um token de acesso (a pulseira de evento que abre só aquele salão) no servidor de destino. Os padrões por trás da troca são a RFC 8693 e a RFC 7523, dois documentos técnicos públicos da comunidade da internet. O efeito prático tem três partes: servidores conectados no primeiro acesso, política vivendo nos grupos e papéis da casa, e revogação central.

Para quem responde por conformidade, esse é o argumento que fecha a conversa. O item a auditar deixa de ser a lista de conectores instalados, que muda toda semana, e passa a ser a política do provedor de identidade. A empresa já opera esse sistema, já o audita e já sabe demonstrá-lo a um terceiro.

A restrição que define o seu cronograma

No lançamento de junho havia um único provedor de identidade atendido, o Okta. Empresa em outro provedor continua na revogação manual até que o provedor dela emita a asserção. Nenhum fornecedor de servidor resolve isso pelo lado dele, porque a ponta que falta é a de identidade.

Mude, portanto, o destinatário da pergunta. Antes de perguntar ao fornecedor do servidor se ele atende a autorização gerenciada, pergunte ao fornecedor de identidade da casa se ele emite a asserção e em que trimestre. Se a resposta vier vaga, adie a promessa de provisionamento central e mantenha a revogação manual documentada no processo de desligamento, com dono nomeado.

Os adotantes declarados em junho dão a leitura de maturidade. Okta como provedor de identidade; Claude, Claude Code, Cowork e Visual Studio Code como clientes; Asana, Atlassian, Canva, Figma, Granola, Linear e Supabase como servidores. Em 25/09/2026 a Anthropic abriu o portal de publicação de plugins do Claude anunciando suporte à autorização gerenciada. A lista cresce, e continua curta diante dos sistemas de uma empresa média.

O perfil de autorização que governa este protocolo

Dizer que o produto usa OAuth 2.0 (o padrão de mercado para um sistema autorizar outro sem entregar senha) informa pouco. OAuth é um arcabouço amplo e comporta implementações que abrem exatamente os riscos que interessam aqui. O protocolo exige um perfil específico, com exigências nomeadas e datadas. A tabela abaixo é o que um auditor cobra e cabe num anexo de contrato.

Duas exigências merecem tradução antes da tabela. A primeira é a audiência do token: o token emitido para o servidor de um fornecedor vale só para ele, senão vira chave de outros sistemas seus. A segunda é a proibição de repasse: quando um servidor repassa um token que não foi emitido para si, o registro de acesso deixa de identificar quem agiu, e a investigação fica inconclusiva.

A revisão 2026-07-28 acrescentou duas amarras. O servidor de autorização passa a declarar quem emitiu a credencial, no campo iss (o carimbo do cartório que reconheceu a firma), e o cliente é obrigado a conferir. A credencial do cliente também fica presa a esse emissor: trocar de provedor exige novo registro.

O que fazer antes da próxima reunião

Envie hoje a pergunta por escrito ao fornecedor de identidade da casa e cobre resposta em 15 dias úteis. Mande também as três perguntas a cada fornecedor de servidor: audiência do token, validação do emissor e escopo da primeira conexão. Quem não responder às três em 15 dias sai da lista de renovação automática.

Em seguida, escolha uma conta desligada no mês passado e cronometre quanto tempo levou para fechar o último acesso de agente. A meta é 24 horas. Se ninguém souber responder, registre isso como achado na ata e siga para "Controlar a tela de terceiro dentro da conversa", que trata do que muda quando o fornecedor passa a devolver interface.