Skip to content

Compliance & Audit

One Audit Trail for SOC 2, HIPAA and the EU AI Act

An ai agent compliance audit trail is the one artifact three very different regulators end up asking for in the same shape: show us who did what, prove the record wasn't edited, and prove nothing went missing. A SOC 2 reviewer, a HIPAA auditor, and an EU AI Act conformity assessor read different rulebooks, but when your autonomous agents call tools that move money, touch patient data, or take consequential actions, all three converge on the same primitive — a record of every action, attributed to a verified principal, that survives an adversary with write access. This post shows how one HMAC-chained AuditMiddleware trail in Promptise Foundry produces evidence for all three, maps each regime's ask to concrete fields, and is honest about where the log ends and a governance program begins.

Why AI Agent Traces Aren't an Audit Trail (or SOC 2 Proof)

The question of ai agent observability vs audit trail usually starts with a comforting assumption: the traces your stack already emits — LangSmith runs, Logfire spans, OpenTelemetry exports — will double as compliance evidence when an auditor asks what your agent did. They won't. Those traces are mutable debugging telemetry, and a vendor's SOC 2 badge attests to that vendor's controls, not to the integrity of the log your own agent produces. This post draws the exact line between the two, names precisely what today's observability tools do and don't guarantee, and shows the one primitive a span export can't give you: a record whose integrity you can verify on demand.

How to Detect a Tampered AI Agent Audit Trail

To detect a tampered agent audit trail you need one property a plain JSONL file or stdout stream can never give you on its own: a way to prove, after the fact, that no record was edited, deleted, or reordered. A log your agent appends to is just bytes on disk. Anyone with write access — a compromised process, a careless migration script, an insider covering their tracks — can rewrite a line, drop an entry, or truncate the file, and nothing about the surviving data reveals the change. This post is the operational verification workflow, not the theory: exactly what Promptise's verify_chain() checks, how the break localizes to the specific entry an insert, edit, or delete touched, and how to wire the check into CI, a periodic integrity job, and an incident-response runbook so you can prove a clean chain on demand.

EU AI Act Article 12: Logging Requirements for AI Agents

EU AI Act agent logging is where a lot of otherwise-solid agent deployments quietly fail their first audit, because the log they built for debugging is not the log the regulation asks for. Article 12 of Regulation (EU) 2024/1689 requires high-risk AI systems to technically allow for the automatic recording of events over the lifetime of the system, at a level of detail that ensures traceability appropriate to the system's intended purpose. If your autonomous agent scores credit applications, screens CVs, or triages a benefits claim — all Annex III high-risk categories — a print() to stdout and a span in a trace backend do not clear that bar. This post explains what Article 12 actually asks for, why the usual logging falls short on three specific properties, and how a tamper-evident audit trail with verified per-principal attribution maps to the obligation. (It is engineering guidance, not legal advice — pair it with your own counsel.)

HIPAA-Grade Audit Logging for Healthcare AI Agents

A HIPAA AI agent audit has one non-negotiable job: prove which verified principal touched which patient record, when, in a record an insider can't quietly rewrite — while never turning that log into a second, leakier copy of the PHI it describes. When an autonomous agent calls a read_patient_record tool, a schedule_appointment tool, or anything that reads or writes electronic protected health information, HIPAA's audit-controls rule (§164.312(b)) expects a mechanism that records and lets you examine that activity, and §164.312© expects that record to be protected from improper alteration. At the same time, HIPAA's Privacy Rule and overlapping regimes like GDPR give data subjects a path to erasure of their upstream data. Those two demands pull in opposite directions — retain the access trail, delete the personal data — and most agent stacks make you reconcile them by hand. This post shows how Promptise Foundry's AuditMiddleware plus a tenant-scoped purge_user do it structurally: attributable and PHI-safe by default, erasable where the PHI actually lives, with the integrity chain left intact.

LangGraph Checkpoints vs. an Audit Log: The Real Difference

The langgraph checkpoint vs audit log confusion is one of the most expensive category errors in agent engineering: teams wire up a checkpointer, watch their graph resume cleanly after a crash, and quietly assume that same durable state will satisfy an auditor asking what the agent did and who authorized it. It won't. A checkpoint is a mutable snapshot of graph state built to resume, replay, and pause for a human. An audit log is an integrity-chained, attributable record built to prove what happened. Both are legitimate; they solve different problems, and using one where you need the other fails at the worst possible moment. This post draws the precise line, states exactly what LangGraph's checkpointers do and don't guarantee, and shows the one primitive a checkpoint can't give you.

Multi-Agent Audit: Who's the Principal After a Delegation Hop?

Multi-agent audit accountability is the question a compliance reviewer asks the moment your fleet stops being one agent: when Agent A — running on Alice's behalf — hands a subtask to Agent B, and B exports a record or issues a refund, which principal does the audit trail name as accountable? This is not the question of how B authenticates the delegation call — that is a separate topic with its own answer. It is the narrower, sharper compliance question that delegation raises: after the handoff, does your tamper-evident record still name the human who set the chain in motion, or does it name the sub-agent's service account? Get that wrong and every audited action taken past the first hop is attributed to a bot, and "the bot did it" is not an answer a SOC 2, HIPAA, or EU AI Act auditor accepts.

How to Prove What Your AI Agent Did for a SOC 2 Audit

A soc 2 audit trail for ai agents is the artifact you reach for the moment a reviewer stops asking about your policies and asks the pointed question: "for this refund your agent issued, show me who was allowed to call that tool, who actually called it, and prove the record wasn't edited after the fact." Pointing at your LLM provider's SOC 2 badge doesn't answer it — that badge attests to their controls, not to evidence of your agent's actions. This post is the step-by-step setup: capability-based per-tool guards so only the right agent can take a sensitive action, AuditMiddleware(signed=True) with a managed PROMPTISE_AUDIT_SECRET so every attempt becomes an attributable, tamper-evident record, PII kept out by default, and a verify_chain() report an auditor will accept.