Agentic Features Active On Unmasked Sub-Production Instance

This page describes the nowisor-ai-subprod-unmasked-posture check from the nowisor Instance Scan Pack v1.2.0 (ai-agent-security group, spec AIA-004). The check emits INVESTIGATE when three posture signals coincide: a non-production instance identity, an active agentic surface, and no data preservers. It never escalates to CRITICAL.

What this finding means

This instance identifies as non-production, has an active agentic surface with entities present, and has no data preservers configured.

The claim boundary is the point of this check. A connected scan cannot observe whether a clone was masked. It cannot read what the clone process did, and sampling record contents to hunt for real PII would be both unreliable and an unacceptable thing for a security scanner to do to your data. So the check detects risk posture only:

All three together produce INVESTIGATE. No unmasked sensitive data has been observed and none is asserted. Where the preserver table cannot be read at all, signal (c) is missing and the check stays silent rather than guessing.

Why it matters for your compliance

ISO 27001 A.8.33 (test information) is the control this maps to most precisely: test information must be appropriately selected, protected and managed. A clone carrying production data into an environment with looser controls is the canonical A.8.33 concern.

NIS2 Article 21(2)(e) covers security in development and maintenance environments, which is exactly what a sub-production clone is.

DORA Article 9(3)(d) requires protecting data from risks arising from data management, including poor administration - an unmasked clone is a data-management risk by definition.

OWASP LLM02:2025 (Sensitive Information Disclosure) covers the AI half: agentic features on the clone can send whatever they can read to whatever endpoint is configured for testing.

The attack path

Why the combination matters even unproven. Sub-production clones routinely carry production data - that is usually the point of cloning. Agentic features on such a clone will send whatever they can read to whatever model endpoint is configured for testing, under looser controls, with fewer people watching, and often with a test API key whose retention terms nobody reviewed.

The access asymmetry. Non-production instances typically have wider developer access, weaker MFA enforcement, and less monitoring than production - while holding the same data. Adding an agentic export path to that environment is the highest-leverage change an attacker could wish for, and it is usually made by the organisation itself.

Why we refuse to escalate. Over-claiming here would destroy credibility with exactly the buyer this module targets - a CISO who will clone a sub-prod instance and check our claim. A finding that says "CRITICAL: unmasked PII sent to OpenAI" without evidence is worse than no finding, because it makes every other finding suspect.

How to fix it

This finding asks a question; it does not assert a breach.

Step 1 - confirm your clone process masks or excludes the sensitive tables named in sensitive_tables_present.

Step 2 - if masking is handled outside data preservers - a clone-exclude list, a post-clone script, a masking tool - record that and close this as accepted risk. The check cannot see those mechanisms, and says so.

Step 3 - if it is not handled, configure data preservers or a masking step before the next clone.

Step 4 - independently, check which model endpoint the agentic features on this instance reach. A test endpoint is still an external data path - pair this with the shadow LLM endpoint check.

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.