{
  "schemaVersion": 1,
  "id": "atlas-lesson-tool-authority-identity",
  "title": "User authority and service identity",
  "category": "learning",
  "format": "Atlas lesson",
  "description": "User authorization, workload authentication, token audience, scope and resource policy are separate checks.",
  "canonicalUrl": "https://semiaifoundry.com/learn/atlas/tool-authority-identity/",
  "publishedDate": null,
  "revisionDate": "2026-10-07",
  "author": null,
  "topic": "Authority, context and execution boundaries",
  "series": null,
  "license": null,
  "rightsUrl": "https://semiaifoundry.com/ai-atlas/licenses.html",
  "version": "1.3.0",
  "status": "Published educational lesson",
  "evidenceScope": "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.",
  "contentCoverage": "published-lesson",
  "artifactUrl": "https://semiaifoundry.com/ai-atlas/lesson-data/tool-authority-identity-f81d65aeb7da2f78.json",
  "interactiveUrl": "https://semiaifoundry.com/ai-atlas/#tool-authority-identity",
  "related": [],
  "supersedes": [],
  "supersededBy": [],
  "contentHash": "b44f3eb511c67e07c3d2597267eb5ec6ad8bac6a295ed965ab0ad011cb49204b",
  "contentLength": 6946,
  "jsonUrl": "https://semiaifoundry.com/agents/publications/atlas-lesson-tool-authority-identity.json",
  "markdownUrl": "https://semiaifoundry.com/agents/publications/atlas-lesson-tool-authority-identity.md",
  "sections": [
    {
      "id": "section-1",
      "title": "User authority and service identity",
      "start": 60,
      "end": 480
    },
    {
      "id": "section-2",
      "title": "The mechanism",
      "start": 480,
      "end": 1827
    },
    {
      "id": "section-3",
      "title": "Science and assumptions",
      "start": 1827,
      "end": 1855
    },
    {
      "id": "section-4",
      "title": "User authority and service identity · explicit relationship",
      "start": 1855,
      "end": 3060
    },
    {
      "id": "section-5",
      "title": "Engineering example",
      "start": 3060,
      "end": 3608
    },
    {
      "id": "section-6",
      "title": "Distinctions and tradeoffs",
      "start": 3608,
      "end": 3933
    },
    {
      "id": "section-7",
      "title": "Specifications and interfaces",
      "start": 3933,
      "end": 4496
    },
    {
      "id": "section-8",
      "title": "Interfaces",
      "start": 4496,
      "end": 4738
    },
    {
      "id": "section-9",
      "title": "Check your understanding",
      "start": 4738,
      "end": 4767
    },
    {
      "id": "section-10",
      "title": "A token intended for service A is presented to service B. What is required before allowing the call?",
      "start": 4767,
      "end": 5247
    },
    {
      "id": "section-11",
      "title": "Evidence and scope",
      "start": 5247,
      "end": 6124
    },
    {
      "id": "section-12",
      "title": "Sources",
      "start": 6124,
      "end": 6609
    },
    {
      "id": "section-13",
      "title": "Continue exploring",
      "start": 6609,
      "end": 6632
    },
    {
      "id": "section-14",
      "title": "Foundations",
      "start": 6632,
      "end": 6756
    },
    {
      "id": "section-15",
      "title": "Related lessons",
      "start": 6756,
      "end": 6946
    }
  ],
  "citations": [
    {
      "title": "Explore in Atlas",
      "url": "https://semiaifoundry.com/ai-atlas/#tool-authority-identity"
    },
    {
      "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/"
    },
    {
      "title": "Published lesson data",
      "url": "https://semiaifoundry.com/ai-atlas/lesson-data/tool-authority-identity-f81d65aeb7da2f78.json"
    },
    {
      "title": "Atlas releases and licensing",
      "url": "https://semiaifoundry.com/ai-atlas/licenses.html"
    },
    {
      "title": "Tool schemas and semantic validation",
      "url": "https://semiaifoundry.com/learn/atlas/tool-contracts-schemas/"
    },
    {
      "title": "Tools, memory & agent loop",
      "url": "https://semiaifoundry.com/learn/atlas/tool-loop/"
    },
    {
      "title": "Evaluation & the AGI frontier",
      "url": "https://semiaifoundry.com/learn/atlas/evaluation/"
    }
  ],
  "recordHash": "4f0d6119c55d45fc1a90d645e57c5216ccd0c5a8d3aa1a2d32259583e828bcc2",
  "contentFormat": "text/markdown",
  "content": "Authority, context and execution boundaries · Atlas v1.3.0\n\n# User authority and service identity\n\nUser authorization, workload authentication, token audience, scope and resource policy are separate checks.\n\n[Explore in Atlas](https://semiaifoundry.com/ai-atlas/#tool-authority-identity)Logical state, task evidence and declared units; no physical assembly scale\n\nLearning objectiveSeparate authentication, audience, scope, resource policy and action approval in a tool request.\n\n## The mechanism\n\nThe 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.\n\n1.  Identify the user, calling workload and receiving resource separately.\n2.  The receiver checks identity validity and the token’s intended audience under its actual authentication mechanism.\n3.  Scopes and resource policy constrain the requested action; user approval cannot silently broaden those scopes.\n4.  A denied write returns a reason and leaves the external environment unchanged.\n\n## Science and assumptions\n\n### User authority and service identity · explicit relationship\n\n$$\nA=I\\land U\\land S\\land R\n$$\n\nAn authorization decision here requires valid identity, matching audience, sufficient scope and resource policy.\n\nSymbols and units\n\nA\n\nAllowed request under the stated security contract\n\nBoolean\n\nI\n\nIdentity or credential validity\n\nBoolean\n\nU\n\nIntended resource audience matches\n\nBoolean\n\nS\n\nGranted scope permits the action\n\nBoolean\n\nR\n\nResource-specific policy permits this principal and operation\n\nBoolean\n\nConsider 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.\n\nAssumptions This is a teaching decomposition, not a complete universal authorization algorithm. The executable incident demonstrates only a bounded role/capability subset.\n\n## Engineering example\n\nConsider 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.\n\n## Distinctions and tradeoffs\n\nA trusted model or a valid token does not grant unrestricted authority.\n\nNarrow credentials reduce the consequences of misuse but require explicit delegation and renewal paths.\n\nAgent runtimes often act through software identities while remaining accountable to user and resource permissions.\n\n## Specifications and interfaces\n\nMechanism boundary\n\nWhose permission makes this action possible?\n\nThis is a teaching decomposition, not a complete universal authorization algorithm. The executable incident demonstrates only a bounded role/capability subset.\n\nEvidence type\n\nAuthored worked example\n\nThe 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.\n\n### Interfaces\n\nDeclared input and state Input\n\nIdentify the user, calling workload and receiving resource separately.\n\nChecked outcome Output\n\nSeparate authentication, audience, scope, resource policy and action approval in a tool request.\n\n## Check your understanding\n\n### A token intended for service A is presented to service B. What is required before allowing the call?\n\n1.  Accept it whenever it is well formed\n2.  Validate B as an intended audience as well as identity and permissions\n3.  Ask the model whether it feels authorized\n\nAnswer and reasoning\n\nValidate B as an intended audience as well as identity and permissions\n\nThe resource server must validate the token’s applicability to itself; model text cannot substitute for that check.\n\n## Evidence and scope\n\nThe 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.\n\nThe 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.\n\n## Sources\n\n-   [MCP authorization](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization)\n-   [OAuth 2.0 Security Best Current Practice](https://www.rfc-editor.org/rfc/rfc9700.html)\n-   [SPIFFE overview](https://spiffe.io/docs/latest/spiffe-about/overview/)\n\n[Published lesson data](https://semiaifoundry.com/ai-atlas/lesson-data/tool-authority-identity-f81d65aeb7da2f78.json) · [Atlas releases and licensing](https://semiaifoundry.com/ai-atlas/licenses.html)\n\n## Continue exploring\n\n### Foundations\n\n-   [Tool schemas and semantic validation](https://semiaifoundry.com/learn/atlas/tool-contracts-schemas/)\n\n### Related lessons\n\n-   [Tools, memory & agent loop](https://semiaifoundry.com/learn/atlas/tool-loop/)\n-   [Evaluation & the AGI frontier](https://semiaifoundry.com/learn/atlas/evaluation/)"
}