No customer auth. No execution.
TaskQ authenticates and attributes the customer before policy, credential resolution, placement, spend, settlement, or proof. The bearer is not just access. It is the root of request accountability.
TaskQ bearer keys identify the customer.
The public Gateway is the only customer-facing surface. Every public request starts with a TaskQ bearer key. If the bearer is missing, expired, revoked, malformed, or outside scope, the request stops before credential lookup, placement, or worker lease.
Authorization: Bearer tq_live_... Content-Type: application/json X-TaskQ-Credential: byok://anthropic-prod X-TaskQ-Policy: must_run_in=CA;trust_floor=audited
Use tenant keys and sub-keys for real organizations.
Production customers should not run everything through one undifferentiated key. Use tenant and sub-key boundaries for teams, apps, environments, budgets, default policies, and audit separation.
Tenant — organization root
Owns plan, billing relationship, default policies, and credential inventory.
Sub-key — app / team key
Limits access by environment, product, rate, budget, provider, and policy scope.
Request — execution unit
Every call inherits customer defaults and may only tighten hard constraints.
Attribution is written into the proof trail.
After authentication succeeds, TaskQ resolves the customer, tenant, sub-key, plan, entitlement, default policy, credential scope, and rate/spend gates. Those decisions become part of the proof surface without exposing raw secrets.
Auth failures fail closed.
Authentication failures do not trigger placement, worker lease, credential unwrap, provider execution, or billable settlement. Sustained abuse can still create security/audit events.
Missing, malformed, expired, unknown, or revoked bearer.
The bearer is valid but lacks access to the requested endpoint, credential, tenant, or policy.
The key exceeded customer, tenant, endpoint, or plan limits.
The customer or sub-key does not have entitlement or spend capacity for this request.
Auth gates sit before spend and placement.
TaskQ does not resolve BYOK material or ask the placement engine for capacity until the customer is authenticated and allowed to spend. This keeps upstream credentials and workers out of unauthenticated paths.
receive → authenticate bearer → resolve tenant / sub-key → check entitlement / balance → rate gate → merge policy → resolve credential handle → solve placement → open HashIQ entry → execute