TPRM PlatformAgentic GRCMSME AssuranceVoice AI for GRCAI Voice AuditCredit-AIPortfolioBlogAbout Crest
Skip to main content

crest.digital

AI GOVERNANCE & AGENTIC CONTROLS

AI Works at Machine Speed. Your Governance Meetings Don’t

An AI agent can take hundreds of actions between two committee meetings. If governance is a monthly review of what already happened, it is reporting, not control. Machine-speed AI needs machine-speed rules, with humans deciding the rules and the exceptions.

Crest.Digital Editorial October 5, 2026 8 min read AI Governance

Most AI governance today is built around meetings: an AI council that reviews use cases monthly, a risk committee that receives a quarterly update, an annual policy refresh. That rhythm was designed for projects that move at the speed of people. Autonomous agents do not. A September 2026 research preprint, “Governing at Machine Speed”, puts the problem bluntly: organisations hold AI policies they cannot operationally enforce, because human-speed review cannot intervene in machine-speed operations.

The paper proposes an architecture and, importantly, says its approach is not yet validated in controlled deployment, so we treat it as a useful framing rather than proof. The framing is right, though, and it turns “agentic GRC” from a slogan into a concrete control-design question: where in the flow of an agent’s actions does the control actually sit?

See what agent-era controls look like in practice.

Crest.Digital’s Agentic GRC workflows monitor controls continuously, route exceptions to named owners and keep an auditable record of every action.

Explore Agentic GRC

The Speed Gap Between Agents and Governance

Consider a procurement agent that prepares and releases supplier payments, or an access agent that provisions accounts. Each can perform hundreds or thousands of actions in the interval between one governance meeting and the next. A committee reviewing a monthly summary is seeing a sample of history. By then a wrong payment has cleared, a privilege has been used, or a record has been changed.

⏱
Reviewing is not controlling. A control that operates after the action can detect a problem. Only a control that operates before or during the action can prevent one.

This is the same distinction internal audit already makes between detective and preventive controls. What is new is the volume and the autonomy. A human clerk who makes a mistake makes a few; an agent that misapplies a rule can repeat it thousands of times before anyone looks. We examined the identity side of this in your next privileged user may not be human, and the assurance side in the agentic AI governance gap.

Why Weekly Review Meetings Cannot Control Autonomous Agents

Three structural reasons make the meeting-based model break down as agents scale.

Cadence mismatch. Governance forums meet weekly, monthly or quarterly. Agents operate continuously. The control interval is orders of magnitude longer than the risk interval.

Sampling is not enough. Reviewers can examine a handful of cases. Agent activity produces volumes where a sample misses the rare, high-impact action, the one above the threshold or sent to the wrong party.

Policies are prose. “Agents must not take material actions without approval” cannot be evaluated by a machine until “material” becomes a number, a counterparty list and a data classification. We made the wider point in an AI policy isn’t an internal control until someone tests it: a policy becomes a control only when something enforces and evidences it.

The Control Model: Policy-as-Code, Thresholds and Approval Gates

Policy-as-code means writing a governance rule in a form software can evaluate before an action is taken. The model has four moving parts, and each one has a human owner.

The Machine-Speed Control Chain

  • Policy: the approved rule, translated into machine-checkable logic and owned by the control owner.
  • Permission: what the agent may read, change, approve or send, set on least-privilege lines.
  • Threshold: value, volume, sensitivity and counterparty limits that define materiality.
  • Decision: every proposed action is allowed, routed to a human for approval, or blocked, then logged as evidence.

The principle is familiar from payment and access controls and from cloud governance. What changes is that it now applies to a non-human actor that reasons and chooses tools. The NIST AI Risk Management Framework asks organisations to govern, map, measure and manage AI risk; policy-as-code is one practical way to make “manage” operational. It also fits the human-oversight direction we covered in Microsoft’s AI constitution and the approval design in AI agents in financial reporting and human approval.

Six Steps to Build Machine-Speed Controls

You do not need to govern every agent at once. Pick one high-impact workflow, such as payments, vendor onboarding or access provisioning, and run it through these steps. They mirror the Discover, Design, Connect, Deploy, Validate and Transfer model we use when building agent and continuous-control solutions.

1

Register the Agent and Its Owner

Record every agent, its business owner, purpose, systems it touches and the identity it uses. If it is not in the register, it cannot be governed.

2

Define Permissions as Least Privilege

List what the agent may read, create, change, approve or send, and remove everything else. Permissions are the first and strongest control.

3

Set Materiality Thresholds

Agree value, volume, data-sensitivity and counterparty limits. Below the limit the agent proceeds; above it the action is escalated.

4

Write the Rules as Policy-as-Code

Convert approved policy into machine-checkable rules that return allow, require approval or block, versioned and owned like any control.

5

Route Exceptions to Named Humans

