Governing AI Between the Checkpoints

Key Takeaways

• AI Governance Cannot Remain Periodic: Agentic AI can act continuously, making point-in-time assessments and scheduled reviews insufficient on their own.
• Authority Goes Beyond Access: Organizations need to understand not simply which systems an AI agent can reach, but what actions, decisions, transactions, and delegations it can perform once there.
• Context Continues to Change After Approval: Permissions, integrations, models, data, business purposes, and dependencies can evolve after deployment, potentially changing an agent's risk without triggering a formal governance event.
• Intervention Needs to Be Graduated: Effective AI GRC requires the ability to detect changes and constrain, pause, escalate, isolate, or terminate activity according to the circumstances rather than relying solely on an emergency shutdown.
• Audit Trails Need Business Context: Technical logs become meaningful governance evidence only when AI actions can be connected to objectives, identities, authority, controls, exceptions, and accountable humans.

Deep Dive

A few weeks ago, I wrote about a question that had followed me from a computer room in Milwaukee thirty years ago into today's conversations about agentic AI, "Where is the big red button?"

The story involved my two-year-old son, an emergency power button, an abruptly silent computer room, and most of a weekend spent bringing systems back online. Three decades later, the memory returned while I was discussing agentic AI with a room full of GRC and security executives. The comparison was imperfect, but the lesson was not. My son was not malicious. He simply possessed the ability to do something without understanding everything that would happen afterward. That becomes a considerably less charming problem when the actor is an AI agent operating across an enterprise.

In Where Is the Big Red Button? AI GRC, Agentic Authority, and Knowing How to Turn It Off, I argued that organizations need to understand how authority can be constrained when an AI agent moves beyond its intended boundaries. The proverbial button is no longer conveniently mounted on a wall. It is distributed across identities, credentials, APIs, workflows, applications, data connections, transaction permissions, delegated agents, and the other pieces of technology that allow an autonomous system to act. I still want to know where that button is, but the more I think about the problem, the more I believe there is a harder question that comes before it: How does the organization know when the button needs to be pushed?

We are accustomed to talking about AI governance as though governance happens at identifiable moments. A use case is proposed, a risk assessment is performed, legal and security conduct their reviews, someone approves the model, access is provisioned, controls are documented, and the system enters production. There is a reassuring neatness to this sequence because it gives us artifacts, decision points, names, dates, and approvals that can be placed into a system of record and retrieved when somebody asks what happened. Much of GRC has been built around precisely this kind of evidence, and for good reason. The difficulty is that the AI does not stop changing simply because the governance process has finished approving it.

An agent approved on Monday may be operating in a different context by Friday. Its permissions may change. The data available to it may expand. Someone may connect another application because the original workflow proved cumbersome. A model may be updated, a new API may become available, or the business process surrounding the agent may evolve. The agent may begin interacting with another agent that did not exist when the original assessment was performed. None of these changes necessarily arrives with a flashing light announcing a new governance event. Individually, each may appear routine. Collectively, they can leave the organization governing something materially different from what it originally approved.

This is an old GRC problem made more consequential by autonomous technology. Traditional GRC has always depended, to some degree, on snapshots. We assess risk at a point in time, certify access at a point in time, test a control at a point in time, audit a process over a defined period, and review policies according to a schedule. These activities remain necessary, but they contain an assumption that becomes increasingly difficult to sustain: that the interval between reviews is sufficiently stable for the previous assessment to remain meaningful. The enterprise, of course, keeps moving after the assessment is finished. Agentic AI makes that weakness harder to ignore because an autonomous system does not merely exist between our governance checkpoints. It acts between them.

An AI agent may retrieve information, update records, initiate workflows, invoke APIs, communicate with other systems, make recommendations, execute decisions, or delegate tasks. Depending on its design and authority, it may perform hundreds or thousands of these actions before a human being next reviews its access or risk profile. This creates an increasingly awkward mismatch between technology capable of operating continuously and governance processes that remain largely periodic. I have joked before that an AI agent can perform thousands of actions while the governance committee is still trying to find a Thursday afternoon when everyone is available. The joke works because anyone who has spent time in GRC recognizes the meeting. The underlying problem, however, is serious. Governance cannot exist only before deployment and after something goes wrong. It has to become part of the operating environment itself.

When Access Becomes Authority

