Cost Allocation and Chargeback for AI Agent Traffic

Enterprise generative AI spend more than tripled in a single year, jumping from $11.5 billion in 2024 to $37 billion in 2025. Ask any CFO the obvious question: which team, feature, or workflow caused last month's spike in the AI bill? Most enterprises can't answer it. The spend is real. What's missing is a system underneath it built to track who spent what.

Uber offers a clean illustration of how fast this goes sideways. Roughly 5,000 engineers rolled out AI coding tools in late 2025, with per-engineer API costs running $500 to $2,000 a month. By April, the entire 2026 AI budget was gone. Nobody had a system telling them, in real time, that the burn rate had gone off a cliff. Cost accountability for AI is fundamentally an observability problem. It gets solved by tagging every request the moment it's made, before finance ever has to reconcile invoices after the fact.

Why AI costs behave differently from every other IT cost organizations already manage

Server costs scale with capacity. SaaS licenses scale with seat count. Both are boring, predictable, and easy to forecast a quarter out. AI costs scale with usage patterns that swing wildly based on who's prompting, how complex the task is, and how much autonomy the agent has been given. The old forecasting playbook doesn't transfer.

Agentic tasks can consume up to 1,000 times more tokens than a simple chat exchange, and the same task can vary by as much as 30 times in total token use from one run to the next, because the agent might take three tool calls to solve something one day and fifteen the next. That variance is a budgeting nightmare. The same "task" can cost wildly different amounts depending on how the agent decided to go about it that day, and a runaway loop, stuck retrying a failed tool call or looping through a bad plan, can burn through thousands of dollars in minutes. Watching request rates won't catch that. Telemetry that prices out cost in real dollars, in real time, catches it.

There's a split hiding inside the token count that most dashboards flatten out entirely, and it's the single most common way teams get their AI math wrong. Output tokens cost far more than input tokens: GPT-4.1 runs $2 per million input tokens versus $8 per million output tokens, and Claude Sonnet 4.5 runs $3 per million input versus $15 per million output. A tool that reports "total tokens used" without breaking that split out is hiding the exact number finance needs. Add in reasoning tokens from o-series models, billed but invisible in the completion length anyone actually sees, and the accounting gets murkier still. FinOps tooling built for cloud infrastructure was never designed for per-request, per-agent, multi-model variance like this. Bolting it on after the fact relocates the blind spot rather than closing it.

How enterprises structure accountability before they can charge anything back

Showback and chargeback sound like the same idea filtered through different corporate dialects. Showback tracks and reports AI costs to business units but leaves the money in a central budget, building awareness without moving a single dollar. Chargeback actually invoices the consuming unit, which creates real P&L impact and forces teams to prioritize their AI use cases the way they'd prioritize headcount. Applied too early, chargeback chills the exact experimentation an organization needs during early adoption. That's the tradeoff most rollout plans get backwards: they reach for the stick before anyone's built the muscle.

The hybrid model most enterprises land on works like this: a central budget absorbs foundation costs, meaning governance, AI literacy training, and shared infrastructure, while the incremental cost of a specific use case gets charged back to the business unit that commissioned it. One framework for this describes a multi-year shift: roughly 70/30 foundation-to-use-case spending in Year 1, moving to 40/60 in Year 2, and 20/80 by Year 3. The ratio flips because early AI use is exploratory and hard to attribute to one owner; by Year 3, the use cases are known quantities and deserve to sit on somebody's P&L.

None of this works without granular tagging underneath it, and most organizations are further behind on that than their FinOps dashboards would suggest. Formal management on paper doesn't guarantee anyone can actually see where the money went; a written policy is not the same thing as working visibility. Before any of it works, someone has to agree on a taxonomy: which costs belong to the center, which belong to the business unit, and at what level attribution actually needs to happen, whether that's user, team, workload, or feature. Skip that conversation and every dashboard downstream is just decoration.

The mechanics of tagging every agent request to an owner

Every AI agent request needs a chain of identity attached to it the instant it's made, not stitched together afterward from scattered logs. That tag has to carry the user or service identity that initiated the request, the team or business unit for chargeback rollup, the workload or feature for product-level attribution, and the model and provider used for cost calculation. It also needs the token breakdown split out: prompt tokens, completion tokens, and, where the model supports it, reasoning tokens counted separately.

Four allocation methods cover most of how this gets done in practice. Proportional allocation splits costs based on actual usage across a shared resource pool. Telemetric allocation uses per-request logs to attribute costs precisely to each consumer. Custom rules apply business logic on top, discounting internal tooling or surcharging customer-facing agents. Virtual tagging lets teams attribute cost without rewriting every application to emit the right metadata, which matters a lot when retrofitting agents built before anyone thought about chargeback.

OpenTelemetry span tags have become the common instrumentation layer for this. Costs get attributed by team, feature, and user through span metadata, so the attribution travels with the request through every hop of a multi-step agentic workflow instead of getting lost at the first handoff.

Reporting and enforcement are two different jobs, and conflating them is where a lot of programs quietly fail. A month-end chargeback report tells finance what happened last month. It does nothing to stop a team from blowing through its allocation on day twelve. Hard caps that throttle or alert before a budget threshold is crossed have to act during consumption, which means the control layer has to sit inside the request path itself, watching in real time rather than reconstructing events from logs after the fact.

The problem compounds fast in multi-agent workflows. An overnight job routing through several different model APIs can rack up real cost with no identifiable owner unless each agent's identity gets propagated through every single hop of that chain.

Where existing tooling covers the gap and where it leaves attribution incomplete

