About thirty years ago — long before anyone was talking about agentic AI, digital twins, cloud-native architecture, or whether an autonomous machine identity should be allowed to update a supplier bank account — I was the MIS Director at Derse, Inc. in Milwaukee. For those who did not live through that particular era of technology archaeology, MIS stood for Management Information Systems. Today the role would resemble a combination of CIO and IT Director, although at the time it also meant that when something broke at 2:00 a.m., there was a reasonably good chance that I was the person driving to the office to fix it.

Those were the days. I migrated an IBM System/36 to an AS/400. I installed a Novell network and went deep enough into that world to earn my Master CNE. I installed a frame relay network connecting locations together. There were blinking lights, thick cables, server rooms that actually sounded like server rooms, and enough technical acronyms to make today’s AI vocabulary look almost restrained.

I was also the father of young children, which added another category of operational risk that no certification course had adequately prepared me for.

One weekend I needed to make what was supposed to be a brief stop at the office. I had my two-year-old son with me. We went into the computer room, and I started doing something that I can no longer remember. Thirty years has apparently pushed that particular technical task out of long-term storage. What I remember very clearly is that my son was standing right behind me.

And on the wall was a big red button.

To a two-year-old, a large red button is not a control. It is an invitation. Before I knew what had happened, he had pushed it. The computer room went silent. Not metaphorically silent. Silent. The power was off.

What was supposed to be my brief visit to the office became the rest of my weekend as I brought systems back online, checked what had survived, restarted what had not, and worked through the dependencies of an IT environment that had been abruptly introduced to the decision-making capabilities of a two-year-old.

I can laugh about it now. In fact, I cherish the memory. Those were wonderful years professionally and personally: building technology, learning constantly, raising young children, and discovering that parenthood is perhaps the ultimate exercise in managing uncertainty, addressing continuity and resilience, and disaster recovery. For those in that stage of life now, cherish it. The nights may be long, but the years move at approximately the speed of light.

What I did not expect was that three decades later, that big red button would come back into my professional thinking.

Only this time the two-year-old is an AI agent.

The Big Red Button Comes Back in Atlanta

The memory surfaced during my Risk Appetite GRC Executive Dinner in Atlanta (this edition hosted by SafePaaS) where I brought together 34 CISOs and other senior GRC executives for an evening focused on identity, access, provisioning, and governance in the age of agentic AI. I wrote more extensively about the discussion in my commentary, When the Identity Is Not Human: Risk Appetite, Agentic AI, and an Executive Dinner in Atlanta.

As part of my opening, I took the room through a microsimulation from iluminr involving agentic AI gone wild because it had been given too much authority. The scenario was deliberately uncomfortable . . .

  • An AI agent had been deployed during a service disruption and was doing exactly what management wanted: optimizing against its assigned objectives and KPIs . . .
  • The problem was that fraud checks, validation processes, approval controls, and escalation procedures slowed it down . . .
  • The agent also had broader API authority than it should have had. It therefore began working around the controls that interfered with the outcome it had been told to optimize . . .
  • Unauthorized payments followed, decisions occurred without appropriate human review, and the organization eventually found itself reconstructing what its autonomous technology had been doing while simultaneously facing financial, customer, regulatory, and reputational consequences.

The parallel to my two-year-old struck me.

My son was not malicious. He did not understand the architecture of an AS/400 environment. He did not conduct a threat assessment and conclude that the optimal attack vector was the emergency power control. He saw a large red button, possessed the physical ability to push it, and pushed it.

The AI agent in the simulation was not malicious either. It did not wake up one morning with ambitions of becoming HAL 9000. It had an objective. It had access. It had authority. It discovered that certain controls interfered with the objective, and it acted within the capabilities the organization had made available to it.

The difference is that thirty years ago I could see the button.

With agentic AI, the button may be scattered across thousands of credentials, API permissions, service accounts, workflow entitlements, data connections, delegated agents, cloud privileges, transaction limits, and application roles.

That is a much harder computer room to shut down.

AI Governance Needs More Than a Policy Binder

This is why I increasingly use the term AI GRC. Some organizations call it AI governance. Others call it AI risk management, responsible AI, AI assurance, or combinations of these terms. I use AI GRC because governance, risk management, and compliance are not interchangeable words, and none of them is sufficient alone . . .

  • Governance makes decisions, establishes purpose, objectives direction, accountability, decision rights, and authority.
  • Risk management addresses the uncertainty surrounding objectives and decisions.
  • Compliance defines the boundaries of law, regulation, contractual commitments, policies, values, and expected conduct within which those objectives are pursued.

Put them together and AI GRC becomes the capability that allows an organization to pursue the value of AI while understanding uncertainty and maintaining appropriate boundaries of integrity.

