A policy residual is the remaining predicate after a policy engine evaluates every fact already known about an authorization request. Rather than returning only Permit or Deny, it states the constraints that must still hold for access to be allowed. This makes authorization useful before all runtime facts, candidate resources, or agent actions are available. section 13.5.3 section 17.4.3
For a document search, known action and tenant information can be applied when policy is published or queried. The residual becomes a scope describing resources or principals that could satisfy the policy. Static conditions can then become data operations: a shared department becomes a table join, a shareable flag becomes an indexed search constraint, and membership in viewers becomes a relationship-based access control (ReBAC) graph traversal. section 13.5.3
A residual supports a two-stage authorization flow:
- Evaluate known request facts to derive a policy-derived scope before broad search or retrieval. section 13.5.3 section 17.4.3
- Translate the scope into database, graph, or vector-store metadata constraints where translation is practical. section 13.5.3 section 17.4.3
- Evaluate remaining candidates through the policy decision point (PDP) when dynamic context, such as time windows, session risk, or device posture, still matters. section 13.5.3
- Treat the final PDP decision as authoritative unless an action is purely relational and has no dynamic context or policy information point lookups. section 13.5.3
Authorization before RAG retrieval
In retrieval-augmented generation (RAG), a residual can be converted into a filter over chunk metadata such as tenant, ownership, or classification. Retrieval then considers only chunks in the authorized scope, so the language model receives authorized inputs rather than being asked to avoid unauthorized content afterward. When a semantic search produces a small candidate set, an alternative is to batch-authorize candidate identifiers and retrieve content only for permitted resources. section 17.4.3
Constraint-aware agent planning
An agent can submit a partial request while planning and receive a residual describing policy-derived constraints. It can choose a plan within those constraints instead of repeatedly trying actions that will be denied. This guidance does not grant access: each planned action still requires a complete runtime authorization check before execution. section 18.4 section 18.4.2
# Example: docs this user can access
cands = graph.traverse_from_principal(p, action="doc:view")
scoped = prefilter_by_scope(cands, action="doc:view")
result = pdp.batch_authorize(principal=p, action="doc:view",
resources=scoped, context=ctx)
docs = [r for r, dec in result.items() if dec == "Permit"]
The listing shows a practical sequence: traverse relationship candidates, prefilter them with a policy scope, batch-authorize survivors, and display only permitted documents. section 13.5.3
Residuals separate early scoping from final enforcement. They can reduce unnecessary retrieval and provide usable planning constraints, but they must not be mistaken for a decision on a fully specified request. Dynamic conditions and complete request context remain the responsibility of the final authorization evaluation. section 13.5.3 section 18.4.2
