Let a trusted broker issue only the authority a tool action needs

Resolve the tool name, action, target resource and tenant from an allowlisted server-side contract. Treat every model-supplied field as untrusted, including a claimed user identity or destination. The broker intersects the caller’s authority with its own service authority and the approved task scope, then either performs the operation itself or issues a constrained credential to the intended executor. A generic read scope may still be too broad unless the resource server also checks which document or account may be read.

RFC8693 defines token-exchange machinery, and RFC8707 defines resource indicators; using them does not automatically create the application’s intended policy. Configure the issuer and resource server to honor the actual audience, actions and resource restrictions. Keep the broker’s long-lived secrets in the trusted execution path, outside prompts, retrieved text and ordinary logs. Returning a token as a normal tool result would expose it to later model context and potentially to unrelated output handling.

For a credential carrying an expiry, validate the issuer/signature and the expected audience as well as the relevant temporal and permission claims. RFC7519 specifies expiration semantics when that claim is used, with implementation-specific clock-skew leeway that must be stated. A service can adopt a stricter no-leeway fixture for testing. Shortening lifetime reduces accepted future use only if every accepting component actually enforces that bound and cannot obtain a broader replacement credential through another path.

A token accepted just before expiration may start work that finishes later unless the operation contract adds a separate execution deadline or cancellation check. Likewise, a stolen bearer credential may be replayable within its allowed window. Revocation mechanisms and propagation differ; RFC7009 discusses token revocation but does not make every distributed validator instantly aware of it. Use appropriately scoped credentials, operation-specific controls and a verified retry/idempotency policy rather than claiming expiry alone makes an action single-use.

Use a harmless controlled resource to test the allowed action, wrong audience, wrong tenant/resource, excessive scope, expiration and revoked credentials under the actual issuer/validator configuration. Repeat a call to establish the declared replay or idempotency behavior, and inspect resource-side effects rather than only the broker’s response. Test queued operations whose permission changes before execution. Log credential identifiers or protected correlation references as appropriate, while excluding the credential value itself.

The modular lab illustrates why a wrapped counter lacks enough information for absolute expiry. Reset, set both m=10,a=3, predict 0,3,6,9,2 through four Steps. Reset and set both m=10,a=1 for comparison. Residue two can represent an unwrapped count of twelve, so the residue alone is not an elapsed-time proof. This is not JWT NumericDate, a real credential clock, cryptography, token issuance or authorization. Credential tests must use the actual clock and validation semantics.