When On-Prem Still Leaks: Four Real Paths

The acceptance test for the new assistant was a walk past two racks in the state data centre. The GPUs were there. The VLAN was there. The architect signed the commissioning note. Two months later a junior officer pasted a live beneficiary row into the prompt box because the demo data had been too polite. The row left the building through a path nobody had walked: the product's timeout fallback, which called a hosted model when the local queue was full.

On-prem had been scored as equivalent to air-gapped in the evaluation sheet. It is not. On-prem means the primary compute is in a facility you can visit. It does not mean the software has given up the internet. Most commercial on-prem agents are designed as occasionally connected products. The connection is where the leak lives.

This teardown names four paths that keep appearing after the rack photo has already been taken. Close them, or write why you accept them. Do not invent a fifth path called we are on-prem so it is fine.

Path one: identity that lives somewhere else

Agents need users. Users need an identity provider. The fastest way to go live is to point the product at a cloud IdP the department already uses, or at the vendor's own tenant because the installer offered a QR code. Every login then exports officer identifiers, device signals, group membership and often the department's email domain.

That export can be acceptable. It is still a transfer of personal data about staff, and sometimes about the citizens those groups imply. A group named disability-pension-approvers is not an anonymous tag.

The leak gets worse when the product maintains a second identity channel for licence seats or for vendor support. You think you federated to NIC or to your campus IdP. The product also created users in a foreign tenant so the success team could log in and help.

Path two: the updater that talks too much

On-prem software still wants patches. The honest design is a signed artefact you pull onto an internal registry and push inward. The common design is a daemon that calls home, learns that a version exists, and uploads a support bundle so the vendor can tell you whether it is safe to apply.

Support bundles are where on-prem goes to die. They include configs with hostnames, last-error traces with request fragments, and sometimes a recent-conversation sample the engineer thought would be helpful. If the updater can build that bundle without an officer clicking yes, you do not control the path.

Path three: the helpful human with a tunnel

When the assistant hallucinates a scheme, someone will ask the vendor to look. The vendor will ask for a tunnel. The tunnel will be temporary. Temporary tunnels have a way of becoming installed agents with a standing certificate.

Even a clean jump-box session leaks if the engineer copies a database extract to their laptop to reproduce a bug. The laptop then syncs to a personal OneDrive. You will find this out during an exit, not during a review.

Write the support path before go-live, including who escorts, what they may copy, and how the copy dies. If that paragraph does not exist, the helpful human will invent a path under pressure, and you will discover it in an exit review when their laptop image still holds a database extract.

Path four: silent fallback and hidden tools

This is the path that failed the SDC in the opening scene. Local model busy. Queue full. GPU down for a driver update. The product is written to protect the demo, so it calls a hosted endpoint, a hosted OCR, a hosted speech model, or a hosted guardrail. The UI does not change. The legal object does.

Four paths. Four owners. If a path has no owner, it is open.

Path	What leaves	Closing move
Identity	Staff identifiers, groups, sometimes citizen-implied roles	Your IdP only; no vendor tenant; review group names
Updater	Version plus optional support bundle	Internal registry; bundles only on written request
Support human	Whatever they can see or copy	Your jump box; no standing tunnel; laptop ban on extracts
Silent fallback	The full prompt and attachments	Fail closed; alert; no hosted tool in the graph

Objections

We will catch this at VAPT. A yearly VAPT that does not include a prompt containing a canary string and a crash-plus-update soak will not catch these paths. Add those two tests to the scope.

Our NIC/SDC policy already forbids outbound. Then show the deny logs. Products that cannot live without outbound will break, and someone will punch a hole to make the demo work. The hole is the leak.

Air-gap is the only answer. Air-gap is an answer. It is also an operations tax. Close the four paths first. If a data class still cannot live with residual risk, then air-gap that class, not the entire estate.

Canaries and the acceptance test that belongs in the PO

