On-prem AI security tools that still phone home

Originally published on AFOKUS Research:

https://afokus.com/research/on-prem-ai-security-tools-that-phone-home/

Canonical source: the URL above. Republish with attribution; do not point canonical at the homepage.

How on-prem AI security installers still egress for license, packs, findings, and support, and how to catch it before you buy.

Published August 13, 2026 · Updated August 21, 2026

Tags: on-prem, zero-egress, procurement

By AFOKUS Research

---

On-prem is a placement decision. It is not a data-path decision.

A product can install on a host you own and still send prompts, findings, license checks, or crash dumps to a vendor network the moment a scan starts. Buyers who treat “on-prem” as “nothing leaves” discover that gap during a residency review, not during the demo.

This note is for security and procurement teams who need an assessment to stay inside a boundary they control. You do not need to buy anything to use it.

What on-prem usually hides

Vendors use on-prem to mean the scanner binary runs on your hardware. That is true and incomplete.

The incomplete part is the control plane. Many installers still reach out for:

• license validation and feature flags
• attack pack or model updates
• finding storage and dashboards
• support tunnels
• crash and usage telemetry

Each path can carry target metadata. Prompts, tool schemas, hostnames, and screenshots are common.

If any of those leave the boundary, the engagement is a hosted workflow with a local agent. The installer location does not change that.

Five egress paths to demand in writing

Ask for a packet-level data-flow diagram. A slide titled “air-gapped option” is not a diagram.

License and feature flags. Some products refuse to start, or drop modules, unless they can reach a vendor control plane. Offline license files exist. Many vendors do not ship them by default.

Attack packs and models. A local engine that downloads new probes mid-run is not offline. Media-based updates that you approve are the honest version of this.

Finding upload. If the only way to read a report is a SaaS portal, findings left your boundary before you did. Local PDF or JSON export with no vendor login is the test.

Support tunnels. Remote assist that mirrors logs or the desktop can move the most sensitive artifacts out first. Treat this as in-scope even when it is “optional.”

Crash and usage telemetry. Default-on telemetry often includes hostnames, versions, and prompt fragments. Default-off, inspectable, and disableable is the minimum.

Any one of these can fail a zero-egress review. Several at once is common.

A lab test that does not need the vendor on the call

Run this on a host you control, against a non-production target.

1. Install from media you received, not from a live download you cannot pin.
2. Disconnect every network path, or allow only DNS you can observe and log.
3. Start a short assessment run that should produce one finding.
4. Export the report to local media.
5. Re-run the same proof after a mock fix, still offline.

If the product stops, waits on a license server, cannot export, or cannot re-prove the fix, treat the on-prem claim as incomplete.

Watch the network while it is still connected once, before the unplug test. Unexpected destinations are as useful as a failed unplug.

Record the destination, the moment it fired, and whether the product continued after you blocked it. A product that retries forever is still a phone-home product. A product that degrades a feature and says so in the log is easier to contract around.

Keep names out of the lab notes unless the buyer already has them. Method notes travel better than a one-off screenshot. File the notes with the procurement record.

How this shows up in regulated buying

Residency and sovereignty rules care about where assessment artifacts live, not where the binary was copied from.

A findings report is often more sensitive than the system under test. It is a curated index of credentials, paths, and proof. If that index is stored or processed in a vendor cloud, the assessment itself becomes a data-processing decision.

This is not a claim about every regulator. It is a buying test. If you cannot show where prompts and findings went, you cannot defend the engagement to an auditor who asks.

Finance and payments buyers usually hit this first because assessment output looks like production data once it contains credentials and paths. The same test applies to any team that promised a customer or a board that test data would not leave a region.

Related live notes on afokus.com:

• What zero-egress means for AI pen tests
• Zero-egress AI red teaming checklist
• Questions before SaaS AI security testing

What a defensible on-prem claim looks like

A defensible claim is boring and testable.

• Updates arrive on media you approve, with versions you can pin.
• License works after install with the cable unplugged.
• Findings stay on disk you own, in a format an engineer can reopen later.
• Proof of fix reuses the same offline path that produced the finding.
• Telemetry is off unless you turn it on, and you can read what it would send.

If a vendor cannot walk that list without exceptions, write the exceptions into the contract or pick a different tool.

Exceptions are not automatically disqualifying. An update channel that runs only during a maintenance window you schedule is different from a silent upload of findings. Write the difference down. If the vendor will not write it down, that is the answer.

Closing

On-prem is useful. It is not a substitute for a data-path review.

Use the unplug test before you sign. Use the five egress questions in every RFP. Keep the findings file on media you control.

AFOKUS Red is built for assessments on infrastructure you control, including zero-egress conditions. Details: https://afokus.com/products/red/

If you want a current-state review against one framework and one environment, book a remote gap assessment. AFOKUS provides a written gap review and readout. AFOKUS does not issue ISO, SOC 2, NCA, or SAMA certificates.