AgentKits

How to Build a Compliance Evidence & Audit-Trail Agent (2026 Tutorial)

Build an agent that turns operational changes into structured, tamper-evident compliance evidence: map each event to your control catalog, assemble the artifacts, and gate filing behind a human compliance owner.

This is a hands-on tutorial for building a Compliance Evidence & Audit-Trail Agent — an agent that turns operational changes into structured, tamper-evident compliance evidence. It maps directly to our Compliance Evidence & Audit-Trail Agent blueprint, so you can read the build here and grab the full runnable kit (system prompt, tools, and a one-command starter) when you're ready. It's written for platform, security, and compliance teams who lose weeks before an audit reconstructing what happened and proving it was done correctly.

The slow part of compliance is rarely the work itself — it's the evidence that the work was done, mapped to the right control, and preserved unaltered. This agent automates that evidence layer, and one rule shapes the whole build: the agent records evidence, it does not decide compliance. Its worst-case action is preparing an incomplete or mis-mapped record, and that record always passes a human before it is filed. Everything else follows from that boundary.

What you're building

The agent is a control loop, not a single prompt. It observes a change event — an access grant, a config change, a deployment, a data-handling action — maps it to the applicable controls in a catalog you supply, assembles the artifacts each control requires, scores completeness, and seals the result into an append-only audit log. Anything high-risk or incomplete is routed to a human compliance owner rather than filed. The blueprint's stack is Claude, LangGraph, OpenAI, but the design transfers to any framework: what matters is the boundary, not the library.

One design choice does the heavy lifting on trust: the agent maps only to controls your catalog actually contains. It ships no opinion about what ISO 42001 or SOC 2 require — your authoritative source does. That keeps the mappings grounded in something you can defend and keeps you out of the "confidently wrong compliance claim" trap, which for a governance use case is the most damaging mistake you can make.

The tools the agent needs

An agent is only as capable as its tools, and only as safe as the contracts on them. This blueprint uses 8: get_event, resolve_actor, classify_resource, lookup_controls, collect_artifacts, and score_completeness — all read-only — plus request_signoff and commit_evidence, which are approval-gated. The split is the whole point: the reads do the tedious enrichment, and the only two tools that write anything are exactly the ones behind the gate.

Just as important is what's absent. There is deliberately no tool that can modify a source system, grant access, or alter a prior audit entry. A capability that isn't in the registry can't be misused no matter how the model is prompted — and that absence is what keeps the agent at Trust Level A3.

Step by step

1. Start with the boundary. Write down the worst-case action — preparing an incomplete or mis-mapped record that gets filed — and decide which tools are gated (request_signoff, commit_evidence) and which simply don't exist (anything that changes a source system). This one decision shapes everything after it.

2. Define a real control catalog. List the event types you want evidenced and, for each, the controls they map to and the artifacts each control requires. Start small — a handful of high-frequency events mapped to ISO 42001 and SOC 2 Common Criteria entries you can cite — and treat it as a living document with an owner, not a frozen file.

3. Wire the read tools first. Confirm the agent can resolve the actor, classify the resource's sensitivity, look up applicable controls, and collect the required artifacts. An agent reasoning over missing context will produce confident nonsense, so get retrieval solid before any reasoning.

4. Score completeness, and let it block. For each mapped control, record what's present and what's missing, and score completeness against the control's threshold. Below threshold — or any regulated resource — must block the gate. A record that looks complete but isn't is the failure you're designing against.

5. Gate the filing. Committing an evidence record is the one consequential action. The agent prepares it fully, then calls request_signoff to route it to a human compliance owner; commit_evidence only runs after explicit approval. A denial or timeout leaves the record unfiled, with the reason logged.

6. Seal it tamper-evident, and explain it. On approval, append the record to an HMAC-chained audit log so any later mutation, reorder, or deletion fails verification — then produce a plain-language "what changed and why it's evidenced" summary a non-engineer reviewer can read.

The guardrails that make it production-ready

The difference between this agent and a flashy demo is entirely in the boundaries. It maps only to controls you define, so it never invents a compliance claim. It holds no tool that can touch a source system. Its one filing action is gated behind a human, and incomplete or regulated records escalate instead of filing. Every record is sealed into a verifiable, append-only log. The blueprint encodes all of this in an AgentAz™ governance section — explicit Trust Level, a written worst-case action, and the human-in-the-loop gate — so the safety is the specification, not an afterthought.

You can check this yourself: paste the kit's agentaz.json into the free, deterministic AgentAz Compliance Scanner and watch it grade. For the deeper reasoning behind these boundaries, see our guide to designing safe AI agents.

Get the kit

This tutorial walks the design; the Compliance Evidence & Audit-Trail Agent blueprint gives you the rest — the full system prompt, all 8 tool contracts, worked examples (including the hard case where it escalates a mis-mapping instead of guessing), Basic/Advanced/Enterprise tiers, and a runnable run.py starter that executes the real loop and blocks the gated tools, on Anthropic or OpenAI. If incidents are more your problem than audits, the same read-heavy, human-gated pattern powers our Incident Root-Cause Analysis Agent tutorial. For the broader production checklist, see building production-ready AI agents.

Frequently asked questions

Keep reading

← All posts