Agentic GRC: Bringing Control Assurance Up to the Speed of Security

A GRC Situation We All Recognize – The GRC Assurance Gap

When a new vulnerability is disclosed, an application changes, or an engineering team introduces another cloud service, the organization’s control posture may change with it, which means the CISO needs to understand where the exposure exists, which controls are affected, how reliable the available evidence is, and what response should follow.

Establishing those answers can take a Security GRC team days or weeks because the team must interpret the change, define the required test, secure engineering support, collect evidence from multiple systems, and evaluate the affected population. During that period, the technology environment continues to evolve, applications continue to be deployed, and the organization continues to make decisions using an incomplete view of its control state.

I believe agentic GRC gives us a way to compress much of this cycle into hours, provided that we apply agents where they offer the greatest value and place their output within a governed execution architecture. This model can help an enterprise move much more quickly from a change in its technology environment to a trustworthy understanding of the resulting control impact.

We call this emerging model Continuous Controls Monitoring 3.0, or CCM 3.0, because it represents a new way to design, deploy, and operate continuous controls monitoring for an agentic era. The CCM 3.0 label isn’t so important. What is important is the model combines agent-assisted control design with deterministic production execution, giving Security GRC teams the ability to create controls more quickly while preserving the repeatability, auditability, and operational discipline that enterprise assurance requires.

GRC Operates Across Two Different Worlds

I tend to think about enterprise GRC as a tale of two worlds, with engineering, IT, security engineering, and security operations forming the first line of defense, and GRC, risk, and audit providing the second and third lines of defense.

The first line operates at the speed of the business because applications, infrastructure, identities, configurations, and data flows are changed continuously through APIs, automated pipelines, infrastructure-as-code, and cloud operating models. Generative AI has accelerated this activity further because agents can now write code, analyze systems, initiate actions, and coordinate technical processes at a pace that would have been difficult to imagine only a few years ago.

The second and third lines frequently operate according to monthly, quarterly, and annual cycles, which means that a control assessment or compliance record may reflect conditions that existed before the most recent application release, infrastructure change, or technology decision. As the rate of change increases, the distance between the operating environment and its documented control state becomes more significant.

This cadence mismatch has existed for some time, and the agentic era is making it increasingly visible because the systems being governed can now change at an exponential rate. If agents eventually participate in the verification and deployment of software as extensively as they already participate in its creation, the existing assurance model will face even greater pressure.

For CISOs and Security GRC leaders, the practical question becomes clear: how can assurance operate at a cadence that reflects the systems it is expected to govern? This need has long been recognized in established security guidance, with NIST SP 800-137 describing continuous monitoring as a way to provide visibility into organizational assets, threats, vulnerabilities, and control effectiveness so that organizations can respond to risk in a timely manner.

That guidance predates the current agentic era, and the underlying requirement has become more urgent as enterprise systems change more frequently and agents assume a larger role in creating and operating them.

Continuous Controls Monitoring Has Evolved In Three Stages

Let me define three eras of CCM. Again, the names are not so important. It’s the capabilities and their evolution that I think you’ll recognize.

CCM 1.0: Automating Manual Evidence Collection

Our first attempts at control automation generally reproduced manual evidence-collection processes, with robotic process automation capturing screenshots, moving files, completing forms, and performing repetitive actions more quickly than a person could perform them.

This model reduced some effort and demonstrated the value of automation, although the underlying evidence process remained largely unchanged because the technology continued to imitate a sequence that had been designed for human execution. Screenshots and samples remained central, and control assessments continued to provide a periodic view of the environment.

CCM 2.0: Using APIs For Broader Evidence Coverage

As enterprise applications became API-centric, continuous controls monitoring entered another stage, which I describe as CCM 2.0. APIs enabled organizations to collect structured evidence directly from cloud platforms, identity systems, development environments, security products, collaboration tools, and enterprise applications, allowing control owners to evaluate larger populations with greater frequency and higher evidence fidelity.

API-based automation represented substantial progress because organizations could begin moving beyond small samples and could establish a clearer transaction path between the source system and the GRC or audit platform. Many enterprises are still developing this capability, and it remains an essential foundation for continuous assurance.

The model also introduced a set of development and operating demands that became more visible as implementations grew. Engineers had to build and maintain integrations, GRC teams had to translate control requirements into technical specifications, source-system changes could break collection logic, and every production workflow required credential management, monitoring, exception handling, data transformation, and evidence provenance.

