eduKate Singapore

VIEW THIS AS

Auto mode follows the Route Engine until you choose a viewpoint.

YOU ARE HERE

ROUTE CHECK

CONNECTED TO

WHAT NEXT

Use the canonical route for this room, or HELP if you are unsure.

Next useful routeCanonical hubHELP

How Superintelligence Works | Agent OAuth Resource Indicators — Audience-Bound Tokens, Tenant Scope and Safe API Routing

—

by

eduKate Asia

Did you know? An AI agent can be correctly authorised to read a calendar yet still become unsafe if it sends that access token to a document service, a different tenant or a copied endpoint from an untrusted message. OAuth resource indicators address a specific part of that problem: a client identifies the protected resource where it intends to use an access token, allowing an authorisation server to issue a token restricted to the intended audience.

The operating rule is simple to state and demanding to implement. Identify the actual resource server before requesting a token; use the OAuth resource parameter where supported; ask for the minimum useful scopes; treat the returned access token as valid only for its intended audience and tenant; and verify what the receiving API actually accepts. Never use a successful token response as a blanket permission to send the same credential to another tool. The 2020 IETF standard is RFC 8707, with current broader security guidance in RFC 9700 (January 2025).

This article concerns present-day OAuth-enabled assistants, API gateways and service integrations. Artificial superintelligence is hypothetical and is not asserted to exist. The worked records below are fictional, clearly labelled examples. The article explains token audiences, exact resource identifiers, multi-tenant boundaries, recovery, diagnostics and safe transfer to another system without claiming to have requested or tested real access tokens.

Contents

The short answer: token audience is not the same as user permission

Picture a service assistant connected to three APIs: a calendar, a file library and a billing database. The user asks it to find a meeting date. A correctly scoped calendar token may help it retrieve the meeting. That does not make the same credential valid for the file library or billing database, even when all three are operated by a related organisation. The resource server receiving the token matters separately from the human task and the OAuth permissions requested.

OAuth defines several roles: the resource owner, client, authorisation server and resource server. In a typical integration, the AI agent or its application acts as a client. It obtains an access token from the authorisation server and presents it to a resource server such as a calendar API. A bearer token can be used by a party that possesses it unless its validation and other controls limit use. The design should therefore prevent accidental or malicious redirection of credentials.

A scope such as calendar.read says something about an allowed operation; it does not necessarily say which calendar service, host or tenant should accept the token. The resource indicator answers the destination question. RFC 8707 provides a resource request parameter by which a client explicitly identifies intended protected resources. The authorisation server can use this request to create an appropriately restricted token, including an audience that limits the recipient.

This mechanism is narrower than a complete security design. TLS protects transport, PKCE addresses parts of an authorisation-code flow, sender-constraining techniques can bind tokens to a key, and resource audience restrictions constrain where a credential should work. Those are different safeguards. An agent must combine them according to the architecture rather than describe any one as comprehensive protection.

To orient the reader, this article proceeds from the identity of a resource, through authorisation and token issuance, to actual API validation. The final proof is not the model’s confident explanation but an observed permission decision from the correct server, checked against the intended action.

First principles: why the receiving server is a security boundary

A credential is not a general badge that should open every door. Its validity depends on the system that issued it, the system that accepts it, the subject or delegated authority it represents, and the permissions it conveys. Even two API paths on the same domain may need separate trust policies. Treating a token as a global secret increases the number of places where a leak can become a successful access attempt.

The authorisation server may represent resources with URIs rather than relying on a vague human label. For example, an organisation might designate https://calendar.example.invalid/tenant/alpha as a resource identifier. This string is fictitious and illustrative; it is not a real endpoint. The URI’s identity must be mapped to a legitimate resource server and the requesting organisation’s tenant. The client should not allow untrusted retrieved text to rewrite that mapping.

