Credentials stay yours. TaskQ gets handles.
Register provider credentials once, route requests by credential handle, rotate or revoke without changing application code, and inspect every credential access event through the HashIQ proof trail.
TaskQ stores encrypted credentials, but the customer owns the provider relationship.
TaskQ does not resell a house Anthropic, OpenAI, or local inference account. The customer registers a provider credential, TaskQ returns a credential handle, and requests reference that handle. Proof records store fingerprints and access events, never raw secret material.
Register a provider credential.
Submit the provider, label, key domain, and credential value over the authenticated Gateway. TaskQ validates the credential, stores encrypted material, and returns a stable handle for application use. Store the handle in your app configuration; do not put raw provider keys into app logs, queues, client code, or job payloads.
curl https://api.taskq.xyz/v1/credentials \\ -H "authorization: Bearer $TASKQ_API_KEY" \\ -d '{ "provider": "anthropic", "label": "anthropic-prod", "key_domain": "kd:CA", "credential": "$ANTHROPIC_API_KEY" }'
Credential lifecycle states.
Credentials move through explicit states so production systems can rotate safely and auditors can understand historical use.
Submitted
Received but not yet validated for new placements.
Usable
May be used for new Relay or Queue work within customer policy.
Draining
New material introduced while in-flight work finishes safely.
Blocked
Immediate stop for new decrypts. Retired credentials remain referenced by old proofs.
Rotate or revoke without changing application routes.
Rotation changes the encrypted credential material behind a handle. Revocation blocks new decrypts immediately. Historical chain entries continue to reference the previous fingerprint for audit continuity.
curl .../v1/credentials/byok:%2F%2Fanthropic-prod/rotate \\
-d '{"credential":"$NEW_PROVIDER_KEY"}' curl .../v1/credentials/byok:%2F%2Fanthropic-prod/revoke \\
-d '{"reason":"customer security rotation"}' Every credential unwrap creates an access event.
The access log is not just an admin feature. It is part of the trust story: which credential fingerprint was used, on which worker, under which key domain, for which request.
{
"event_type": "credential.access",
"credential_fpr": "sha256:...",
"key_domain": "kd:CA",
"worker_id": "ca-ab-yeg-01",
"custody_class": "pinned",
"request_id": "req_...",
"ts": "2026-06-12T00:00:00Z"
}Credential errors fail before execution.
Missing, unavailable, revoked, or policy-incompatible credentials stop the request before worker dispatch. Some failures create rejection entries so customers can prove prevention.
The request did not specify a credential or the handle does not exist in scope.
The credential is revoked, retired, invalid, or provider validation failed.
The request policy requires a custody boundary this credential cannot satisfy.
No eligible pinned, enclave, or customer-owned node can unwrap and execute under policy.