A valid token for the refund service proves that the caller has some delegated authority there. A scope such as refund:create may say what operation is allowed without saying which order, tenant, amount or approval it covers. If the service accepts an order ID from the model and checks only the token's audience and coarse scope, a mistaken or injected ID can target a different customer's order. The signature is valid. The authorization decision is incomplete.

Bind the action to the actual resource and delegation. At the tool boundary, resolve the order under the authoritative customer account, check the initiating user's rights, action limit and approval state, and compare the normalized parameters with the approved intent. Then use a short-lived, purpose-bound grant or a server-side decision record tied to order, tenant, amount ceiling and operation ID where the architecture supports it. RFC 9396 defines authorization_details for fine-grained OAuth requests. RFC 8693 defines token exchange for delegation scenarios. Those standards provide vocabulary and mechanisms, not an automatic replacement for the refund service's resource checks.

I would test an agent that is approved to refund order A while a retrieved document supplies order B's identifier. The service must reject B even if the token is valid and both orders are in the same tenant. Also test a lower amount, an amount above the approved cap, a changed currency, and a token minted for the right service but another run. Log the authorization decision with subject, resource, approval or grant ID, action parameters and policy version without exposing bearer tokens.

An interviewer might say the agent should never invent an order ID. Agreed, but model behavior is not the security boundary. The tool service must enforce what the user delegated. The agent has a valid user token. Why can the second tool reject it? addresses a token rejected by a second tool because of audience. The agent used a valid tool. Why did a retrieved tenant ID expose another customer's data? addresses a retrieved tenant ID crossing a customer boundary. This question assumes the token reaches the right tool and asks whether coarse operation scope still lets the agent choose the wrong resource.