Don't ask an AI if you're audit-ready. Put it in a read-only room.

A founder opens the coding agent on a Thursday afternoon, points it at the company repo, and types the question that has been sitting in the back of their head since the enterprise deal got serious: Are we SOC 2 ready?

The agent thinks for a moment and writes back a paragraph. It is a good paragraph. It mentions access controls and encryption at rest, notes that logging looks reasonable, suggests the change-management process could be tightened, and closes with a confident line about being "largely on track for a Type II audit with some gaps to address." The founder forwards it to the security lead. It reads like progress.

It is not progress. It is a paragraph with no room around it.

Nothing in that answer points at a file. Nothing says which line of which config implies encryption at rest, or whether the logging it praised has actually been running for the ninety days an auditor will ask about, or whether "access controls" means a reviewed policy or a sentence someone wrote in Notion in 2024. The agent did what a fluent model does when you ask it a yes-or-no question about a body of evidence it half-read: it produced the most plausible answer. Plausible is the exact failure mode you cannot afford in an audit. An auditor doesn't want your best guess about whether a control exists. They want the artifact.

So the useful move here is not a better prompt that coaxes a more careful paragraph out of the same agent. The useful move is to stop asking for a paragraph at all, and to build the agent a room it can only answer inside of.

A small repo that names the right constraint

On June 17, 2026, a project called ai-audit-orchestrator showed up on Hacker News under the title "Turn your AI coding agent into a read-only compliance auditor." It is worth being honest about its traction: the Hacker News post sat at two points with no comments when we looked. This is not a movement. It is one person's repo, created days ago.

It is still worth tearing down, because it gets one thing exactly right, and the thing it gets right is a constraint, not a feature.

The repo isn't a scanner or a GRC platform, and it never runs anything against your code. Its own description is the whole thesis compressed into a line: "Evidence or silence; method public, results private." Inside is a set of prompts and templates that turn a coding agent — Claude Code, Cursor, Codex, whichever you use — into a disciplined read-only auditor that works through your own repository one framework at a time. Every finding it produces must carry a path:line citation or the exact phrase No evidence found. There's no third setting where the agent gets to be reassuring.

That rule is the interesting part. Read it again as a design constraint rather than a writing instruction. The agent is not being asked to try to cite evidence. It is being told that a claim without a citation is not a finding — it is silence. The model's natural ability to write a smooth, hedged, audit-flavored paragraph has been taken away from it on purpose.

Here is the line worth keeping: evidence or silence is not a writing style. It is a room design.

Why the prompt isn't the protection

Before we get to the room, the project deserves credit for saying out loud what most "make your agent do X" prompts won't.

The repo's SECURITY.md is blunt: the repo contains prompts and templates, not executable code, and the real control is the runtime environment, not the prompt wording. A prompt that says "do not edit files, do not run code, do not touch the network" is a request. A model can ignore a request — through a confused instruction, a clever bit of text in a file it's reading, or just a bad turn. The master orchestrator prompt lists hard rules — no edits, no fixes, no commits, no running repo code, no installs, treat the audited repo as untrusted, report secret presence only and never expose the secret itself — and the SECURITY.md immediately undercuts any temptation to trust those rules as enforcement. It tells you to run the thing in a throwaway read-only or sandboxed checkout, with no production credentials, a shell allowlist limited to read-only inspection, no writes or network or installs, and the audited files treated as untrusted input.

That honesty is the tell that someone has actually thought about this. Prompt constraints describe intended behavior. The room enforces it. You need both, and if you only get one, you want the room.

This is also where the project is different from things we've covered before. It is not an audit log. RootSign's rehearsal of an agent audit chain is about producing a tamper-evident record of what an agent did. This is the question one layer earlier: when an agent makes an audit claim, can it point at the evidence behind it? And it's not a component inventory. The OpenACA agent composition analysis tells you what's in the agent's stack. This tells you whether the agent's answer about your repo is grounded in your repo.

The room, in eight fields

Strip the project down and what's left is reusable no matter which agent or framework you bring: a read-only audit room. It's the environment and rule set you wrap around a single compliance pass. Here are the fields that define one, in a form you can copy.

Scroll sideways to see all 3 columns.

Field	What it sets	Why it matters
Checkout	A throwaway, read-only or sandboxed copy of one repo	The agent can read everything and change nothing. The control is the mount, not the manners.
Credentials	None. No production secrets in the room	An auditor of your controls should never hold the keys to the thing it's auditing.
Shell allowlist	Read-only inspection commands only — no writes, network, installs, or repo-code execution	Removes the capability to act, instead of asking the model not to.
Framework + version	One framework per pass, with its current edition confirmed from an official source as of the audit date	Stops the agent auditing you against last year's version of a standard.
Evidence rule	Every finding carries a path:line citation or says No evidence found	Kills the plausible paragraph. A claim with no pointer isn't a finding.
Type I vs Type II split	Separate "the control is designed" from "the control operated over time"	The gap between these two is where most readiness reviews quietly lie.
Resume Packet	A small state object passed between single-purpose subagents, one per turn	Context control and an audit trail for the audit itself.
Stop rule	An explicit point where the agent stops and hands questions to a human	The room is allowed to say "this needs a lawyer," not invent an answer.

