An Auditor Accepted Evidence Collected by My AI Agent. Governing the Agent Was the Hard Part.

Last month, an auditor accepted evidence collected by an AI agent. That's the part most teams aren't ready for.

Here's what happened. I retired a $48,000-a-year GRC platform and put a scoped internal agent in its place. Read-only keys. It pulled evidence from AWS, IAM, and GitHub, wrote the control narratives, and timestamped everything. The auditor signed off.

But the agent passing the audit wasn't the hard part. Governing the agent was.

What the Agent Actually Did

The engagement was a SOC 2 Type II with an ISO 42001-adjacent scope — the client is running production LLM workflows and their auditor had started asking real questions about AI controls. They'd been paying $48K a year for a GRC platform that, to be honest, was doing about $8K worth of actual work: dashboards, some auto-collectors that half-worked, and a lot of screenshots that a human had to shepherd across the finish line every time.

I killed the contract at renewal. What replaced it was smaller and sharper — a scoped internal agent, running on infrastructure I control, wired into the client's production accounts through read-only credentials.

Its job was narrow. Every day, it did four things:

• Pulled evidence from AWS (Config, IAM, CloudTrail, security group state, KMS key policies, GuardDuty findings).
• Enumerated IAM across the org — users, roles, MFA state, access key age, permission boundaries, service control policies.
• Queried GitHub for repo-level branch protection, required reviewers, code-scanning status, dependency alerts, and the last 90 days of PR-approval history.
• Wrote the narrative — mapping each finding to the corresponding SOC 2 control and, where AI was in scope, to ISO 42001 Annex A.6 (AI system life cycle) and the relevant NIST AI RMF function.

Every artifact carried a cryptographic timestamp and a signed provenance record. The auditor accepted it. Not because it came from an AI — because it was verifiable.

The Controls I Put Around It Before It Touched Anything

This is the part most teams skip. They see an agent doing useful work and start scaling before they've drawn the fence. I don't blame them — the ROI is real and it's obvious. But an ungoverned agent holding production keys isn't automation. It's an incident with a countdown.

Before this agent touched a single control, I treated it like any other privileged identity in the environment. Which means it got the same three things every privileged identity gets, and one more that's specific to AI.

1. Least-privilege access — and "read-only" is not enough on its own

Read-only sounds like the safe default. It's not, on its own. A read-only role that can enumerate every S3 bucket, list every secret name, and dump every IAM policy is one exfiltration path away from being the worst kind of breach — the quiet kind, where the attacker never had to modify anything to walk out with everything.

Least privilege for this agent meant:

• A dedicated IAM role, not a reused human identity. Every action in CloudTrail attributable to the agent, not to a person who "logged in as."
• Permission boundaries capping what the role can ever be granted, even if someone tries to expand it later.
• Resource-level scoping — the agent could Describe* and Get* against evidence-relevant services, not everything. No blanket ReadOnlyAccess managed policy. That policy has 700+ actions in it. The agent needed 40.
• Time-boxed session credentials issued through STS with a maximum lifetime, and no long-lived access keys anywhere in the agent's environment.
• No secret-reading access at all. The agent can see that a Secrets Manager secret exists, when it was rotated, and who has access. It cannot read the value. Ever.

That last point is the one that trips people up. "Read-only" access to Secrets Manager, on the default managed policy, includes GetSecretValue. If your agent has that, your agent has your production database credentials, your Stripe key, and every OAuth token you've ever cached. That's not read-only. That's total.

2. A documented reason to exist, mapped to a framework

Every privileged identity in a well-run environment has a documented business reason to exist. Service accounts have owners, purposes, and review dates. Humans have roles, managers, and offboarding triggers.

Agents need the same thing — and one more layer on top, because they can act. The layer on top is a framework mapping. For this engagement, that meant:

