How Do You Prove AI-Agent Governance to an Auditor?

"We govern our AI agents" is a claim. An auditor's job is to disbelieve claims until you show them evidence. That gap — between having a governance policy and being able to prove it held on a specific action, on a specific day — is where most AI-governance programs come apart when the assessment actually happens.

We hear a version of this often: a team has written an AI acceptable-use policy, turned on the model vendor's safety filter, and enabled some logging. Then a customer security questionnaire, a SOC 2 auditor, or an EU AI Act readiness review asks a harder question — show me that a high-risk action was actually stopped, who was allowed to override it, and where that decision is recorded. The policy PDF doesn't answer that. Evidence does.

What an auditor actually asks for

Auditors don't grade intentions. For each control, they want an artifact — something that shows the control operated, repeatedly, across the audit period. For AI-agent governance the recurring questions are concrete:

• Was the action evaluated before it happened? Not "did we log it afterward," but was there a decision point that could have said no.
• Who or what could override a block, and is that recorded? Separation of duties: the party that requests an action shouldn't be the party that approves it.
• Is there a durable trail? A retained record of what was allowed, warned, sent for human approval, or blocked — with enough context to reconstruct the decision.
• Is the control independent of the thing it governs? A guardrail the agent's own author can switch off is a feature, not a control.

Answer in the framework's language

Whatever regime you're measured against, these questions map to named controls, and it helps to answer in the assessor's vocabulary:

• EU AI Act, Article 14 (human oversight) — high-risk systems need a human who can intervene. "Require approval on a consequential action, routed to a person with full context" is the evidence.
• EU AI Act, Article 15 (accuracy, robustness, cybersecurity) — resilience against manipulation such as prompt injection. Detection-and-block records are the evidence.
• NIST AI RMF (Govern / Measure / Manage) — accountability, measurement over time, and response in operation. A retained decision trail speaks to all three.
• HIPAA and sector rules — access controls and audit trails over protected data. The same records, scoped to the data class.

A timing note, because it matters: in July 2026 the EU's Digital Omnibus pushed the high-risk obligations — Articles 14 and 15 among them — from August 2026 out to December 2027 (Article 50's transparency duties stayed on the 2026 date). The deadline moved; the demand for evidence didn't. Customer security questionnaires and SOC 2 auditors ask now, and the control expectations behind those Articles are what mature buyers want regardless of the statutory date. Building the evidence trail early is cheaper than assembling it under a deadline later.

One honest caveat: a tool does not make you compliant, and anyone who tells you otherwise is selling a story you'll have to walk back in the room. What these controls share is a single underlying demand — a record that the decision happened, independently, and was retained.

Why independence is the part people miss

The most common gap we see isn't missing logs — it's that the "governance" runs inside the same system it is meant to govern. If the model vendor both takes the action and certifies it was safe, that's self-certification, and a careful auditor treats it as such. Separation of duties is a named requirement in most regimes for a reason. Governance the governed party can edit, disable, or mark its own homework on isn't evidence an assessor will lean on. (We wrote more on why an agent's own instructions aren't security.)

This is why enforcement should run outside the agent's reach and independent of any one model or cloud — so the record of "this action was evaluated, and this is the verdict" comes from a party that isn't the one taking the action.

What "evidence" looks like in practice

Concretely, the artifact an assessor can use is a per-action record: what was attempted, the verdict (allow / warn / require-approval / block), the policy that applied, who approved an override if one occurred, and a timestamp — retained across the audit period and exportable. That is what turns "we have a policy" into "here is the control operating, tens of thousands of times, over the last quarter."

Shrike produces that record as a by-product of enforcing at the action boundary. We don't issue your certification — your organization and your assessor do that. What we give you is the material the conversation needs: independent, per-action, retained, and mapped to the controls your auditor is already asking about. Our compliance posture and the docs cover how that maps to specific frameworks.

A policy is a claim. An auditor buys evidence.