Shadow AI - Unsanctioned External LLM Endpoint

This page describes the nowisor-ai-shadow-llm-endpoint check from the nowisor Instance Scan Pack v1.2.0 (ai-agent-security group, spec AIA-003). The check flags outbound integrations configured to reach external model providers outside the Generative AI Controller. It discovers the endpoint column from sys_dictionary and matches configured URLs against known provider hosts.

What this finding means

One or more REST messages, connections or connection aliases on your instance are configured to reach an external model provider. That is an undeclared model-data export path: it sits outside the Generative AI Controller's logging and data-handling configuration, and outside whatever data-processing agreement covers your sanctioned route.

Severity is conditional on what the instance can actually prove:

What this finding does not claim. Detection is configuration-based. The check reports what is configured to be reachable, never what was transmitted - a read-only scan cannot observe traffic. The evidence carries detection_basis: configured_endpoint_host_match so nobody mistakes it for proof of exfiltration.

Why it matters for your compliance

NIS2 Article 21(2)(d) - supply chain security. An external model provider reached outside your sanctioned route is an unmanaged supplier relationship in the middle of your data flow.

NIS2 Article 21(2)(a) requires policies on risk analysis and information system security; an export path nobody declared has not been risk-assessed by definition.

DORA Article 9(3)(a) requires the security of the means of transferring data. Article 9(4)(c) limits logical access to approved functions - an undeclared endpoint is unapproved by construction.

OWASP LLM02:2025 (Sensitive Information Disclosure) and LLM03:2025 (Supply Chain) are the direct industry analogues. EU AI Act Article 50 transparency obligations attach where the integration is user-facing.

The attack path

The path does not require an attacker at all - most instances of this finding are well-intentioned engineering. That is what makes it dangerous.

The benign origin. A developer builds a summarisation feature. They create a REST message to a provider, paste an API key into a credential record, and ship. Nothing about that is anomalous to ServiceNow: it is a normal outbound integration.

What it costs you. The prompt bodies never appear in the Gen AI Controller's logs, so you cannot answer "what did we send them?". The provider's retention and training terms were never reviewed, so you cannot answer "what did they keep?". Under GDPR/DORA questioning, both answers are required and neither exists.

The attacker's version. An attacker who can create a REST message has a low-observability exfiltration channel that looks exactly like the benign case above - which is why the benign cases must be cleaned up first. Every legitimate undeclared endpoint is cover for an illegitimate one.

How to fix it

Step 1 - identify owner and purpose for each endpoint listed in the evidence (endpoints[] names the table, the column, the sys_id and the matched host).

Step 2 - route it through the Generative AI Controller or your sanctioned connection alias, so prompts, responses and data-handling settings are logged centrally.

Step 3 - confirm the paperwork. Verify a data-processing agreement covers the provider and that the payload is permitted to leave the instance and the jurisdiction. Pair this with the data-residency check if you are in an EU-regulated scope.

Step 4 - retire what is not needed. Deactivate the integration and revoke its credentials. An unused REST message with a live API key is still a live export path.

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.