LLM Connection Terminating Outside The EU
This page describes the
nowisor-ai-llm-data-residencycheck from the nowisor Instance Scan Pack v1.2.0 (ai-agent-securitygroup, 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:
- Repoint to the provider's EU region where one exists - usually the model id or host carries the pin.
- Where no EU region exists, establish a lawful transfer basis and record the supplier assessment. The endpoint configuration carries neither.
- 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:
- 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.