Caller identity in agent and tool traffic: who the gateway sees

Caller identity is the origin of the call, not the credential that carried it. When two teams share the same agent, the gateway recognizes the credential and not the person: quota, trace, and authorization collapse into one thing. The NIST published SP 800-63-4 in July 2025 to separate authenticating a credential from asserting identity.

The three boundaries a company believes it has disappear together. The invoice arrives later.

What exactly is lost when the credential is shared

A gateway that sees only the credential loses three things at once, and the company treats each one as a separate problem. It loses quota, because the ceiling now covers the whole group. It loses the trace, because the trace records the key and not the team. And it loses authorization, because the scope granted to the neighbor applies to whoever stands nearby.

All three come from the same cause. The credential is a shared object, and a shared object has no owner. The engineering team opens a key for a triage agent, the support team finds out it works, the revenue team plugs the same agent into its own workflow. Nobody did anything wrong and nobody decided anything. The boundary simply vanished, and the first place it hurts is not the invoice.

The invoice is an aggregate document. It is not false, it is insufficient to answer the question finance asks. Who spent it. On what. Authorized by whom. An invoice that sums four teams into one line answers "the company spent it," and that answer was already known before the invoice arrived.

Why a per-key ceiling is not a per-business-unit ceiling

The AI budget per team starts from an explicit premise: the key is the team. The per-key ceiling, the alert at 80%, and the trace per call all work while that premise holds. The problem is that it stops holding the moment the second team uses the same agent, and nothing in the system announces that it happened.

Modeling, not configuration. A per-key ceiling answers the question "how much did this credential consume." A per-business-unit ceiling answers "how much did the revenue team consume, on which model, and who answers for it." They are different questions, and the second is not obtained by dividing the first.

The fifth row is the one that decides the value of the modeling. A per-key ceiling does not fail visibly when the premise breaks. It keeps working exactly as designed, summing what it can see, and what it cannot see is the difference between the area's real consumption and the consumption that shows up on its bill. The error does not produce an alarm, it produces a number.

Caller identity: the full chain, and where it breaks

Caller identity is the attribute that answers who originated the call, and it has to survive from the end user to the tool server. The full chain has five links: the end user, the agent, the credential the agent uses, the gateway the call passes through, and the tool server that executes it. Identity dies when one of those links carries only the credential and not the origin. The first link is the one with no mechanism by default, not a guaranteed step. The user's identity only enters the chain if the agent host authenticated it and passed it forward. A static key does not carry it, which is why the break at the entry point is the most common one.

There are three break points, and none of them is exotic. The first is the entry: the agent authenticates with a static key and the human behind it never reaches the gateway. The second is delegation: an agent calls another agent, or a subagent, or a tool server that fires a new call, and the origin is not propagated on the second leg. What is lost there is not only the propagation, it is the re-authorization. A subject that arrives at the second leg without a reduced scope carries the identity without reducing the authority, and that is a worse failure mode than simply losing the origin, because the trace points at the right person with the wrong permission. The third is the exit: the tool receives the call without knowing on whose behalf it is being executed, so it applies the credential's permission.

Caption: caller identity has to survive from the origin to the tool; three break points collapse quota, trace, and permission.

The second point deserves attention because it is the least visible. The tool traffic control plane established the gateway as the single inspection point and named authentication and auditing as its functions. Recognizing the credential, however, is not recognizing the caller, and the difference shows up precisely in delegation. A flow that calls three tools in sequence logs three lines with the same credential identifier. The question auditing asks, which user triggered this chain, has no answer in any of the three.

The log shows the key. It does not show the person.

Cost and access break on the same cause

Calling this a cost problem underestimates the defect. The shared credential is an authorization vector, and the over-permission it produces is structural, not accidental. A team that only needed to read can now write because the neighbor's credential allows it, and nobody granted that permission by decision, it was inherited through sharing.

The failure mode is always the same. The agent belongs to one area, the tool belongs to another, and the scope is the wider of the two because nobody declared the smaller one. The support team gains write access to the financial system because the triage agent was authorized to post a record and the key is the same. The first sign is not the ceiling blowing out: it is an altered record that nobody recognizes as their own.

One account answers for two areas.