A commissioning photo of a rack is not an acceptance test. Write four canaries into the purchase order. A dummy PAN-shaped string in a prompt. A crash. A licence-renewal window. A forced local-model failure. After each, the proxy log is empty of unlisted hosts and the canary string is absent from every outbound body.

Pay the second milestone only after those four canaries pass. Vendors who complain are telling you the product is occasionally connected. You can still buy it if you accept a listed path. You should not pay as if you bought an isolated box.

Repeat the four canaries after the first patch. Updaters restore defaults. A product that passed in March and phones home in April failed the year, not the month.

A 30-day path hunt, then 60 days of closing

1. Week 1: identity diagram, including every tenant the product created.
2. Week 2: updater and registry review; intercept one support-bundle attempt.
3. Week 3: support-path tabletop; revoke standing tunnels.
4. Week 4: fail the local model on purpose; watch for fallback.
5. Days 31–90: close what you found; amend the MSA; repeat the four tests after the next patch.

What goes in the file

Four test records with dates, the deny-list from the proxy, the identity diagram, the support runbook, and a sentence that says fail closed. If the commissioning note only has a rack photo, commission is not finished.

On-prem Prcept deployments should fail closed when a local component is down. If a path still wants the internet, it should be listed before install, not discovered after a canary string leaves.

How to defend this in the file

A P1 CIO/CTO will be asked to explain “When On-Prem Still Leaks: Four Real Paths” to a secretary who has ten minutes. Do not start with the model. Start with the store, the hop, the clause, or the residual risk. “on premise data leakage AI” is a search phrase. The file needs a decision.

On-prem is a location. Leakage is a path. Four paths keep showing up after the servers are already in the data centre. DPDP does not define sovereign AI. Transfers can be lawful and still be a bad idea. Sector circulars can be stricter than DPDP. Write which instrument you are using.

If you cannot name the Data Fiduciary, the processor, the location of traces, and the erasure method, you are not ready for production personal data — whatever the architecture PDF says.

• One sentence on lawful basis or the procurement rule you are invoking.
• One sentence on where prompts, embeddings and logs live.
• One sentence on who can compel the operator.
• One artefact: packet capture, DPA schedule, or deletion certificate template.

Close this loop before the next CAB

Put “When On-Prem Still Leaks: Four Real Paths” on the next change-advisory or bid-opening agenda as a single line item with an owner. If it cannot earn a line item, it will not earn a control. The owner should be a P1 CIO/CTO, not “the vendor.”

Revisit the item when the model, the GeM term, the region, or the SI changes. “on premise data leakage AI” is not a one-time workshop. It is a watch item. Date the last check. Unsigned watch items are souvenirs.

What the next noting must contain

“When On-Prem Still Leaks: Four Real Paths” belongs in a file, not only in a search result. A P1 CIO/CTO should be able to point at one artefact that proves “on premise data leakage AI”: a packet capture, a processing schedule, a scored evaluation row, a dated notice, or a refusal rule. If the only evidence is a slide, you have a heading.

On-prem is a location. Leakage is a path. Four paths keep showing up after the servers are already in the data centre. DPDP 2023 does not define sovereign AI and does not write a blanket localisation rule for every model hop. CERT-In’s 28 April 2022 directions still set specified incident clocks and 180-day log retention in India for in-scope events. The November 2025 AI governance text is guidance, not a statute. A Proprietary Article Certificate, when it is lawful, lives in GFR Rule 166 — not Rule 161.

Write three dated sentences under C1 Sovereignty & Data Residency: what was decided, which designation owns it after the next posting order, and when it will be re-checked. Unsigned sentences are souvenirs. Dated sentences are controls.

• Name the designation that owns “on premise data leakage AI”, plus a deputy.
• Attach one artefact a stranger can open next year.
• Name the instrument you are actually using — Act, direction, GFR clause, GeM term, or guideline paragraph.
• Leave unsourced percentages, GMV slides and house forecasts out of the noting.
• Revisit when the model, the SI, the notice, the region or the posting changes.