That requires us to think differently about authority. For years, identity governance has largely centered on whether someone should be able to access a particular system or resource. That question remains important, but it becomes inadequate when the identity on the other side is autonomous. Consider something as ordinary as a supplier record. An agent might need permission to read it. Another might be allowed to update contact information. Another might modify payment details, while another could initiate the payment itself. Technically, these are all questions about permissions. From a business perspective, they represent profoundly different forms of authority and profoundly different consequences if that authority is misused, misunderstood, or allowed to drift.

The risk, therefore, does not reside simply in whether the agent can reach an application. It resides in what the agent can cause to happen once it gets there. That is why I have argued that least privilege needs to evolve toward least authority in business context. An agent should possess the minimum authority necessary to accomplish a defined business objective, but the relationship cannot end when the permission is granted. That authority needs to remain connected to the purpose that justified it, so the organization can recognize when the two begin to separate.

We already know how easily that separation happens with human and traditional non-human identities. Employees change roles and accumulate privileges. Service accounts survive long after anyone remembers why they were created. Third parties retain access after projects change. Temporary exceptions have a remarkable ability to become permanent. Agentic AI does not eliminate any of these familiar weaknesses. It adds autonomy to them. An agent originally authorized to perform one narrow function may gradually acquire additional integrations, information, tools, or permissions because each individual change seems reasonable. Six months later, the organization may still possess a perfectly accurate record of what the agent was supposed to be when it was approved, while the agent operating in production has become something materially different.

This is where continuous AI GRC becomes necessary, although the word continuous deserves some care. It does not mean placing another AI agent in charge of watching every AI agent and declaring the governance problem solved. Automation will certainly be essential because human beings cannot manually review every action occurring at machine speed. But automation and accountability are not interchangeable. If one autonomous agent is responsible for governing another, the organization still needs to understand the authority of the governing agent, the controls surrounding it, the decisions it is permitted to make, and the human being ultimately accountable for the arrangement. Otherwise, we have not solved the governance problem. We have simply moved it one level further away from the person expected to explain it.

What organizations need instead is the ability to recognize meaningful changes in context and respond according to their significance. If an agent suddenly requests privileges outside its approved purpose, the organization should be able to see that request in relation to the purpose for which the agent exists. If it begins accessing information it has never touched before, materially changes its transaction patterns, invokes another agent, creates credentials, or extends its effective authority through a new integration, those events should not remain isolated technical facts buried in separate systems. They need to be understood as changes to the agent's risk and governance context.

Visibility is only the first part of that capability. There also has to be a proportionate response. Some actions can reasonably be automated. A prohibited transaction might be blocked, an unexpected privilege request denied, or activity outside an established threshold paused for review. Other situations will require human judgment because the deviation may be legitimate, the business context may have changed, or stopping the agent may create a larger operational problem. In those cases, authority might be constrained, additional approval introduced, a workflow suspended, or an identity quarantined while the organization determines what has changed. The proverbial big red button remains available when circumstances demand it, but a mature control environment should offer more than two choices between allowing an agent to continue operating and shutting everything down.

That distinction is important because intervention itself can create risk. Stopping an agent in the middle of a financial process may leave transactions in an uncertain state. Revoking access may interrupt a critical service. Suspending one workflow may affect another process that depends on it. An organization that has thought seriously about AI resilience therefore needs to understand not only how to terminate authority, but how to constrain it gracefully. There should be room between normal operation and emergency shutdown for slowing activity, reducing authority, introducing human review, isolating particular transactions, and limiting what an agent can touch while the situation is investigated.

An Audit Trail Is More Than a Log

This is also where the question of the audit trail becomes more complicated. Organizations are going to accumulate extraordinary quantities of AI telemetry. Logs will tell us that an API was called, a model produced an output, a credential was used, a workflow executed, or a record changed. All of that is useful evidence, but technical evidence is not necessarily accountability. If a regulator, auditor, board member, customer, or executive asks six months later why a consequential AI decision occurred, the organization may need to reconstruct far more than the sequence of technical events.

It may need to know what objective the agent was pursuing, what information it had available, which model and version were operating, what authority had been granted, which identity exercised that authority, and what controls applied at the time. It may need to establish whether another agent participated, whether an exception had been granted, whether a human intervened, and who ultimately owned the agent and the business process in which it was operating. An organization can possess a log telling it precisely what happened at 2:14:37 p.m. and still be unable to explain why the action was permitted to happen. That distinction is the difference between possessing technical records and possessing an audit trail capable of supporting accountability.

