BYOK for hosted AI agents

BYOK, or bring your own key, means a hosted agent uses credentials issued under your model-provider account. You control that account and can revoke its credentials. The hosting service still runs the agent and may handle the key so the agent can make requests. Key ownership alone does not establish who can read it or where prompts are processed.

For a team choosing hosted agents, BYOK can make provider usage easier to attribute and keep model access under its own account. It also creates an operating responsibility: someone must manage permissions, investigate usage, rotate credentials, and keep the agent running when access changes.

Which account pays for the model?

For requests authenticated with your own model-provider key, usage is associated with the provider account that issued it. Hosting charges are a separate part of the arrangement. Check whether the hosting product also includes a default model, credits, a router, or a fallback provider, because those paths may have different billing rules.

A useful cost record separates the hosting subscription from provider usage and other paid tools. Our always-on agent cost model shows how to account for those charges separately. Do not assume a change to one automatically limits the others. Removing an agent's hosting seat, for example, is not a substitute for revoking a key that remains usable elsewhere.

For an agency, choose who owns each provider account before connecting it. A client-owned account gives the client direct control of its model billing and credentials. An agency-owned account can simplify administration, but requires agreed allocation and an offboarding procedure. Avoid passing a single personal key among teammates; OpenAI's guidance calls for individual keys and appropriate permissions. OpenAI API-key safety guidance.

Where does the key go in cloudrun?

cloudrun's published engine documentation directs users to connect their own providers in the Models panel. The implementation reviewed on September 5, 2026 receives a provider key through an authenticated server route, checks access to the project, and sends the key to the selected Hermes profile. The runtime validates the key and saves it through its environment configuration interface. cloudrun engine documentation.

This describes the inspected implementation, not a test of the deployed release. In that implementation, the key passes through the hosting control plane and is made available to the runtime, so both belong inside the credential's trust boundary.

The same inspection did not establish a model-key vault with a published encryption design or a zero-knowledge arrangement. A claim about encryption at rest needs evidence for the actual storage and key-management configuration. The fact that a value is hidden in the settings screen does not supply that evidence.

Are environment variables hidden from agent tools?

An environment variable keeps a credential separate from application source, but it is still available to processes that receive it. Upstash explicitly warns that code running inside a Box can read environment credentials. A tool or script in that environment therefore belongs inside the credential's trust boundary. Upstash security documentation.

This matters when an agent can install packages, run shell commands, or execute a newly added skill. Review those capabilities before adding a key with broad access. A project-specific credential with limited permissions is easier to reason about than an account-wide credential used across unrelated workloads.

Keep keys out of prompts, skill documents, ordinary logs, and repository files. OpenAI also advises against deploying API secrets in browser or mobile application code. The secret should be handled by the intended server-side credential flow. OpenAI API-key safety guidance.

Are profile keys independent?

Hermes profiles separate configuration and state on the same machine. That is useful for running agents with different models or purposes. It is still necessary to inspect how each credential type is stored and shared, especially when a profile is cloned.

Current Hermes documentation says static keys can be copied during cloning, while some OAuth logins are shared through the root authentication store to avoid duplicating single-use refresh tokens. A second profile is therefore not automatically an independently authorized account. Hermes profile documentation.

For client work, verify the selected profile's provider account after creation or import. Run a small controlled request and confirm attribution in the provider's own usage view. Do not rely only on a connected badge or a profile name.

What should the credential inventory contain?

Maintain a record of each credential's purpose without storing its secret value in that record. An inventory should let an operator find the issuing account, identify affected deployments, and contact the person who can replace it. For client work, connect this record to the ownership and offboarding process in the agency fleet playbook.

Keep development and production credentials separate where the provider supports it. This makes a test failure or accidental workload easier to contain and lets you rotate one environment without interrupting the other.

Evaluate the setup with a test credential

Before using a client's account, agree who owns the model key, its spend limit and its revocation procedure. Use a separate test credential to evaluate the documented cloudrun Models setup, then verify what the agent can access.

Create a test workspace, and use the credential inventory above before connecting a client workload. Carry the account owner and revocation decision into the client-agent launch checklist so they remain part of the handoff.

Does disconnecting a provider revoke the key?

In the reviewed cloudrun code, disconnecting an API-key provider removes its runtime environment setting. It does not call the issuing provider to revoke the credential. Any other copy of that key may therefore remain usable until the issuer disables it.

For a suspected leak, revoke or rotate the credential at the provider and investigate usage. For a planned replacement, create the replacement, update the intended runtime, confirm a small request works, and retire the old key. OpenAI's guidance specifically recommends monitoring usage and rotating a suspected compromised key. OpenAI API-key safety guidance.

Backups need attention too. A backup made before rotation may contain the old credential. Restoring it should not silently make that credential part of the operating configuration again. Include credential replacement in the restore checklist.

Does BYOK mean private inference?

BYOK identifies the account used to authorize model requests. It does not by itself change the model provider's processing, retention, or training policy. Review those settings for the actual provider, account, endpoint, and plan you use.

Likewise, a key owned by the customer does not imply that the hosting operator cannot administer the runtime. Review the hosting service's access policy and telemetry configuration independently. Avoid converting a billing feature into a broader privacy claim.

Before connecting a production key, confirm the issuing account, grant only the access required, and name the person responsible for replacement. After connecting it, verify a real request in the provider's usage records. That gives the deployment owner a concrete basis for managing model access over time.