AI in GRC: Citation Is Not Verification

An AI agent reads a security policy, finds a relevant paragraph, and marks a requirement as met. Its explanation sounds plausible and includes a source link. But what change to the requirement or evidence would change that verdict?

Recent research into governance, risk, and compliance (GRC) makes that question unavoidable. A model can give the right answer for the wrong reason, cite a genuine source attached to the wrong system, or confuse a written policy with an effective control. At Secani, we take this as a product design challenge: the connection between requirement, observation, and decision must be open to inspection.

Test whether the verdict depends on the rule

The preprint Verdict Without the Rule keeps a case fixed while deleting, replacing, or negating the governing rule. Across five locally run models and 20 domains, deleting the rule changed the verdict in an average of only 5.3 percent of cases. An unchanged verdict is not automatically wrong: different rules can lead to the same outcome. But a correct answer alone cannot establish that the system used the supplied rule.

That calls for reviewed pairs of cases, not just single-answer benchmarks. If an access-review requirement changes from quarterly to monthly while the available logs stay the same, the assessment may need to change. Rewording the same requirement without changing its meaning should leave the assessment stable. Both reactions matter.

Separate policy coverage from operational proof

PACE separates retrieval of relevant policy passages from assessing whether they cover a security requirement fully, partially, or not at all. Its reported results concern documentation coverage, not whether the described measures work in practice. A policy can demand multifactor authentication for privileged access without proving which accounts are technically protected or which exceptions exist.

ReCon documents an even simpler failure: in some examples, models treat the requirement text included in the prompt as if it were company evidence. Requirements and company records therefore need distinct identities in the data model. A citation should point to the passage that actually supports the claim.

This distinction makes findings actionable. “The policy exists, but technical evidence is missing for three privileged accounts” tells a consultant what to investigate. “Partially compliant” does not.

Check the relationship, not only the source

The pipeline in From Legacy Documentation to OSCAL extracts assets from system descriptions and uses structured threat intelligence to produce compliance artifacts. Its error analysis shows why a real source can still support the wrong conclusion: if an asset is extracted incorrectly, later queries may return genuine vulnerabilities for a different product.

Human review is most valuable at such high-impact links: a product version, system boundary, site, or control assignment on which many later findings depend. An extracted suggestion should remain distinguishable from a confirmed inventory item. When a foundational link is corrected, the derived assessments must be traceable.

Give evidence a scope and a time window

Compliance-as-Code for AI-Driven Identity Systems proposes “evidence contracts” that specify required evidence types, mappings, fields, releases, and observation periods. Its prototype uses synthetic identity workflows, so the study is an architectural example rather than a broad enterprise validation.

A March test report does not automatically prove that a control still works after a September system change. A configuration export for one subsidiary does not establish the state of another. Evidence needs a subject, origin, period, and supported claim. If an integration stops delivering current data, the present state is unproven; that is different from a demonstrated control failure.

Make agreed checks repeatable

Ontological Knowledge Blocks describes a structured intermediate representation of expert-defined obligations, compiled into executable validation rules. The normative interpretation remains a human responsibility. A separate risk-assessment preprint maps observable technical artifacts to ordinal outcomes using versioned rules and checks some consistency properties formally. Neither study establishes a universal compliance engine or empirically calibrated incident probabilities.

The useful principle is to distinguish interpretation from repeatable execution. An agent can suggest criteria from a policy. Once experts approve them, checks such as a missing field, expired observation period, or exceeded threshold should not need a fresh model interpretation on every run. A verdict should record the requirement version, evidence versions, and applied logic.

Reopen decisions when their premises change

Continuous compliance is not a demand to reopen every control after every document edit. It requires knowing which conclusions depend on the information that changed. A corrected heading may have no effect. A new exception for privileged access may affect several frameworks.

The historical decision should remain intact: it may have been justified at the time. But it should not live on indefinitely as a current claim after its premises have changed. Explicit, versioned relationships let consultants focus on assessments that genuinely need another look.

These papers do not prove that GRC can be fully autonomous. Several are preprints or evaluations of narrow prototypes. They do, however, point to a useful standard for Secani: agents should prepare information, propose mappings, explain gaps, and help consultants reach defensible decisions faster.

A green status is an output. The traceable connection between requirement, reality, and decision is the product.