The API authenticates a request and enqueues {user_id, tenant_id, action}. A worker reads it later and uses a service credential to call a privileged tool. If the worker treats those two IDs as authority just because they came through a queue, it has moved trust from an authenticated request into editable task data. A bug in a producer, an overly broad queue-write permission or an internal test publisher can claim another user. The queue proves that a permitted producer sent bytes, not that the named user authorized the action. This is a confused-deputy shape. AWS's IAM guidance explains the general problem, while SQS least-privilege guidance addresses which producers can write to a queue.

At intake, bind the authenticated principal to an action record that the producer cannot arbitrarily rewrite. Store the requester, tenant, allowed operation, resource, parameters, approval version and expiration under a server-issued job ID. Enqueue the opaque ID and a minimal routing hint. The worker reads the authoritative record, verifies its integrity and current eligibility, then asks the policy service whether this action may execute now. The privileged tool should also enforce the target tenant and action, rather than accepting a free-form user ID from the model or message body.

If someone argues that a signed queue message is enough, ask who signs it and what it attests. A signature from an overprivileged producer proves which service submitted the claim, not whether that service bound it to the authenticated user correctly. Signatures can protect transit and detect tampering, but they do not substitute for the authorization decision. Audit the original principal, producer identity, job ID and execution decision so the chain can be reconstructed.

Test a producer trying to enqueue a different tenant's job, a modified message after intake and a legitimate job whose user loses access before execution. The last case may require fresh approval or a fail-closed stop under the product's policy. The agent's task was approved yesterday. The employee loses access today. Does the scheduled action run? covers revocation of a scheduled task. This case asks how the worker knows whose task it received in the first place.