TaskQ does not win by pretending to be your upstream provider. You bring the provider relationship. TaskQ authenticates, places, proves, meters, and logs every credential access into a HashIQ trail.
The upstream account belongs to the customer. TaskQ’s job is to enforce policy around where and how that credential is used, then prove what happened after the request leaves the gateway.
You bring Anthropic, OpenAI, local inference, or future provider credentials. TaskQ remains the execution control plane.
Proof records bind to credential fingerprints and handles. The credential value never belongs in receipts, logs, dashboards, or chain entries.
Each credential unwrap creates a visible access event: which worker, which key domain, which request, which custody class.
Credentials move through handles and key domains, not casual plaintext. The Gateway resolves a BYOK handle, the custody service enforces the key-domain policy, and HashIQ records the access without exposing the secret.

Credential state is a first-class control surface. Access does not depend on an old dashboard note or someone remembering to clean up a key.
Accepted, encrypted, fingerprinted, and validated before active placement.
New requests can use this handle if customer, key domain, worker, and custody class match policy.
New credential comes online while in-flight work drains from the old one.
Retired credentials remain referenceable in proofs. Revoked credentials stop new decrypts immediately.
A customer can bind credentials to named key domains. A Canadian credential can be constrained to Canada. An Alberta workload can require Alberta. A private worker pool can keep the key inside the customer boundary.
| Domain | Constraint |
|---|---|
| kd:CA | Credential can unwrap only inside Canadian-compliant custody. |
| kd:CA-AB | Credential can unwrap only in Alberta-approved execution contexts. |
| kd:EU | Credential can unwrap only inside EU key-domain policy. |
| kd:customer-owned | Credential stays inside customer-operated custody or HSM integration. |
TaskQ separates execution capacity from credential custody. Plain leased workers can be useful for queue workloads, but synchronous BYOK relay defaults to pinned, enclave, or customer-owned custody.
TaskQ-controlled nodes for sync relay and sensitive custody paths.
TEE-backed custody class for future broad third-party execution with stronger guarantees.
Private workers and customer key domains where TaskQ is the control plane, not the secret holder.
The developer experience should stay simple while the custody model stays serious.
export TASKQ_API_KEY="tq_live_..." export TASKQ_CREDENTIAL="byok://anthropic-prod" curl https://api.taskq.xyz/v1/messages \\ -H "x-taskq-credential: byok://anthropic-prod" \\ -H "x-taskq-policy: must_run_in=CA,must_not_run_in=US" \\ -d '{ "model":"claude", "messages":[...] }' # response headers x-taskq-request-id: req_01HX... x-taskq-chain-key: hshq_184467 x-taskq-credential-fpr: sha256:91c...8fa x-taskq-placement-proof: proof_9a2
Give customers the upstream control they want, without losing routing, proof, custody, and operator placement.