The table is the artifact. The repo's structure maps onto it — the master prompt's turn template includes an audit state header, the framework and version, the scope inspected, an evidence map, a control matrix, top blockers, Type I gaps, Type II gaps, a remediation backlog, the human and legal questions, a confidence-and-limitations note, and the Resume Packet at the end. But you don't need this specific repo to build the room. You need the eight fields and the discipline to fill them in before the agent gets a question.

The split that catches the lie: Type I versus Type II

The single most useful idea the project borrows from real audit practice is the line between Type I design evidence and Type II operating evidence, and it's worth a concrete example because it's where readiness reviews tend to fool the people running them.

Type I asks: does the control exist and is it designed correctly? You have a password policy that requires MFA. The policy is written, it's reasonable, the config that enforces it lives at a specific line in a specific file. The agent can cite it. Design evidence: present.

Type II asks: did the control actually operate, the way it's designed, over a period of time? Did MFA stay enforced every day for the audit window? Is there log evidence that it did, and that nobody quietly disabled it for a contractor in March? That's operating evidence, and it is a completely different artifact from the policy. A policy file proves design. It does not prove operation.

This is exactly where the confident Thursday-afternoon paragraph goes wrong. The agent sees the policy, sees the config line, and reports the control as satisfied. An auditor running a Type II review will ask for ninety days of evidence that it ran, and the answer is often a shrug. The repo's framework objective sheets lean on this on purpose — across SOC 2 Type II readiness, ISO/IEC 27001, ISO/IEC 27701 and GDPR, ISO/IEC 42001, penetration-test readiness, EU AI Act technical documentation, and DORA/NIS2 vendor resilience, the emphasis is on operating evidence, not just code or policy text. A room that separates the two columns forces the agent to admit which kind of evidence it actually has. That admission is the whole value.

It also keeps the work honest about scope. Frameworks like ISO/IEC 42001 for AI management systems and risk practices like the NIST AI Risk Management Framework exist precisely because "we have a policy" and "the policy governs our day-to-day" are different claims. None of those bodies endorse this repo, and you shouldn't pretend they do. But they're the reason the Type I/Type II split isn't a nicety — it's the difference between an audit and a vibe.

One subagent per turn, and a small packet between them

The room handles state in a way that's easy to skip past and worth slowing down on. Instead of one agent holding the whole audit in a giant context window, the harness runs a chain of single-purpose subagents — one per turn — and moves state between them through a small Resume Packet.

There are two reasons this is more than tidiness. The first is context control. A single agent carrying an entire framework's worth of inspection in one window drifts, forgets its own earlier findings, and starts to blur the evidence rule under the weight of everything it's holding. Narrow subagents, each with one job and a compact handoff, stay sharper about the one rule that matters. This is the same instinct behind treating agent evals as tests of workflow receipts: you want each step to produce something checkable, not a long unverifiable monologue.

The second reason is that the Resume Packet is itself an audit trail of the audit. You can see what state moved from one step to the next, which means a human can later ask how a given finding came to be — what scope was inspected, what the agent carried forward, where a conclusion entered the chain. An audit you can't audit is just a longer paragraph.

Why the filled-in outputs never get committed

One more rule from the project that teams get wrong by default: the method is public, the results are private. The SECURITY.md is explicit that you must never commit real audit output, filled Resume Packets, or evidence registers, because those artifacts map your live weaknesses. A completed audit is a tidy index of exactly where you're soft. Pushed to a repo — even a private one with broad internal access — it becomes a gift to anyone who shouldn't have it.

So the prompts and templates are open. What comes out of a real run is not. That separation should be a setting in your room from the first pass, not a cleanup you remember to do later.

The constructive next step the project points at is an optional Evidence Pack: turn the gaps the audit found into a private evidence register that stores metadata only — a pointer to where the artifact lives, who owns it, which system it came from, the period it covers, when it was collected, a hash, privacy and secrets flags, and review status. The Evidence Pack README is careful to say what it is not: not a GRC platform, not a replacement for an auditor. It's a disciplined list of where your proof lives and whether it's been checked. That's the same shape as an AI workflow evidence packet — a register of evidence pointers, not the evidence itself sitting in a repo.

A first pass you can run this week

Here's the smaller, honest version of "are we SOC 2 ready," and it fits in an afternoon.

Take one repo and make a throwaway read-only checkout of it — no production credentials anywhere near it. Pick one framework, not all of them, and have the agent confirm the current edition of that standard from an official source before it starts. Hold it to the evidence rule: every finding is a path:line or the words No evidence found, with no smoothing in between. Ask it to sort what it finds into Type I (designed) and Type II (operated over time). When it hits something that needs a human or a lawyer, the right output is the question, not an answer.

Then take the gaps and convert them into a private, metadata-only evidence register, so you know where each piece of proof lives before an auditor ever asks. If you want a structured starting point for the room's guardrails, our AI workflow security review worksheet covers the read-only and credential boundaries you'll want decided up front.

What you'll get out of that first pass is not a certificate. It's something more useful at this stage: an honest map of what you can actually point at, and a clear list of the places where the true answer today is No evidence found. That sentence is not a failure. It's the first accurate thing the agent has told you.

The agent was never going to make you audit-ready. The room is what makes its answer worth reading. Build the room first.

---

Bring one repo and one framework. We'll help you define the read-only checkout, the evidence fields, and the stop rule before an agent writes its first finding — and turn the gaps into a private evidence packet you can actually hand to an auditor. Scope a read-only audit room with BaristaLabs.