[Use Case] Upstream model update invalidates derived payment authority mid-chain
fg-tida-use-cases-use-case-upstream-model-update-invalidates-derived-payment-authority-mid-chain-68
| Type | FG-TIDA document |
|---|---|
| Group | Trust and Identity for Humans and Agentic AI |
| State | Submitted |
| Authors | Not entered |
| Last updated | 2026-10-23 15:11 UTC |
Formats and resources
Abstract
1. Identification
Title: Upstream model update invalidates derived payment authority mid-chain
Submitting organization: Solutions by Jewel
Contact name: Jewel Darlington
Contact email: governance@solutionsbyjewel.com
Sector (tick all that apply; a cross-industry case may tick more than one):
- [ ] Education
- [ ] Displaced persons / humanitarian
- [ ] Health
- [x] Financial services
- [ ] Telecom
- [ ] Media and publishing
- [ ] Logistics
- [ ] Energy
- [ ] Critical infrastructure
- [ ] Smart home / IoT
- [x] Other (specify): Enterprise procurement and accounts payable
2. The situation
Plain language description (required, 3 sentences max): An organization authorizes a procurement agent to pay approved suppliers, and that agent issues narrower authority to a payment agent to settle one invoice. Before the payment executes, the procurement agent's model is updated. The payment service receiving the instruction must decide whether authority derived from the procurement agent still holds.
Actor (every party involved): Organization O (principal and deployer); procurement agent A1 (agent instance deployed by O); payment agent A2 (agent instance deployed by O, acting on authority derived from A1); payment service S (relying party, operated by a separate organization); independent termination authority T (designated by O).
Action: A2 submits an instruction to S to pay one supplier invoice under authority derived from A1.
Decision required: May S execute A2's payment instruction when A1, the agent that issued A2's authority, has changed model version since issuing it?
Problem encountered: S lacks two inputs the decision depends on: (1) a binding between A2's grant and the model version A1 was running when it issued that grant, and (2) a status signal showing that A1's authorization moved to suspended after the update.
Current mitigation: O sets per-transaction ceilings, human approval above a stated threshold, and a stop condition on supplier bank-detail changes. Exceptions go to manual review.
Residual gap: After an upstream version change, every downstream artefact still passes the checks available to S, and S executes an irreversible payment under authority whose technical basis has changed. Any rejection S makes lacks a standard record linking the trigger, the chain and the decision.
3. Actors and context
Taxonomy roles involved
- [x] Principal — possesses the authority being exercised; source of the mandate
- [x] Relying party — must decide whether to accept the agent's authority
- [ ] Builder
- [x] Deployer / Owner
- [x] Agent instance
- [ ] User — interacts with the agent; may or may not be the principal
- [ ] Infra provider
- [ ] Attestor
- [x] Other (specify): Independent termination authority (T), designated by the principal to suspend or revoke the chain
Mandates in this case (required)
| Grantor | Grantee | What is conferred | Governing regime |
|---|---|---|---|
| Organization O | Procurement agent A1 | Pay approved suppliers; per-transaction ceiling; 30-day validity; human approval above a stated threshold; stop condition on any change of supplier bank details; authority to issue narrower derived grants within these limits | Agency and contract law of O's jurisdiction, with O's account agreement with its bank. Single regime; the jurisdiction is left open so participants can test the case against their own regime |
| Procurement agent A1 | Payment agent A2 | Pay one invoice from one supplier, for the invoice amount, valid 24 hours; equal to or narrower than A1's grant on every condition | Same regime as the O → A1 mandate; the derived grant carries the parent's limits |
| Organization O | Independent termination authority T | Suspend or revoke A1 and every grant derived from A1; place agents in a defined safe state | O's internal governance instrument under the same regime |
Cross-border?
- [ ] Yes — jurisdictions involved:
- [x] No
Embodied (physical actuation or sensing)?
- [ ] Yes — physical context:
- [x] No
Agent action type (required; tick all that apply. Where several apply, the most consequential governs the case)
- [ ] Read-only
- [x] Consequential (reversible)
- [x] Irreversible
Crosses organisational boundary? (required)
- [x] Yes (specify): O's agents instruct payment service S, operated by a separate organization
- [ ] No
Risk level (required)
- [ ] Low
- [ ] Medium
- [x] High
4. Theme relevance
| Theme | Yes | Primary | Justification (required if checked) |
|---|---|---|---|
| Dynamic Identity | [x] | [ ] | A1 keeps its agent identity across a model update. S needs the execution instance and material version that issued A2's grant, so identity and version have to be bound to the grant. |
| Continuous Trust and Attestation | [x] | [ ] | The model update is a material change to a condition supporting A1's authorization. A1's status moves to suspended pending reassessment, and that status must be checkable at action time. |
| Delegation | [x] | [x] | A2's authority is derived from A1. Its validity depends on the parent grant and on the issuing agent's state, and suspension or revocation of the parent must reach every derived grant. |
| Discovery and Cross-Border Trust | [ ] | [ ] | |
| Runtime Enforcement (Control Plane) | [x] | [ ] | S enforces the decision at the moment of action and records the rejection with the chain, the trigger and the decision time. |
| Embodied AI Identity and Trust | [ ] | [ ] |
Related theme proposals: #5 (Provenance of Authority for Agentic AI), #23 (authorization and privilege lifecycle management of AI agents), #16 (Operational Human Oversight Integration), #1 (accountability and attribution after an agent has acted). Related use cases: #9 (payment rail, authority traced to a principal) and #6 (same agent, changed context).
5. Requirements
| # | Type (choose one) | Requirement description | Criticality (choose one) |
|---|---|---|---|
| 1 | Technical | A derived grant references its parent grant and binds to the issuing agent's execution instance identity and material version (system, model, configuration). | Must |
| 2 | Technical | Each grant declares the conditions under which it ceases to bind. A material version change in any issuing agent in the chain is a declared condition. | Must |
| 3 | Technical | A change in an issuing agent's authorization status propagates to every grant derived from it, and a relying party can check that status at action time without contacting the issuing agent. | Must |
| 4 | Technical | Derived authority is equal to or narrower than its parent on every condition, and each hop records the attenuation it applies. | Must |
| 5 | Technical | After reassessment, resumption runs on newly issued derived authority scoped to the resulting state. Earlier grants stay expired and remain in the chain as history. | Must |
| 6 | Technical | The relying party records each rejection as adverse evidence: the grant chain, the trigger, the status checked and the decision time. | Must |
| 7 | Business | The principal designates an independent termination authority able to suspend or revoke the chain without the participation of the acting agents. | Should |
| 8 | Technical | Evidence presented to the relying party is sufficient for the specific action it supports, with the evidence burden scaled to consequence. An irreversible payment carries the highest burden in this case. | Should |
6. Assessment criteria
Success criteria: S rejects A2's instruction after A1's model update, records the rejection with the chain and the trigger, and accepts a later instruction issued under reassessed authority.
Measurable metric: For a test chain of depth N, the share of descendant grants invalidated after a version change at hop k (target 100%), and the elapsed time from the version change to the first relying-party rejection.
7. Duplication check
Existing standards or SDOs (which existing work touches this case): Recommendation ITU-T X.509 (attribute certificates and privilege management, including delegation of privilege); IETF RFC 8693 OAuth 2.0 Token Exchange (actor and may_act claims); W3C Verifiable Credentials Data Model v2.0; IETF RFC 9334 RATS Architecture; ITU-T SG17 proposed work item X.aplm-aia (privilege lifecycle management for AI agents, referenced in themes #23).
Overlap notes (why the work named above does not already solve this): X.509 privilege management and RFC 8693 express delegation and the acting party. RATS conveys evidence about an agent's state. The gap this case isolates sits between them: a derived grant's validity tied to the material version of the agent that issued it, with status propagating to every descendant grant. Use case #9 covers revocation after composition across agents holding separate mandates. This case covers invalidation inside a single delegation chain, triggered by a technical change in an upstream agent.
8. Maturity
Pilot status
- [x] Hypothetical
- [ ] Pilot in progress
- [ ] Deployed in production
Reference implementation: n/a. Conceptual reference: SBJ AI Governance Architecture V2.0 (AC-01 Authorization Invalidation Trigger Semantics; AC-03 Delegation and Branch-and-Merge Provenance; AC-04 Execution Identity and Material Version Binding; AC-05 Evidence Sufficiency as an Authorization Condition), https://solutionsbyjewel.com/ai-governance/architecture/
SBJ independently benchmarked Architecture V1.0 against six publicly documented real-world AI cases: 185 applicable determinations (160 Pass, 24 Partial, 0 Fail, 1 Insufficient Evidence, 7 Not Applicable), validated with material limitations within the tested scope. Autonomous irreversible material financial transactions were inadequately represented in that cohort, and SBJ makes no validation claim for that authority class. This use case targets that class directly. The organizations referenced in the benchmark did not participate in, sponsor or endorse SBJ's work.
9. IP and confidentiality
Confidentiality level
- [x] Public
- [ ] FG-internal only
- [ ] Redact before publication
IP notes (optional): Uses the publicly disclosed constructs of SBJ AI Governance Architecture V1.0 and V2.0. SBJ implementation mechanics sit outside this submission.
10. Assets
Link to assets:
- [ ] Dataset
- [ ] Code
- [ ] Protocol
- [x] Other: SBJ AI Decision Record V2.0 technical package (JSON Schema and conformance fixtures), https://github.com/solutionsbyjewel/sbj-ai-governance-decision-record ; SBJ AI Governance Architecture V1.0 record, https://solutionsbyjewel.com/sbj-ai-governance-architecture-v1
IP notes (optional): The example is synthetic and offered for requirements analysis.
Revisions
- No file revisions have been uploaded.