When a client communicates its intended resource, the authorisation server can apply the resource’s required format and audience constraints. A receiving resource server must still validate every access token according to its own requirements. A token with an apparently plausible audience claim cannot be trusted merely because a generative model inspected a decoded JSON payload. Signature, issuer, expiry, type and other checks may be necessary under the applicable profile.

RFC 8707 explains that identifying the intended resource assists encryption, token data selection and prevention of token redirect. Its core benefit for an agent is to make a boundary explicit before the action. A token intended for calendars should not become a capability to access payroll merely because the client has an API call for payroll available in the same tool registry.

An agent security record should distinguish requested resource, returned audience, requested scope, authorised account or tenant, and actual destination. Some access tokens are opaque and will not expose claims to the client. In that case the client must rely on the provider’s documented contract, while the resource server performs authoritative validation.

How the resource parameter is represented

RFC 8707 defines the OAuth resource parameter for authorisation requests and access token requests. The value is an absolute URI identifying a protected resource. A client may use a resource value such as https://files.example.invalid/acme, with the example domain deliberately nonfunctional here. The server can use that information to make a token suitable for the selected resource and to reject inappropriate targets.

The literal resource URI is not necessarily the exact URL for every individual API operation. An API might have many endpoint paths under one resource identity. What matters is the documented mapping between the configured resource identifier and the actual resource server. The agent should use trusted provider metadata or configuration for that mapping, not invent a resource URI by stripping random path segments from a user-supplied link.

More than one resource parameter can be present under the standard, but RFC 8707 cautions that a token with several audiences increases trust requirements. A token accepted by multiple resource servers creates more ways for one recipient to reuse it at another. When feasible, an integration should request one resource per access token and keep credentials separate for different tools.

The authorisation server may reject the selected resource. The invalid_target OAuth error code identifies a request for a resource that the server does not accept in the relevant context. The correct response is to inspect the configured resource and provider policy, not to cycle through guessed URLs until something returns a token.

A resource value should be stable enough to support intentional identity checks and precise enough to prevent cross-tenant confusion. If a shared host serves several tenants under distinct paths, the resource design may need a tenant-qualified URI. RFC 8707 specifically discusses that multi-tenant issue. A mere string match to the shared host can be insufficient when different tenants should never share token authority.

An end-to-end request and verified API call

Start with the user’s permitted job: read the next appointment from the calendar owned by tenant Alpha. A trusted application configuration maps the calendar tool to an issuer, a resource identifier for tenant Alpha and the documented calendar.read scope. This mapping is checked before the agent retrieves or sends credentials. The assistant’s natural-language plan can suggest the tool; it is not the source of authority for the mapping.

The client proceeds through the provider’s appropriate OAuth grant. Where RFC 8707 is supported, it includes the configured resource in the authorisation or token request as applicable. Other controls, such as registered redirect URI, authorisation-code binding and client authentication, must still be followed. The response is inspected for success and for the access token’s usable scope under the provider’s documented contract.

The client then calls only the intended calendar resource server and sends the credential through the provider’s approved channel, typically an HTTPS Authorization header. It never places the access token into a query string for convenience, logs it in full, or copies it into an email to troubleshoot an error. Secrets should be handled by the connector’s secure token store rather than ordinary model text.

On receipt, the calendar API validates whether the token is active, appropriately issued, unexpired, authorised and intended for that resource. For JWT access tokens following the relevant profile, RFC 9068 includes rules for audience and other validation. Opaque-token systems may use internal lookup or introspection, depending on provider design. The client should not assume every token is a JWT.

Finally the application checks that the requested operation actually succeeded and that the returned data belong to the intended tenant and task. An HTTP 200 without verifying the owner, record identity or effective query filter may still leave a wrong-answer risk. The user-facing result states only what was observed, with no unsupported claims about other systems’ permissions.

Worked scenario: three APIs and an authorisation budget

Here is an invented example with exact counts. Over a test week an assistant is expected to make 120 permitted API calls: 84 file reads, 24 calendar reads and 12 billing lookups. The totals check: 84 + 24 + 12 = 120. An overly broad design reuses one token across all three resource servers. A better design requests distinct tokens with explicit resource identities and scopes appropriate to each job.

