Connect your model
Bring your own key
Keep customer inference, workspace provider connections, and Integrity authorization distinct.
Bring your own key (BYOK) means using your provider account for customer-model inference. Keep your intended model and configured provider or router, and route supported traffic through the deployment's Integrity base URL.
Three separate credentials#
Platform key
Your server sends the platform key to Integrity. It identifies which deployment is requesting service; it is separate from the credential used to call your model provider.
- Responsibility
- You manage it in the workspace.
- Boundary
- Customer deployment admission
Keep credentials out of prompts, tool results, and client-side code.
| Credential | What it authorizes | Who manages it |
|---|---|---|
| Platform API key | Admission to the workspace-scoped Integrity deployment. | Your authorized workspace administrators. |
| Customer provider credential | Inference through your configured provider or router and billing account. | Your provider account and server-side application. |
| Runtime grant | Tenant-scoped Integrity evaluation behind the platform connection. | Integrity; your application does not construct or receive it. |
Connect your customer model#
Use the deployment's connection instructions to configure the upstream route. In your model client, set the Integrity base URL, keep the provider key as the model client's credential, and add x-triage-api-key, x-triage-session-id, and Idempotency-Key for Integrity identity.
For Chat Completions and Responses, the gateway receives the provider credential as Authorization: Bearer …. Anthropic Messages uses x-api-key. Azure-compatible upstream routes use the documented gateway translation; read Authentication before configuring custom headers.
The gateway uses the provider credential supplied on the request. A saved dashboard connection does not automatically supply that credential. If a route, credential, or required review fails, the gateway does not silently switch your customer model, provider, or account.
Keep both keys in server-side secret storage. Disable provider-client automatic retries and cross-origin redirects, and recover uncertain work by its original operation ID. The Python and TypeScript examples include these settings.
Saved workspace connections#
Workspace features such as available graders can use separately saved provider connections. These credentials are stored in authenticated encryption envelopes. The provider resolver uses an eligible customer connection first; some interactive features can use a configured platform-funded provider when no eligible customer connection is available.
Inspect the selected provider, model, credential source, and recorded usage for those jobs. Their routing and accounting are separate from intercepted model traffic. Do not assume a workspace grader uses your agent's provider key or bills the same account.
Rotation and recovery#
Rotate the platform key and provider key in their respective systems, update your secret store, and verify the intended deployment and route before resuming. A provider credential change can invalidate an existing route binding; recover or reconcile the original operation instead of resubmitting with new identifiers.
Never put a secret in a task prompt, constitution, feedback note, browser bundle, or support report. See Security and evidence for encrypted storage, redaction, and retention boundaries.