The agentic GRC
operating model.

Agentic GRC is often framed as policy generation or automated compliance. I see a more useful role: turn control intent into repeatable work. Discover evidence, evaluate defined conditions, route exceptions, prepare a decision packet and preserve the resulting record. The agent accelerates the loop. Authority remains explicit.

Design around bounded roles

A single broad “GRC agent” combines too many trust assumptions. Specialised roles make permissions, inputs, outputs and failure modes easier to test. An evidence agent can collect approved artefacts; a control agent can evaluate a defined condition; a workflow can prepare an access-review packet; an exception monitor can detect overdue decisions.

Every role needs an authority profile: systems it may read, artefacts it may create, state it may change, decisions it may recommend, actions it may never perform, escalation recipients and mandatory log fields.

How to read the diagram. READ, ASSESS, DECIDE and ASSURE are authority paths, not autonomous-agent maturity levels. Information can move forward, but permissions do not automatically propagate with it. The main control boundary is between producing an assessment and changing authoritative state.

What it does not claim. The figure does not require four separate models or four software products, and it does not claim that every decision needs manual approval. Low-risk deterministic actions can be automated when authority, limits and rollback are defined. The model claims that material decision rights should remain identifiable even when execution is automated.

Distributed cognition is not distributed authority

Specialisation can justify multiple workers without requiring a decentralised decision system. A practical default is central decision authority with distributed cognition: parallel specialists collect or analyse evidence, an orchestrator or synthesis layer reconciles their outputs, and a policy or accountable human gate controls consequential transitions.

This distinction matters because delegation is often mistaken for authority transfer. A specialist may possess a capability and still be ineligible to use it in the current context; an eligible capability may still require separate authorization; and an authorized recommendation does not automatically carry execution authority. In compact form: capability possession is not eligibility, capability authority or execution authority.

Separate recommendation from action

An agent may compare a requirement with configuration and recommend that a release gate remain blocked. That does not mean the same identity should be able to change production access, close an audit finding or accept risk. Enforcement should use service identities, approval states and event records rather than relying on prompt language alone.

This boundary has established analogues. ISO/IEC 27001 provides a risk-based information-security management baseline. NIST SP 800-53 includes separation-of-duties and audit/accountability control families. For high-risk AI systems in scope, EU AI Act Article 14 requires effective human oversight and the ability, as appropriate, to disregard, override or reverse system output. Those sources support bounded authority. They do not prescribe this exact agent architecture.

Human oversight is a qualified control

A human approval step is not evidence that effective oversight occurred. Mitchell, Ghosh and Passi argue that sustained automation, approval fatigue and overreliance can degrade the cognitive conditions on which oversight depends. Their paper is a position paper rather than an end-to-end validation, but it sharpens the control requirement: reviewer attention, competence, independence and access to evidence are part of the control design.

This changes the design target from “put a person in the loop” to “route scarce human attention to the decisions that require judgement, after machine-verifiable checks have removed routine noise.” Oversight quality should then be measured separately from task-success or user-satisfaction metrics.

Engineer the evidence trail

An AI-generated statement is not automatically audit evidence. A material recommendation should carry provenance: source reference, retrieval time, version or commit, applicable control, workflow/model version, result, known limitations, reviewer and final decision. The objective is replayability of the decision context, not deterministic reproduction of identical model wording.

Structured records are important here. Control IDs, risk tier, gate state, exception class, approval identity and artefact hashes are easier to query and test than free-form summaries. Natural language remains useful as an explanation layer.

Recent benchmark work strengthens this point. EG-VQA demonstrates that answer correctness can diverge from evidence grounding in multimodal reasoning, while ExtractBench separates schema-valid extraction from complete, source-grounded enterprise document extraction. These are different domains, but both support the general qualification rule: correct output ≠ evidence-grounded qualified outcome.

The EU AI Act provides a useful legal example for systems within its scope: Article 12 requires logging capabilities for high-risk AI systems, while Articles 13 and 14 address transparency and human oversight. This should not be generalized into a claim that every internal GRC agent is a high-risk AI system.

Quality-gate the decision packet

More context is not automatically better context. A retrieved finding can contain the correct location or control reference and still carry a misleading diagnosis, stale assumption or weak solution direction. Passing every generated finding downstream can therefore reduce decision quality rather than improve it.

For material decisions I prefer a structured packet: evidence and location → explanation → root cause or control condition → proposed treatment → dependencies and impact → quality gate → decision. Low-quality or contradictory findings should be rejected, returned for repair, or replaced by a safer fallback instead of being injected merely because they are available. The governing principle is simple: retrieval result is not actionable diagnostic evidence, and more context is not proof of a better outcome.