Suppose an operator asks the assistant to read one calendar appointment. Under the broad design the same bearer credential might be accepted by three servers, giving it a potential set of permitted operations much larger than the one requested. Under an audience-restricted design the calendar token should be rejected by file and billing services even if it is accidentally presented there. The distinction is about capability boundaries, not about increasing the number of useful calendar calls.

In the fictional workload, calendar operations represent 24/120 = 0.20, or 20% of the calls. File reads account for 84/120 = 0.70, or 70%, and billing lookups for 12/120 = 0.10, or 10%. These are shares of requests, not probabilities that any token will be stolen. It would be inaccurate to claim that isolating calendar tokens reduces security incidents by 80% merely because calendar work is 20% of the workload.

Now assume each tenant has the same three resource families and there are two mutually isolated tenants, Alpha and Beta. That yields six tenant-resource combinations: two tenants multiplied by three distinct resource classes. If policy requires one credential boundary for each combination, a client should not silently collapse those six boundaries into a token accepted everywhere. However, separate access tokens do not guarantee isolation if the resource server ignores tenant validation.

A deliberate negative test can present an Alpha calendar token to the Beta calendar API in a controlled test environment and expect rejection. Another can present the calendar token to the Alpha billing API and expect rejection. Both are boundary checks, not an invitation to probe arbitrary external endpoints with real secrets. If either token is accepted contrary to the documented policy, stop rollout and investigate issuer configuration and resource-server validation.

The design target is therefore six precise audience-and-tenant combinations in this toy example, plus the scopes and other access rules each use requires. That number comes from the assumed policy matrix, not from a universal rule that every integration needs six tokens. The worked calculation teaches how to count distinct trust relationships rather than equating tool availability with authority.

Audience restrictions, scopes and sender constraints solve different problems

Audience restrictions define intended recipients. Scopes describe classes of allowed operations. A sender-constrained token ties use to a cryptographic key or client certificate under a supported mechanism. These safeguards can operate together but answer different security questions. A token that is restricted to the right audience can still be misused for an unauthorised operation if the server fails to enforce scopes.

An audience-restricted token alone does not prevent someone who steals it from presenting it to the designated recipient. For bearer credentials, possession remains powerful. The IETF’s 2025 OAuth security best current practice discusses token replay prevention and privilege restriction. Sender-constraining mechanisms include approaches such as DPoP and mutual TLS, each with its own validation and operational demands.

In the eduKate engineering series, DPoP tokens and signed proofs focuses on proof keys and replay checks, while OAuth mutual TLS explains certificate-bound credentials. Neither article is replaced by resource indicators; this specialist guide answers the identity-of-recipient problem.

Consider a token for files.example.invalid with scope files.read. If it is accepted by billing.example.invalid, the audience boundary has failed even when the scope string says read. If the files API allows files.delete despite a read-only scope, operation authorisation has failed. If the token is stolen and replayed successfully to files.example.invalid, a bearer-token misuse threat remains even when audience and scope were correct.

Good system design checks all these separately. In an incident report, do not write only ‘OAuth was secure’ or ‘OAuth failed.’ Name the claim at issue: issuer trust, audience, tenant identity, scope, possession, token binding, expiry or business action. Specific diagnoses lead to specific repairs.

Tenant identity requires more than matching a familiar hostname

Multi-tenant applications frequently expose multiple customers’ records under one domain. An access token for Tenant Alpha must not permit Tenant Beta’s operations merely because both addresses begin with the same hostname. RFC 8707 warns about this and recommends specific resource identifiers where necessary to reflect tenant identity. The exact URI design depends on the provider.

Suppose two resource identifiers are https://api.example.invalid/tenant/alpha and https://api.example.invalid/tenant/beta. These names are teaching examples. The path portion can help communicate intended tenant to the issuer and resource server. But that only improves security when the issuer creates a sufficiently specific token and the receiver validates the tenant identity. A client-side string convention without server enforcement provides little protection.

