Transcript: connect your provider API key safely
This walkthrough connects a provider API key to AI Gateway HQ without copying that provider secret into every tool. The gateway keeps the credential at one encrypted control boundary while applications use separate workload identities and approved routes.
1. Use an API credential
Start with an API credential issued by the provider account you control. A ChatGPT, Claude, or coding-agent subscription login is not interchangeable with a provider API key unless that provider offers an explicit supported authorization flow.
2. Restrict the key before saving it
At the provider, create a dedicated credential with the narrowest useful permissions, quota, and spend boundary. Separate production from test, avoid personal credentials, and keep the provider's own account alerts enabled.
3. Name the account clearly
In Providers, choose Add BYOK provider. Give the account a name that identifies its owner and environment, select the supported provider profile, and enter a base URL only for Azure or a customer-validated OpenAI-compatible endpoint.
4. Encrypt, verify, and enable
When you save, the credential is encrypted before storage and is never returned through the console. AI Gateway HQ verifies supported catalog access without sending a prompt or creating inference spend. A failed verification leaves the account disabled.
5. Give applications separate identities
Do not copy the provider key into the calling application. Create a separate AI Gateway HQ workload key for each application and environment, then store that one-time key in the application's secret manager.
6. Reference the account from a route
Add the enabled account to an approved route with an explicit model and priority. Multiple accounts can support bounded fallback or balancing, but capability, health, quota, policy, and budget eligibility are always checked first.
7. Rotate through a safe stop
When a provider key changes, use Rotate instead of creating an ambiguous duplicate. The replacement is encrypted and the account is disabled. Test the new secret, then explicitly enable it before traffic can use it again.
Verify the boundary before expanding
Confirm that the Providers view shows only a fingerprint and current health, then send a small governed request. Review the route, provider attempt, policy decision, usage, latency, and cost evidence before adding more workloads or provider accounts.