A single API integration may be relatively straightforward to build, and an enterprise program may require hundreds or thousands of integrations and control instances to operate reliably across business units, technology stacks, cloud environments, and geographic boundaries. The distinction between writing a script and operating an enterprise control therefore becomes fundamental.

CCM 3.0: Designing Controls with Agents

Large language and reasoning models give us a new way to address the design portion of this problem because they can interpret intent, understand context, evaluate available information, and assemble technical components dynamically. This capability leads us toward CCM 3.0.

Agentic GRC Begins with a Description of Intent

In a conventional control-automation process, the GRC team defines the requirement, communicates it to an engineering team, waits for development capacity, reviews the implementation, and begins the cycle again whenever the requirement or source system changes.

With CCM 3.0, a Security GRC professional can begin by describing the intended control outcome in natural language, including:

• the risk or condition that requires evaluation;
• the systems, assets, applications, and business units in scope;
• the evidence that should be collected from each source;
• the criteria that should be applied to that evidence;
• the expected risk or compliance output;
• the frequency at which the control should run;
• the exceptions that require human review; and
• the remediation guidance that should accompany a finding.

An agent can interpret this intent and construct a proposed control by identifying relevant data sources, selecting evidence-collection components, assembling evaluation logic, and defining the required outputs. The GRC professional can review the proposed logic, run a unit test against a limited environment, inspect the results, and refine the control before approving it for production.

This process gives the people who understand the control objective a more direct role in its technical implementation, which can reduce the time spent translating requirements across organizational boundaries and waiting for routine automation requests to reach the front of an engineering queue.

Engineering teams remain essential because they establish the architecture, integrations, security boundaries, reusable components, and operating standards that make this capability dependable. The agent gives GRC professionals greater technical leverage within that environment, allowing engineering capacity to be focused on platform design, complex integrations, security, and higher-risk technical problems.

The longer-term implication is that risk and compliance can begin moving from writing static rules toward describing intended states and outcomes. This is similar to the declarative models used in cloud infrastructure and Kubernetes, where a team defines the required state and the operating system continuously reconciles that state with the observed environment.

Probabilistic Design Requires Deterministic Execution and Deterministic Data

Agents are inherently probabilistic, which means that a model may produce different outputs when it receives the same request under similar conditions. When several agent actions are chained together, the uncertainty associated with each step increases across the sequence.

Recent research supports the distinction between agent capability and agent reliability. In the 2026 Princeton University study Towards a Science of AI Agent Reliability, researchers evaluated recent agentic models across repeated runs, prompt variations, environmental changes, and injected faults, finding that rapid capability gains over the preceding 24 months had produced much smaller improvements in reliability.

For enterprise assurance, the implication is that an agent’s ability to complete a task does not establish that the agent can execute the task dependably in production. Reliability must be evaluated separately through characteristics such as consistency, robustness, predictability, and safety.

This reliability gap presents a serious challenge for enterprise assurance because internal auditors, external auditors, regulators, customers, executives, and control owners need to understand how a conclusion was reached and whether the approved logic was applied consistently across the full population.

If an agent evaluates every production record and makes each compliance determination independently, the organization may struggle to demonstrate repeatability, explain why results changed, or reconstruct the logic applied during a previous execution. These questions become especially important when the evidence supports a regulatory filing, customer assurance commitment, risk-acceptance decision, or board report.

At ComplianceCow, our approach separates the design process from production execution.

Table 1: Separation of Control Design vs. Execution Operating Model

Agentic GRC Automation Function	Execution & Governance Model
Interpret the control requirement	Agent-assisted
Assemble the proposed control	Agent-assisted
Review and test the control	Human-validated
Approve the control	Governed
Execute the approved control	Deterministic
Record evidence and results	Traceable and repeatable
Monitor ongoing execution	Observable and managed

The agent is used to help design, test, and modify the control, with a person remaining in the loop to inspect the logic and validate the expected output. Once the control has been approved, a deterministic runtime executes it in production, applying the same logic consistently across every relevant repository, cluster, cloud account, identity, application, or other asset.

This architecture gives an enterprise:

• access to the speed and semantic reasoning of a language model during control development, and
• the repeatability required for assurance in the production control environment.

