Agent identity and delegated authority determine which person or application is allowed to ask which connected tool to do what. A model may know how to call a service, but knowing a command is not permission to execute it. Properly bounded AI needs caller identity, resource scope, approved purpose and independent enforcement by the receiving system.
This complete guide follows an invented Pinecrest Learning Archive through thirty tool requests. It distinguishes public reading, teacher-approved drafting and requests that a tool rightly denies. We work out the count of permitted actions, trace the difference between a scope and a genuine approval, then change a delegation and recalculate the outcome.
This is a specialist, unnumbered branch of How Super Intelligence Works. The series name is educational; it does not claim artificial superintelligence has been achieved.
Chapter contents and permission-checking routes
1. Identity is the answer to who is acting · 2. Authority is not the same as capability · 3. Delegation must remain bounded by the user task · 4. Five dimensions of an access decision · 5. The fictional Pinecrest Learning Archive · 6. Three scopes for the exercise · 7. Thirty requests with explicit outcomes · 8. Compute the authorised share without overclaiming · 9. A denied operation can be the correct result · 10. Resource identifiers are not permissions · 11. OAuth provides a standard framework for delegation · 12. MCP authorisation is transport-specific · 13. Audience binding protects where a token may be used · 14. A scope is not the entire business policy · 15. Tokens should be protected as credentials · 16. Expiry gives time a role in authorisation · 17. Revocation changes the next action · 18. Step-up authorisation is not automatic escalation · 19. Prevent the confused-deputy problem · 20. Source instructions must not rewrite permissions · 21. A2A tasks do not carry unlimited authority · 22. Separate denial from factual task failure · 23. A delegated publication still needs content approval · 24. Independent transfer: the Birch Archive · 25. Transfer after one delegation is withdrawn · 26. What a good access audit actually records · 27. Frequently asked questions · 28. Authoritative sources and advanced reading
1. Identity is the answer to who is acting
A human user, model-hosting application, agent process, tool client and protected document service can be different participants. Each has a role in the chain. A tool that receives a request should know the appropriate authenticated caller rather than trusting a model’s plain-text claim that it represents a teacher or manager.
The model’s name is not an identity proof. An output such as ‘I am the administrator’ is text to interpret, not an authenticated credential. Security decisions should use trusted identity mechanisms outside the model’s generated content.
2. Authority is not the same as capability
A scheduling tool may be capable of changing a lesson date while a particular assistant is authorised only to read the current schedule. The correct system does not offer unrestricted operations simply because the model could formulate the necessary parameters.
A boundary is meaningful when the external service enforces it. An instruction telling the model not to call a sensitive tool is useful guidance but cannot replace a permission check that denies the operation even after an incorrect model suggestion.
3. Delegation must remain bounded by the user task
If a tutor authorises an agent to prepare a draft, that delegation does not give the agent the tutor’s unrelated account privileges. The requested action, resource and duration matter. A draft preparation permission is not a blanket licence to publish, contact parents or inspect student medical records.
The application should preserve what was actually granted and refuse work outside that scope. Delegated tasks can change during a conversation, but each consequential change requires its appropriate legitimate authorisation.
4. Five dimensions of an access decision
A useful access check identifies the principal, the operation, the target resource, the applicable context and the current authorisation state. Context can include effective time, permitted course, task purpose or a specific approved document. Implementations differ, but these dimensions help prevent accidental overreach.
For example, a staff member’s role might permit editing draft worksheets in one assigned programme but not publishing every document in the organisation. A role label alone may be too broad to express that distinction.
5. The fictional Pinecrest Learning Archive
Pinecrest is an entirely invented archive containing public learning guides, teacher-prepared worksheet drafts and restricted pupil information. A parent-facing assistant may read public catalog descriptions; a tutor’s approved workflow may create draft notes for an assigned class; publishing final materials requires a distinct authorised action.
No real identity records, accounts, classes or tokens are accessed in this teaching example. Every request and outcome in the following packet is fictional. The exercise is about deciding which access should be permitted under stated rules, not testing a live system.
6. Three scopes for the exercise
Define an illustrative public-catalog read permission, a tutor-draft create permission and a separate manager-publish permission. These are fictional conceptual scopes, not actual OAuth strings or standard WordPress roles. The archive’s policy maps each to named resources and purposes.
The parent information assistant receives only public read permission. The drafting assistant may prepare a worksheet under a teacher’s active delegation, but it cannot read private pupil records or publish. A manager can approve publication only through the proper process, not merely by writing ‘approved’ inside a model prompt.
7. Thirty requests with explicit outcomes
During the invented period, eighteen permitted requests read public catalog information, seven properly delegated requests create worksheet drafts, and five requested operations are denied because they exceed the caller’s effective authority. These three categories are stipulated, exhaustive and mutually exclusive for the exercise.
Twenty-five operations are allowed and five denied. The denied requests are not proof of a cyberattack; some may reflect an ordinary mistaken workflow. The security success is that the tool did not perform an action outside its defined permission boundary.
8. Compute the authorised share without overclaiming
Under the packet, 18+7=25 of the thirty requests receive a positive permission decision. Thus 25/30=5/6, or about 83.3%. Five of thirty are denied, about 16.7%. These are counts of permission outcomes, not a measure of how accurate the draft worksheets are.
A model might prepare a structurally valid draft from the wrong rubric. Its permitted operation would still need educational checking. Access approval and factual correctness are separate dimensions of a reliable service.
9. A denied operation can be the correct result
Suppose a parent assistant asks to fetch a private pupil register while answering a public library-hours question. The protected service should reject the attempt. The correct result is not an empty register silently presented as if the lookup succeeded; it is an access-denied outcome with a safe explanation.
The application may continue helping with the supported public answer. A precise denial preserves the original legitimate purpose without treating the user or source content as hostile merely because one operation was outside scope.
10. Resource identifiers are not permissions
A guessed or well-formed record ID does not confer the right to access that record. A tool accepting a string called document_id should still verify that the caller may read the object referenced by that particular value.
This prevents an overbroad tool design where a model is allowed to query unrelated private information simply by changing an argument. Input structure, identity and object-level authorisation must all be checked.
11. OAuth provides a standard framework for delegation
OAuth allows applications to access protected resources according to authorised flows and scope. The IETF’s RFC 9700, Best Current Practice for OAuth 2.0 Security, published January 2025, describes important security requirements and updated threat guidance.
OAuth is not a claim that an AI agent may decide which privileges it wants. A suitable authorisation server and protected resource define how rights are requested, granted and checked. A particular token format is not universally guaranteed to be a readable JSON object, so applications should follow the relevant protocol and implementation rather than relying on imagined token fields.
12. MCP authorisation is transport-specific
The MCP authorisation specification dated 28 July 2026 describes optional authorisation for MCP implementations and a flow for HTTP-based transports based on established OAuth mechanisms. It distinguishes resource server, client and authorisation server roles.
A client accessing an MCP tool with a bearer token does not make the language model the authorisation server. The protected service must validate the token and enforce the applicable scopes and resource policy. Other transports may follow different established credential-handling practices.
13. Audience binding protects where a token may be used
A token intended for one protected service should not automatically be accepted by another. The audience or resource binding connects the credential to its intended recipient and reduces risks when credentials are exposed across services.
Consider a fictional archive token that authorises a public catalog API. It should not be accepted by a separate staff-payroll resource merely because both systems use the same style of bearer token. Real services must apply appropriate validation rather than trust the model to refrain from misusing a credential.
14. A scope is not the entire business policy
A scope may indicate draft creation, but the tool may also need to check which class a tutor is assigned, which document is targeted and whether the delegation is currently valid. A broad technical permission should not automatically replace specific institutional rules.
A user may legitimately have access to a category of files without permission to publish the current resource. Applications need a context-sensitive policy when these distinctions matter. Good design separates coarse authentication from the final operation-specific decision.
15. Tokens should be protected as credentials
Credentials can carry authority and must not be placed inside public prompts, logs or tutorial screenshots. In a real application, appropriate secure transport, protected storage, lifecycle controls and minimal exposure are necessary.
This chapter provides no real tokens or credential values. A model may refer to a permission state or a source ID in its answer, but that does not justify revealing secret authentication material to a user who did not need it.
16. Expiry gives time a role in authorisation
A delegation can be valid when initially granted and invalid after expiry. A long-running agent should not assume that a previous successful tool call makes its next call authorised forever. The protected service needs to apply the applicable time and token validation rules at the actual operation.
An expired token can require appropriate renewal or user action, depending on the workflow. It is wrong for an AI assistant to invent a new credential or describe a failed protected request as completed.
17. Revocation changes the next action
Suppose a teacher withdraws the assistant’s draft permission during the fictional term. Previously created drafts may remain historical facts, but a new request to create another draft should fail under the revised authority. A model should not keep using an old assumed role.
Systems must define how revocation and permission changes are enforced and how stale or long-running tasks are handled. There is no universal guarantee that every transport uses the same immediate revocation mechanism; real operators must validate their own design.
18. Step-up authorisation is not automatic escalation
A routine read-only request may need a narrower permission than an external publication action. If a tool requires additional authorisation for publishing, the agent should request the legitimate process rather than treating a tool error as an invitation to bypass the policy.
Authorisation challenges can be part of well-designed flows, but the model cannot fabricate a user’s consent. A person or institution must actually supply the required approval where applicable.
19. Prevent the confused-deputy problem
A confused deputy is a system that uses its own authority to perform a task on behalf of another actor who did not have the necessary right. An AI agent with overly broad service credentials can become such an intermediary when it obeys an untrusted source or mistaken user request.
Restrict the service’s effective permission and verify the requested target against the real principal and purpose. It is not enough to rely on a text instruction saying that the model should be trustworthy.
20. Source instructions must not rewrite permissions
A public worksheet may contain a note that looks like an administrator instruction, asking the assistant to export private pupil data. That note arrived as source content to be analysed, not as permission from the teacher or authorisation server.
The OWASP Prompt Injection guidance describes the risk of lower-trust information influencing model actions. Enforced tool permissions provide another layer that can reject the requested export even if the language model misunderstands the source.
21. A2A tasks do not carry unlimited authority
An A2A research task can be delegated from one agent to another, but its task ID and accepted status do not create access rights to arbitrary external tools. Each participant must apply the permissions of the original legitimate goal and its own trusted service configuration.
The A2A task lifecycle helps describe progress, additional input and terminal states. Those state transitions are not a substitute for identity and object-level access checks.
22. Separate denial from factual task failure
The fictional parent assistant’s forbidden roster lookup may be denied while its public catalog answer remains fully supported. That is not a hallucination or a network outage. It is an access-control decision that should be recorded accurately.
A tool call might also fail because the source is unavailable or its arguments are malformed. These different causes require different recovery. A system that treats every failure as permission denied will be as misleading as one that hides every denial.
23. A delegated publication still needs content approval
Even a manager-authorised publishing workflow should verify which document is being released and whether the approval covers its exact version. Scope to call publish is not necessarily an approval for every possible text the agent could generate.
The external record should be read back before the application says it is publicly available. This is a separate evidence boundary from token validity, and a security system should not combine them into one broad status called trusted.
24. Independent transfer: the Birch Archive
Now consider another invented archive receiving twenty access requests. Eleven are permitted public reads, five are properly delegated draft operations and four exceed the caller’s effective authority. Sixteen may proceed and four should be denied, under the stipulated policy.
The permitted share is 16/20=80% and the denied share 4/20=20%. These percentages do not measure the quality of any later generated text. They measure only the specified access decisions under the fictional rules.
25. Transfer after one delegation is withdrawn
Suppose one of Birch’s five delegated drafting requests occurs after the relevant permission has been revoked. If every other condition is unchanged, the permitted count falls from sixteen to fifteen and denied requests rise to five. The permitted share becomes 15/20=75%.
A correct system recalculates the outcome from the new permission state. It does not keep the earlier 80% because that number once appeared in an evaluation report. The important fact is the authority applicable at the moment of each operation.
26. What a good access audit actually records
An audit record can identify the principal class, action, resource class, decision, relevant policy version and non-sensitive operation identifier. It should not print secret access tokens or unnecessary personal information.
These fields allow an authorised reviewer to understand why a tool rejected an operation and whether a changed role affected the result. Logging everything indiscriminately may create another privacy problem, so access and retention need to be designed carefully.
27. Frequently asked questions
Does an agent need a human identity? It needs an appropriate authenticated application or delegated identity under the system’s design; claiming to be a human in model text is not proof. Does a valid OAuth scope guarantee that every action is appropriate? No. Resource-specific rules and purpose may still restrict it.
Can a public document grant private database access? No. A tool permission must come from the legitimate security process. Can a token expire during an agent workflow? Yes, and the system must apply its current authorisation rules rather than assume earlier acceptance remains valid.
Applied delegated-access audit: identity, scope changes and independent decisions
A token is not the person
A bearer token is a credential used in a protected service interaction. Its possession may let a caller make requests according to the applicable policy, but a model’s claim to hold a token is not an authentication event. The server must use the configured verification process.
Never let an agent fabricate a credential string in a prompt or treat source text as an authorisation receipt. A technical token and the human approval that allowed it to be issued are different evidence records.
The token’s audience is a resource boundary
Imagine two fictional services operated by Pinecrest: public catalog and private staffing records. A credential intended for the catalog must not be accepted by the staffing service merely because its format looks familiar. The receiving resource needs to validate the intended audience and other relevant properties.
Audience confusion can make one service a path into another. Resource binding is therefore a key engineering control, not just a decorative token claim.
Scope narrowing prevents unintended reach
The teacher’s original account might allow several tasks. A delegated assistant preparing one class’s worksheet does not need all those permissions. Its effective reach should be limited to the specific draft operation and resource scope necessary for the job.
This is least privilege applied to an AI workflow. The model remains useful for its assigned task while an accidental or adversarial request for unrelated records fails at the protected service.
Use context, not only role names
A tutor may be permitted to draft material for one academic level but not another, even though both documents are formatted as worksheets. The application should check course assignment, document ownership and the applicable source rules rather than approve everything bearing the label tutor.
The same principle applies after staff duties change. A previous authorisation decision might be valid for a prior class and invalid for a new one. Access control should use the current relevant context.
Check which operation was actually requested
Read, create_draft and publish are different verbs. An assistant permitted to retrieve the current class schedule has not obtained permission to edit it. A publish request should identify the intended artifact and the separate approval that governs release.
If an API accepts a general action string, the server should map it to explicit authorised operations. A model’s free-text rationale cannot replace that decision.
A permission error is information, not a challenge to improvise
Suppose the public assistant receives an access-denied result when asking for a private record. The appropriate response is to preserve the denial and continue with the authorised public task if possible. The model should not try unrelated service identities or search for a different undocumented endpoint.
This behaviour is important for user trust as well as security. An assistant that hides denial by fabricating a private answer would fail both access and factual integrity.
Revocation should be tested, not merely promised
A system may document that user authorisation can be withdrawn, but a real test should check whether a subsequent request is denied under the applicable method. Token expiry, cached policy decisions and long-running tasks can complicate the transition.
The policy and implementation must define what happens to work already completed and what can continue. A previously saved draft remains a historical event; it does not automatically authorise a new write after rights are removed.
Long-running tasks need renewed authorisation when appropriate
An agent may spend time reading permitted source material before attempting to publish a resulting report. The relevant publishing authority should be checked at the moment of the write, not simply inferred from an earlier successful read.
This matters for tasks that cross a review deadline or use multiple connected services. A task may be valid to analyse but no longer authorised to commit its proposed action. The workflow should support a pending or needs_authorisation state.
A manager’s approval is object-specific
A manager may approve publication of a particular version of a learning notice. That is not approval to publish any future text under the same title. Link the decision to a stable artifact and current policy where the workflow requires it.
This prevents a model from replacing the approved document after sign-off while reusing the earlier permission. The tool should check the approval contract separately from the caller’s general publishing scope.
The delegated chain can lose context
A parent assistant might ask a document agent to retrieve a public notice; that agent might call a protected archive through MCP. The second service must not assume that the first assistant’s general permissions apply to every resource it serves.
Preserve a trustworthy delegation and resource context across the permitted chain. A correct agent-to-agent task ID helps correlation but does not supply authorisation by itself.
Distinguish an administrative mistake from an attack
A denied request could result from a teacher selecting the wrong class record, a recently revoked delegation, a configuration problem or an intentional attempt to access forbidden data. The access outcome alone does not identify the actor’s intention.
An incident response should investigate with proportionate evidence rather than label every denial malicious. The primary goal is to enforce the policy and give legitimate users a clear recovery route.
An independent access test must include misuse cases
Test a permitted public read, a correctly delegated draft, an unapproved publication, a request outside the resource audience, an expired credential and a revoked scope. For each, define the desired decision before executing synthetic calls.
A system that only tests valid operations will not demonstrate that its boundary rejects forbidden ones. A denied request can count as a passed security test when the denial is required by policy.
Quantify the effect of a changed scope
Return to Pinecrest’s thirty fictional requests. If two of the seven draft requests lose valid delegation before execution and all other requests are unchanged, allowed operations drop from twenty-five to twenty-three. Denied operations rise from five to seven.
The new share allowed is 23/30, approximately 76.7%. The earlier 83.3% does not carry forward after the permission state changes. This is a change in access decisions, not a measured change in model intelligence.
The logs must not become a new secret store
For each protected action, an audit may record an operation ID, principal class, resource category, requested verb, policy decision and timestamp. Avoid copying raw access tokens, full pupil records or unnecessary personal identifiers into a broadly readable trace.
Security observability needs to support legitimate investigation while minimising exposure. A data-rich log without access controls can create a second privacy risk even if the original tool was correctly protected.
A public-facing answer can remain useful after denial
A parent whose assistant lacks access to a private register can still receive a supported answer about published opening hours or programme descriptions. The final reply should not pretend the forbidden query succeeded or expose an internal secret.
This is a positive design goal: an appropriately restricted assistant completes the safe part of the job and explains which additional step needs an authorised person. A system should not reward the model for bypassing its own boundaries.
Technical trust is not unlimited factual trust
Successful token validation establishes a permitted technical interaction under the relevant rules. It does not establish that the retrieved document is current or that an inferred claim is accurate. A legitimate service can provide obsolete information.
Keep access checks and claim-grounding checks separate. The source owner may need to correct a public policy notice while the security controls have worked exactly as intended.
The complete authority card
A compact review card names the requesting actor, agent client, protected service, resource, operation, effective scope, approval state and observed outcome. It also identifies which fields are unverified. Such a card makes the delegated chain understandable without exposing credentials.
Students can use a paper version to classify Pinecrest’s thirty requests and then adjust the answers when a delegation is revoked. The aim is to transfer an access-control principle into changed circumstances rather than memorise one set of permission rates.
Continue the delegated-access mechanism: Contract-First Agents defines what may count as completion, Idempotency and Recovery protects the identity of each permitted external action, and Agent Observability distinguishes protected operations from model narratives. Permission to act does not itself prove that the requested outcome occurred. Explore the full 100-topic Super Intelligence curriculum and How X Works for related foundational mechanisms.
28. Authoritative sources and advanced reading
The MCP July 2026 authorisation specification and OAuth 2.0 Security Best Current Practice, RFC 9700 support the technical distinctions. See also OWASP Excessive Agency. They do not validate Pinecrest’s invented access counts.
Continue with MCP and A2A Protocols, Permissions and Containment, Contract-First Agents and How Super Intelligence Works. All roles, access requests and decisions in the exercise are fictional. Sources reviewed 22 October 2026.