Docs

Enrichment

The PIP fetches from trusted customer APIs the facts that the decision needs and that are neither in the token nor in the call.

Some rules depend on facts that are neither in the token nor in the tool call. "Can only refund orders below the customer limit" needs the limit, which lives in the billing system. "Can only touch tickets of their own team" needs the team of the ticket. Putting these facts in the token does not work: the token would be issued with the value from hours ago, and it would grow with every new rule.

The PIP (Policy Information Point) solves this at call time. It fetches the facts from trusted sources, customer APIs that the administrator registered, and adds them to the AuthZEN question before it reaches the PDP.

Context source, binding and trusted attributes

A context source is an authorized API of the customer: address, GET method and its own credential, stored encrypted. A binding is one operation of that source, approved for one server tool, that enriches the subject or the object of the call. It can be written by hand or imported from OpenAPI 3. It says which identifiers come from trusted inputs of the call and which response fields become trusted attributes, with a declared type. In the Admin, each binding is a row of the Trusted attributes tab.

The trusted attributes go into subject.properties.chokepoint and resource.properties.chokepoint. The PIP overwrites these fields, so no mapping can fake a trusted attribute. Each one carries the value, the source and binding revisions and the time it was resolved.

Fetching is not deciding

The split follows the model that Cerbos uses in its External API: one layer fetches facts, another evaluates them. The PDP's CEL conditions only read the facts that the PIP delivered. They make no HTTP calls. This keeps evaluation predictable and makes it possible to record exactly which facts supported a decision.

The agent token never goes to the sources. Each source uses its own credential.

When a fact is missing

A fact that the policy requires and that did not arrive blocks the call with 503. A source that is disabled, or whose configuration changes during the call, also blocks. Ignoring the fact would evaluate the condition without it, and the result could be an ALLOW that nobody configured.

The cache stores source responses, never decisions. It is bounded in size and qualified by scope, revisions, identity, resource and parameters, and its lifetime is configured on each source.