The direct answer
Do not forward a credential intended only for one service to another service as a shortcut. Establish the downstream authorization path explicitly, validate the intended recipient and permitted operations, and still check the current actor’s authority over the requested object.
Draw the two-resource boundary
A connector reads a product description from Catalog and proposes saving a draft note in Ticket Notes. It already has a Catalog credential. That does not establish permission to present the same credential to Ticket Notes, or to use a broad application credential on the user's behalf.
This guide proposes a review for that boundary. Catalog and Ticket Notes are fictional resources; Connector C-1 and user U-17 are invented identifiers. The example contains only inert metadata and expected decisions. No tokens, keys, OAuth flow, model request, provider account or authorization experiment has been created or exercised.
Separate where, what and who
RFC 8707 defines a resource parameter by which a client can tell an authorization server which protected resource it wants to access. It distinguishes that destination question from scope, which typically describes the requested access. Asking for a resource does not force the authorization server to grant access; its policy still applies.
RFC 9700 recommends audience restriction and requires the receiving resource server to reject a token not intended for it. It also describes restrictions to resources and actions. Audience matching therefore belongs at the receiver, not merely in a connector's configuration screen.
The actor question remains separate: which user and application context is this operation acting under? A client identifier in a request body does not prove the presenter is that client. RFC 9700 discusses sender-constrained tokens, which require a supported proof mechanism. Do not confuse a desired client label with verified possession. Nor does an audience match alone authorize a particular ticket, tenant or write operation.
Write a fictional credential and authority map
Use these metadata cards as test inputs to an application decision stub, not as token contents to trust. Real integrations may use opaque tokens, signed formats or other agreed validation mechanisms. Reading fields from an unverified payload is not validation.
Catalog card CAT-1:
intended_resource: urn:demo:catalog
subject: U-17
permitted_operation: catalog.read
Notes card NOTE-1:
intended_resource: urn:demo:ticket-notes
subject: U-17
permitted_operation: notes.draftThe URNs are non-network fixture identifiers, not discovery endpoints. The application separately records C-1's allowed workflow, the authenticated user, permitted Catalog object P-7 and Ticket Notes object T-17. If the actual deployment supports resource indicators, use the identifiers and validation rules agreed by that deployment; this fixture does not configure a real authorization server.
For the proposed workflow, a Catalog-only grant cannot be expanded by the model asking for Notes access. A Notes credential must come from the integration's supported authorized mechanism and remain within the permitted grant. This guide does not prescribe a universal token-exchange flow.
Review an audience, actor and scope matrix
All rows below are proposed independent cases. “Validated” is a stubbed result for checking application decisions, not evidence that cryptographic or issuer validation succeeded.
| Proposed case | Expected decision | Reason |
|---|---|---|
| Validated CAT-1 reads permitted P-7 at Catalog | Allow that read | Recipient, operation and current object authority align |
| CAT-1 is proposed for Ticket Notes | No downstream dispatch | Wrong intended resource |
| CAT-1 is used to modify Catalog | Deny | Read permission does not include that action |
| Validated NOTE-1 drafts on permitted T-17 | Allow only the recorded draft operation | Separate Notes authority is established |
| Notes subject U-22 is attached to U-17's workflow | Deny inconsistent actor binding | Do not switch subjects through model output |
| NOTE-1 targets unauthorized T-99 | Deny | Right audience is not object authorization |
| Configuration supplies a broad Catalog admin credential | Hold for a narrower authorized configuration | Proposed integration policy excludes excess privilege |
| Required presenter binding or token validity cannot be established | Deny | A claimed client name is insufficient evidence |
The broad-credential row is a deliberate policy choice for this fictional integration, not a claim that OAuth universally rejects every token containing extra scope. Record the decision the actual application intends to enforce.
Keep credentials outside the model-controlled route
Resolve resource identity, allowed operations and credential selection from trusted integration settings and current authorization context. Do not accept an arbitrary audience, token endpoint or credential reference from a tool description or model-generated argument. A tool's friendly name cannot replace that mapping.
RFC 6750 explains that possession of a bearer token can enable use without demonstrating a cryptographic key, and that tokens need protection in storage and transport. Keep real credentials out of prompts, ordinary logs and diagnostic fixtures. Record safe decision categories and synthetic identifiers instead of reusable secrets.
If a downstream grant is unavailable, stop that operation and give a useful status such as “Catalog read completed; Notes access is not configured.” Do not retry with an unrelated administrator credential or reuse a token issued only for the connector itself. Service-owned access and user-delegated access need distinct, explicit authorization models.
State what a future check would establish
A proposed local review would feed the metadata cases into a policy stub and inspect a dispatch recorder. It should show the permitted Catalog read and separately authorized Notes draft, with no cross-resource dispatch for rejected cases. The harness should also vary object ownership and current authority independently of audience. This remains unrun and cannot validate an OAuth implementation.
A real integration review must additionally verify issuer trust, token validity, intended audience, required sender proof and the deployment's actual protocol. Boundary's planned request router does not supply that authorization server or universal connector delegation control. Its eight mock policy checks are separate evidence, not token-security results.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.