Audit records for AI agent activity
When someone asks why an agent did that, a log line in a bucket is not an answer. A record that names the actor, the decision, the approver and the outcome, in a chain that fails verification if it is edited, is.
What each record carries
Actor and agent, the action and resource, the policy decision and the policy version it was made under, any approval and who made it, the tool result the runtime reported, and the link to the previous record.
- Identity is taken from the agent-bound key, never from a header a caller could set.
- Governance events append to a per-organization hash chain; editing one breaks verification.
- Records are signed, and the chain can be verified without trusting the console.
- Model traces sit alongside, so the call and the decision can be read together.
Why hash chains rather than a log
An append-only log answers "what was written". A hash chain answers "has anything been changed since", which is the question an auditor or an incident review actually asks — and it is answerable by the tenant rather than by the vendor's word.
Pairing records with traces
The trace explains the call: which agent, which model, how many tokens, what it cost, how long it took, what policy decided. The audit record explains the accountability: who was allowed, who approved, what was reported back. Read together, they answer the two questions a post-mortem always starts with.
Questions
Can I export the records?
The audit API exposes the chain and a verification endpoint per organization, so records can be pulled and checked outside the console.
Do traces store my prompts?
No. The edge records the governance and usage layer — identity, provider, model, tokens, cost, latency, policy decision and tool names. Message content is forwarded to your provider rather than filed. A pending approval keeps the tool arguments an approver has to read, on the edge, and erases them when it closes.
What is not verified?
That a local action succeeded. Tool results are runtime-reported evidence, which is exactly why the audit record stores them as reported rather than as fact.
Related
- AI agent control plane — A control plane sits beside the data plane: your agents keep talking to their model providers, and the control plane decides who they are, what they may spend, which tool calls they may make, who reviews the risky ones, and what record survives afterwards.
- LLM gateway — One endpoint for every agent, one key per agent, and a decision on every request: authenticated, attributed, budgeted, recorded, then forwarded to your provider with a key only the gateway holds.
- Agent approvals — Autonomy is fine until the tool call is `kubectl delete pod checkout-api` in production. Approval puts one named person in that gap, and only for the calls that need it.
- Documentation — endpoints, provider keys, and the full policy reference.
Try it: run the open-source edge, or apply as a design partner. Questions: outreach@descles.com. See also terms and privacy.