AI Governance Layer Deployed But Unconfigured

This page describes the nowisor-ai-governance-unconfigured check from the nowisor Instance Scan Pack v1.2.0 (ai-agent-security group, spec AIG-008). The check flags AI Control Tower or an equivalent governance layer present with an empty registry, no active policy records, or coverage short of the active agent estate.

What this finding means

A governance layer is deployed on this instance and is not doing governance work. The check looks for three problems:

• the registry is empty
• the policy table has no active records
• the registry holds fewer entries than the active agent estate

Governance of governance, stated precisely. Native tooling gives customers controls; this check verifies the controls are configured. It reports on the governance layer rather than through it, and reproduces nothing the layer itself reports - no risk scores, no observability, no policy content.

The precondition mirrors its sibling. A layer must be present for this to fire; on an instance without one the check reports not_applicable. The registry-coverage check does the same in reverse. Between them, an absent layer produces one honest N/A pair rather than two findings about the same gap: deployed-and-empty is this check's finding, deployed-and-incomplete is the other's.

Why it matters for your compliance

NIS2 Article 21(2)(f) requires policies and procedures to assess the effectiveness of your measures. A shelfware governance layer is the textbook example of a measure that exists and underperforms - and 21(2)(f) is precisely the obligation to notice.

NIS2 Article 21(2)(a) covers the risk-analysis policy the layer is meant to implement.

ISO 27001 A.8.16 (monitoring activities) and A.5.15 (access control) are the control halves. DORA Article 9(4)(a) requires a documented policy - an empty policy table is the absence of one, in the system that is supposed to hold it.

The attack path

False assurance is the whole risk. The organisation buys a governance layer, sees a dashboard, and reasonably concludes the estate is governed. An empty registry renders as a clean dashboard, not as an error - nothing on screen distinguishes "nothing to report" from "nothing configured".

Why an attacker prefers this to no tooling. A deployed-but-empty layer manufactures confidence. Defenders check the dashboard, see green, and stop looking. With no tooling at all, at least nobody believes the estate is covered.

It decays back. Governance configuration is not a one-time state. Every reorganisation orphans owners, every new agent that skips registration widens the gap, and every policy left inactive after a pilot stays inactive. This belongs on a schedule, not in a project plan.

How to fix it

Step 1 - populate the registry so every agentic entity has an entry with a named owner. The registry-coverage check enumerates exactly what is missing.

Step 2 - activate the policy set. An empty policy table means the layer is observing without governing.

Step 3 - confirm observability covers every active agent class the finding lists, including the inbound external-agent surface if present.

Step 4 - set a review cadence. Coverage decays every time somebody builds an agent without registering it, so a passing result today is not a durable one.

How this check stays honest

Every check in the ai-agent-security group is enumeration-driven: table and field names are resolved from sys_db_object and sys_dictionary on your instance, never asserted from a hardcoded list. The sn_aia namespace is paid-SKU gated and cannot be verified against a ServiceNow developer instance, so asserting its identifiers from documentation alone would risk exactly the fabricated-identifier problem this codebase audits for.

Two consequences you will see in the output:

• An absent plugin produces not_applicable, never a pass. The absence of Now Assist is not a security win; it means the control is out of scope. A check that silently passed would let a customer believe they were assessed on something that was never examined.
• An unresolvable field produces not_applicable, not a finding. Where the release does not expose the column a check needs, the check says so and names it. Firing anyway would flag healthy instances on releases we simply cannot read.

All detection is read-only. No record contents are inspected or transmitted.