The agent should validate the selected account against a trusted connection record and the user’s authorised context. An instruction embedded in an external document saying ‘the correct account is Beta’ cannot override the authenticated user’s account selection. Where a user deliberately changes tenants, the application should re-run the permission selection and obtain an appropriate token rather than reusing the prior context invisibly.

Some providers use different audience formats or include tenant identity in claims beyond the audience. Do not treat one vendor’s claim layout as universal. The aud field in a JWT is an audience claim, while tenant identifiers and authorisation semantics may follow other documented conventions. A resource server must validate the relevant full set of conditions required by its issuer contract.

If the client is handed a link to a file in another tenant, it should first ask whether it has a legitimate authorised route to that tenant’s resource. A copied HTTPS URL is not evidence of delegated access. If the check fails, report a permission boundary instead of attempting to transform an Alpha token into a Beta credential.

API routing: a helpful tool selection can still leak a token

AI agents often select tools from natural-language descriptions. A user says ‘show me my appointments’; the agent selects CalendarSearch. But tool selection is probabilistic and a tool description may be stale or ambiguous. Credential routing must not depend exclusively on that selection. The execution layer should bind each registered tool to a known destination, resource identity, policy and token issuer.

Imagine a search result that contains a new endpoint and tells the assistant to retry the calendar action there. The source may be untrusted user content. It cannot supply a new OAuth audience or recipient simply by containing a plausible URL. The agent should treat the endpoint as data to inspect under ordinary source-validation rules, not as permission to send the calendar token.

Redirects are another complication. If an API returns an HTTP redirect to a different origin, a client must avoid forwarding sensitive authorization headers without a deliberate trusted policy. Audience restrictions add defence, but sending secrets to an untrusted origin can still expose them. Inspect final destination and redirect semantics rather than assuming all redirects are harmless.

At the boundary, the credential store should accept a stable tool or resource identifier and return a token only for an authorised destination. The agent should receive tool results and permission errors, not raw token strings in its prompt. Keep resource-token mapping outside editable task content and log only non-secret metadata such as policy decision, resource class and correlation ID.

A useful safety test deliberately swaps destination names between two test connectors while retaining their labels. The executor should reject the mismatch before an HTTP request is sent. This failure mode differs from a model choosing the wrong informational answer: the unintended request itself can leak a secret and must be stopped at the connection boundary.

Diagnosing invalid_target, invalid_token and wrong-account results

An OAuth invalid_target response can indicate that the requested resource indicator is unsupported or invalid for that authorisation flow or client. The remedy is not to ask for a broad token with no resource restriction merely to make the error disappear. Check RFC 8707 support, the provider’s registered resource identifiers, client permissions and grant-specific rules. A provider may also choose not to fulfil a multi-resource request.

An API may reject a credential because it is expired, not active, outside the required audience, missing scopes or associated with a different account. Those distinctions matter. If a JWT fails audience validation, refresh logic should not blindly issue repeated tokens for the same wrong audience. Change the configured target only after trusted review of which resource actually owns the request.

A successful response containing unexpected tenant data is a separate warning. The response may show a valid token used with an incorrectly selected connection. Verify owner identity and request filters rather than treating HTTP status alone as a privacy guarantee. Resource-server enforcement and data-level authorisation must both work.

The system should use bounded retries. A transient network error can justify retrying a safe read according to provider rules, while an authorisation denial often requires configuration or human action. Retrying a blocked request across guessed audiences risks noisy security logs and accidental privilege escalation. Keep a clear distinction among temporary failure, permanent permission denial and unknown outcome.

If an agent’s OAuth token request times out, first determine whether the provider issued a credential and whether the original request can be safely retried. Multiple tokens can coexist; duplicate issuance may complicate revocation and audit. Use supported token-handling libraries, stable correlation records and a conservative interpretation of ambiguous outcomes rather than displaying an imaginary success.