Send above-threshold and unusual actions to accountable approvers with the context needed to decide quickly, and time-box the response.

6

Log, Test and Review Continuously

Keep a tamper-evident record of every decision, test the controls on a rolling basis, and review thresholds when results or risk change.

Run the first deployment in monitor-only mode: let the policy engine record what it would have allowed, escalated or blocked, compare that with human judgement, and tune the thresholds before you enforce. This is the same validate-before-trust discipline we apply in agentic AI workflows for vendor risk.

Extend the same discipline to your third parties.

Agents increasingly act on vendor data and vendor systems. Crest.Digital’s platform brings continuous third-party intelligence into the same evidence trail.

What Internal Audit Should Test

Machine-speed control does not shrink the audit role; it sharpens it. Auditors move from reading policy to testing enforcement. The Institute of Internal Auditors and ISACA both provide control and governance guidance that applies directly: define the objective, test design, then test operation.

In practice that means checking that every agent is registered with an owner; that policy rules match the approved risk appetite; that the enforcement point cannot be bypassed; that approvals came from the right people; and that logs are complete and tamper-evident. Because rules and agent behaviour change often, testing works best as a rolling activity rather than an annual one. Our guide to why AI agents need audit trails covers the evidence standard, and the case for an independent assurance layer explains who should do the testing. For the wider supply-side view, see end-to-end vendor risk governance and the measurable impact organisations report.

Your Turn: Where Does Your Control Sit?

  • After the fact: a committee reviews a report of what agents did.
  • Around the agent: permissions are limited, but thresholds and approvals are informal.
  • In the flow: every action is checked against coded policy, escalated above threshold and logged.

Which describes your most autonomous agent today? Share your answer when you post this on LinkedIn.

Crest Perspective

AI governance programmes that treat AI risk as a technology problem will be underprepared for the regulatory environment taking shape in 2025–26. The EU AI Act, NIST AI RMF, and emerging FCA guidance all frame AI risk as a governance and accountability question first — the technology controls follow from having clear answers to who is responsible, what decisions the AI influences, and what the escalation path is when the system behaves unexpectedly.

Frequently Asked Questions

It means enforcing AI policy at the moment an agent acts rather than reviewing it afterwards. Instead of a monthly committee reading a report about what agents did, the rules (what an agent may access, change, spend or send) are written as machine-checkable policy, evaluated before each action, and logged. Each action is allowed, routed to a named human for approval, or blocked. Human governance still sets the rules, thresholds and exceptions; the control runs at the speed of the system it governs.

Policy-as-code expresses a governance rule in a form software can evaluate automatically, for example: an agent may approve payments up to a set value, only to vendors on the approved master, and never to a bank account changed in the last 30 days. The policy is versioned, tested and owned like any other control. When an agent requests an action, a policy engine returns allow, require approval or deny, and writes the decision to an audit log. The idea comes from infrastructure and cloud governance and is now being applied to autonomous agents.

No. It moves humans to where they add the most value. People define risk appetite, set thresholds, approve high-materiality actions, investigate exceptions and review how the controls are performing. What they stop doing is trying to review every action after the fact, which is impossible at agent volumes. Human-in-the-loop becomes human-on-the-loop for routine actions and human-in-the-loop for anything above threshold. Accountability remains with named owners, which regulators and auditors expect.

Audit the control design and its operation, not just the policy. Check that every agent is in a register with an owner, that the policy rules match the approved risk appetite, that the enforcement point cannot be bypassed, and that decisions are logged tamper-evidently. Then test operation: sample allowed, escalated and blocked actions, confirm approvals were obtained from the right people, and look for exceptions and policy overrides. Continuous testing is better than annual sampling because agent behaviour and policies change frequently.

Start with one high-impact agent workflow, such as payment preparation, vendor onboarding or access provisioning. Register the agent, list what it can read and change, set two or three transaction thresholds, define who approves above them, and turn on logging. Run it in monitor-only mode first, compare decisions with human judgement, then enforce. Expand to other workflows once the thresholds are stable. A small, evidenced control beats a comprehensive framework that nobody enforces.

AI Governance Policy-as-Code AI Agents Internal Audit Human-in-the-Loop Continuous Controls

Sources & References

  1. NIST AI Risk Management Framework (AI RMF 1.0)
  2. EU AI Act — Regulation (EU) 2024/1689
  3. OECD AI Principles (Recommendation of the Council on Artificial Intelligence)
  4. FCA: Artificial Intelligence — Our Approach
  5. The Institute of Internal Auditors (IIA): Global Internal Audit Standards

See how Crest can help

AI-powered TPRM, compliance automation and GRC intelligence for enterprise teams.

Request a Demo →

Ready to get started?

Bring structure, automation, and continuous intelligence to your GRC Process — without adding headcount.

★ Schedule a Demo