The mechanism
The person asking for work, the software making a request and the service receiving it are distinct principals. Authentication establishes an identity under a particular trust mechanism. Authorization evaluates whether that principal may perform a particular action on a particular resource. A service identity can be genuine while its request is outside the user’s permitted scope. Token audience and expiry also matter: possession of a token intended for one resource is not authority at every other service. Model output cannot create credentials or expand a capability. The incident fixture demonstrates a deliberately small role/capability gate: a read-only user can obtain asset and manual data but cannot reserve stock. It does not implement token issuance, OAuth, workload attestation or cryptographic signatures. Those mechanisms explain why a production boundary requires more than a prompt saying that an action is allowed.
- Identify the user, calling workload and receiving resource separately.
- The receiver checks identity validity and the token’s intended audience under its actual authentication mechanism.
- Scopes and resource policy constrain the requested action; user approval cannot silently broaden those scopes.
- A denied write returns a reason and leaves the external environment unchanged.
Science and assumptions
User authority and service identity · explicit relationship
An authorization decision here requires valid identity, matching audience, sufficient scope and resource policy.
Symbols and units
- A
- Allowed request under the stated security contract
Boolean
- I
- Identity or credential validity
Boolean
- U
- Intended resource audience matches
Boolean
- S
- Granted scope permits the action
Boolean
- R
- Resource-specific policy permits this principal and operation
Boolean
Consider a synthetic token with audience maintenance-api and scope asset:read. An authenticated read of FAN-7 can be allowed, but a reservation requires a write scope and the relevant resource policy. Sending that token to a payroll service should fail audience validation even if its signature is otherwise valid. In the local incident case the read-only role reaches a schema-valid reservation proposal and is denied before review or service; all four FILTER-A units remain. The example uses role flags, not real tokens.
Assumptions This is a teaching decomposition, not a complete universal authorization algorithm. The executable incident demonstrates only a bounded role/capability subset.
Engineering example
Consider a synthetic token with audience maintenance-api and scope asset:read. An authenticated read of FAN-7 can be allowed, but a reservation requires a write scope and the relevant resource policy. Sending that token to a payroll service should fail audience validation even if its signature is otherwise valid. In the local incident case the read-only role reaches a schema-valid reservation proposal and is denied before review or service; all four FILTER-A units remain. The example uses role flags, not real tokens.
Distinctions and tradeoffs
A trusted model or a valid token does not grant unrestricted authority.
Narrow credentials reduce the consequences of misuse but require explicit delegation and renewal paths.
Agent runtimes often act through software identities while remaining accountable to user and resource permissions.
Specifications and interfaces
- Mechanism boundary
- Whose permission makes this action possible?
This is a teaching decomposition, not a complete universal authorization algorithm. The executable incident demonstrates only a bounded role/capability subset.
- Evidence type
- Authored worked example
The durable incident experience executes typed fixture tools, authority checks, exact review, receipts and independent final-state checks. Its policies are authored code and its storage boundary is local; it is not a real model or production workflow platform.
Interfaces
- Declared input and state Input
- Identify the user, calling workload and receiving resource separately.
- Checked outcome Output
- Separate authentication, audience, scope, resource policy and action approval in a tool request.
Check your understanding
A token intended for service A is presented to service B. What is required before allowing the call?
- Accept it whenever it is well formed
- Validate B as an intended audience as well as identity and permissions
- Ask the model whether it feels authorized
Answer and reasoning
Validate B as an intended audience as well as identity and permissions
The resource server must validate the token’s applicability to itself; model text cannot substitute for that check.
Evidence and scope
The durable incident experience executes typed fixture tools, authority checks, exact review, receipts and independent final-state checks. Its policies are authored code and its storage boundary is local; it is not a real model or production workflow platform. The quantities and fixtures are authored. Source scope is recorded in the automation learning review manifest; no source benchmark or private system behavior is claimed. This is a teaching decomposition, not a complete universal authorization algorithm. The executable incident demonstrates only a bounded role/capability subset.
The durable incident experience executes typed fixture tools, authority checks, exact review, receipts and independent final-state checks. Its policies are authored code and its storage boundary is local; it is not a real model or production workflow platform.