What is an audit trail for AI agents?
An audit trail records what each agent did, as whom, and how it ended. CoreSpeed keeps one per org: action, actor, outcome, code and cost, never the prompt.
An audit trail for AI agents is a record of every action an agent took through a platform: which tool, which actor, which organization, and how it ended. On CoreSpeed the trail lives at Dashboard → Activity. It holds one record per tool call or control-plane action, and the dashboard joins each record to the billing ledger for cost.
What does one record hold?
A record identifies the action, the actor, the organization, the outcome, the surface, the request and the time. For a failure it also carries the code and the text the agent was shown, bounded to 512 characters. Where a billable action has a charge, the record references it.
| Field | What it holds |
|---|---|
| Action | The tool or control-plane operation, such as slack__post_message |
| Actor | The member, or the identity that owns the API key or agent key |
| Organization | The org the call was attributed to |
| Outcome | ok, error, held or denied |
| Surface | Which surface the call came through |
| Request and time | The request and when it happened |
| Code and text | For failures: the error code and the message the agent saw, up to 512 characters |
| Charge | A reference to the ledger entry when the action was billed |
What a record does not hold matters as much. A call refused before any tool ran, such as an unknown tool name or invalid arguments, leaves no record. The client already has its answer, and there was no action to audit.
What do the four outcomes mean?
ok means the tool ran and returned a result. error means the tool was called and failed, or was refused at the tool level; the record carries the code. held means the call stopped at a hold: a billing hold on the organization wallet, or a pending approval under Smart Approval. denied means a verdict refused it, with the reason when a human denied it.
A gated call carries its approval id, so you can go from the record to the card and back. Every decision under Smart Approval is in the log, including the allows nobody saw. The approvals page describes the verdicts; the trail is where they end up.
Who can see what?
Members see actions attributed to themselves. Organization admins see activity across the organization. Non-admin views do not expose IP address or user-agent metadata.
API-key activity is attributed through the key's owning identity, so the same organization and member rules apply. A member key (sk-cs-...) acts as the member who created it, so its calls are attributed to that member. An agent key (sk-csa-...) belongs to an agent principal with an identity of its own, so its calls are attributed to the agent, and the agent's owner is the member who answers for it. This is the reason to give an unattended job you operate an agent key rather than a personal one: the trail then says which agent did what, and accountability stays with a named person. The authentication page describes the principals.
Why are prompts kept out of the trail?
Sensitive request content is not copied into the trail. Metadata is redacted before enqueueing, detail is bounded, and prompts are not treated as audit payloads. The trail answers "what was done, by whom, with what result". It does not answer "what was the agent thinking", and that is deliberate: a transcript in an audit store is a second copy of every secret that passed through a conversation.
The bounded failure text is the one piece of agent-facing content kept, capped at 512 characters, so a person can diagnose a failure without opening the client. It is the same text the agent saw, which is what you need when the agent reports "it failed" and nothing more.
How does the trail relate to the bill?
The billing ledger is the authority for money. Activity records reference a charge when one exists, and the dashboard joins the two to display cost. The audit event itself is never the money authority, and an audit retry cannot duplicate a charge.
That separation keeps two questions apart. "What did this cost" is answered by the ledger, itemized per action in credits. "What happened" is answered by the trail. Reading them together in the dashboard gives cost per action, per actor and per key, which is the number a monthly spend cap on a key is measured against. The billing page covers the caps.
A failure that reaches the trail arrives at the agent as a tool-level result, and the trail keeps its code:
{
"result": {
"isError": true,
"structuredContent": { "error": { "code": "needs_reauth" } }
}
}The code in a result like this is what the record keeps, along with the message text.
What happens when the audit pipeline is down?
Emission is asynchronous and fail-open for the product action. A temporary audit-pipeline failure does not repeat or roll back a connector call that was already valid. Retries, deduplication and a dead-letter path protect the recording pipeline separately, so a record that could not be written at once is retried, and a retry cannot write the same record twice.
Fail-open is a choice. The alternative, fail-closed, would mean a Slack message does not send because the log was slow. For a trail attached to actions a person asked for, the action comes first and the record follows.
FAQ
Does the trail include what the agent said to me? No. Prompts are not audit payloads. The record holds the action, actor, outcome, code and bounded failure text.
Why is a call missing from Activity? It was refused before any tool ran: an unknown tool, invalid arguments. Those leave no record.
Can a non-admin see IP addresses? No. Non-admin views hide IP and user agent. Admins see the organization's activity.
Is the cost in Activity the billed cost? The cost shown is joined from the billing ledger, which is the authority for money. The activity record only references the charge.
How long is history kept? The Free plan keeps 30 days of history; CoreSpeed Pro keeps one year.