Authority provenance

Authority provenance is the verifiable origin and sequence of grants behind an agent’s requested effect. It is not the same as a credential issuer.

01 / The operating case

What changes in a real workflow?

An operations agent invokes a shutdown API using its valid workload identity; an investigator must learn which approved incident and operator originated permission.

Trace the authority boundary
  1. 01Authority origin
  2. 02Task and grant
  3. 03Current decision
  4. 04Observed outcome

02 / Decision boundary

Put the check where it can stop the effect.

Join owner, task, parent grants and approval references to the decision while preserving the meaning and scope of each link.

Architecture review / negative test

Make the boundary testable.

Keep the difference between a grant issuer, the identity provider and the accountable human or organization. A credential may be issued by a cloud platform while the business permission originated with an incident commander. Record this relationship as explicit references rather than deriving it from a free-text log or the last user who touched a ticket.

03 / Failure and evidence

What goes wrong, and what can be proven?

Failure mode

A log identifies the calling service but cannot explain who gave it permission for this shutdown.

Evidence to retain

Keep stable grant references and issuance/revocation events; do not assert non-repudiation from a mere event log.

04 / Canonical scope

Why this reference stands alone

The authority graph describes the data relationships; provenance answers the incident-review question of origin.

Architecture field test

Provenance must survive the decision

Who supplied the authority being exercised?

Decision path for this question
  1. 01Record accountable origin
  2. 02Preserve delegation edge IDs
  3. 03Validate current effective scope
  4. 04Join decision and outcome evidence

Work the boundary

A remediation agent requests a firewall block through a child worker. The security team needs to know which incident authorized the block, which operator delegated the task, which child performed it and whether the firewall rule took effect. A child token by itself answers only one of those questions.

Decision contract and failure case
Required factsOriginator, grant issuer, delegation chain, purpose, task, protected action and the records of effect.
Allow only whenThe provenance chain is intact and every issuer was entitled to narrow the authority it passed on.
Deny whenA child presents a valid-looking grant whose parent or business origin cannot be found.

Break the assumption

Delete the parent edge reference from an otherwise valid child request. Reject rather than infer authority from a familiar workload identity. Later, join the decision ID to firewall state; a provenance trail without an effect trail is incomplete.

Design tradeoff

Preserving immutable provenance across runtimes adds correlation and retention obligations. Minimize sensitive payloads, but keep stable references and integrity evidence needed to reconstruct the chain.

For provenance must survive the decision, consult NIST NCCoE agent identity and authorization concept. This worked decision and negative test are ProofGrid analysis.

Continue with Authority graph.

Primary references

Read the underlying material

Architecture discussion

Choose one consequential action and make its boundary explicit.

Request a Conversation