Quem pode delegar

A primeira pergunta de toda chamada é se o sujeito delegou ao agente. A coluna Who can delegate responde a ela. Sem delegação, o agente nem consegue token: o token exchange falha com no_delegation, e a chamada também (Delegação).

A delegação é configurada por provedor de identidade. Cada provedor conectado ao ambiente pode aparecer uma vez na coluna, com os sujeitos marcados dele.

Manage identity providersCopiar link da seção

Manage identity providers, na barra de seção, mostra quantos provedores o agente tem. Com um, abre o painel dele. Com nenhum ou vários, abre a lista: quantos sujeitos delegam e de quantos provedores, depois uma linha por provedor com os tipos e as delegações ("People · Delegations: 2 of 7"). Cada linha abre o painel daquele provedor, com Back to para a lista. Add identity provider inclui um provedor habilitado que ainda não está na lista; quando todos os provedores habilitados já estão nela, a lista sugere conectar outro em Identity providers.

O painel do provedorCopiar link da seção

Clicar num provedor no grafo seleciona a ligação provedor → agente e abre o painel:

Includes diz que tipos de sujeito o provedor oferece a este agente:

• People: pessoas que entram no IdP e usam o agente, por exemplo no editor.
• Services: service accounts. Um sistema roda o agente sozinho, com token próprio, como um pipeline de release.

Who can delegate · N of M é a lista do diretório, com uma seção People e uma seção Services. Cada seção mostra "N of M" e tem Select all N ou Clear. A busca procura em todos os sujeitos do provedor; os marcados aparecem primeiro, e Show more carrega mais de 10 em 10.

Expires é Never ou On a date; escolher uma data abre o calendário. Define se a delegação desse provedor acaba naquele dia. É uma condição da relação no OpenFGA: depois da data, nenhum sujeito do provedor delega mais ao agente, sem ninguém precisar desmarcar.

Last consent recorded mostra quem registrou o consentimento e quando. O ícone de ajuda explica de onde ele vem.

Remove {provedor} tira o provedor e todas as delegações dele do rascunho.

Select all não é "todo mundo"Copiar link da seção

Não existe um modo "todos, inclusive os futuros". Select all marca cada sujeito que o diretório lista agora, e a publicação grava uma delegação para cada um. Quem for criado no IdP depois não entra sozinho: o administrador marca e publica de novo. A decisão é deliberada: uma delegação sempre aponta para um sujeito que alguém viu na lista.

ConsentimentoCopiar link da seção

A delegação diz que a pessoa autorizou o agente, então esse consentimento precisa estar registrado.

Ele vem de uma de duas fontes:

• O administrador, para os sujeitos marcados na lista. O consentimento é registrado uma vez para cada identity provider no agente, não por pessoa: o Admin registra quem confirmou e quando, a partir do administrador logado, e um provedor sem consentimento não pode ser publicado.
• A pessoa, no login a partir de um harness de código (Harness login). Cada pessoa aceita na página de consentimento, e o registro guarda a pessoa, o grupo que a tornou elegível e a validade.

Alguns IdPs conseguem provar a delegação por conta própria (Entra On-Behalf-Of, Okta Cross App Access, o claim act no Keycloak). O Xokepoint ainda não aceita essas provas, então um sujeito da lista precisa do consentimento no Admin para todo provedor, Keycloak e Google Workspace inclusive.

Harness loginCopiar link da seção

O bloco Harness login fica no painel do provedor, abaixo do registro de consentimento. Pessoas deste identity provider entram a partir de um harness de código e consentem elas mesmas; o administrador escolhe quais grupos podem. O agente continua decidindo o que elas podem fazer: servers, tools e regras são os mesmos para todos.

• Quando o provedor não inclui People, o bloco só diz "Include People above to let people log in from a harness."
• A chave People in chosen groups can log in from a harness liga o modo: "They consent at login. You do not list them one by one."
• A caixa de regra abaixo da chave diz a regra: Only members of these groups can log in. Uma pessoa do provedor fora dos grupos é recusada no login e nunca vê o agente. Sem grupo, a caixa diz "Choose at least one group. Without a group, harness login stays off." e o rascunho não pode ser publicado.
• Groups são chips dos grupos do diretório do provedor, com busca. No Keycloak, o chip mostra o caminho do grupo ao passar o mouse. Um grupo escolhido que não existe mais no diretório continua visível, marcado "Not found in {provedor}". Os grupos casam pelo ID no provedor: um grupo renomeado mantém o acesso, um grupo apagado e criado de novo não.
• Consent lasts {n} days e At most {m} days: a validade padrão de um consentimento e a máxima. A primeira é no máximo a segunda, e um consentimento nunca dura mais que a expiração do provedor.
• Um aviso aparece sempre que a chave está ligada: "Removing someone from a group in {provedor} does not cut access at once. It ends after 24 hours without use or when the consent ends. To cut access now, block the person."

A participação nos grupos é lida do diretório do provedor a cada login (Conectar um provedor de identidade). No Keycloak, a participação por um grupo pai não é herdada, e no Microsoft Entra ID e no Google Workspace grupos aninhados não são seguidos: a pessoa precisa ser membro direto de um grupo escolhido. No Okta, o grupo Everyone, que reúne todas as pessoas da org, não pode ser escolhido.

BlockedCopiar link da seção

Blocked · N lista as pessoas vetadas no agente, com nome, sujeito, motivo e Unblock. Escolha uma pessoa do diretório e Block. Uma pessoa bloqueada não usa o agente, sejam quais forem os grupos ou o consentimento dela. Bloquear não exige a chave ligada, e também tira a delegação da pessoa do rascunho.

Um bloqueio faz parte do rascunho e do histórico de revisões. Quando você publica, os consentimentos e as máquinas dessa pessoa no agente são revogados na hora, e ela não consegue mais entrar nele. Block em Harness sessions adiciona a pessoa a esta lista.

Desligar o harness login, tirar People do provedor ou remover o provedor revoga os consentimentos desse provedor quando você publica. Remover um grupo revoga os consentimentos que foram aceitos só por esse grupo.

Adicionar um provedorCopiar link da seção

Add identity provider, na lista de identity providers, mostra o formulário de inclusão:

1. Identity provider: os provedores conectados que ainda não estão no agente.
2. Includes: pessoas, serviços ou os dois.
3. Who can delegate: marque os sujeitos.
4. Expires: nunca, ou numa data.
5. A caixa de confirmação: "I confirm that these subjects agreed to let {agente} act for them". Ela grava o consentimento com o nome do administrador e a hora.
6. Add N to draft só fica disponível com pelo menos um sujeito marcado e a confirmação feita.

Antes de entrar na publicação, cada sujeito é confirmado pelo provedor. Um usuário removido do diretório não vira delegação.

A delegação de uma pessoaCopiar link da seção

Uma delegação individual tem seu próprio painel, aberto pela lista do provedor ou pelo painel de grupo: sujeito e tipo, consentimento, expiração e Remove delegation. Uma delegação nunca tem regras sobre dados da chamada: Rule on call data fica desabilitado com o motivo "Who can delegate has no rules. Add the rule to a tool of the agent."