The Controls Are Still Being Written: Governing AI When the Technology Outruns the Audit
Oct 20, 2026 · @disc
“The technology is ahead of the governance and compliance. Control frameworks and audits are still being worked through.”
That sentence is the honest state of AI assurance in late 2026. Your engineering team ships an agent that reads a customer’s data room, calls three internal APIs through an MCP server, and writes back to the CRM. Your auditor arrives with a checklist written for a chatbot that summarizes PDFs.
Nobody is lying in that room. The standards are real, the certifications are real, and the auditors are competent. But the thing being certified moves faster than the thing doing the certifying. Every month, the gap between what an AI system can do and what a control framework can describe gets a little wider.
The mistake most organizations make is treating that gap as a waiting room: “We’ll build controls once the standard tells us what they are.” That is backwards. The gap is where your risk lives, and it is where attackers are already working. The organizations that come out ahead are the ones that govern to the risk now and let the frameworks catch up to them.
This post is a field guide to that gap: where it is widest, why audits are struggling with it, what threats live inside it, and how to build controls and evidence today that will survive the audit criteria that haven’t been written yet.
Where the technology has outrun the frameworks
The gap is widest wherever AI stopped answering and started acting. Most control language was written for a model that receives input and returns output. Production systems in 2026 plan, remember, call tools, delegate to other agents, and change state in systems of record.
| What production AI does now | What most control language still assumes | The resulting gap |
| Agents chain tool calls across APIs, SaaS, and databases | A model produces text a human reads | Authority is exercised by software, not reviewed by a person |
| MCP servers expose internal systems to any connected agent | Integrations are point-to-point and change-controlled | New tools appear at runtime; the “inventory” is never current |
| Persistent memory carries context across sessions and users | Each interaction is stateless | Poisoned memory outlives the session that planted it |
| Multi-agent workflows hand tasks between agents | One system, one owner, one risk assessment | Accountability fragments at every hand-off |
| Vendors ship model updates weekly, sometimes silently | A model version is validated once, then deployed | Your validated system is not the one running today |
| System prompts govern behavior in natural language | Configuration is code, reviewed and versioned | Policy changes ship without approval, tests, or a hash |
| Non-deterministic outputs from identical inputs | Re-performing a control yields the same result | Auditors cannot re-perform and get the same answer |
Each row is a place where a control exists on paper and fails to bind in production. The policy says “human oversight.” The agent executes 400 tool calls an hour. Nobody signs off on call 237.
This is the pattern from our earlier posts, now at scale. Your system prompt is production code, so it needs change control. You approve the envelope of what an agent may do, not each action, so the envelope must be enforced at runtime. And sovereignty or airgapping buys you control over where a model runs; only runtime governance buys you safety over what it does.
What the frameworks cover today, and where they stop
The frameworks are not empty. They are management-system and risk-taxonomy layers that tell you what to govern. What they mostly don’t yet tell you is how to prove a specific agentic control worked at runtime.
| Framework | What it gives you today | Where it stops (for now) |
| ISO/IEC 42001:2023 (AIMS) | A certifiable management system: AI policy, risk and impact assessment, Annex A controls, lifecycle, supplier oversight | Annex A controls are outcome-level; no prescribed tests for tool authorization, memory integrity, or MCP trust boundaries |
| ISO/IEC 42006:2025 | Requirements for bodies that audit and certify AIMS, built on ISO/IEC 17021-1 (published July 2025) | It raises auditor competence requirements; certification bodies and accreditors are still building that bench |
| NIST AI RMF 1.0 + Generative AI Profile (NIST AI 600-1) | GOVERN, MAP, MEASURE, MANAGE functions and a GenAI risk catalog | Voluntary and non-certifiable; MEASURE leaves test design to you |
| EU AI Act as amended by the AI Omnibus (Reg. (EU) 2026/1744) | Risk tiers, prohibited practices, GPAI duties, Article 50 transparency | Annex III high-risk obligations moved from 2 Aug 2026 to 2 Dec 2027; Annex I to 2 Aug 2028 |
| OWASP Top 10 for Agentic Applications (ASI01–ASI10) + LLM Top 10 2026 | The best current threat taxonomy for agents: goal hijack, tool misuse, identity and privilege abuse, cascading failures | A risk list, not a control standard or audit criterion |
| ISO/IEC 27001:2022 | Mature ISMS controls for access, logging, supplier, and change management | Written for deterministic systems; silent on prompts, model drift, and agent identity |
Two signals tell you how unsettled this is. First, the EU delayed its high-risk regime partly because harmonized standards and guidance were running behind. The regulator itself admitted the controls weren’t ready to audit. Second, OWASP moved agentic risk into its own list in December 2025 and, by September 2026, was already unveiling a donated Agent Control Standard alongside the LLM list. The taxonomy is maturing; the control catalog is still being drafted.
A delay is not a reprieve. The Annex III requirements didn’t shrink; only the date moved. Article 50 transparency and GPAI obligations stayed on schedule. And your enterprise customers’ security questionnaires never had a delay at all.
Why audits are still being worked through
Audits struggle with AI for a structural reason: assurance was built on re-performance and sampling, and agentic AI breaks both. An auditor can re-run a change ticket. An auditor cannot re-run last Tuesday’s agent session and expect the same output.
Five evidence problems show up in nearly every AI audit right now:
- The attestation problem. A “human-in-the-loop” checkbox records that someone said they reviewed an output. It does not record what they saw, how long they looked, or whether they could have stopped the action. As we argued in our When Structure Pays case study with Frontier Founder, an oversight checkbox captures the overseer’s statement, not evidence of oversight.
- The non-determinism problem. The same prompt yields different outputs. Sampling 25 transactions tells you little about the 26th. Evidence has to shift from sampled outputs to enforced boundaries and continuous evaluation.
- The drift problem. Foundation-model vendors update models on their own schedule. The system you assessed in Q1 may not be the system running in Q3, and the change never touched your change-management process.
- The supplier-opacity problem. Most organizations deploy third-party models. Your AIMS covers your use; the model’s training data, safety testing, and update cadence sit behind a vendor’s SOC 2 report that was never scoped for AI behavior.
- The competence problem. ISO/IEC 42006 now sets requirements for AIMS certification bodies, but a standard for auditor competence is not the same as a bench of auditors who can read an MCP tool manifest or test for indirect prompt injection.
None of this means certification is hollow. When we took Virtual Data Room through ISO/IEC 42001 Stage 2 on the first attempt, the certifying body tested the management system rigorously. But the strongest evidence in that audit was what we built ahead of the criteria: an MCP Governance Standard that defined how agents may connect to systems, with controls written to be enforced and evidenced rather than merely documented. That is the lesson. Auditors are working it out in real time, and they reward organizations that hand them evidence they can actually rely on.
The threat model of the gap
Attackers don’t wait for a control framework to be finalized. They aim at exactly the places where a policy exists but no runtime control enforces it. Mapped to the OWASP Top 10 for Agentic Applications, the gap looks like this:
| Threat (OWASP ASI) | How it lives in the gap | What the paper control says | What actually stops it |
| Agent goal hijack (ASI01) | Indirect prompt injection via a document, email, or web page the agent reads | “Inputs are validated” | Untrusted-content isolation; no tool call without policy check on intent and parameters |
| Tool misuse (ASI02) | Agent uses a legitimate tool for an illegitimate purpose, such as bulk export | “Least privilege” | Per-tool allowlists, parameter bounds, rate limits, and egress controls at the gateway |
| Identity and privilege abuse (ASI03) | Agent acts with a shared service account; confused-deputy calls across trust boundaries | “Access is role-based” | Per-agent identity, token audience validation, OAuth 2.1 with PKCE, short-lived scoped tokens |
| Agentic supply chain (ASI04) | Malicious or rug-pulled MCP server, poisoned tool description, swapped model | “Vendors are assessed annually” | Signed tool manifests, pinned versions, runtime integrity checks |
| Memory and context poisoning (ASI06) | Planted instructions persist in long-term memory and fire later | (Usually not addressed) | Memory provenance, tenant isolation, TTLs, write review for persistent memory |
| Cascading failures (ASI08) | One agent’s bad output becomes another agent’s trusted input | “Each system has an owner” | Trust boundaries between agents, circuit breakers, blast-radius limits |
| Human-agent trust exploitation (ASI09) | Approver rubber-stamps a confident, well-formatted recommendation | “Human oversight is required” | Oversight designed for intervention: risk-tiered approvals, shown evidence, measured review |
The rightmost column is the point. None of those controls require a regulator’s sign-off to implement. They are ordinary security engineering, applied to a new kind of principal: software that acts with delegated authority. Several came straight from our v1.1 redline of the ShareVault MCP Governance Standard: SSRF and egress controls, tool manifest integrity, token audience validation, and confused-deputy protections.
Governing ahead of the framework: seven design principles
You don’t need the final control catalog to build controls that will satisfy it. Every mature framework converges on the same few ideas. Build to those ideas now and you will map cleanly to whatever text gets published.
- Govern to the risk, map to the framework. Start from your AI system inventory and threat model, not from a clause list. Then crosswalk each control to ISO 42001 Annex A, NIST AI RMF, and the EU AI Act. Controls built clause-first break the first time the clauses change.
- Treat every agent as a principal. Give each agent its own identity, its own scoped credentials, and its own audit trail. If you can’t answer “which agent did this, under whose authority?”, you don’t have access control.
- Approve the envelope, enforce at runtime. Humans approve the boundaries: allowed tools, data classes, spend and volume limits, destinations. A policy gateway enforces them on every call. Reserve human approval for actions that cross a risk threshold.
- Put prompts and tool manifests under change control. System prompts, tool descriptions, and model versions are production configuration. Version them, hash them, test them, and require approval to change them.
- Design oversight for intervention, not attestation. A reviewer needs the evidence, the authority to stop the action, and enough time to use both. Measure override rates; a reviewer who never overrides is a signal, not a control.
- Assume the model changes underneath you. Pin versions where you can. Where you can’t, run a standing evaluation suite on every vendor update and treat a failed eval like a failed deployment.
- Make the evidence a by-product of operation. If evidence has to be assembled for the audit, it’s a narrative. If it’s emitted by the control as it runs, it’s proof.
Evidence that survives an audit that hasn’t been written yet
You can’t predict the exact audit criteria for 2027. You can predict what any competent auditor will ask: Show me it was designed, show me it ran, and show me it worked. The trick is shifting evidence from statements to records.
| Control area | Weak evidence (a statement) | Strong evidence (a record) |
| AI inventory | A spreadsheet updated before the audit | An inventory fed by the gateway, listing every agent, model version, and connected tool seen in the period |
| Human oversight | “Reviewed” checkbox with a name | Approval log showing what was displayed, decision time, overrides, and actions blocked |
| Tool authorization | Policy stating least privilege | Gateway decision logs: allowed and denied calls, with the rule that fired |
| Prompt and config change | Prompt text in a wiki | Versioned, hashed prompts with approver, eval results, and deploy timestamp |
| Model drift | Vendor release notes in a folder | Eval-suite results on each model version, with pass thresholds and exceptions |
| Third-party AI suppliers | Vendor SOC 2 report | AI-specific supplier questionnaire, contractual change-notice terms, and your own testing results |
| Incident response | IR plan that mentions AI | Tabletop records for a prompt-injection or rogue-agent scenario, with findings closed |
| Impact assessment | One-time AI impact assessment | AIIA tied to each system in the inventory, re-run on material change |
Notice what strong evidence has in common. It is continuous, machine-generated, and tied to a specific system and period. That is what lets an auditor rely on it without re-performing a non-deterministic process. It also happens to be exactly what your security team needs to detect an attack in progress.
Compliance crosswalk: one control, many frameworks
Build each control once and map it everywhere. This is how a governance-ahead program stays resilient as frameworks evolve: when a clause moves, you re-map; you don’t rebuild.
| Control | ISO/IEC 42001 Annex A | NIST AI RMF | EU AI Act (high-risk) | ISO/IEC 27001:2022 | OWASP ASI |
| AI system and agent inventory | A.4, A.6 | MAP 1, GOVERN 1 | Art. 9, Art. 49 registration | 5.9 | ASI04, ASI10 |
| Per-agent identity and scoped access | A.6, A.9 | MANAGE 2 | Art. 15 | 5.15–5.18, 8.2, 8.5 | ASI03 |
| Runtime policy gateway (tools, egress) | A.6, A.9 | MANAGE 2, MEASURE 2 | Art. 15 | 8.16, 8.20–8.23 | ASI01, ASI02 |
| Prompt, manifest, and model change control | A.6 | GOVERN 1, MANAGE 4 | Art. 9, Art. 17 | 8.32, 8.25 | ASI01, ASI04 |
| Continuous evaluation and drift monitoring | A.6 | MEASURE 2, MEASURE 3, MANAGE 4 | Art. 9, Art. 15, Art. 72 | 8.16 | ASI08, ASI10 |
| Oversight designed for intervention | A.9 | GOVERN 3, MANAGE 2 | Art. 14, Art. 26 | 5.2 | ASI09 |
| Operational logging and evidence | A.6 | MEASURE 2, MANAGE 4 | Art. 12, Art. 19 | 8.15 | All |
| AI impact assessment | A.5 | MAP 1–MAP 5 | Art. 27 (FRIA, where applicable) | 5.34 | — |
| Third-party model and tool assurance | A.10 | GOVERN 6, MAP 4 | Art. 25, Art. 26 | 5.19–5.23 | ASI04 |
| AI incident response | A.6, A.8 | MANAGE 4 | Art. 73 (serious incidents) | 5.24–5.28 | ASI08, ASI10 |
Mappings are indicative. Confirm against the current text of each framework and your system’s risk classification before relying on them in an audit.
A 90-day plan to govern ahead of the audit
Ninety days is enough to move from “we have a policy” to “we have evidence.” It is not enough to be finished, and that’s fine. The goal is a program that keeps pace with the technology rather than one that chases the auditor.
Days 1–30: See it
- ☐ Build an AI inventory covering models, agents, MCP servers, connected tools, and data classes touched
- ☐ Classify each system by risk, including EU AI Act tier where you have EU exposure
- ☐ Threat-model your top three agentic workflows against OWASP ASI01–ASI10
- ☐ Identify every place a “human oversight” control is a checkbox
Days 31–60: Bound it
- ☐ Issue per-agent identities and replace shared service accounts
- ☐ Route tool calls through a policy gateway with allowlists, parameter bounds, and egress rules
- ☐ Put system prompts, tool manifests, and model versions under versioned change control
- ☐ Redesign the highest-risk oversight point for intervention, with risk-tiered approvals
Days 61–90: Prove it
- ☐ Stand up a continuous evaluation suite and run it on every model or prompt change
- ☐ Turn on decision logging and retain it as audit evidence
- ☐ Run a tabletop on a prompt-injection or rogue-agent incident and close the findings
- ☐ Crosswalk your controls to ISO 42001, NIST AI RMF, and the EU AI Act, and run an internal audit against it
By day 90 you can hand a customer, a board, or a certification body something rare: evidence that your AI controls run, not just that they exist.
The bottom line
The technology is ahead of governance and compliance, and it will stay ahead. Control frameworks and audits will keep being worked through for years, because the systems they describe keep changing.
That is not a reason to wait. It is the reason to lead. The organizations that win enterprise deals, pass certification, and avoid the incident headline are the ones that govern to the risk today, enforce at runtime, and let the evidence speak. When the final audit criteria arrive, they won’t be scrambling to comply. They’ll be the reference implementation.
Work with DISC InfoSec
DISC InfoSec helps B2B SaaS and financial services firms build AI governance that holds up in production and in the audit room. We took ShareVault through ISO/IEC 42001 Stage 2 certification on the first attempt and authored their MCP Governance Standard.
Start with a free AI Governance Readiness Assessment, or try our AI Governance Maturity Calculator and AI Risk X-Ray to see where your gap is widest.
“Disc Infosec” Deura, AICP, CISSP, CISM, ISO/IEC 42001 Lead Implementer, ISO/IEC 27001 Lead Implementer Principal Consultant, DISC InfoSec · PECB Authorized Training Partner info@deurainfosec.com · (707) 998-5164 · Book a call
Sources
- EU Digital Omnibus on AI enters into force — National Law Review
- Did the EU delay the AI Act? — Messaging Architects
- ISO/IEC 42006:2025 — ISO
- OWASP Top 10 for Agentic Applications for 2026 — OWASP GenAI Security Project
OWASP’s 2026 LLM Top 10 and new Agent Control Standard — CSA Labs
- The Controls Are Still Being Written: Governing AI When the Technology Outruns the Audit
- If Your Frontier Model Vanished for 3 Weeks, Would Your Business Stop?
- The Evidence Lifecycle: Which Organizational Events to Log for Liability — and How Long to Keep Them
- 14 Months to Comply. 12 Months of Work. The High-Risk AI Playbook Nobody Has Started
- Your biggest AI risk isn’t hackers. It’s your own data walking out the door
