Task-bound authority

Task-bound authority scopes a grant to a work item, its target and completion or cancellation state, rather than a reusable standing role.

01 / The operating case

What changes in a real workflow?

An agent assigned invoice I-42 finishes reconciliation; its later attempt to read I-57 with the same token must not inherit I-42 permission.

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

02 / Decision contract

What the executor must check

Issue a task reference, check its active state for consequential calls and revoke dependent grants on completion or cancellation.

InputPrincipal · task · action · target
DecisionGrant ancestry · policy · current state
ResultEnforce · record · verify outcome

Architecture review / negative test

Make the boundary testable.

Define the state machine for assignment, active work, cancellation, completion and uncertain execution. A task identifier needs a trusted issuer and one scoped target set. When a task closes, dependent grants should stop authorizing new actions even if a session or workload credential remains technically valid.

03 / Failure and evidence

What goes wrong, and what can be proven?

Failure mode

Long-lived tokens outlive the work, and a new assignment silently reuses the prior task’s authority.

Evidence to retain

Correlate grant issuance, task state transitions, action decisions and cancellation events.

04 / Canonical scope

Why this reference stands alone

Purpose describes why an action is allowed; task binding describes which instance of work owns it.

Primary references

Read the underlying material

Architecture discussion

Choose one consequential action and make its boundary explicit.

Request a Conversation