The agent helps people construct the control, and the runtime turns the approved design into a dependable operating capability.

Agents Require Governed GRC Building Primitives

A language model can generate a script quickly, which can be useful during experimentation and prototyping, and an enterprise control requires a broader set of components to operate securely and reliably at scale.

I think of these components as GRC building primitives, similar to the services and artifacts that cloud platforms provide for constructing applications. An agent can assemble a stronger control when it has access to trusted, reusable components that already understand how to connect to systems, collect evidence, transform data, evaluate conditions, route findings, and record results.

These primitives may include:

• connectors to operational, security, development, and business systems;
• credential, secret, and permission management;
• evidence-collection tasks;
• data normalization and transformation functions;
• control-testing and validation components;
• policy, control, and framework mappings;
• exception-routing and approval workflows;
• remediation actions;
• reporting and evidence-delivery functions;
• version and change records;
• production orchestration; and
• execution monitoring and observability.

The agent uses these primitives to design the control, and the runtime manages their execution across the enterprise environment. This structure gives the organization a way to govern what the agent can assemble, which systems it can access, how evidence is handled, and how approved controls are moved into production.

The distinction becomes especially important at enterprise scale because evaluating one repository, one application, or one Kubernetes cluster presents a very different systems problem from evaluating thousands of repositories, applications, clusters, identities, and cloud resources.

At that scale, the architecture must account for throttling, rate limits, distributed execution, partial failures, credential boundaries, system availability, control versions, API changes, and ongoing maintenance. A successful agent interaction provides a starting point, and the surrounding runtime determines whether the resulting control can support an enterprise assurance program.

Recent NIST research supports this emphasis on the production environment surrounding an AI system. NIST AI 800-4, Challenges to the Monitoring of Deployed AI Systems, explains that post-deployment monitoring is needed to verify that AI systems continue to operate reliably, identify unforeseen outputs created by model non-determinism or changing inputs, and provide visibility into unexpected consequences.

NIST also identifies performance degradation, fragmented logging across distributed infrastructure, and the difficulty of scaling human oversight alongside rapid deployments as continuing challenges. For agentic GRC, these findings reinforce the importance of a runtime that can monitor execution, identify failures, preserve operational visibility, and involve people when a control requires investigation or judgment.

Building Chain of Custody Into Agentic GRC Architecture

Enterprise evidence often passes through several systems before it reaches a control owner or GRC platform. A control may collect configuration data from a cloud environment, combine it with identity or asset information, apply evaluation logic, generate a finding, and deliver the result into an IRM system.

Every stage can affect the reliability of the final conclusion, which means that a credible agentic GRC architecture must be able to record:

• where the evidence originated;
• when the evidence was collected;
• which identity or credential accessed the source;
• which data transformations were applied;
• which control logic evaluated the evidence;
• which version of the control was executed;
• how exceptions and failures were handled; and
• where the evidence and resulting determination were delivered.

This chain of custody allows the organization to demonstrate the fidelity of the transaction from the source system through the compliance and audit environment. It also supports investigation when a control produces an unexpected result or when an auditor asks how a particular conclusion was reached.

As automated controls become a more significant source of assurance, the automation itself may be reviewed as part of an audit, which makes versioning, approvals, access controls, testing records, observability, and operational ownership part of the control environment.

Managing Token Consumption Is An Architectural Concern

Model usage creates another systems issue because sending large volumes of enterprise evidence through frontier models can generate substantial token costs, and model providers may apply rate limits that affect production throughput.

The long-term economics of frontier models will continue to develop, and enterprise architects still need to design for the costs and constraints that exist within their current operating environment. Token consumption can expand rapidly when agents are applied indiscriminately across large data populations, creating both financial exposure and operational dependencies.

The separation between design and execution helps contain this problem. Models can be used during control creation, testing, troubleshooting, and modification, where their reasoning capabilities provide direct value, and the approved runtime can process production evidence through deterministic logic.

This approach limits the volume of data sent through the model and reduces the likelihood that a rate limit will interrupt a production control. It also allows organizations to select different models for different design tasks, including private, commercial, and open-source options, according to their security, performance, and economic requirements.

What CCM 3.0 Offers Security GRC Professionals