• ISO 42001 Annex A.6.2.2 (AI system objectives) — the agent's purpose stated in operational terms: "collect and normalize evidence for the annual SOC 2 audit, without modifying any monitored system." Written down, versioned in Git, reviewed at every quarterly steering meeting.
• ISO 42001 Annex A.5.2 (AI system impact assessment) — a documented assessment of what happens if this agent misbehaves, malfunctions, or is compromised. What's the blast radius? Who's affected? What's the recovery path? Signed off by the risk owner before the agent went live.
• NIST AI RMF — MAP function — context established, use case scoped, categorization done. The agent is a "narrow, task-specific system operating on structured infrastructure metadata," not "an autonomous assistant with tool access." That distinction matters — the controls flow from it.
• NIST AI RMF — MANAGE function — documented triage plan for drift, hallucination, or unexpected behavior, with defined escalation paths and a hard stop procedure. If the agent generates a narrative that doesn't reconcile against the raw evidence, humans review before anything leaves the system.

3. Tamper-evident logging

"We log everything" is not a control. "We log everything, in a place the agent cannot reach, with cryptographic guarantees that nothing was silently modified after the fact" — that's a control.

The agent's logging setup:

• All actions attributable through CloudTrail to the dedicated IAM role. No shared identities.
• Independent application-layer log stream — every prompt, every tool call, every response — shipped in real time to a log store the agent's role has zero write access to.
• Write-once storage for the audit-evidence artifacts. S3 with Object Lock in compliance mode, so nothing — including me, including the agent, including a compromised admin — can silently rewrite the evidence after collection.
• Hash-chained provenance on each artifact. Every evidence file references the hash of the previous one, so a gap in the chain is immediately visible.

If the agent were compromised tomorrow, I could show the auditor — and the client's board — exactly what it touched, when, and whether anything was tampered with after the fact. That's not paranoia. That's what "tamper-evident" actually means, and it's what separates a defensible AI deployment from one that's going to become a case study.

4. The AI-specific control: bounded output and human-in-the-loop for consequential decisions

The agent could pull evidence and draft narratives. It could not mark a control as satisfied, close a finding, or move anything into a "ready for auditor" state on its own. Every artifact it produced went into a review queue. A human — me, for this engagement — reviewed and signed off before it left the system.

This maps directly to ISO 42001 Annex A.6.2.6 (event logging) and A.9.2 (responsible use of AI). The agent's role is bounded to information gathering and drafting. The consequential judgment — "is this control operating effectively?" — stays with a human. Because if the auditor pushes back on that judgment, a human needs to defend it.

The Question That Actually Matters

Most teams are asking the wrong question about AI in compliance work. They're asking "can AI do the work?" The answer is obviously yes, and getting more obviously yes every month.

The question that actually matters is "can you prove the AI was governed while it did it?"

An auditor doesn't care that an agent wrote your evidence. They care whether you controlled the agent. They care whether the identity was scoped. They care whether the actions are attributable. They care whether the outputs are verifiable against the underlying data. They care whether a compromised agent would have been noticed.

Those are all questions with concrete answers. And the answers are either "yes, here's the documentation, here's the log stream, here's the framework mapping" — or they're some version of "we haven't thought about that yet."

Only one of those two answers passes an audit.

A Transferable Checklist

If you're deploying an agent — for compliance work or anything else that touches production — here's the checklist I'd run through before it gets its first credential. This isn't every control. It's the minimum viable governance envelope.

The Two-Year Bet

The teams that come out ahead over the next two years won't be the ones running the most agents. They'll be the ones who can produce, on demand, exactly what every agent touched — and prove they scoped it before it ever ran.

Fast, useful, and auditable at the same time. Not two of the three.

The companies I'm working with right now, the ones that are getting this right, all did the same thing: they treated AI governance as a first-class engineering problem before they scaled the agents. The controls came before the automation. And now, when their board asks about AI, or their customer's security team asks, or their auditor asks — they have answers that aren't retroactive.

The ones that scaled first and are trying to bolt governance on now? They're rebuilding, quietly, and hoping nobody asks the wrong question in the interim.

If Any of This Sounds Familiar

If you're running agents in production and you're not sure your governance envelope would survive a real audit — or if your board has started asking about AI controls and you don't have a defensible answer yet — let's talk. I help teams build the fence before the agent needs it, not after.