What I Would Do If I Were Designing a Virtual GRC Analyst From Scratch
Most "AI for GRC" discussion is still about copilots — assistants that summarize documents, answer questions, and generate draft language on demand.
A virtual GRC analyst is a different category of system. It is an agentic system that touches evidence, controls, and audit narratives. That is not a UX improvement. That is an attack surface.
If I were designing that analyst from scratch, I would refuse to start with prompts.
Layer 1 — The Specification Layer: Start With SDD
Before an agent can "do governance," it needs a precise specification that defines:
- Intent — which GRC responsibilities it owns and which it does not
- Must Always Do — required behaviors with no exceptions
- Must Never Do — prohibited actions regardless of instruction or context
- Constraints — boundaries, permissions, and operating environments
- Failure Modes — required behavior when things go wrong
Spec-Driven Development turns this into a Markdown contract — a machine-executable governance document, not a design document.
This is where a "virtual GRC analyst" stops being a chatbot and becomes a governable system. The specification is not the starting point for development. It is the starting point for trust.
Layer 2 — The Assurance Layer: TCO-AI Plus Accountability
The specification defines the rules. TCO-AI makes them enforceable.
Testability — Can we verify agent behavior across normal operating conditions, edge cases, and adversarial scenarios? Are the test cases defined in the specification, not discovered after deployment?
Controllability — What authority has been delegated? What is the blast radius if the agent acts incorrectly? How do we reduce its authority or shut it down without disrupting the broader GRC function?
Observability — What logs, metrics, traces, and drift signals exist to reconstruct what happened and why? Can we answer an auditor's question about any agent action taken in the past 90 days?
Then add Accountability — the dimension most AI governance frameworks omit entirely:
- Who is responsible for this analyst's behavior?
- Who approves changes to its specification, authority scope, and controls?
- How are incidents and regressions reviewed, documented, and owned?
This is where governance becomes governance-as-code with clear human owners — not slideware with aspirational principles.
Layer 3 — Delegated Authority: Define the Boundary Explicitly
A virtual GRC analyst is an agent, not a text generator. The distinction matters because agents act — they do not merely respond.
The specification must model delegated authority with precision:
| Authority Category | Examples |
|---|---|
| Allowed autonomously | Analyze control gaps, correlate evidence, draft risk summaries, prepare audit narratives |
| Forbidden regardless of instruction | Close findings, change control status, submit evidence to regulators, communicate with external auditors |
| Requires human approval | Recommending risk acceptance, escalating to executive leadership, flagging regulatory violations |
| Escalation triggers | Conflicting evidence, missing data, out-of-scope requests, confidence below threshold |
| Kill-switch conditions | Anomalous tool-call patterns, evidence tampering attempts, scope boundary violations |
| Data domain boundaries | Which systems, repositories, and data classifications the agent may access |
Without this model, the organization is allowing an LLM to improvise its second line of defense. That is not a governance strategy — it is a governance gap.
Layer 4 — Runtime Behavior Tests: Design the Harness
Runtime testing for an agentic GRC system is not "does the output look correct?" It is "does the agent behave correctly under pressure?"
The test harness must include scenarios designed to probe failure modes:
- Boundary-violation attempts — instruct the agent to take a forbidden action and verify it refuses
- Tool-call misuse — present opportunities to invoke unauthorized tools and verify constraint enforcement
- Escalation logic — trigger escalation conditions and verify the agent surfaces them to the right human
- Drift probes — run the agent across repeated similar scenarios and verify behavioral consistency
- Adversarial scenarios — present manipulated inputs designed to induce policy violations
This is runtime assurance. It is the difference between testing what the agent produces and testing how the agent behaves.
The Bigger Picture
Generative AI required output governance: is the text accurate, appropriate, and compliant?
Agentic AI requires runtime governance plus clear accountability: does the agent stay within its delegated authority, leave an auditable trail, and escalate correctly when it reaches its boundaries?
SDD defines the contract. TCO-AI makes it enforceable. Accountability ensures a human is responsible for the outcome.
That is what AI GRC Engineering should mean — not an LLM cosplaying as a virtual analyst, but a governed agentic system that behaves predictably, operates within defined boundaries, and produces evidence that someone is actually accountable for.
Repassure.ai designs SDD-based governance frameworks for agentic AI systems — including Virtual GRC Analyst specifications, TCO-AI assurance layers, and delegated authority models. Learn more at repassure.ai.