For Security GRC professionals, CCM 3.0 can create a more direct path between control expertise and control operation because the practitioner can describe an intended outcome, participate in the construction of the control, validate its logic, and inspect its results.

This capability may allow routine controls to be developed and modified within hours, especially when the required connectors and tasks already exist within the organization’s library of GRC primitives. When a company moves from one development platform to another, adds a cloud provider, or changes the scope of a control, the GRC team can adapt the design through the same agent-assisted process.

Several practical benefits follow:

• control development can move closer to the people who understand the risk;
• routine automation can require less engineering coordination;
• control owners can gain greater visibility into the evaluation logic;
• evidence can cover larger populations at shorter intervals;
• control drift can be identified earlier;
• findings can carry useful context and remediation guidance;
• evidence can remain available throughout the year; and
• GRC teams can spend more time on risk analysis, control quality, and business decisions.

The quality of the underlying control remains decisive because an agent can implement an unclear requirement or inconsistent process very quickly. Before automation begins, the organization still needs to establish the risk being addressed, the intended outcome, the authoritative evidence sources, the evaluation criteria, the control owner, and the conditions that require human judgment.

Agents can reduce the technical friction involved in expressing those decisions as executable controls. They cannot remove the need for sound control design, shared definitions, reliable data, stakeholder agreement, and clear accountability.

What CCM 3.0 Offers CISOs

For the CISO, the primary benefit is a shorter path from environmental change to reliable assurance because the security organization can define a relevant test, validate it, deploy it, and execute it across the enterprise estate with far less delay.

When a new vulnerability is announced, the organization can identify the affected technology, construct a compensating control, evaluate in-scope systems, determine exposure, and provide remediation guidance. The resulting evidence can support prioritization, incident response, risk acceptance, executive reporting, customer assurance, and audit.

The CISO can get:

• earlier visibility into emerging exposure;
• continuous evaluation across larger system populations;
• closer alignment between security operations and GRC;
• repeatable findings supported by traceable evidence;
• more focused use of security engineering capacity;
• clearer visibility between formal audit periods;
• faster adaptation to new technologies and threats; and
• a governed model for using agents within assurance processes.

The broader benefit involves decision quality and decision speed because the CISO can understand which assets are affected, how serious the exposure is, which controls require attention, and where remediation should begin.

This model can also strengthen the relationship between security and GRC because security teams receive assurance processes that reflect the current operating environment, and GRC teams gain access to operational evidence that supports stronger control evaluations and more useful conversations about risk.

Two Questions To Ask About Agentic GRC

As the term “agentic” becomes widely used, enterprise buyers will need to look beyond the conversational interface and examine the architecture that supports it.

Before adopting an agentic GRC capability, here are two questions I’d recommend asking:

• What do these agents rely on? What trusted building primitives, components, data sources, and capabilities support the agent?
• What runtime do you provide? How is the generated control deployed, executed deterministically, maintained, monitored, and scaled in production?

These questions help distinguish a useful demonstration from an enterprise assurance capability because the value of an agentic system depends on the reliability, governance, and scalability of the environment surrounding the model.

When a vendor or internal team describes a capability as agentic, the central questions should concern the runtime, the control primitives, the evidence chain, and the operating model. Those elements determine whether the agent’s output can become part of a trusted control environment.

Toward Declarative GRC

The longer-term opportunity is a declarative model for GRC in which a Security GRC professional describes the intended control state and the system continuously reconciles that intent with the observed state of the enterprise.

In this model, the organization defines the control objective, scope, evidence requirements, evaluation criteria, and expected response. The system translates that intent into an executable control, evaluates the operating environment, records the supporting evidence, identifies deviations, and initiates the appropriate workflow.

This would bring Security GRC closer to the systems it governs because controls would become machine-readable, evidence would be collected continuously, and assurance could respond as the enterprise changes.

For Security GRC professionals, this creates a path toward greater technical leverage, stronger ownership of control outcomes, and more time for the judgment-intensive parts of risk and assurance. For CISOs, it creates a shorter and more dependable path from environmental change to an enterprise-wide understanding of control impact.

This is the vision behind CCM 3.0:

• Agents help people describe, design, and adapt the controls the organization requires, and
• Governed infrastructure executes those controls consistently across the enterprise.

As applications, infrastructure, and security operations become increasingly agentic, GRC will need an operating model capable of governing them at a comparable speed.