Same agent, changed context: authority applicability before continuation or return to operation
fg-tida-use-cases-same-agent-changed-context-authority-applicability-before-continuation-or-return-to-operation-86
| 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: Same agent, changed purpose: current authority applicability
Submitting organization: Individual expert contribution (Forkit AI)
Contact name: Arpita Sarker
Contact email: [a.sarker@forkit.dev](mailto:a.sarker@forkit.dev)
Sector:
- [ ] Education
- [ ] Displaced persons / humanitarian
- [ ] Health
- [ ] Financial services
- [ ] Telecom
- [ ] Media and publishing
- [ ] Logistics
- [ ] Energy
- [ ] Critical infrastructure
- [ ] Smart home / IoT
- [x] Other (specify): Enterprise software and knowledge work
2. The situation
Plain language description:
A company authorizes an AI agent to summarize specified internal product documents for product planning. Later, the same agent is asked to summarize the same documents for the same internal requester, but for sales-campaign preparation, which is outside the original grant’s purpose limitation. The case compares these two contexts and then tests whether a human reviewer’s approval to continue changes the outcome.
Actor:
Enterprise E, the principal and deployer; Agent A, with persistent identity A1; internal requester U1; Enterprise Action Service R, the relying party that permits or blocks execution; and Human Reviewer H.
Action:
Q1: Read document set D1 and return a private summary to U1. The technical operation, documents and recipient remain fixed; the declared workflow purpose changes.
Decision required:
May Enterprise Action Service R permit Agent A to perform Q1 under grant G1 for the current workflow purpose?
Problem encountered:
In the assumed workflow, R receives the agent’s identity, the existing grant and any recorded human approval, but the authorization check does not bind these to the current workflow purpose. R therefore lacks an adequate basis to distinguish an action covered by G1 from the same operation performed for a purpose outside G1.
Current mitigation:
Identity verification, role and permission checks, and human approval before continuation. Contextual authorization mechanisms could additionally evaluate purpose where it is represented and reliably established.
Residual gap:
The workflow must distinguish an unchanged grant’s provenance from its applicability to the present action and context. It must also distinguish a human’s authority to approve workflow continuation from authority to expand or replace the agent’s grant.
3. Actors and context
Taxonomy roles involved
- [x] Principal — Enterprise E, source of the mandate
- [x] Relying party — Enterprise Action Service R
- [ ] Builder
- [x] Deployer / Owner — Enterprise E
- [x] Agent instance — Agent A
- [x] User — Internal requester U1
- [ ] Infra provider
- [ ] Attestor
- [x] Other (specify): Authorized human overseer H
Mandates in this case
| Grantor | Grantee | What is conferred | Governing regime |
|---|---|---|---|
| Enterprise E | Agent A | G1: authority to read D1 and prepare private summaries for U1 solely for internal product planning. Sales-campaign preparation is outside this purpose limitation. | Germany; German law governs the assumed enterprise mandate. Enterprise policy P1 expresses its operational scope, subject to applicable law. |
| Enterprise E | Human Reviewer H | H1: authority to review, hold, constrain, approve continuation or escalate within the oversight process. H1 does not authorize H to amend G1 or originate a replacement agent grant. | Same German legal regime. Enterprise oversight policy P2 expresses H’s assumed decision rights, subject to applicable law. |
Assumptions and test boundary:
- G1 and H1 are assumed to have been validly originated. Their legal validity and the grantor’s standing are not disputed.
- A1, G1, Q1, D1 and U1 remain unchanged across the paired contexts.
- G1 is not revoked, expired, superseded or rewritten.
- Only the workflow purpose changes: internal product planning versus sales-campaign preparation.
- The current purpose is explicitly recorded and reliably established as a test input. Inferring purpose from ambiguous behaviour is outside scope.
- No other applicable agent grant is available in the negative case.
- U1’s task request does not itself confer additional authority.
- H remains authorized under H1. Human input is assumed authentic, and oversight capacity and access to relevant information are sufficient.
- The governing regime and other relevant operating conditions remain constant.
Cross-border?
- [ ] Yes — jurisdictions involved: Not applicable
- [x] No
Embodied (physical actuation or sensing)?
- [ ] Yes — physical context: Not applicable
- [x] No
Agent action type
- [x] Read-only
- [ ] Consequential (reversible)
- [ ] Irreversible
The action retrieves information and returns a private summary. It does not modify source records, send external communications or execute business transactions.
Crosses organisational boundary?
- [ ] Yes (specify): Not applicable
- [x] No
Both workflow purposes remain within Enterprise E.
Risk level
- [ ] Low
- [x] Medium
- [ ] High
Medium is assumed for this hypothetical use of internal company information outside an explicitly permitted purpose.
4. Theme relevance
| Theme | Yes | Primary | Justification (required if checked) |
|---|---|---|---|
| Dynamic Identity | [x] | [ ] | Persistent identity A1 remains unchanged across different authority-applicability outcomes. |
| Continuous Trust and Attestation | [ ] | [ ] | Not directly tested; no change in attestation is required. |
| Delegation | [x] | [x] | The case tests the continuing applicability of an existing purpose-bounded authority grant. |
| Discovery and Cross-Border Trust | [ ] | [ ] | Not exercised; the case remains within one enterprise and jurisdiction. |
| Runtime Enforcement (Control Plane) | [x] | [ ] | The current applicability determination must be consumed before execution or resumption of the affected action. |
| Embodied AI Identity and Trust | [ ] | [ ] | Not exercised; no physical actuation is involved. |
Related theme proposals:
- [Theme #5 — Provenance of Authority for Agentic AI](https://github.com/FG-TIDA/themes/issues/5)
- [Theme #16 — Operational Human Oversight Integration for Agentic AI Trust Systems](https://github.com/FG-TIDA/themes/issues/16)
The proposed interface boundary is that the authority function supplies the current applicability determination, and Theme #16 consumes it when evaluating intervention and continuation or return to operation. The case does not prescribe an implementation or introduce a parallel authority model.
5. Requirements
These are proposed requirements for review.
| # | Type (choose one) | Requirement description | Criticality (choose one) |
|---|---|---|---|
| 1 | Technical | Persistent agent identity, grant provenance and current authority applicability shall remain distinguishable. | Must |
| 2 | Technical | An applicability determination shall identify the agent, grant, action, relevant context and assessment time. | Must |
| 3 | Technical | A material change to a grant-relevant contextual condition shall trigger revalidation before execution or resumption of the affected action. | Must |
| 4 | Technical | Contextual inapplicability shall remain distinguishable from revocation, expiry, supersession, absence of a grant and insufficient evidence to determine applicability. | Must |
| 5 | Technical | Human approval to continue shall not expand or replace the agent’s grant unless the applicable authority model permits that human to establish such authority and an explicit authority-establishing act occurs. | Must |
| 6 | Technical | An action shall not proceed under a grant that is inapplicable or whose applicability cannot be established. The original grant record and the reason for the current determination shall be preserved. | Must |
6. Assessment criteria
Success criteria:
Pair 1 — context change without grant mutation
Both variants use the same A1, G1 and Q1, including the same documents and output recipient.
- Variant A: internal product planning. The workflow purpose satisfies G1’s purpose limitation. G1 is applicable, and the action may proceed subject to other applicable controls.
- Variant B: sales-campaign preparation. The workflow purpose is outside G1’s purpose limitation. G1 is inapplicable, and the affected action must not execute under it.
G1 remains unchanged and available for actions within its original scope. The negative result is contextual inapplicability, not revocation, expiry or loss of agent identity.
Pair 2 — human intervention after the applicability check
Apply the same human-review checkpoint to both variants. H records an authentic approval to continue the workflow under H1.
| Context | Human decision | Expected outcome |
|---|---|---|
| A: internal product planning | Approve continuation | G1 remains applicable. The action may proceed if the other oversight and runtime conditions are satisfied. |
| B: sales-campaign preparation | Approve continuation | G1 remains inapplicable. H’s approval does not expand G1, and the affected action must not proceed under it. |
H may hold or escalate the affected action. This does not itself require revoking G1 or stopping unrelated actions that remain authorized.
If Enterprise E subsequently originates a bounded grant G2 for the new purpose, that grant must be explicitly recorded and assessed for current applicability. This would be a separate authority-establishing event, not an implicit restoration or rewriting of G1.
Measurable metric:
For these defined hypothetical test cases:
- Correct applicability determination in all four conditions: A and B, each before and after human approval.
- Zero executions permitted under G1 in the sales-purpose conditions.
- Every determination identifies A1, G1, Q1, the assessed purpose, assessment time and reason.
- G1’s original content and provenance remain unchanged in every condition.
- No contextual-inapplicability result is mislabeled as revocation or insufficient evidence.
These are proposed acceptance criteria, not reported implementation results.
7. Duplication check
Existing standards or SDOs:
- [NIST SP 800-162 — Guide to Attribute Based Access Control (ABAC) Definition and Considerations](https://csrc.nist.gov/pubs/sp/800/162/upd2/final)
- [IETF RFC 9334 — Remote ATtestation procedureS (RATS) Architecture](https://www.rfc-editor.org/rfc/rfc9334.html)
- Related FG-TIDA work: [Theme #5](https://github.com/FG-TIDA/themes/issues/5) and [Theme #16](https://github.com/FG-TIDA/themes/issues/16)
Overlap notes:
ABAC already supports authorization decisions using subject, object, operation and relevant environmental attributes. Existing contextual authorization mechanisms may implement the purpose-sensitive decision in this case.
RATS addresses evidence appraisal and attestation results supporting relying-party decisions. Attestation can complement, but does not by itself establish, the purpose limitation and human grant-making rights assumed here.
This submission does not claim that existing mechanisms cannot support the scenario or propose a replacement authorization architecture. It supplies a concrete paired test for the Theme #5 / Theme #16 interface: preserve grant provenance while determining current applicability, and distinguish oversight approval from an act that establishes new authority.
The contribution is a scenario and proposed assessment criteria for the existing workstreams. Further overlap review, including against relevant ITU-T study-group work, remains open.
8. Maturity
Pilot status
- [x] Hypothetical
- [ ] Pilot in progress
- [ ] Deployed in production
Reference implementation: N/A — no implementation is submitted.
9. IP and confidentiality
Confidentiality level
- [x] Public
- [ ] FG-internal only
- [ ] Redact before publication
IP notes:
Individual expert contribution by Arpita Sarker, affiliated with Forkit AI. The scenario is hypothetical and contains no confidential customer or deployment information. No proprietary implementation is included.
10. Assets
Link to assets:
- [ ] Dataset
- [ ] Code
- [ ] Protocol
- [ ] Other: None supplied
No implementation assets accompany this submission. Following semantic review, the agreed cases may be mapped into executable fixtures in coordination with the [UC-4 discussion](https://github.com/FG-TIDA/use-cases/issues/4).
IP notes:
Not applicable to implementation assets; none are submitted.
Revisions
- No file revisions have been uploaded.