The Model Context Protocol authorization specification addresses this point directly. It requires the client to include the resource parameter in the request and the server to validate that the token was issued specifically for it, rejecting tokens that do not name it as the audience. Audience binding only holds when the authorization server honors that parameter, so it is a question to ask the vendor, not a standard to assume. The same section prohibits the server from passing the token it received from the client downstream to the API, which is token passthrough. The reason is the confused deputy, an old authorization failure pattern: an intermediary with a broad credential acts for someone who has none, and the downstream system trusts it. Passthrough is one of the routes into that state.

The LLM gateway is the only position in the architecture that sees both sides of that flow. That is why the fix belongs there and not in each application.

What the gateway has to carry for identity to survive

A gateway solves the problem when it carries seven things, and none of them is optional. The list below is not a configuration, it is the minimum contract between the identity a system claims to have and the identity it can prove per call.

1. Originating subject. The end user's identifier travels on the call, and the browser session is not enough. Without it, the gateway authenticates the machine and ignores the person.
2. Authorization context per call. The permit decision is recomputed on every execution, with scope declared per tool, instead of granted once at credential creation.
3. Attribution per business unit. Quota, policy, and trace point at the responsible area, and the area is a first-class attribute, not a label applied afterward.
4. Propagation on delegation. When an agent calls another agent, or a subagent, or a tool server that fires a new call, the originating identity survives the second leg.
5. Complete trace per call. Every execution records subject, area, key, tool, model, tokens, and cost, and the LLM call audit can reconstruct the entire chain from any point in it.
6. Effective least privilege. The call's scope is the intersection of what the area may do and what the tool requires, and the excess is denied by default instead of tolerated.
7. Ceiling on the right dimension. The API key spend cap remains valid as treasury protection, and the ceiling that answers to the area is a second control, applied over the same call.

The order matters little. The absence of any one of them, however, reopens the defect. The seven are not at the same maturity stage: the originating subject on the call is current delivery, and propagation on delegation is still rare in production tooling. On the vendor side, the practical question is which of those seven properties the gateway delivers today, and it is in the LLM gateway for the enterprise that the list gets checked.

Four sharing arrangements: what is lost in each one

The table below crosses four real sharing arrangements with the three boundaries, and shows where each one falls. The quota column collapses first in all of them, which is why the problem gets diagnosed as cost when the cause is identity.

The first row is the configuration that works, and it is not the most common one. The second is the one that shows up most often in companies that grew fast, because sharing the agent is the cheap decision and nobody measures its cost on the day it is made.

The fourth row explains a specific symptom: production spend that nobody can reproduce in test, because test uses the production key and both consumptions land on the same line. When the team finally separates the keys, production spend looks like it drops, and in fact it only became visible.

Test and production do not separate themselves.

Where it hurts first, and why it is not this month's invoice

The first place the absence of caller identity causes real damage is not the monthly close. It is the software contract renewal, when someone has to justify what was bought and cannot attribute consumption to any area. This month's invoice is a cash problem. Cash gets solved. A renewal without attribution is an internal credit problem, and that one does not get solved with payment.

There is also the regulatory reading, and it has a deadline. The NIST published the final revision of the Digital Identity Guidelines in July 2025, replacing SP 800-63-3, and the series deals precisely with the difference between authenticating a credential and asserting a subject's identity to a service.

None of them obliges a private company to anything. NIST does not regulate the buyer, it regulates the vocabulary. The standard that shows up in contracts, vendor questionnaires, and internal audits asks who, never only whether. That reading is this one, not a measured figure. SP 800-63C, the federation volume, requires the assertion to be restricted to a specific recipient starting at FAL2, which is the same property the test below looks for in the gateway. A company that can only answer "the credential" is left with a gap that nobody signs off on.

The counterargument, in its strongest version

The serious objection is not that caller identity is irrelevant. It is that managing identity per call is expensive and adds a failure point in the critical path. The gateway starts depending on an identity service, the service goes down, the traffic stops. Operational simplicity has value, and the single key is simple.

The answer is that the objection describes the cost of doing it and ignores the cost of not doing it, which is already being paid. Every incident that requires reconstructing who altered a record in the financial system consumes days of engineering, and a handful of them in a year already exceeds a week of stalled work. Every renewal without attribution consumes a renegotiation. The cost is not created by caller identity, it becomes visible.

