Who Owns AI API Keys in a Business? Company vs Provider Accounts

In most cases the company should own the model provider account, the billing relationship and the data terms, and the agent should run on scoped API keys issued under that account. A partner-held account can work for a short, clearly bounded pilot, but it moves cost visibility, data handling and exit control into someone else's hands. A simple test decides it: if your implementation partner disappeared tomorrow, could you keep the agent running, or switch it off, without asking anyone's permission?

Key takeaways

• Ownership sits in the account, not in the key. Whoever administers the account controls billing, data terms, usage limits and the power to revoke access.
• A company-held account gives you direct invoices, direct data terms and a clean exit, at the cost of needing an internal owner and a basic finance routine.
• A partner-held account is faster to start and easier to administer, but it hides usage behind the partner's invoice and makes leaving harder.
• The practical middle path is a company-held account with separate, scoped keys per agent role and per environment, stored in a secrets manager.
• Whatever you choose, write down who holds each account, who can rotate each key and how access is revoked before the first key is issued.

What does owning an AI API key actually mean?

An API key is a credential. It proves to a model provider that a request comes from someone allowed to make it, and it ties that request to an account. The key itself is the least interesting part. The account behind it is where ownership lives.

The account holds five things that matter to a business:

• The contract and the data terms, including how prompts and outputs may be retained or used.
• The payment method and the invoices.
• Usage limits, rate limits and the logs that show who consumed what.
• The list of people who can create, view and revoke keys.
• The history you need to audit what the agent did with model access.

Whoever administers the account controls all five. Holding a key without administering the account is closer to borrowing a visitor pass than owning the building.

Three different parties tend to be called "the provider" in these conversations, and mixing them causes confusion. The model provider runs the model. A cloud provider may offer the same model through your existing cloud account. The implementation partner builds and operates the agent. In this article, company-held means the account is in your company's name, whether it was opened directly with the model provider or through your own cloud account. Partner-held means the account belongs to the implementation partner, who passes model access through to you, usually inside a single combined invoice.

What changes when the company holds the account?

The first change is billing. You see the model provider's own invoice and usage breakdown rather than a bundled figure. That makes it possible to tie spend to one agent role and to measure cost per completed piece of work, which is the habit behind the unit economics approach the FinOps Foundation describes. A monthly total tells you very little. Cost per handled supplier query or per drafted reply tells you whether the role is worth running.

The second change is control. You decide who can create keys, you set spend limits, and you can revoke any key in one working session. The third is data terms. The contract is with you, so your legal and security people can read the retention and processing terms directly instead of relying on a summary. The fourth is continuity. If you change partner or model, the account, the usage history and the provider relationship stay where they are.

Ownership also brings work. Someone must administer the account, someone must be the backup, and someone in finance must know the invoice is coming and that it moves with usage. Spend alerts matter for exactly this reason. You also become responsible for key hygiene: where keys are stored, who can see them and when they are rotated.

The most common failure is mundane. The account is opened with one employee's personal email and a personal card to get started quickly, and then that person changes roles or leaves. Open the account with a role-based company address, a company payment method and at least two named administrators. The model invoice is also only one part of running an agent; the total cost of owning an AI agent covers the rest.

When is a partner-held account acceptable?

There are honest reasons to start on a partner's account. A company may have no procurement path for a new vendor yet. It may want a short test on non-sensitive material before committing anything. Or it may have no one available to administer an account in the first weeks. In those cases a partner-held account removes friction, and that is a fair trade if the terms are clear.

Use a partner-held account only when these conditions are written down:

• The arrangement is time-boxed, with a handover date.
• Usage is reported per agent role in a form you can read, not folded into one undifferentiated charge.
• The data handling terms that apply to your content are stated, including any subprocessors.
• Your data, prompts and agent configuration can be exported on request.
• No sensitive company or customer data enters the agent until the account moves under your name.

The risks are real even with those conditions. Billing is harder to audit. A pooled account may share rate limits across the partner's customers. You may be bound by terms you never read. And the longer the arrangement runs, the more the agent's configuration, integrations and history become tangled with an account you cannot administer.

Illustrative scenario: a mid-sized distribution company starts a pilot on a contractor's account because it is the quickest way to test an agent that triages supplier emails. The pilot works, so it quietly becomes production. Months later the contractor engagement ends. The keys live in the contractor's workspace, nobody can say which part of the invoice was model usage, and the data terms were never reviewed. Moving the agent means opening a new account, reissuing every key and re-testing every integration, all under time pressure. None of this was inevitable. A handover date and a usage report would have prevented most of it.

How do billing, control and exit compare?

