Autonomous GRC and the new shape of the compliance program

The term "autonomous GRC" is having a moment. Vendors who shipped a chat sidebar last quarter are claiming it. Buyers are asking what it means. Auditors are quietly preparing to push back on whatever it ends up meaning. As the dust settles, the term is going to either anchor a real category or become marketing noise.

We think it should mean something specific. This post is our working definition, the architecture that makes it real, and what's still left to build.

A working definition

Autonomous GRC is a compliance program where the platform operates the day-to-day lifecycle and humans gate the decisions that matter.

Unpack that:

• "Operates the day-to-day lifecycle" — not just automates a few tasks. Authoring, evidence operations, assessment work, vendor reviews, audit prep, incident workflows, all of it. End-to-end, not 20% of it.
• "Humans gate the decisions that matter" — the human is in the loop, but at the right altitude. They're approving direction, not typing first drafts. They're calibrating risk, not chasing screenshots.
• "Program" — not a tool, not a feature, not a chatbot. A program is the full operational scope: people, policy, framework coverage, evidence cadence, vendor management, audit posture.

That definition is intentionally aggressive. It excludes any current platform that markets itself as autonomous-something but actually requires a full-time compliance manager to operate. It also sets a bar that no platform fully clears today — including ours, honestly. We're closer than the incumbents, but autonomous GRC is a road we're on, not a place we've arrived.

What autonomous doesn't mean

Three common misreadings worth heading off:

Autonomous doesn't mean unattended. The point isn't to remove the human. The point is to move the human from "first draft author" to "reviewer and decider." A program with no humans isn't autonomous; it's negligent.

Autonomous doesn't mean AI-everywhere. The reliable parts of an autonomous program — evidence collection, control enforcement, audit trail generation — should be deterministic code, not model outputs. The role of AI is to author and maintain that code, not to be that code. (We've written more about this distinction in agent-first GRC.)

Autonomous doesn't mean no oversight. Autonomous programs have more observable oversight than legacy programs, not less. Every plan is captured. Every approval is logged. Every tool call is recorded. The trade-off is that the oversight has to be designed deliberately, not assembled in the last two weeks before an audit.

The architecture that makes it possible

An autonomous GRC program has six load-bearing pieces of architecture. Anything calling itself autonomous should have all six.

1. An orchestration runtime. Something that can take a goal, plan against it, execute steps, and surface decisions. Most GRC platforms don't have this — they have workflow engines (rules + triggers) or chat interfaces (model + prompt), but not a true orchestration runtime that can reason about plans. Without this, "autonomous" is just better automation.

2. Agents with skills. Specific, tested, scoped units of work. "Draft policy" is a skill. "Map controls between SOC 2 CC and ISO 27001 A.5" is a skill. A skill is not a chatbot — it has known inputs, known outputs, known failure modes. You can audit a skill the way you can audit a function.

3. Plans, step-runs, and approvals as first-class objects. Not log events. Not opaque traces. First-class objects that you can list, query, replay, and audit. A program where you can't show me the last 50 plans the agent executed is a program where "autonomous" is a marketing claim.

4. Deterministic recipes for the reliable work. The work that has to be the same every time — pulling cloud config, computing access reviews, checking MFA enforcement — runs on inspectable code, not on the model. The agent authored the code, but the agent isn't in the execution path. This is the property that makes the program auditable.

5. Safety floors at the runtime level. Hard limits the agent can't talk its way around. No PII out. No destructive actions on prod. No calling tools that aren't on the workspace allowlist. Implemented at the orchestration layer, not in the prompt. (Prompts are advisory. Floors are walls.)

6. Audit trail as a side effect. Every plan, step-run, approval, and tool call is captured by default. The audit packet isn't something you assemble before the engagement. It's a query you run.

A platform that has all six is autonomous-ready. A platform that has fewer is closer to "AI-assisted GRC" — useful, but not autonomous.

What changes for the operator

When the program is autonomous, the operator's calendar reshapes.

More time on judgment, less time on production. The compliance manager who spent 60% of their week assembling artifacts now spends 60% of their week deciding what the program should cover, which findings matter, where the risk appetite should sit, what to push back on. The work is higher-leverage and harder. Some people love it. Some people don't — they liked the production work.

More approvals, fewer first drafts. Approvals are short, frequent, and focused. The skill is reviewing well — knowing when to push back on a draft, when to ask the agent to redo a plan, when to override a safety floor. This is a calibration skill. It takes practice.

More program design, less program operation. When the operator stops being the bottleneck on every artifact, they can think about the program at the scope level. Are we covering the right frameworks? Should we add HIPAA? When does PCI ROC start? What's our vendor risk threshold for high-tier subprocessors? The work shifts up a level.

More auditor conversation, less auditor preparation. Because the audit trail is a side effect, the operator can spend audit season having actual conversations with the auditor about scope, judgment, and findings — instead of running around assembling PBC items.

What changes for the team

The compliance team headcount profile changes too.

Fewer junior associates doing production work. The "I'll assign this to a junior compliance analyst" reflex doesn't survive autonomous GRC. Junior production work — assembling evidence, drafting first responses, writing initial narratives — is the work the agent now does. You don't need three associates for that. You need a smaller team of more senior reviewers.

More leverage from each senior practitioner. A senior GRC engineer running an autonomous program can carry the program scope that used to require a team of four or five. That's the headline economic argument, and it survives a careful look.

A new kind of role: the program designer. Someone whose job is to define what the agent is supposed to do, calibrate the safety floors and approval thresholds, and tune the program as the company changes. This is GRC-adjacent but isn't quite traditional GRC — it's more like a platform engineer for compliance. We're seeing this role emerge in early-mover companies.

What's still left to build

Honest assessment of where the gaps are, as of mid-2026:

Cold-start onboarding is still slow. Even with the best platform, getting an agent productive on your specific environment, frameworks, and risk appetite takes weeks. We're working on this. So is everyone else serious.

Cross-platform agent governance is immature. If your company has agents from five vendors operating in your environment, governing them is currently a manual exercise. AI Governance modules exist (ours included), but the cross-vendor story is early. Standards like the EU AI Act and ISO 42001 will force this to mature.

Auditor education is mid-maturation. Big-four auditors and the major mid-market firms are catching up fast. Some smaller firms are still puzzled by recipe-based evidence. This will be table stakes by 2027.

Tooling for the long tail of frameworks lags. SOC 2, ISO 27001, HIPAA, PCI: well supported. CMMC, FedRAMP, IRAP, SAMA: less so. Programs running unusual frameworks still do more manual work than they should.

What we're betting

We're betting that "autonomous GRC" will eventually be the default, and that platforms that don't have the six architectural pieces above will be relegated to legacy spreadsheet replacements over the next two years. That's an aggressive prediction. It might be wrong on timeline. We don't think it's wrong on direction.

If you're running a compliance program and you want to see what the architecture looks like in real software, the AI page is the most direct read. If you want to see how it shapes pricing, the pricing page breaks down the platform, modules, and token economics. Or start a trial — fastest way to decide whether the thesis lands for you.

Related reading on this site: agent-first GRC (the foundational argument) and GRC engineering (the practitioner-level mechanics).