JWT and opaque tokens: validation belongs to the receiving API

Some OAuth access tokens are JWTs carrying issuer, audience, expiration and other claims. Others are opaque strings with meaning known to the issuer or resource server. A client should not presume that every access token can be decoded as a JWT or that successfully decoding Base64 text establishes authenticity. A readable payload is not a verified signature.

Under the JWT access-token profile RFC 9068, the resource server validates the token according to specified requirements, including issuer, signature, audience and relevant claims. Key choice, algorithm policy and token type matter. The implementation should use a standards-conformant library and the provider’s current metadata instead of a hand-written verifier generated from a prompt.

For opaque credentials, token introspection may be part of the architecture. The sibling OAuth token introspection guide explains active status, permission fields and caching. The exact authoritative endpoint and response interpretation depend on the provider. The same audience separation principle applies regardless of token representation.

An API gateway can validate some claims before forwarding, but upstream services still need a defensible trust model. If a gateway passes identity assertions to an internal service, the service should verify the source and scope of those assertions. Otherwise a correctly issued external token can be laundered into an overly broad internal principal.

Monitor configuration drift. A new API may be introduced with an audience name that is accidentally copied from an older resource. A deployment should include negative tests proving cross-resource rejection as well as positive tests proving legitimate requests succeed. This is how a naming convention becomes an enforced safety boundary.

A second numerical test: correct approvals and rejected cross-resource requests

Consider an invented test suite of 90 token-use attempts. Forty-five are expected to succeed at their intended resource; thirty are cross-resource attempts that should be rejected; fifteen use the correct resource but the wrong tenant and should also be rejected. The categories total 45 + 30 + 15 = 90. These are constructed test cases, not an actual security survey.

Suppose the test environment approves all 45 legitimate requests, rejects 29 of 30 cross-resource attempts and rejects all 15 cross-tenant attempts. Legitimate success is 45/45 = 100%. The cross-resource rejection rate is 29/30 ≈ 96.67%, and cross-tenant rejection is 15/15 = 100%. Across the 45 negative cases, 44 are blocked, giving an aggregate rejection rate of 44/45 ≈ 97.78%.

The one cross-resource acceptance is a critical failure even though the aggregate rejection figure looks impressive. A security requirement may call for no unauthorised approvals, not merely a high average. The test should preserve which particular resource combination succeeded improperly, which token and policy version were used, and whether the receiving server ignored audience validation.

Change one condition: the authorised calendar token now permits both read and write under a new scope. The earlier legitimate-read tests are insufficient. You need new positive checks for permitted writes, negative checks for disallowed operations and tests ensuring the token is still rejected by other resource servers and tenants. A wider operation permission cannot silently widen the set of permitted recipients.

Statistical language needs care. These 90 engineered tests do not estimate the real-world probability of compromise. They provide coverage of chosen expected behaviours. They may miss other bugs and configurations. The useful result is a traceable assertion about the tested resource/tenant matrix, together with the explicit boundary case that failed.

An agent should report ’44 of 45 designed negative requests were rejected; one cross-resource access remained improperly accepted’ rather than claim the token system is safe because its rejection percentage exceeds 97%. Accurate denominators and failure severity both belong in a responsible test summary.

Privacy, logs and least information

RFC 8707 notes that use of resource indicators can give the authorisation server more specific knowledge of which resources a client intends to access. This is an inherent privacy consideration in some deployments. A useful security design should avoid collecting or retaining more user-context information than is necessary for access decisions and audits.

Credentials should not appear in diagnostic URLs, copied error reports or language-model transcripts. Record masked identifiers or hashes only when those are operationally appropriate and avoid designing logs that can reconstruct access tokens. A correlation ID and an audience policy label often help troubleshooting without revealing credential material.

