Direct answer: Not from the vendor dashboard. A provider bills one API key and sees a single machine identity, so its records cannot say which person, session, or workflow sent a request. A usable audit trail has to be captured on your side, at the moment each request is emitted, from the gateway and telemetry you already run.
The request I hear from security and platform leads is reasonable and specific. Produce an audit trail of what we have sent to our model providers. The instinct that follows is almost always wrong, and the wrong instinct is expensive, so it is worth taking apart before anyone spends a quarter on it. The instinct is to go to the OpenAI or Anthropic dashboard, export the usage data, and treat that export as the audit. It will not work, and the reason it will not work explains what a real audit trail actually requires.
What makes a record an audit trail?
Start from what an audit record has to contain to be one, because the definition does the work here. An audit trail answers three things for every event: who did it, what they did it to, and when. Actor, object, time. Drop the actor and you no longer have an audit trail, you have a volume log. That distinction is the whole game, because the vendor export is rich on object and time and completely blind on actor, and no amount of processing downstream can restore an identity that was never recorded.
Why can't the provider tell me who sent what?
Look at what the provider actually sees on the wire and the blindness becomes obvious. Your organization authenticates to the provider with an API key, often a small handful of keys, sometimes one. Every request from every engineer, every agent, every automated job arrives under that same credential. From the provider's side there is one customer sending a large number of requests. The person, the session, and the workflow that produced each one were collapsed into a shared machine identity at the boundary, and the boundary is upstream of everything the provider records. Their billing is a faithful account of what one key did. It is silent on the only question an audit asks.
The exported CSV disappoints in a way that surprises people, and the disappointment traces straight back to that missing actor. You get token counts, model names, timestamps, aggregate cost. You go to answer the question that prompted the whole exercise, which sounds like "did anyone send customer data to a model last Tuesday, and if so who and in which workflow," and the export has nothing to say. It can tell you a lot of tokens moved on Tuesday. It cannot name a session, cannot name a person, cannot show you a prompt. The data is accurate and structurally incapable of being an audit, and reprocessing it more cleverly does not add the column that was never captured.
Where do I build the audit trail instead?
So the correct place to build the audit is your side of the boundary, upstream of the identity collapse, which turns out to be where you have the most control and often the least effort. The moment to capture attribution is emission: the instant a request is assembled and about to leave, when the actor is still known. Two vantage points already sit at that moment for most teams. A gateway or proxy such as LiteLLM sees every outbound request in one place before it fans out to providers. And OpenTelemetry spans, if your agents and SDKs emit them, already carry request context in a structured, queryable form. The trail you want is a byproduct of infrastructure you are probably already running.
What you do at that point is stamp each request with the attribution the provider will erase. Tie the request to a session identifier so a multi-step agent run reads as one coherent story rather than forty disconnected calls. Tie the session to the workflow that launched it, so you can ask about the migration agent or the support-summarizer as a unit. Tie the workflow to the person or team that owns it. Do that at emission and you have the actor dimension the vendor can never give you, joined to the object and time you can also see locally. Now the three columns of a real audit record exist in one place.
The stamping is more mundane than it sounds, which is the good news for the team that has to run it. A trace or session identifier propagated through your OpenTelemetry context already links the tool calls, retrievals, and model requests of a single agent run, because that is what distributed tracing was built to do. A gateway like LiteLLM can attach a header or metadata field carrying the calling service and team on every proxied request. You are not inventing an identity system; you are keeping an identity you already hold at the point where the request would otherwise shed it. The engineering is a matter of passing a field through, and the reason it rarely gets done is that nobody framed the outbound request as an audit event worth labeling.
What should the finished trail let me ask?
With attribution in hand, the audit stops being a data dump and becomes queryable, which is the property that makes it worth building. A dump answers "how many tokens." A queryable trail answers the questions an audit is actually for: show every request in the last thirty days where a credential pattern appeared in the prompt, grouped by team. Reconstruct the full session behind this one flagged request. List which workflows touched a given internal API through a model. Those are joins across actor, object, and time, and they are only possible because you captured the actor before the provider flattened it away.
We built Oberhahn to stand this up from the sources you already have, ingesting from your gateway, OpenTelemetry, and provider APIs, attributing each request to its session, workflow, and team, so the audit trail exists as a live queryable record instead of a monthly CSV you cannot pivot on. The demo shows the attributed view against sample data before you connect anything real.
A word on what this trail honestly proves, because overclaiming here is how good tooling loses trust. It proves what was sent and from which session, workflow, and team a request originated. That is a record of activity, and it is exactly what an audit needs. It is not proof of intent, and it is not a per-person surveillance feed. The workflow is the working unit here, because that is what you fix or approve. Attribution to a person exists so you know who owns the pipe to remediate it, not so you can rank keystrokes. Build the trail to answer audit questions and it will answer them. Build it to watch people and it will fail at both.
Frequently Asked Questions
Can I get an audit trail from the OpenAI or Anthropic dashboard?
No. Those dashboards report usage against your API key, so they see one machine identity sending many requests. They can show token counts, models, timestamps, and cost, but they cannot name the person, session, or workflow behind any request, because that identity was collapsed into a shared key before it ever reached the provider. An audit needs the actor dimension, and the export does not have it.
Why can't I reconstruct who sent what from provider billing data?
Because the information was never recorded there. Your requests all authenticate under the same key, so the provider genuinely cannot distinguish one engineer or agent from another. You cannot recover an attribution that was destroyed at the boundary; you can only capture it earlier, on your side, at the moment each request is emitted.
Where does an AI usage audit trail actually come from?
From your own emission points, upstream of the provider. A gateway or proxy like LiteLLM sees every outbound request in one place, and OpenTelemetry spans from your agents and SDKs carry request context in structured form. Stamp each request with session, workflow, and team as it leaves, and you have the attribution the vendor can never supply, joined to the content and timing you can already see.
What questions should a real audit trail be able to answer?
Specific, joined ones: every request in the last month where a credential appeared in a prompt, grouped by team; the full session behind a single flagged request; which workflows sent data to a given model. These require actor, object, and time in one queryable place. A billing export gives you object and time only, which is why it answers "how many tokens" and nothing an audit actually asks.