Restructuring your API keys will not fix your AI spend problem. It will give you more secrets to rotate and the same unattributed invoices. The teams I see splitting keys to solve spend attribution are solving the wrong problem, and adding operational overhead they did not budget for.
The actual problem is that AI calls do not carry attribution metadata when they leave your infrastructure. That is a different problem, and it has a different fix.
You Have Already Solved a Version of This
When microservices became the default architecture pattern, engineering teams ran into the same wall. Logs everywhere. Dashboards green. Total latency 800ms. No way to trace a single request across ten services and know which hop spent 600 of those milliseconds.
The solution was not splitting the services differently. It was distributed tracing: attaching a shared identifier to each request at the point of origin so that its full path through the system could be reconstructed after the fact. Jaeger, Zipkin, OpenTelemetry. These tools exist because the right instrumentation layer was missing, not because the service architecture was wrong.
AI spend has the same instrumentation gap. The key architecture is not the issue. The missing piece is a layer that attaches attribution context to every call before it leaves your stack.
What the Gap Actually Looks Like
Every AI call your organization makes carries a timestamp, a token count, and an API key. It does not carry a team name, a feature flag, a workflow identifier, or an outcome tag unless your infrastructure explicitly adds those before the call goes out.
The vendor bills what the call carried. One key or ten keys, it does not matter. If the call carried a token count and a key, the invoice is a token count and a key. Attribution is not in the key. It is in the metadata attached to the call. A team using a single shared key with proper call-level metadata has better attribution than a team running per-service keys with nothing attached.
The Fix Is an Instrumentation Layer
The architectural correction is adding a layer between your application code and your AI vendors that enriches every outbound call with attribution context: the task type, the workflow it belongs to, the team that triggered it, the feature it is serving. That context has to be in the call when it leaves your infrastructure. The vendor's record is written at the moment the request completes. There is no adding it later.
Some teams build this as a proxy service. Some implement it as a wrapper around their AI SDK. The implementation is secondary. What matters is that every call your organization makes carries the metadata that makes it attributable. That layer is what distributed tracing was for latency. Your AI stack does not have it yet.
The Honest Trade-off
An instrumentation proxy adds a component to your critical path. It has to be maintained, monitored, and kept available. That is a real engineering cost and it belongs in the roadmap conversation, not minimized.
What it is not is a cost that scales with your team count. You build it once. The operational overhead is fixed. A key-per-team architecture gives you more secrets to manage, more rotation schedules to run, and more access audits to coordinate, multiplied by every team that onboards afterward. Both approaches involve real work. One of them solves attribution. The other solves access control and leaves attribution unsolved.
What This Makes Possible
When attribution is embedded at the call level, the questions that have been unanswerable become answerable in real time. Which task type is driving cost growth. Which agent is generating the most calls. Whether cost per workflow is trending up or down. Whether the model you chose for a use case is performing better than the alternative over time. Those answers require attribution data at the call level. They do not require a specific key structure.
At Oberhahn, this is the layer we built. An instrumentation system that sits between your application stack and your AI vendors, attaches attribution metadata to every call, normalizes it across vendors, and makes it queryable by task, by workflow, by team, by outcome. It works with the key architecture you already have. It does not require a migration. You turn it on, and every call from that moment forward is attributable.
Distributed tracing did not require teams to redesign their service architecture. It required an instrumentation layer that made the existing architecture observable. AI spend has the same problem. The fix is the same kind of layer.