Normalize controls before automating them

Agentic GRC becomes harder to govern when every standard or regulation is implemented as an independent checklist. Malcolm Shore's TACO proposal provides a useful practitioner pattern: normalize overlapping requirements from ISO/IEC 42001, NIST AI RMF, the EU AI Act and ISACA guidance into common control objectives while preserving mappings back to each source.

This is not a substitute for applicability analysis or source-specific compliance testing. The useful architecture boundary is normalized control ≠ originating obligation. TACO also distinguishes process maturity from control effectiveness, which is important for assurance: a mature process is not automatically an effective control, and an effective point control does not establish a mature management system.

Hard stops and failure modes

A hard stop is a system state that the agent cannot waive. Examples include a missing required approval, unresolved critical finding or prohibited action. Whether a particular condition deserves a hard stop is a risk decision, not a universal rule.

Failure analysis must also include the automation itself: stale evidence, source substitution, excessive permissions, prompt or tool injection, incorrect policy version, model drift, unavailable dependencies, duplicated actions and automation bias by reviewers. Human approval is not a sufficient control if the reviewer cannot understand the evidence or routinely rubber-stamps the recommendation.

Claim boundaries

• Established: organisations need risk management, traceability and appropriately assigned oversight; separation of duties and auditability are established security/control patterns.
• Supported: separating assessment, approval and execution reduces concentration of authority and improves auditability; current research also supports quality-gating diagnostic context, distinguishing evidence grounding from answer correctness, and treating human oversight quality as a control property.
• Hypothesis: specialised GRC agents organised around bounded authority paths and quality-gated decision packets can reduce control-operation cost without reducing accountability.
• Not claimed: that human approval is always safer, that an LLM recommendation is evidence by itself, that multiple specialist agents require decentralised authority, that TACO is a normative standard, or that this model establishes compliance with any standard or regulation.

Limitations and validation

The model has not yet been validated through controlled comparative studies across organisations. Additional workflow roles increase complexity and can create latency or false assurance. Human review can itself fail. Some controls are better implemented deterministically without an LLM. Regulatory classification depends on the actual system, actor, intended purpose and jurisdiction.

A useful falsification test is operational: compare a conventional workflow and an agent-assisted workflow on evidence completeness, exception detection, false positives, time to decision, reviewer overrides and untraceable actions. If the agentic design cannot improve the loop without weakening evidence or authority boundaries, it should not be used.

Evidence notes

• E1: NIST AI RMF 1.0 and NIST AI 600-1 support lifecycle risk management and governance of AI/GenAI; they do not define Agentic GRC.
• E2: ISO/IEC 42001:2023 supports an organisational AI management system and continual improvement; it does not prescribe the four authority paths.
• E3: EU AI Act Articles 12-14 support logging, transparency and human oversight for high-risk AI systems in scope. Applicability must be assessed before treating these as legal requirements for a particular GRC agent.
• E4: NIST SP 800-53 Rev. 5 is an antecedent for separation of duties and auditable events, not an AI-agent architecture standard.
• E5: SHERLOC (Tamoyan et al., 2026) reports that structured diagnostic findings can improve downstream code-repair outcomes while low-quality findings can create negative transfer; this supports quality-gating intermediate diagnostic context, not a direct claim about GRC effectiveness.
• E6: Mitchell, Ghosh and Passi (2026) argue that nominal human-in-the-loop presence is not sufficient evidence of effective oversight. Their intervention inventory is not treated as an experimentally validated integrated architecture.
• E7: EG-VQA and ExtractBench support separating output correctness or structural validity from evidence grounding and completeness in their evaluated domains.
• E8: TACO (Shore, 2025) supports provenance-preserving control normalization and separates process maturity from control effectiveness as a practitioner architecture, not a normative standard.
• Reassessment trigger: changes to AI RMF, EU implementing guidance, agent identity standards, or evidence from deployments showing that the role split or quality gate increases risk or cost without measurable control benefit.

Evidence base

Standards and regulation

• NIST AI RMF 1.0
• NIST AI 600-1, Generative AI Profile
• ISO/IEC 42001:2023
• ISO/IEC 27001:2022
• NIST SP 800-53 Rev. 5
• EU AI Act, consolidated text

Research and benchmarks

• SHERLOC: Structured Diagnostic Localization for Code Repair Agents
• Mitchell, Ghosh & Passi — AI Agents Push Humans Out of the Loop
• Huang et al. — EG-VQA
• ExtractBench — enterprise document extraction benchmark

Architecture and practitioner evidence

• Malcolm Shore — TACO: Integrating Control Objectives for AI