There is also an architectural reason for the identity service to be less fragile than the objection assumes. The MCP specification recommends the short-lived token, and makes the resource parameter on the client side and audience validation on the server side mandatory. It also obliges refresh token rotation for public clients, which is what closes the window on a leak. A gateway that respects that contract depends on tokens that expire and not on long sessions, which reduces the impact of a leak instead of amplifying it.

How to test whether the gateway recognizes the caller before you sign

The test fits in one afternoon. It requires no production traffic and no sophisticated agent, and the answer that matters shows up in the first question within the first hour.

1. Register two distinct keys and assign each one to a different area, with the same agent running on both.
2. Fire the same tool call chain through both keys, including a two-leg flow where an agent calls a tool that fires another call.
3. Read the trace the way finance would. Does each area's call appear separately, with the originating user identifier and the cost per model?
4. Verify the second leg of the delegation. Does the origin survive when the call is handed off, or does the second tool's log show only the credential?
5. Try to deny with the neighbor's key. Give one area a key with the neighbor's wider scope and fire, as a user of that area, a tool its own scope does not cover. The refusal has to come from the caller, not from the key. If the request goes through because the credential authorizes it, the gateway applies policy to the key and still does not know the caller.

The fifth question separates applying policy to the caller from applying policy to the credential. A system that denies only what the key does not allow is logging traffic with scope, not governing who called. Worth saying what the test does not prove on its own: a single refusal is compatible with a gateway that only looks at the key, which is why the variation above inverts the question instead of repeating it.

FAQ

What is caller identity in an LLM gateway? It is the set of attributes that answers who originated a call, and the credential that carried it is only one of them. It has to survive from the end user to the tool server, and it covers at least the originating subject, the responsible business unit, and the authorization context of that specific execution.

Why does a per-key ceiling not solve budgeting per business unit? Because the per-key ceiling measures what the credential consumed, and the credential stops representing one area when two teams start using the same agent. The number stays correct. And useless. A per-business-unit ceiling requires the area to be an attribute of the call, not an inference made from the key.

Is sharing the agent credential between teams always a mistake? Not always, but it is always a decision that has to be recorded. In a test environment, with synthetic data and a low ceiling, sharing is acceptable and economical. In production, with customer data and a transactional tool, it mixes quota, access, and trace into a single line that nobody can separate afterward.

How does identity survive when one agent calls another agent? It survives when the originating identity is propagated as part of the delegated call, and not replaced by the second agent's credential. In practice, that means the gateway has to issue an authorization context for the chained execution that preserves the original subject and restricts the scope to the destination tool.

Is caller identity the same as API key authentication? No. Key authentication answers whether whoever called may call. Caller identity answers who they are, on behalf of which area, and with what authorization. A gateway can authenticate every call successfully and still be unable to answer who altered a specific record.

How much of this does Nexforce Router already cover? Router governs budget per key, per agent, and per project, with real-time consumption of tokens per session and per agent, routing rules per key, and the complete trace of every call. It is the layer where quota, policy, and trace live in the same control point, which is why per-business-unit modeling starts there. Whoever is choosing the tool can start from the criteria for evaluating an LLM gateway and apply the questions from the test above to each candidate.

Further Reading and References

• MCP gateway: the control plane for AI agent tool traffic
• AI budget per team: governance with traceability
• LLM call trace: how to audit request and token
• How to evaluate and choose an LLM gateway
• Model Context Protocol, authorization specification and security best practices: modelcontextprotocol.io/specification/2026-07-28/basic/authorization
• NIST, Digital Identity Guidelines, SP 800-63-4, published in July 2025: pages.nist.gov/800-63-4

Who answers for the call is an architecture decision

Caller identity is not an observability feature you switch on later. It is a decision about who answers for what the AI did, taken at the moment the first agent starts being shared, and silently reversed every time a key is copied to the team next door.

The test costs an afternoon. The answer is binary. Either the gateway can name the area and the originating user per call, or the company is operating with three boundaries that exist only on the org chart. Quota, access, and trace fall together, and they come back together when identity starts surviving all the way to the tool server.

It is at that layer that the Nexforce Router operates. A single API, one key, 300 or more models, with budget per key, per agent, and per project, real-time consumption of tokens per session and per agent, routing rules per key, security guardrails, and the complete trace of every call in centralized observability. Quota, policy, and trace sit in the same control point, in the place the call already passes through.