Two broad categories of tools try to solve this today, and neither closes the gap alone. Platform-level cost management tools like CloudZero, Finout, and Apptio Cloudability pull OpenAI, Anthropic, and cloud AI spend into a unified dashboard. Useful for finance-level rollups, sure, but they depend entirely on tags being set correctly upstream. Feed them garbage and they report garbage with confidence. LLM-native observability tools like Langfuse, Helicone, and Portkey give per-request token tracking for teams that instrument their own applications directly. Strong for single-application visibility, noticeably weaker once an agent starts hopping across multiple tools and services.

Provider-native attribution has gotten better, but it still isn't built for enterprise agentic use, and treating it as sufficient is the mistake most platform teams make first. Anthropic's Enterprise Analytics API added per-user attribution but stops short of per-request granularity. Snowflake's AI observability tools can track AI function costs by user and model, but agent-level attribution across a genuinely multi-agent environment still needs extra tooling layered on top.

The deeper structural issue: application-layer instrumentation only works if every team instruments its own agents correctly and consistently, every single time. In practice, that discipline breaks down, and ungoverned or shadow AI workloads produce no tags at all. Shadow AI is the attribution gap that never shows up in any dashboard: spend that lands on the invoice with no owner in any allocation system whatsoever. No amount of downstream tooling fixes a tagging problem created upstream.

Why the MCP gateway is becoming the natural home for AI cost attribution

Anthropic released the Model Context Protocol in November 2024. By December 2025, it had reached 97 million monthly SDK downloads. Fast adoption created an immediate governance headache: connecting AI agents directly to dozens of MCP servers at scale isn't operationally sustainable, and the protocol itself doesn't solve governance. No attribution, no access control, no audit trail comes built in.

An MCP gateway sits in the middle as a control plane and closes exactly that gap. It centralizes authentication and authorization, so every agent request passes through one governed layer before it ever touches a tool or data source. It propagates identity, stamping each request with the agent's identity and the human or service principal behind it, so attribution rides along through multi-hop workflows automatically instead of evaporating at the first handoff. It keeps a durable audit log of every tool call, every token event, every access decision. And it enforces policy in real time: budget caps, rate limits, and access restrictions applied the moment the request happens, not reconstructed from logs a week later.

Emerging practices guidance treats MCP the same way organizations already treat any other API surface: put a gateway in front of it. The comparison holds up. MCP servers need a governed distribution layer for the same reason REST APIs need an API gateway. Direct, ad hoc agent-to-server connections aren't auditable, aren't attributable, and don't scale past a handful of teams before someone loses track of what's talking to what.

None of this works if the identity behind the request is anonymous, and that's the part vendors gloss over. The MCP specification has incorporated OAuth 2.1, but implementation quality varies across servers, and on-behalf-of identity propagation through multi-agent chains needs explicit testing before anyone trusts it. Role-based access control tied to an existing identity provider, Okta or Entra ID, is the only way to guarantee every request carries a verifiable owner at scale. Shared credentials or anonymous service accounts collapse attribution back to zero, no matter how good the gateway's telemetry looks on paper.

What to look for in an MCP gateway when cost attribution is a requirement

A handful of questions separate a gateway that actually supports chargeback from one that just looks good in a sales deck. Does it emit token counts, model calls, and latency at the individual request level, or only as aggregates that hide the variance discussed earlier? Does identity propagate through multi-agent hops, or does attribution quietly stop at the gateway's own boundary? Does it plug into the identity provider already in place, SSO and RBAC through SAML or OIDC, so ownership gets enforced at the team and role level without standing up a second, parallel identity system? Can it throttle or alert before a budget threshold gets crossed, or does it only report after the damage is done?

The 2026 vendor landscape reflects a market still sorting itself out, and the differences between vendors are worth taking seriously rather than treating as interchangeable checkboxes. Some vendors position themselves as enterprise AI control planes connecting agents and MCP servers through a governed layer, enforcing RBAC through existing identity providers and surfacing real-time cost and usage telemetry, built for security and platform teams who want governance from day one rather than retrofitted later. Speakeasy is one such platform, built specifically for governing AI agents and MCP servers across enterprise teams. Kong AI Gateway offers an MCP proxy capability, a natural fit for organizations already running Kong for API management. Other vendors lean enterprise with managed deployment options. Some gateways target container-based deployments with administrator control over which teams can reach which servers.

What to avoid: local or Docker-based MCP deployments, which ship with no production governance whatsoever. No RBAC, no audit logging, no centralized access control. Bolting authentication and identity management onto that setup after the fact, at enterprise scale, costs more engineering time than most teams budget for going in. And whichever gateway gets chosen, its telemetry has to feed directly into whatever FinOps tooling the organization already runs. Attribution that lives only inside a gateway's own dashboard is a nicer-looking dead end, not allocation infrastructure.

How to move from a working attribution layer to an operational chargeback program

Attribution infrastructure is the prerequisite, not the finish line. The technical layer, tags, identity propagation, real-time telemetry, has to get wrapped in process before anything resembling a chargeback program exists, and skipping that step is the single most common way these programs die in their first year.

A staged rollout is the difference between a program that survives contact with actual business units and one that gets quietly killed in its second quarter. Stage one is showback: publish cost reports to business units with no budget transfer attached. This builds familiarity with the data and, more usefully, surfaces owners who genuinely had no idea they were driving a meaningful share of the AI bill. Stage two is soft chargeback: assign a notional budget against actual consumption, still with no real financial transfer, so teams start feeling the shape of accountability before it costs them anything. Only after those two stages does real chargeback, with actual invoices and actual P&L impact, become something a business unit can absorb without treating it as a hostile surprise.

Skip straight to invoicing teams for AI spend before the attribution layer is solid, and the numbers on that invoice will be wrong, contested, and ignored, and the whole program loses credibility in one bad billing cycle. Get the attribution right first, and chargeback becomes a number every team already recognizes as its own, rather than a finance mandate nobody trusts.