AI Control Tower Registry Coverage Gap

This page describes the nowisor-ai-control-tower-coverage-gap check from the nowisor Instance Scan Pack v1.2.0 (ai-agent-security group, spec AIA-009). The check flags agentic entities running in the instance but absent from the AI Control Tower registry. Control Tower being deployed is a hard precondition - without it the check reports not_applicable.

What this finding means

AI Control Tower is deployed on your instance, and the estate contains agentic entities its registry does not know about.

This is governance of governance. Native tooling gives you the control; this check verifies the control is actually covering the estate. It deliberately reproduces nothing Control Tower reports - no risk scores, no observability, no policy content - and answers the one question Control Tower cannot answer about itself: what is running here that was never registered.

The evidence names where each entity was found and where it was expected (found_in / expected_in), so the answer is auditable in a single read. That is deliberate: buyers evaluate agent-security tooling by creating an unregistered agent and timing how long discovery takes to surface it.

Why it matters for your compliance

NIS2 Article 21(2)(f) requires policies and procedures to assess the effectiveness of your security measures. A governance tool with incomplete coverage is the textbook example of a measure that exists on paper and underperforms in practice - and Article 21(2)(f) is precisely the obligation to notice that.

NIS2 Article 21(2)(i) asset management requires the inventory to be complete, not merely present.

ISO 27001 A.8.16 (monitoring activities) and A.5.16 (identity management) both depend on knowing what exists. DORA Article 9(4)(a) requires a documented policy, which an unregistered agent sits outside of.

The attack path

The false-assurance failure mode. The organisation buys a governance layer, sees a populated dashboard, and reasonably concludes the estate is governed. The dashboard is accurate about everything it knows and silent about everything it does not. Coverage gaps are invisible from inside the tool by construction - a registry cannot list what was never registered.

Why an attacker cares. A deployed-but-incomplete governance layer is better for an attacker than no governance layer, because it manufactures confidence. Defenders check the dashboard, see green, and stop looking. An agent outside the registry inherits that blind spot.

Why this check must be N/A without Control Tower. On an instance with no governance layer, reporting every agent as an uncovered gap would double-count a defect the governance-configuration check already reports, and would inflate the finding count with no new information. "You have no Control Tower" is one finding, not N.

How to fix it

Step 1 - triage each uncovered entity. Confirm it is legitimate and has a named owner. The evidence carries sys_created_by and sys_created_on for entities you do not recognise.

Step 2 - register the legitimate ones so the governance layer's inventory matches the instance.

Step 3 - treat the unrecognised ones as unsanctioned deployments. Deactivate and review who created them.

Step 4 - re-run to confirm coverage is complete, then keep this check on a schedule. Coverage is not a one-time state; it decays every time somebody builds an agent without registering it.

Note on matching. Comparison is by normalised name, so an asset registered under a different label will still appear. Confirm each entity before acting.

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.