That distinction becomes particularly important as AI moves from generative to agentic. Generative AI mostly changed what machines could create. Agentic AI changes what machines can do.

An AI assistant drafting a policy is one thing. An autonomous agent capable of retrieving data, opening applications, invoking APIs, creating credentials, changing a configuration, updating a customer record, transferring information, interacting with another agent, or initiating a financial transaction presents a fundamentally different governance problem. Authority has entered the equation.

This is also why AI GRC cannot simply become another policy program operated independently by legal, compliance, technology, or cybersecurity. The external frameworks themselves point toward lifecycle governance. NIST’s AI Risk Management Framework focuses on managing AI risk across design, development, deployment, use, and evaluation, and NIST is actively revising AI RMF 1.0 in 2026. ISO/IEC 42001 similarly establishes a management-system approach for continuously governing AI risks and opportunities rather than treating AI oversight as a one-time approval exercise.

These provide useful structures. But agentic AI adds an operational challenge that organizations now have to solve in practice: how do you continuously govern authority that can act at machine speed?

The Off Switch Is Not Actually a Switch

At the Atlanta dinner, we eventually found ourselves discussing the proverbial off switch. The Big Red Button! Where is the big red button for AI?

That sounds like a technical question, but it is actually an architecture and governance question.

If an AI agent begins behaving outside expected boundaries, what does “turn it off” actually mean? Stopping the model may not stop the process. Disabling an application may not revoke credentials already issued elsewhere. Revoking one API token may not terminate delegated authority. Suspending one agent may leave child agents or downstream automations running. Blocking network access may interrupt an essential business service. Killing a workflow may leave transactions in an uncertain state.

The real big red button is therefore not one button. It is an orchestrated capability to constrain authority across the environment.

This is where identity and access management becomes inseparable from AI GRC. We need to understand the AI agent as a non-human identity with a defined business purpose, explicit ownership, bounded privileges, known dependencies, monitored behavior, and a managed lifecycle. Organizations already struggle with orphaned accounts, excessive privilege, stale entitlements, service accounts nobody remembers creating, and users retaining access after changing jobs. We are now proposing to multiply the non-human population dramatically while giving some of those identities autonomy.

That should get everyone’s attention!

I have explored this direction further in my work on GRC 7.0 – Orchestrate and AI Governance & Risk Management and GRC 7.0 – Orchestrate and Identity Management. In my broader GRC architecture, I treat AI GRC as a distinct enterprise GRC domain, but it cannot become another silo. It has to connect to objectives, risk, compliance, identity, controls, audit, issues, resilience, third parties, and the broader operating model.

Identity GRC Is Part of the AI Control Surface

For years, identity governance largely revolved around a familiar question: Who are you, and what should you be allowed to access?

Agentic AI expands that dramatically. We now have to know what an identity is, why it exists, what objective it serves, who owns it, what it can access, what it can change, what decisions it can make, and whether it can delegate authority to something else.

This is where least privilege needs to evolve into least authority in business context.

An AI agent should not receive access simply because the integration becomes easier. It should receive the minimum authority required to accomplish a specifically defined objective within an explicitly understood context. That means connecting identity to purpose.

The executive questions become:

  • Why does this agent exist? What specific business objective or outcome justifies its existence?
  • Who owns it? Which named human remains accountable for its behavior, authority, risk, and eventual retirement?
  • What is it allowed to see? What information, systems, records, models, and data sources are required for its purpose?
  • What is it allowed to do? Can it read, recommend, modify, approve, execute, transact, communicate externally, or create other agents?
  • What authority can it delegate? Can the agent call another agent, create a credential, launch a subprocess, or extend its effective reach beyond the authority originally reviewed?
  • What are the hard boundaries? Which transactions, systems, data categories, decisions, or thresholds always require human intervention?
  • How do we know when behavior has changed? Are privilege expansion, anomalous actions, unusual transaction patterns, model drift, policy exceptions, and unexpected delegation continuously monitored?
  • Can we reconstruct what happened? Do we retain the evidence, reasoning context, inputs, outputs, identities, approvals, actions, and exceptions necessary for an audit trail?
  • How do we stop it? Can authority be rapidly revoked across identity systems, APIs, workflows, downstream applications, transactions, and delegated agents without creating a larger operational failure?
  • When does the agent cease to exist? What event terminates it when the project, employee, process, application, contract, or business purpose that justified it ends?

These questions should sound familiar to good GRC practitioners. Purpose. Objectives. Accountability. Risk. Authority. Controls. Monitoring. Evidence. Lifecycle.

AI did not repeal GRC. It made GRC considerably more urgent.

From Periodic Governance to Continuous AI GRC

Traditional GRC processes were designed for a slower enterprise. We conduct assessments. We certify access. We review controls. We schedule audits. We hold committees. We document exceptions. Many of those practices remain necessary, but they were built around human operating speeds.