Do not overshare resource paths or tenant identifiers in public reports. A tenant-specific resource URI may contain account structure or internal naming information. The intended audience must be precise enough for enforcement, but operational telemetry should follow the organisation’s privacy and retention rules.

Token expiry and revocation still matter. When a user disconnects an integration, the system should remove or invalidate the delegated route according to provider capabilities. Cached tokens, queued actions and retries should not continue under a revoked decision. The client should recheck authorisation for sensitive operations when the environment may have changed.

Finally, avoid converting access to one resource into an informal search across all connected services. The agent’s job and the user’s permissions govern data minimisation. Even where several resource-specific tokens exist, using them all for every prompt may be unnecessary and invasive.

Nine recurring engineering mistakes and their repairs

Mistake one: treating scope as a destination. A string such as calendar.read does not by itself prove which API should receive the token. Repair by configuring a trusted resource identifier and testing audience validation. Mistake two: constructing resource URIs from retrieved webpages. Repair by using verified provider metadata and registered configuration.

Mistake three: sharing a bearer token across unrelated APIs because they have the same corporate owner. Repair by requesting resource-specific tokens where supported and enforcing receiver checks. Mistake four: ignoring tenant path components in shared-host systems. Repair by reflecting tenant identity in a validated audience and authorisation context where the provider’s design requires it.

Mistake five: decoding a JWT and assuming its visible aud string is trustworthy. Repair with proper signature, issuer, algorithm, type, expiry and policy validation on the receiving side. Mistake six: silently dropping the resource parameter after an invalid_target error. Repair by diagnosing provider support and resource identity without weakening controls to hide the error.

Mistake seven: following a redirect while carrying credentials to an unexpected origin. Repair by checking the effective destination and blocking unauthorised credential forwarding. Mistake eight: claiming that audience restrictions stop token replay at the legitimate resource. Repair with suitable sender-constraining or other replay and operational controls when required.

Mistake nine: reporting any HTTP success as proof of the correct user’s intended action. Repair by checking resource ownership, tenant, requested operation and returned record identity. The larger pattern is that accurate evidence must accompany every transition: authorisation request, token issuance, API validation and observed business result.

A review that identifies the exact broken gate is more useful than simply saying OAuth was misconfigured. Engineers can then write targeted tests and prevent recurrence without granting broader permissions.

Transfer exercise: from a calendar read to an invoice approval

Now change the task from finding a calendar event to approving an invoice. The user still works in Tenant Alpha, but the financial API is a separate resource and the requested action is higher consequence. The original calendar token must not be sent to the invoice service even if the calendar action completed successfully a moment ago.

The agent should identify the permitted invoice workflow, verify the user or service authority required for that specific operation, obtain an appropriately audience-restricted token and present the requested invoice information for the required approval gate. A token can authenticate a client without eliminating an organisation’s need for separate human confirmation of payments.

Suppose a fictional organisation allows approvals below SGD 500 only after a named review and requires two reviewers for SGD 500 or more. These thresholds are invented for illustration and are not legal or industry standards. For an invoice of SGD 680, the rule’s numerical comparison is 680 ≥ 500, so two reviews would be required under that fictional policy. An audience-restricted billing token is a prerequisite for contacting the financial service, not evidence that those reviews occurred.

Now the invoice link points to another tenant. The correct response is to reject the old tenant context and determine whether a new, independently authorised connection exists. Rewriting the resource indicator to match the link is not sufficient; the security policy must establish who may act for that tenant and whether the invoice actually belongs there.

The changed-context lesson is that the same principles still apply—specific resource, least privilege, recipient validation, tenant checks, bounded retries and independent verification—but the business action introduces additional approval rules. A secure API token and a permitted financial decision are different claims.

What resource indicators cannot guarantee

RFC 8707 defines a way to communicate intended protected resources. It does not guarantee that every authorisation server supports the extension or will honour every requested resource. It does not create a universal URI format, and it does not excuse resource servers from validating issued credentials properly.

