01 / The operating case
What changes in a real workflow?
One parent grants two children bounded invoice tasks, while a third child attempts to submit a payment outside every path.
- 01Authority origin
- 02Task and grant
- 03Current decision
- 04Observed outcome
02 / Decision contract
What the executor must check
At decision time traverse the relevant ancestor path, validate expiry and narrowing, intersect policy and reject missing or circular links.
Architecture review / negative test
Make the boundary testable.
Model grants as directed edges with immutable identifiers and a declared parent. A validation algorithm should reject cycles, missing parents, expired ancestors and scope widening before evaluating policy. Include task state and approvals as referenced facts; do not assume that a graph database itself creates authorization or makes stale edges current.
03 / Failure and evidence
What goes wrong, and what can be proven?
A flat list of roles cannot establish which specific parent authorized the attempted payment.
Store graph edge identifiers and the validated path in evidence without leaking more sensitive data than necessary.
04 / Canonical scope
Why this reference stands alone
Provenance emphasizes explanation of origin; this architecture page owns graph structure and validation invariants.
Technical deep dive
Validate the chain as a graph, not a list of roles.
An authority graph needs edge integrity and monotonic narrowing. Before a leaf grant authorizes an action, traverse to a trusted origin, verify each issuer and parent reference, check expiry and revocation at every hop, and compute the effective intersection of scopes. A missing ancestor is a denial, not an opportunity to fall back to the child’s credential. Graph storage is an implementation choice; the security property is that the path and its constraints are verifiable at decision time.
Organization: payment.release ≤ $100,000
└─ Finance agent: payment.release ≤ $25,000
└─ Invoice child: invoice.match only
Request: payment.release $8,400 → DENY
Reason: operation absent from child grantRun the negative test
Delete the finance-agent edge after the child is issued. A decision that evaluates only the child will falsely allow; a chain validator must deny because it cannot reach a valid origin. Then attach a second parent approval that denies the target and confirm effective authority is the intersection, not whichever parent permits more.
Continue to Shared authority budgets for the adjacent boundary.
Architecture field test
An authority graph is a decision input
Which path gave this principal permission?
- 01Name accountable origin
- 02Trace signed grant edges
- 03Intersect constraints along path
- 04Bind leaf decision to effect
Work the boundary
A maintenance coordinator delegates inspection to one agent and restart to another. If the inspection agent asks for restart, the graph must not borrow the sibling restart edge simply because both descend from the coordinator.
| Required facts | Edge issuer and subject, parent reference, task, scope, expiry, revocation state and policy version. |
|---|---|
| Allow only when | At least one valid, authorized path supports the action without mixing incompatible permissions from separate paths. |
| Deny when | A missing parent, cycle, wider child edge or revoked origin breaks the asserted path. |
Break the assumption
Construct a diamond-shaped delegation graph with two paths to the same child. Remove one parent and attempt an action only that path authorized. The evaluator must report which remaining path, if any, supports it.
Design tradeoff
Graph provenance improves explanation but requires stable edge identifiers and careful path semantics. A graph picture is insufficient unless an executor uses its validated effective scope.
For an authority graph is a decision input, consult NIST NCCoE agent identity and authorization concept. This worked decision and negative test are ProofGrid analysis.
Continue with Authority provenance.
Primary references