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 trace records the governance and usage layer — identity, provider, model, tokens, cost, latency, policy decision and proposed tool names. Message content is forwarded to your provider rather than filed. An approval record does keep the tool arguments an operator has to read.
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 per provider, one key per agent, and a decision on every request: authenticated, attributed, budgeted, traced, then forwarded.
- 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 on one agent: 1,000 governed requests free, no card. Request packs add 25,000 more to the same workspace. Questions: outreach@descles.com. See also terms and privacy.