Resolve rate-limit scope from trusted identity

Establish the scope at admission

Authenticate the caller and resolve the permitted local tenant and provider connection. Use that trusted mapping to select the scheduler's budget.

Treat an account identifier in a request as a selection to validate, not proof of authority. Otherwise a caller may spread work across invented keys and bypass local controls.

Keep the same scope in the durable operation record and verify it when workers execute.

Separate fairness from access

A scheduler deciding that capacity is available does not authorise the business operation. Apply the normal access checks and connection policy independently.

Likewise, an authorised request can still be delayed by capacity policy. Explain that state clearly without exposing another customer's usage or credentials.

Test cross-tenant operation lookup and cancellation as well as initial submission.

A synthetic caller might change a budget key from account-A to account-A-2 on every request. If the limiter accepts that key directly, each request appears to belong to a fresh allowance. Resolve the provider connection from the authorised account record and derive the key on the server instead.

Apply the same principle to priority. A user-supplied urgent flag should not automatically place every historical import ahead of other customers' live work. The scheduler needs a trusted rule for who can request that priority and for which operation types.

Protect operational metadata

Queue records can reveal customer activity, resource identifiers and business timing. Restrict detailed views to the appropriate support scope.

Avoid logging access tokens or full provider request bodies to explain rate-limit failures. Bounded status, timing and operation references are usually sufficient.

Control who can change budgets, priorities and pause states. Those controls can materially affect service availability even without changing application data.

Test abuse and recovery boundaries

Use synthetic callers to attempt invalid scope selection, repeated high-priority claims and cancellation of another tenant's delayed work. Confirm the trusted policy holds.

Keep expensive validation bounded before durable admission where appropriate, while preserving the service's legitimate retry behaviour.

The review should show that users cannot obtain more authority or scheduling capacity by changing labels, and that operators can recover delayed work without gaining unnecessary access to every tenant's integration data.