← All KB Checks
HIGHScriptOnlyCheck

LLM Connection Terminating Outside The EU

nowisor-ai-llm-data-residency··Source on GitHub →

LLM Connection Terminating Outside The EU

This page describes the nowisor-ai-llm-data-residency check from the nowisor Instance Scan Pack v1.2.0 (ai-agent-security group, spec AIG-006). The check flags model endpoints pinned to a non-EU region on instances showing an EU-regulated signal; unpinned global endpoints report INVESTIGATE.

What this finding means

Scope gate first. The check speaks only where residency is actually a requirement: it fires only when the instance name carries an EU-regulated signal. On an instance with no such signal it is silent - a non-EU customer using a non-EU endpoint has no finding here, and inventing one would be noise that trains people to ignore the category.

Three outcomes, from the endpoint URL:

Endpoint Result
explicit non-EU region token FAIL
EU region token pass (silent)
no region pin at all INVESTIGATE

The limit is stated in the finding. A URL is not a data-flow proof. A provider may route differently than its hostname suggests, and a global endpoint may or may not process in-region. So an unpinned endpoint is a question, not a verdict.

Why it matters for your compliance

NIS2 Article 21(2)(d) supply chain security covers the provider relationship. 21(2)(h) covers cryptography, which is how cross-border transfers are usually mitigated when they cannot be avoided.

DORA Article 9(3)(a) requires the security of the means of transferring data - and for EU financial entities, where the transfer terminates is part of that.

ISO 27001 A.5.15 / A.8.24 cover access control and cryptography.

EU AI Act Article 50 transparency obligations attach where the integration is user-facing. Residency itself is more directly a GDPR Chapter V and DORA question than an AI Act one, which is why the AI Act mapping here is marked conditional.

The attack path

This is a compliance exposure before it is a security one. The data may be perfectly secure in transit and at rest and still be unlawfully transferred. That distinction matters because the remediation is contractual and architectural, not a hardening task.

Where it usually comes from. A default endpoint. Providers publish a global hostname that resolves wherever they choose, and the EU-pinned variant requires opting in - often with a different model id, a different region tag, sometimes a different price. The default is chosen during a proof of concept and never revisited before production.

Why unpinned is not a failure. Assuming non-compliance from a hostname would produce findings the customer can trivially rebut, and a check that can be rebutted gets switched off. Asking the right question preserves the finding's credibility.

How to fix it

For non-EU pinned endpoints:

  1. Repoint to the provider's EU region where one exists - usually the model id or host carries the pin.
  2. Where no EU region exists, establish a lawful transfer basis and record the supplier assessment. The endpoint configuration carries neither.
  3. Consider an EU gateway that terminates in-region.

For unpinned endpoints: confirm the processing region with the provider in writing, then pin the endpoint if the provider supports it. Record the answer either way, so the next scan is a re-confirmation rather than a fresh investigation.

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:

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