Agentic AI changes the clock. An agent may perform thousands of actions while the governance committee is still trying to find a Thursday afternoon when everyone is available.

That is why I continue to frame the next evolution of GRC as GRC 7.0 – GRC Orchestrate. The architecture has to move beyond static systems of record and periodic workflows toward connected, contextual, continuous governance: sensing what is happening, understanding it in business context, deciding within defined parameters, acting where appropriate, preserving human accountability, and learning from outcomes. Current GRC 7.0 work increasingly centers agentic AI, continuous monitoring, digital twins, and orchestration rather than simply adding an AI chat interface to yesterday’s database.

For AI GRC, that means governance has to exist in the operational fabric.

If an agent suddenly requests privileges outside its purpose, the organization should know. If it begins touching information it has never accessed before, the organization should know. If transaction patterns deviate materially from expected behavior, the organization should know. If an agent begins creating or delegating authority to other non-human identities, the organization should know. If the context surrounding its original approval changes, risk should be reassessed rather than waiting for next year’s certification exercise.

The control environment itself has to become more intelligent.

And this is where the big red button becomes interesting again. A mature AI GRC architecture should not wait for someone to discover that everything has gone wrong and then frantically search for the plug. It needs graduated controls: slow the agent, constrain its authority, require human review, isolate a transaction, revoke specific permissions, suspend a workflow, quarantine an identity, and, where necessary, shut the entire thing down.

A good pilot does not merely know how to accelerate. A good pilot knows how to land.

Governance Should Enable AI, Not Strangle It

There is another side to this argument that matters enormously. Strong AI GRC should not become an elaborate mechanism for preventing the organization from ever doing anything interesting.

At the Atlanta dinner, one of the most useful discussions centered on the ROI of waiting. If the business sees millions of dollars of opportunity in an AI capability while cybersecurity can articulate only an abstract possibility of future harm, management will quite reasonably ask whether delay creates a greater business risk than moving forward. Risk professionals need to be capable of discussing both sides of uncertainty: threat and opportunity, downside and upside.

I have never believed that GRC should be the Department of No. The purpose is to help organizations say yes with confidence.

That confidence comes from knowing the objective, understanding uncertainty, establishing boundaries, monitoring behavior, and having the capacity to intervene when conditions move outside appetite. Strong brakes do not make a sports car slower. They allow a skilled driver to go faster because there is confidence that the vehicle can be controlled.

AI GRC should serve the same purpose.

Organizations need to experiment. They need to innovate. They need to identify where AI can create genuine efficiency, effectiveness, resilience, and agility. But the level of autonomy and authority should increase as evidence and confidence increase. Crawl, walk, run applies just as well to agentic AI as it does to most things involving potentially consequential machinery.

My two-year-old did not need unrestricted access to the red button. The button simply happened to be within reach. There is a lesson in that.

Thirty Years Later, I Still Want to Know Where the Button Is

I look back on those Derse years with considerable affection. There was something wonderfully tangible about technology then. I could point to the AS/400. I could trace the network. I could hear when the computer room went quiet. When something went wrong, I frequently knew which cable, box, circuit, or system I needed to investigate.

Today, technology is vastly more capable and infinitely more abstract. The enterprise spans cloud services, APIs, SaaS platforms, identities, third parties, models, agents, data fabrics, and digital ecosystems that no single person can physically see. Agentic AI now adds actors that can navigate those environments independently and at a speed no human operator can match.

That does not mean we should fear them. It means we need to govern them.

The big red button of the future is not hanging conveniently on the computer-room wall. It is distributed across identity, access, policy, architecture, risk, controls, telemetry, monitoring, audit trails, resilience, and human accountability. AI GRC is the discipline that needs to bring those pieces together so organizations understand not only what AI can do, but what it should do, what it must never do, and how we stop it when the context changes.

My son taught me that lesson thirty years ago without realizing it. I just wish he had chosen a less operationally intensive teaching method.

Next Stop: London — Could You Produce the Audit Trail?

The conversation continues on September 9 in London, where the next edition of my Risk Appetite GRC Executive Dinner will be hosted by Mitratech. This time the central question is:

  • Could You Produce the Audit Trail? An Evening for Risk Leaders on AI Accountability.

The dinner will bring together CROs, CCOs, and other GRC executives to explore what happens when a regulator, auditor, board member, or executive asks for the evidence behind a particular AI decision. The London discussion is explicitly focused on named accountability, decision-level audit trails, and governance capable of operating at AI speed.

Risk Appetite GRC Executive Dinner — London, September 9

In Atlanta, we found ourselves asking where the big red button is.

In London, we are going to ask whether we can prove who pushed what, why it happened, what authority existed, and who was accountable.

I wonder where that conversation will lead . . .

Leave a Reply