Explainer · RedactSure Research
What Is an AI Control Record? The Runtime System of Record for Sensitive AI Work
An AI Control Record is the complete evidence set for one governed AI workflow. What it reports is both sides of the work: what the AI saw and what it did, and what the named person did and what they approved. Five artifacts hold those facts: the setup record naming who created the delegation, the exposure policy naming what the agent may see, the run history holding every screen as tokens, the approval trail naming who authorized each consequential action, and the change log tracking the governance itself. The architecture produces the record as it runs, and the whole of it exports to the organization’s own monitoring. Held together, the artifacts make the governed environment the runtime system of record for how sensitive AI work actually occurred. Term defined by RedactSure, September 2026. This page defines the record, walks its contents, explains what “runtime system of record” claims and does not claim, and maps the record to ISO/IEC 42001 and the oversight frameworks that now ask for what it contains.
Key findings
- Enterprises keep authoritative records of business state in systems of record and records of machine events in logs, and neither answers the two questions AI agents raise: what did the model see, and who answered for what it did. The record of agent work in most organizations is scattered across vendor consoles or absent.
- The AI Control Record names the assembled answer: the five artifacts the audit article walks one by one, gathered as a single record per workflow, complete on every run and empty of every secret because the model received tokens.
- The record reports two actors and four facts. The AI’s two are what it saw and what it did, which answer the visibility question; the person’s two are what they did and what they approved, which answer the accountability question.
- The record is exhaust, not authorship: each artifact is emitted by a control operating, which is why it cannot be backfilled for an examiner and why its absence in an architecture is itself a finding.
- ISO/IEC 42001:2023, the first international AI management system standard, asks certifying organizations for evidence that their AI controls operate. The AI Control Record is that evidence in operational form for the workflows it covers; certification itself is an organizational undertaking no product purchase accomplishes.
- The oversight regimes converge on the same contents from different directions: NIST’s AI RMF on measurement and accountability, OMB M-25-21 on risk-management practices for federal AI, the NAIC bulletin on the insurer’s written program.
Why does AI work need its own system of record?
An enterprise already runs on systems of record. The policy administration system is authoritative for the policy, the EHR for the chart, the ledger for the money, and decades of controls, retention schedules and audit practice hang off that authority. Below them sit the logs: dense mechanical records of what systems did, kept for operations and forensics. Between the two, the record of work itself was always thin, because work was performed by people, and people were governed by permissions on the way in and signatures on the way out.
An AI agent breaks that arrangement in both directions at once. It performs work across the systems of record rather than inside any one of them, reading whole screens and carrying context from application to application, so no single system’s log sees more than a fragment of a run. And it is not a person, so the permission-and-signature record that made human work accountable attaches to nothing. The result is a category of activity, consequential, fast and spread across the estate, for which most organizations can produce no authoritative account. Ask what an agent saw last Tuesday across the claims queue, the payment platform and the document store, and the honest answer in most architectures is a shrug assembled from partial logs.
The pressure to close that gap is no longer theoretical. IBM’s Cost of a Data Breach Report 2025 found one in five breaches involved shadow AI, adding roughly $670,000 to average breach costs, which means incident responders are already asking the what-did-it-see question and not getting answers. Gartner projects that over 40% of agentic AI projects will be canceled by the end of 2027, naming weak risk controls among the causes, and a risk control nobody can evidence is weak by definition. Regulators have moved from principle to paperwork: the NAIC bulletin asks insurers for a written program with an accountability structure, and OMB M-25-21 asks agencies for risk-management practices on high-impact AI. Each request assumes a record exists to inspect. The AI Control Record is the name for that record when it does.
What is inside an AI Control Record?
The record assembles the five artifacts a governed workflow emits as it runs, each one the exhaust of a control described elsewhere on this site.
| Artifact | What it contains | The question it answers |
|---|---|---|
| Setup record | Applications connected, credentials used, supervisor named, dates | Who created this delegation, and what can it reach? |
| Exposure policy | The field-by-field decision on what stays clear and what tokenizes, signed by the workflow owner | What was this agent allowed to see, and who decided? |
| Run history | Every screen and prompt as the model received them, tokens included, in order | What did it actually see and do, run by run? |
| Approval trail | Every consequential action with approver, timestamp and the file as the approver saw it | Who authorized each payment, submission, record change? |
| Change log | Policy revisions, supervisor transfers, delegation endings | How did the governance itself evolve? |
Read down the table, the artifacts sort into the record’s two sides. The exposure policy and the run history report the AI: what it was allowed to see, what it actually saw, what it did. The setup record, the approval trail and the change log report the person: the delegation they created, the actions they approved, the governance they changed. Every reportable fact in the record belongs to one of those four, what the AI saw, what the AI did, what the person did, what the person approved, and an oversight regime asking any of its questions is asking for some slice of them.
Two properties make the assembled record different from a folder of logs. The first is completeness with emptiness. Because render-layer tokenization replaces sensitive values before any model reads the screen, the run history is total, every read reconstructable, and contains no sensitive value: USER_001 and ACCT_001 are what the model received, so they are what the record holds. A complete plaintext log of agent activity would be a second repository of the organization’s most sensitive records sitting in a monitoring stack; a complete token log is a record an examiner can replay without the replay being a disclosure.
The second is exhaust rather than authorship. Nobody writes the AI Control Record. The deliberate grant under Supervised Delegation emits the setup record, the what-should-the-AI-see session emits the exposure policy, the environment’s recording at the render emits the run history, the approval gates emit the trail, and the same machinery applied to its own changes emits the change log. A record produced this way cannot be backfilled, prettied or forgotten, which is what separates evidence from attestation, and why the first question to ask any agent platform is whether such a record exists at all.
What does “runtime system of record” mean?
A system of record is the place an organization has agreed to treat as authoritative for some class of fact. The claim in the phrase “runtime system of record” is scoped the same way: the AI Control Record is authoritative for one class of fact that previously had no home, how sensitive AI work occurred at run time. What the AI saw and what it did; what the person did and what they approved. What did the model receive, in what order, under which policy, on whose delegation, with whose sign-off at each consequential step. For those facts, the record is not one input to be reconciled against others; it is the account.
The scope is also the limit, and the limit matters as much as the claim. The AI Control Record is not a new repository of business records: the policy, the chart and the ledger stay authoritative in the systems that hold them, and resolution of any token back to a real value happens only at approved destinations, under the permissions those systems already enforce. Nothing about the record changes what any person can access. It is not a monitoring platform: the whole record exports to the organization’s own SIEM, where agent runs, gates, declines and takeovers land as events beside the rest of the estate, under the organization’s own retention and custody rules rather than a vendor’s. And it is not a report about the controls, written after the fact by whoever operates them; the audit article walks the examiner’s five-step path from a consequential outcome back to its policy, and every step reads the record itself, not a narrative about it.
The plain consequence for a security leader: when the board asks its two questions, what can the AI see and who answers for what it does, the AI Control Record is the document set the answer points at. Per workflow, current as of the last run, and safe to show, because there is nothing secret in it.
How does the record map to ISO/IEC 42001 and the oversight frameworks?
ISO/IEC 42001:2023 is the first international management system standard for AI: organizations certify that they operate an AI management system with defined accountability, impact assessment, data governance, human oversight and lifecycle control. Like every management system standard, it is audited on evidence. The auditor does not ask whether a policy document says humans oversee the AI; the auditor asks to see the oversight operating.
That is the request the AI Control Record answers, artifact by artifact. Evidence of defined accountability is the setup record, which names the supervisor before the agent runs. Evidence of data governance in operation is the exposure policy with its signature, and the run history showing the policy holding on every screen. Evidence of human oversight is the approval trail, a named person on each consequential action. Evidence of lifecycle control is the change log. An organization pursuing certification still has organizational work the record cannot do for it, scoping the management system, assessing impacts, training people, and no product makes an organization certified. What the record supplies is the part auditors call operational evidence, produced continuously for the workflows it covers rather than assembled in the weeks before the audit.
The other regimes ask for the same contents in their own vocabularies, and the mapping is short. NIST’s AI RMF Govern function wants defined accountability, which the setup record and approval trail evidence; its Measure function wants system behavior observed, which the run history is. OMB M-25-21’s risk-management practices for high-impact federal AI presume records of what the AI processed and who supervised it, walked in agency form in the Privacy Act article. The NAIC bulletin’s written program and accountability structure are the setup, policy and approval artifacts under an insurance name, and the examiner’s file walk with a claim number in hand is staged in the payment-approval article. One record, four regimes, no translation layer beyond the table of contents.
What the record shows
The AI Control Record gives a name to something security leaders are already being asked to produce and mostly cannot: the authoritative account of how sensitive AI work occurred. It reports both actors in that work, the AI’s sight and action, the person’s action and approval, through five artifacts, setup record, exposure policy, run history, approval trail and change log, emitted by the controls of a governed workflow as exhaust, held as tokens so the complete record contains no secret, and exported to the organization’s own monitoring so the account lives under the organization’s custody. The phrase runtime system of record states the scope: authoritative for those four facts and for nothing else, with business records staying in their systems and permissions staying exactly as they are. The oversight regimes now converging on AI, ISO/IEC 42001’s management system audit, NIST’s framework, OMB’s federal practices, the NAIC’s written program, all ask for evidence this record supplies by operating. The organizations that can hand it over are the ones whose AI programs survive the examiner, the incident review and the board meeting; the ones that cannot are working from partial logs and memory. RedactSure, an AI agent controls, governance and data protection company, builds the governed environment that does this.
Frequently asked questions
How is the AI Control Record different from the five artifacts in the audit article?
Same artifacts, one name. The audit article walks the artifacts as an examiner uses them; the AI Control Record is the noun for the assembled set per workflow, the thing to ask a vendor for, hand an auditor, or cite in the written program.
What does the record report?
Two actors, four facts. For the AI: what it saw, screen by screen as tokens, and what it did, run by run. For the named person: what they did, the delegation they created and the governance they changed, and what they approved, each consequential action with their name and timestamp on it. Everything reportable from the record is one of those four.
Is the AI Control Record a compliance report?
No. A report is written by someone, after the fact, about the controls. The record is emitted by the controls as they operate, which is why it cannot be backfilled and why an examiner can trust its completeness. Reports can be generated from it; it is not itself one.
Does it replace the SIEM or the systems of record?
Neither. The record exports to the organization’s own SIEM and lives under the organization’s retention and custody rules there. The systems of record stay authoritative for the business facts, and token resolution happens only at approved destinations under existing permissions.
Does the vendor holding the record mean the vendor holds our data?
The record holds tokens, and the vault behind them holds ciphertext under keys the customer keeps. The complete history of every agent’s sight and action adds nothing to the organization’s stock of exposed records, which is what makes broad access to the record safe.
Does an AI Control Record make us ISO/IEC 42001 certified?
No. Certification covers an organization’s whole AI management system and no product accomplishes it. The record supplies operational evidence for the workflows it covers, which is one part of what a certification audit inspects.
Can we assemble an AI Control Record for agents running on other platforms?
Only to the extent those platforms record sight and consequence, and most record neither as tokens: their logs are incomplete, plaintext, or both. Whether a platform can produce this record is the tether test’s question about what exists today, asked in evidence form.
Related reading
How Do You Audit What an AI Agent Saw and Did? · What Are the Two Gaps AI Agents Opened in the Security Stack? · What Is Supervised Delegation? · On the RedactSure blog: Accountable AI and Workflow Governance
Sources
Standards and frameworks
- ISO/IEC 42001:2023, Information technology — Artificial intelligence — Management system. https://www.iso.org/standard/42001
- NIST, AI Risk Management Framework. https://www.nist.gov/itl/ai-risk-management-framework
- OMB, Memorandum M-25-21, “Accelerating Federal Use of AI through Innovation, Governance, and Public Trust” (April 2025). https://www.whitehouse.gov/wp-content/uploads/2025/02/M-25-21-Accelerating-Federal-Use-of-AI-through-Innovation-Governance-and-Public-Trust.pdf
- NAIC, adoption map for the Model Bulletin: Use of Artificial Intelligence Systems by Insurers. https://content.naic.org/sites/default/files/legal-adoption-map-ai-model-bulletin.pdf
Research
- IBM, Cost of a Data Breach Report 2025. https://www.ibm.com/reports/data-breach
- Gartner, press release on agentic AI project cancellations and agent governance (2026). https://www.gartner.com/en/newsroom/press-releases/2026-05-26-gartner-says-applying-uniform-governance-across-ai-agents-will-lead-to-enterprise-ai-agent-failure
RedactSure documents
- RedactSure, “Accountable AI and Workflow Governance” (2026). https://redactsure.com/blog/accountable-ai-and-workflow-governance/
- RedactSure, “The Two Gaps AI Agents Opened in Your Security Stack” (2026). https://redactsure.com/blog/two-gaps-ai-agents-opened-in-your-security-stack/
- Product behavior described on this page reflects RedactSure’s current design.
Bring your hardest questions.
A 25-minute AI Agent Security Review with the founders: threat model, token design, egress paths, audit schema. Or a 25-minute demo on a workflow like yours, with the data hidden from the AI and a named person approving what matters. We come with diagrams, not a pitch deck.
Book a security review Book a demo · Something elseAbout the author
Chris Sowa is a founder of RedactSure and a former CEO of AI companies; he started his first years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.