Docs

Documento de permissões

As cinco partes da configuração de um agente e o que cada uma vira na decisão.

Cada agente tem um documento de permissões com revisões: um rascunho em edição e as revisões publicadas. O documento tem cinco partes. Quatro delas correspondem a um passo da ordem de avaliação; a quinta, os escopos, agrupa as delegações por identity provider.

Scopes são os identity providers de onde o agente aceita sujeitos. Cada escopo guarda o consentimento, registrado por um administrador, e uma data de fim opcional para todas as delegações daquele provedor. Um escopo sem consentimento não é publicado. Um escopo também pode aceitar o consentimento da pessoa a partir de um harness de código (person_consent): os grupos elegíveis do IdP, pelo menos um, e a validade padrão e a máxima. O documento também guarda a lista blocked: pessoas vetadas no agente, acima de qualquer grupo, delegação ou consentimento (Quem pode delegar).

Delegations são os sujeitos que delegam ao agente: issuer, subject e tipo, dentro do escopo do provedor deles. Antes de entrar, o sujeito é confirmado pelo provedor dele.

Capabilities são as tools que o agente pode chamar, por server, sempre com a lista explícita de tools e expiração opcional. Não existe "todas as tools do server".

Resources são os allowed values: os valores exatos que o agente pode usar no allowed values parameter de uma tool, por server, por exemplo os repositórios em que o agente pode agir. O backend mantém esses valores, mas o Admin não os mostra, porque eles só conferem uma lista de valores exatos, o que uma regra já faz (order_id in ["1001", "1002"]), e o parâmetro deles pertence à tool, então escolhê-lo muda todo agente que chama a tool. Eles ainda não têm hierarquia.

Conditions são expressões CEL com nome, com os bindings de que dependem e com os limites da instância que leem (required_limits), cada uma presa a uma aresta agente · server · tool. Elas não viram tuplas, porque o OpenFGA não avalia dados da chamada (Condições).

O que a publicação confere

Antes de aceitar uma revisão, a publicação confere que os issuers são confiáveis, que as tools estão revisadas no catálogo, que os bindings das condições estão ativos, que os mappings que definem os tipos de recurso existem e que cada sujeito existe no provedor. Uma revisão com qualquer referência quebrada não é publicada.

Remover o agente apaga todas as tuplas dele no OpenFGA antes de remover a configuração.