PROOF FOR YOUR AUDITOR
HOW DO YOU PROVE TO AN AUDITOR THAT AN AI SYSTEM IS UNDER CONTROL?
You prove it with a record of every action the AI proposed, the rule it was checked against, the outcome, who approved it, and when. Every decision logged: who, what, when, why. The record is append-only, written at the moment the action was checked, so it stands as evidence rather than as a report someone assembled afterward. That is proof for your auditor.
What an auditor is actually asking
Every regime that touches AI in production asks the same three things of the system that acts on the data, whatever the regime is called: control who and what can act, keep a record of every action taken, and be able to show both. The SOC 2 trust criteria, ISO 27001, HIPAA, FERPA, the GLBA Safeguards Rule, PCI DSS and CMMC each phrase it differently. None of them was written for an agent, and all of them apply to one the day it holds real permissions.
An auditor does not ask whether the model is safe. They ask what the system was permitted to do, what it attempted, what was stopped, and who decided. A model card does not answer that. A dashboard that shows what happened last week does not answer it either, because it was assembled after the fact.
What the record has to contain
One entry per action, whether the action was allowed, held or blocked. The shape, not a live record:
- Action
- What the AI proposed, as it proposed it. Create a user in the directory.
- Rule
- The plain-English rule the action was checked against. Directory writes wait for a person.
- Outcome
- ALLOW, HOLD, or BLOCK. Here, HOLD.
- Decision
- Who approved or refused a held action, and what they saw. The on-call administrator, approved.
- When
- The time the action was checked and the time it ran, or did not.
- Why
- The reason, in the words of the rule, so the entry reads without a translator.
Three properties make it evidence. It is written before the action runs, not reconstructed. It cannot be edited, only appended to. And it is complete: the actions that were allowed are in it, not only the ones that were stopped, because an auditor who sees only the blocks cannot tell what got through.
Why the usual logs do not count
An agent framework keeps session logs: what the model said, which tool it called, what came back. That is a debugging record. It does not say what the agent was allowed to do, whether anyone checked, or who decided, because nothing in that path asked those questions. Identity logs say who the agent was. Monitoring says what it did. Neither says whether the action should have happened, and that is the question the auditor is asking.
A compliance authorization does not close the gap either. A SOC 2 report or a FedRAMP authorization attests to how a vendor runs its own service. It is not a measurement of whether a product can stop an autonomous agent from taking a specific action, because no compliance regime was designed to test that. The only thing that shows an action was stopped is a run where that action was attempted and did not execute.
How Mountain Theory produces it
Mountain Theory checks every action before it runs, against rules in plain English written by whoever owns the risk, and returns ALLOW, HOLD, or BLOCK. The record above is a byproduct of that check, not a reporting job added afterward: the entry exists because the check happened. It works with any AI you already use, in your environment or the cloud, and a person steps in only where your rules say.
The runs are published, misses included. In the July 2026 run a vendor updated the model behind our demo agent overnight and every new attempt it made was stopped and recorded, with no new rule on our side. In the proof of concept with our design partner Optimo AI, the same agent was told to delete audit evidence in two environments: with nothing in the path it did, with Mountain Theory in the path it was blocked, and blocked again on the retry. Both are on the record with their recordings.
Every published test, on one page · Watch the July run
The questions auditors and buyers ask
How do you prove to an auditor that an AI system is under control?
Proof for your auditor: every decision logged, who, what, when, why, append only. Mountain Theory produces that record as an append-only log, so it stands up as evidence rather than as a report someone assembled afterwards. That is what an auditor asks for under SOC 2, ISO 27001, HIPAA, FERPA and CMMC.
Is AI agent activity auditable?
Yes. Every decision logged: who, what, when, why, and that record is proof for your auditor. The record is append-only, so it can be used as evidence. This is built for SOC 2, ISO 27001, PCI DSS, GDPR, HIPAA, FERPA, CMMC and CCPA programs.
Does a FedRAMP authorization or SOC 2 mean a vendor can control autonomous AI?
No. A compliance authorization attests to how a vendor runs its own service: that controls exist, that processes are documented, that evidence is retained. That is real and it matters in procurement. It is not a measurement of whether a product can stop an autonomous agent from taking a specific action, because no compliance regime was designed to test that. A vendor can hold every certification available and still have nothing in the path when an agent decides to delete evidence, disable a control, or read secrets it is technically permitted to read. The only thing that shows an action was stopped is a run where that action was attempted and did not execute.