# Carry tenant identity into queued work

A worker needs an explicit, trusted scope for the job it executes. Save that scope at submission and validate it again according to the workflow's authority policy.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Resolve the tenant before enqueueing

Authenticate the requester and confirm membership or delegated authority for the selected tenant. If the client sends a tenant identifier, treat it as a selection to validate, not as proof.

Load the target within that scope and verify the requested operation is permitted. A user who can read an invoice may not be allowed to export every invoice in the account.

Create a job record with the trusted tenant, target, operation and requester or service ownership. Keep the queue message small by referencing that record where appropriate.

```json
{
  "jobId": "export-example-17",
  "tenantId": "tenant-example-a",
  "operation": "exportInvoice",
  "invoiceId": "invoice-example-42",
  "requestedBy": "user-example-8",
  "authorityMode": "recheckRequester"
}
```

The authority mode is an illustrative application choice. Define the actual policy for each job type rather than allowing arbitrary client values to choose how checks run.

## Validate the worker's input

The worker loads the trusted job and confirms it owns a valid execution attempt. Reject missing tenant scope and unsupported operations rather than falling back to a default account.

Recheck the relevant authority before reading data or producing an effect. If the job is intentionally organisation-owned, verify the service's scope and the original authorisation record under that policy.

Use tenant-scoped data access throughout. Do not load an unscoped record and rely on a later output filter to hide mistakes.

## Keep context isolated across execution

Avoid mutable global tenant state in a worker handling multiple jobs. Pass scope explicitly or use a runtime mechanism whose isolation is understood and tested.

If database session settings establish row-policy context, apply them with the correct transaction and connection-pool discipline. Verify cleanup and failure behaviour so a reused connection cannot carry the previous tenant into another job.

Include tenant scope in caches, idempotency records and storage paths according to the data model. The worker's correct query is only one part of the output path.

## Protect the generated result

Store the export with tenant ownership and serve it through an authorised endpoint or appropriately controlled link. Record the job and source identifiers for support without exposing the full document in routine logs.

Test two tenants with similar target identifiers, concurrent jobs and a retry after permission revocation. Inspect the stored file as well as the download response. The implementation should preserve scope from the initial request to the final artifact, not merely inside the queue message.

## Sources

- [OWASP: multitenant security](https://cheatsheetseries.owasp.org/cheatsheets/Multi_Tenant_Security_Cheat_Sheet.html)
- [PostgreSQL: row security policies](https://www.postgresql.org/docs/17/ddl-rowsecurity.html)