{"id":"tool-authority-identity","name":"User authority and service identity","shortName":"User authority and service identity","role":"User authorization, workload authentication, token audience, scope and resource policy are separate checks.","description":"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.","mechanism":["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."],"learningObjective":"Separate authentication, audience, scope, resource policy and action approval in a tool request.","engineeringExample":"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.","misconception":"A trusted model or a valid token does not grant unrestricted authority.","check":{"question":"A token intended for service A is presented to service B. What is required before allowing the call?","options":["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":1,"explanation":"The resource server must validate the token’s applicability to itself; model text cannot substitute for that check."},"checks":[],"prerequisites":["tool-contracts-schemas"],"related":["tool-loop","evaluation"],"specs":[{"label":"Mechanism boundary","value":"Whose permission makes this action possible?","context":"This is a teaching decomposition, not a complete universal authorization algorithm. The executable incident demonstrates only a bounded role/capability subset."},{"label":"Evidence type","value":"Authored worked example","context":"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":[{"name":"Declared input and state","direction":"in","signal":"Identify the user, calling workload and receiving resource separately."},{"name":"Checked outcome","direction":"out","signal":"Separate authentication, audience, scope, resource policy and action approval in a tool request."}],"tradeoff":"Narrow credentials reduce the consequences of misuse but require explicit delegation and renewal paths.","whyAI":"Agent runtimes often act through software identities while remaining accountable to user and resource permissions.","sourceIds":["automation-mcp-auth","automation-oauth-bcp","automation-spiffe"],"sources":[{"title":"MCP authorization","url":"https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization"},{"title":"OAuth 2.0 Security Best Current Practice","url":"https://www.rfc-editor.org/rfc/rfc9700.html"},{"title":"SPIFFE overview","url":"https://spiffe.io/docs/latest/spiffe-about/overview/"}],"science":[{"title":"User authority and service identity · explicit relationship","equation":"An authorization decision here requires valid identity, matching audience, sufficient scope and resource policy.","explanation":"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."}],"evidenceNotes":"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.","level":"software","branch":"Authority, context and execution boundaries","subbranch":"User authority and service identity","scale":"Logical state, task evidence and declared units; no physical assembly scale","kind":"system","workstream":"W11","visualFamily":"software-flow","labId":"library","labScope":"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.","history":[],"workedTrace":{"readScopeAllowsReservation":false,"stockAfterDenial":4}}