The differences are easiest to see side by side. Use this as a decision guide: for each dimension, ask which side you would be comfortable defending to your finance lead and your security lead.

• Billing: a company-held account shows the provider's own invoice and usage by project, so spend can be tied to one agent role. A partner-held account usually shows a single combined figure, and you rely on the partner's reports to understand it.
• Control: with your own account you set spend limits, create and revoke keys and decide who is an administrator. With a partner's account those powers belong to the partner, and you ask for changes.
• Data terms: your own account means a direct agreement you can review with legal and security. A partner's account means you inherit terms you did not sign, plus the partner's own handling of your content.
• Capacity: a pooled partner account may share rate limits across several customers, so another customer's busy day can slow your agent. A dedicated account has limits of its own.
• Continuity: if the partner relationship ends, a company-held agent keeps its account, history and keys, and only the partner's access is removed. A partner-held agent may stop or need rebuilding.
• Exit: leaving a company-held setup means revoking the partner's access and issuing new keys. Leaving a partner-held setup means opening a new account, reissuing every key, re-pointing every integration and checking that the agent still behaves the same way.
• Speed: partner-held wins on the first day. The gap narrows quickly, because opening an account is usually a modest administrative task rather than a project.

Between the two sits the arrangement most mid-sized companies end up preferring: the company holds the account and the partner works inside it with limited, revocable access. You get the visibility and exit rights of ownership, and the partner can still do the work. Avoiding lock-in is largely a matter of keeping these control points in your hands, as discussed in how to avoid AI vendor lock-in with business agents.

How should you set up accounts and keys?

This plan works for a first agent and scales to several. It assumes a company-held account with a partner or internal team operating inside it.

• Open the account in the company's legal name, with a role-based admin address, a company payment method and at least two named administrators.
• Create a separate project or workspace for each agent role, and separate testing from production, so a mistake in testing cannot spend production budget.
• Issue one key per agent and per environment, limited to the models and capabilities that role needs. Least privilege, as described in the OWASP authorization guidance, applies to keys as much as to people.
• Store keys in a secrets manager and let the agent's runtime read them. Keys should never appear in prompts, shared documents, chat threads or code repositories, and people should not copy them around.
• Set spend limits and usage alerts for each project, and name who receives the alerts and what they are expected to do.
• Record usage per agent with consistent telemetry, such as request counts, volume and errors. The OpenTelemetry conventions for generative AI are a useful vocabulary, and they let you reconcile the invoice against agent roles.
• Schedule key rotation and an access review, and rotate immediately when a person or partner with access leaves.
• Write down the exit steps: who revokes what, in which order, and how the agent is paused safely while new keys are issued.

Key handling is one case of a wider rule: the agent should have its own identity and accounts rather than borrow a person's, which why your company AI agent needs its own identity and accounts explains. Write the exit steps while the relationship is healthy. The AI provider exit strategy guide lists what to keep, export and document. If your organization follows a risk framework such as the NIST AI Risk Management Framework, this inventory of accounts, owners and revocation steps is also useful evidence of governance.

How does Be Human handle model accounts and keys?

Be Human's default recommendation is that the model account sits in the client company's name, with billing and data terms held by the company. During setup, each agent role gets its own scoped keys per environment, stored in a secrets manager and never in prompts or documents, with spend limits and usage monitoring agreed up front. Managed operations include permission review, which covers who can use or rotate each key, and the handover documentation records every account, key owner and revocation step so the company can change partners or models without rebuilding. If a company prefers a different arrangement, the ownership, reporting and handover terms are agreed in writing before any key is issued.

Frequently asked questions

Can an employee open the account with a personal email and card to get started? It works on day one and causes trouble later, because the account, the invoices and the admin rights belong to one person. Open it under a role-based company address with a company payment method and two administrators, so no single departure can lock you out or leave you paying through someone's expense claim.

Does a company-held account cost more than a partner-held one? Not by default. A company-held account removes an intermediary layer from the invoice and lets you see actual usage, but your total depends on usage, model choice, support and operations. Ask for a usage forecast per agent role and compare total cost of running the agent, not only the model line.

What if we use more than one model provider? Hold each account in the company's name and keep the same discipline for each: scoped keys, spend limits, named administrators and written exit steps. The agent can then route work between models without any provider becoming a hidden dependency, and one review process covers all accounts.

How often should keys be rotated? Follow the schedule your security owner sets, and rotate immediately when someone with access leaves, when a key appears somewhere it should not, or when a partner engagement ends. Scoped keys per agent and environment make rotation a small, routine task instead of an emergency that affects everything at once.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.