API keys are the hardest part of AI attribution. Here is how to resolve them

Attributing AI spend to people would be easy if the providers reported by person. On the API surface they report by key, and a key is a string that could belong to anyone or to no one. Resolving keys to owners is the unglamorous center of the whole problem, and most companies have never done it, which is why their AI spend is a total.

This is what a key can be, what the providers tell you about it, and a process for resolving the ones they do not.

The three kinds of key

Every API key in an organization is one of three things, and the first job is to decide which.

A personal key. One person created it for their own use: their laptop, their scripts, their experiments. Its usage is that person's usage. It should resolve to them and count in their figure and their team's budget.

A shared key. A team, or a whole company, uses one key that someone created once and pasted into a wiki. Its usage belongs to the team, not to any one person, and cannot be split further by anything the provider reports. It should resolve to the team.

An infrastructure key. A production service calls the model on behalf of customers. Its usage is a cost of goods, not a person's spend. It should be marked as infrastructure and kept out of the people view while staying in the ledger, because a company still wants the total.

The fourth state is the honest one: unknown. A key nobody has claimed, with usage nobody can explain. That state should be visible and sorted by spend, because the biggest unknown is the most important decision.

What the providers tell you

More than nothing, less than enough.

A name. Both Anthropic and OpenAI let the creator name a key, and the name is often the only human clue. "jane-laptop" resolves itself. "prod" and "test" say which kind of key it is. "key-3" says nothing.

A workspace or project. Both providers scope keys to a workspace or project, which is often a team. A key in the "sales-ops" project is probably the sales operations team's. This is a strong hint about the team even when it says nothing about the person.

An owner, sometimes. OpenAI records who owns a key, and when the owner is a user rather than a service account, that is the person. This is the single most useful field either provider exposes, and it resolves a large share of keys with no human involvement. Anthropic does not expose a creator on its admin API.

The usage pattern. A key that spends the same amount every hour, on the same model, seven days a week, is a service. A key that spends during working hours in one time zone with a spike on weekday afternoons is a person. The pattern is not proof, but it narrows the guess.

The process

Here is a process that works, in the order that resolves the most spend fastest.

1. Take what the provider gives you. Every key with a recorded owner resolves to that owner, automatically, on every sync. Every account the provider names by email becomes a person without anyone typing. This should happen before a human looks at anything.

2. Build the directory first. The rest of the resolution depends on having a list of people to resolve to. Pull it from the CRM, the identity provider or Slack, by email, with team and role where they exist. Resolution is a pick from a list, and the list has to exist.

3. Sort the unknown by spend. The unmatched queue should show the biggest unknown first, with the key's name, its workspace, its usage pattern, and its spend. Ten keys usually account for most of the unattributed money, and resolving those ten is an afternoon.

4. Resolve in one choice. For each key, the person doing it picks a person, a team, or infrastructure, from a search box that knows all three. The choice is the whole decision, so it should save on selection and write an audit row. A form with a save button for each of a hundred keys is why this never gets done.

5. Re-attribute the past. When a key resolves, every historical usage row on that key moves to the owner. The person's spend starts when their usage started, not when someone got around to the mapping.

6. Ask, for the rest. A short message to the workspace owner, "these three keys in your project spent this much last month and nobody has claimed them", gets an answer most of the time. Automate the message if the volume justifies it.

Shared keys deserve a policy, not a mapping

Once shared keys are identified, the question is whether to keep them. The case for splitting a shared key into personal keys is that it makes the usage attributable. The case against is friction. The right answer is usually to split the expensive ones and leave the cheap ones, and to make sure the team budget counts the shared key either way, so the budget cannot be routed around through it.

What good looks like

A company with resolved keys has three numbers it can defend: spend by person, spend by team including shared keys, and unattributed spend, which should be small and falling. The third number is the health metric. If it is growing, keys are being created faster than they are being claimed, and the process needs to run more often.

None of this requires reading a single prompt. Key names, workspaces, owners and usage patterns are metadata, and metadata is enough.

Arbitir registers every key and account the providers name, resolves keys with a recorded owner on its own, builds the directory from HubSpot, Salesforce or Slack, shows the rest in an unmatched queue sorted by spend where a choice of person, team or infrastructure saves on selection with an audit row, and re-attributes history when a mapping lands.