Permission document
The five parts of an agent's configuration and what each one becomes in the decision.
Each agent has a revisioned permission document: a draft being edited and the published revisions. The document has five parts. Four of them correspond to a step of the evaluation order; the fifth, the scopes, groups the delegations by identity provider.
Scopes are the identity providers the agent accepts subjects from. Each scope holds the consent, recorded by an administrator, and an optional end date for every delegation of that provider. A scope without consent is not published. A scope can also accept person consent from a coding harness (person_consent): the eligible IdP groups, at least one, and the default and maximum validity. The document also holds the blocked list: people vetoed on the agent, above any group, delegation or consent (Who can delegate).
Delegations are the subjects that delegate to the agent: issuer, subject and kind, inside the scope of their provider. Before it is added, the subject is confirmed by its provider.
Capabilities are the tools that the agent can call, per server, always with an explicit tool list and an optional expiration. There is no "all tools of the server".
Resources are the allowed values: the exact values the agent can use in the allowed values parameter of a tool, per server, for example the repositories where the agent can act. The backend keeps them, but the Admin does not show them, because they only check a list of exact values, which a rule already does (order_id in ["1001", "1002"]), and their parameter belongs to the tool, so choosing it changes every agent that calls the tool. They have no hierarchy yet.
Conditions are named CEL expressions with the bindings they depend on and the instance limits they read (required_limits), each attached to one agent · server · tool edge. They do not become tuples, because OpenFGA does not evaluate call data (Conditions).
What publication checks
Before it accepts a revision, publication checks that the issuers are trusted, that the tools are reviewed in the catalog, that the condition bindings are active, that the mappings that define the resource types exist and that each subject exists in its provider. A revision with any broken reference is not published.
Removing the agent deletes all of its tuples in OpenFGA before the configuration is removed.