For AI GRC, the evidence therefore has to connect technical activity to business context. Identity, authority, objective, risk, control, policy, action, exception, and human accountability cannot live in separate systems and be expected to become coherent only when somebody asks a difficult question. This is one reason I continue to argue that AI GRC cannot become another silo. AI governance touches identity because agents need authority, cybersecurity because that authority creates an attack and control surface, operational resilience because constraining an agent may interrupt important processes, and third-party risk because models, infrastructure, data, and applications may belong to someone else. It touches compliance because AI actions occur within legal, regulatory, contractual, and ethical boundaries, and it touches audit because organizations eventually need to demonstrate what happened and why.

Separate those disciplines too aggressively and the organization loses the context it needs to govern AI well. The security team may know what credential was used. The identity team may know what permissions were granted. Compliance may know which policy applied. Risk may know the scenario that was assessed. Internal audit may know which control was tested. The business may know why the agent exists. None of those perspectives is sufficient on its own because the governance question lives in the relationship among them.

GRC Has to Move With the Enterprise

This is where the architecture of GRC itself has to evolve. For years, GRC technology has excelled at recording things. Risks go into risk registers, controls into control libraries, obligations are mapped, policies are managed, assessments are distributed, issues are tracked, and evidence is collected. We still need these systems of record, but increasingly we also need systems capable of understanding what is happening now and connecting it to what the organization already knows. The record of an agent's authority cannot live in one system, its identity in another, its activity somewhere else, its controls in another repository, and its business objective in somebody's PowerPoint presentation if we expect governance to respond coherently when circumstances change.

That is what I mean when I talk about the evolution toward GRC orchestration. The objective is not simply to put AI on top of yesterday's GRC database and give users a conversational interface. It is to connect governance to the operational fabric of the enterprise so that meaningful changes can be sensed, understood in context, and acted upon while they still matter. AI makes the requirement particularly urgent because autonomous systems compress the time between decision and consequence, but the underlying problem is larger than AI. Organizations have never really been static. Objectives change, regulations change, suppliers change, employees change, technology changes, threats change, and markets change. GRC has often behaved as though it could periodically stop this moving enterprise, take a photograph, assess the photograph, and rely on it until the next scheduled review. Agentic AI makes the blur much harder to ignore.

None of this should become an argument for slowing AI adoption until uncertainty disappears. I have spent too much of my career arguing that GRC should enable good decisions rather than become the Department of No. Organizations have legitimate reasons to pursue AI, and there are real opportunities for greater efficiency, effectiveness, resilience, agility, and entirely new ways of operating. The governance challenge is to create enough confidence for organizations to increase autonomy responsibly rather than choosing between uncontrolled experimentation and paralysis.

That confidence comes from knowing what an AI agent is supposed to do and understanding the authority it possesses in pursuit of that objective. It comes from seeing when its context changes, preserving evidence of the decisions and actions that follow, and maintaining meaningful human accountability throughout its lifecycle. It also comes from having the ability to intervene proportionately when behavior, authority, or circumstances move outside acceptable boundaries. A well-governed organization should not have to choose between trusting an agent completely and shutting it down completely. It should know enough about what is happening to make a better decision while there is still time to make one.

That brings me back to the question I started with in the earlier article. I still want to know where the big red button is. I want to know which identities need to be disabled, which credentials revoked, which APIs constrained, which workflows suspended, which transactions stopped, and which delegated authorities terminated when an agent moves beyond acceptable boundaries. But knowing how to stop something is useful only if the organization can recognize that it needs stopping. The harder challenge for AI GRC may therefore be everything that happens before anyone reaches for the button: sensing the change, understanding its significance, connecting it to business context, determining whether it remains within risk appetite, and responding before a manageable deviation becomes an incident.

The big red button still matters. The better measure of AI governance, however, may be how rarely the organization is surprised enough to need it.

The GRC Report is your premier destination for the latest in governance, risk, and compliance news. As your reliable source for comprehensive coverage, we ensure you stay informed and ready to navigate the dynamic landscape of GRC. Beyond being a news source, the GRC Report represents a thriving community of professionals who, like you, are dedicated to GRC excellence. Explore our insightful articles and breaking news, and actively participate in the conversation to enhance your GRC journey.