Resource-specific tokens do not replace user consent, client authentication, PKCE, expiry, revocation, sender constraining, scope checking or data-level permissions. They also do not validate the factual accuracy of an AI agent’s planned action. A correctly audience-restricted token can still be used for a wrong but technically permitted operation if business checks are missing.

The scheme does not give the language model independent access to an account. The model should receive a restricted tool interface with clear outcomes; credential issuance and routing belong to trusted application components. A prompt that claims ‘the user approved everything’ is not equivalent to real provider authorisation.

Security results depend on the actual issuer, API gateways, identity model, token representation, audience design and provider configuration. The correct protocol for one OAuth provider may not be portable without adaptation to another. Review the current provider contract and the applicable IETF security recommendations before changing production auth.

The illustrative test counts above demonstrate how to expose a wrong-audience acceptance. They are not estimates of compromise frequency or proof of a live system’s posture. This article did not mint tokens, test production accounts or run attack simulations.

Frequently asked questions

What is an OAuth resource indicator? It is a parameter defined by RFC 8707 that identifies the protected resource for which an OAuth client requests access. It helps an authorisation server tailor and restrict the access token to the intended recipient.

Is the resource parameter the same as scope? No. Resource indicates where the token is intended to be used; scope generally expresses which operations are authorised. Both may be required and are validated under the provider’s policy.

Can one token be valid for several APIs? Some systems can issue tokens with multiple audiences, but RFC 8707 cautions that multi-audience bearer tokens require high trust among recipients. A single intended resource is encouraged when feasible.

Do I need a JWT to use resource indicators? No. The resource indicator participates in the OAuth request. The resulting access token may be opaque or JWT-encoded depending on the provider. The receiving resource server enforces the relevant validation policy.

What does invalid_target mean? It indicates that the authorisation server rejected a requested resource target in the relevant context. Check supported resource identities, client configuration and provider policy instead of removing restrictions blindly.

Will audience restriction prevent a stolen bearer token from being reused at the intended API? Not on its own. Audience restriction limits recipients; stolen bearer tokens can still pose a risk at the intended recipient. Sender-constraining and other controls address different threats.

Why include a tenant in the resource identity? In some multi-tenant deployments, different customers share a host but must have separate authorisation boundaries. A sufficiently specific resource and receiver policy can help prevent cross-tenant misuse.

Can an AI agent choose a new audience from a document? It can suggest a resource as task data, but trusted configuration and actual user/provider authorisation must validate any change. Untrusted text cannot grant access or decide where secrets should be sent.

How do we verify a successful tool action? Check the actual response from the correct resource server, the tenant and target record, and any required business approval. An explanatory sentence produced by the model is not external verification.

Primary sources, verified siblings and the next useful route

The source standard is RFC 8707: Resource Indicators for OAuth 2.0 (February 2020). For the wider threat model use RFC 9700: Best Current Practice for OAuth 2.0 Security (January 2025). When a provider uses JWT-formatted OAuth access tokens, consult RFC 9068: JWT Profile for OAuth 2.0 Access Tokens (October 2021). Provider-specific behaviour should still be checked against its own current documentation.

For a different stage in OAuth, see PKCE and redirect binding and pushed authorisation requests. Those explain how credentials are requested safely; they are not substitutes for the resource audience of the credential issued.

For credential status and sender constraints, continue with token introspection, DPoP and mutual TLS. Each answers a separate engineering question rather than repeating this recipient-boundary guide.

Teams implementing resource indicators should begin with a provider-supported audience map, tenant ownership checks and test cases demonstrating rejection at wrong recipients. They should then extend checks to revocation, expiry, suspicious redirects and observed action outcomes. This is an executable review discipline, not an invented approval performed by an AI model.

Explore the broader How Super Intelligence Works library and education that transfers into life. The teaching theme is precise transfer: knowing the definition of a token is less useful than being able to identify which server must reject it when the context changes.

Discover more from eduKate Singapore

Subscribe now to keep reading and get access to the full archive.

Continue reading