ENT-RN-005Experiment activeExperiment active

Privacy boundary testing for hybrid local/cloud AI

A practical test architecture for hybrid local/cloud AI systems where privacy depends on data classification, routing policy, trace redaction, and egress verification.

privacylocal-first AIegress testingdata minimisation

Technical uncertainty

Whether executable route tests can detect unauthorized egress through prompts, embeddings, traces, caches, model calls, and tool arguments before a workflow is deployed.

Expected evidence

Data classification matrix
Egress path inventory
Boundary test suite
Redaction coverage report

Next experiment

Create synthetic restricted-data fixtures and run them through model routing, trace emission, cache, and tool-call paths to identify boundary violations. The output should include an egress-path inventory, a redaction coverage report, and a failure list showing exactly which boundary was crossed and by which step.

Sources

References

Artifacts

Privacy boundary matrix

Hypothesis

Privacy assurance for hybrid AI requires executable boundary tests that classify data, trace every egress path, and fail builds when sensitive fields cross an unauthorized model, tool, log, telemetry, or storage boundary.

Boundary problem

Hybrid AI creates invisible data paths

A hybrid AI system often mixes local inference, cloud models, vector databases, observability tools, browser agents, email APIs, and analytics. Sensitive data can leave the intended boundary through obvious paths such as model prompts, but also through traces, cache keys, embedding inputs, tool arguments, screenshots, exception logs, and debugging exports.

The privacy control should therefore be executable. A policy document is not enough; the system needs tests that simulate sensitive inputs and prove that routing, redaction, and telemetry behavior match the declared boundary.

Boundary matrix

Classify data before testing egress

Data class	Allowed execution	Disallowed paths
Public	Local or controlled cloud	None, subject to normal retention policy
Internal	Approved cloud or local	Unauthorized vendors, public logs, unmanaged exports
Confidential	Local or controlled private cloud	General-purpose SaaS models, raw telemetry, browser screenshots
Restricted personal data	Local-only unless explicit controlled route exists	Embeddings, prompts, traces, support logs, third-party tools
Secret/regulated	Isolated environment only	Network egress, model API calls, external observability

Boundary test surface

input classifier

prompt builder

retriever

model router

tool gateway

trace emitter

cache

storage

egress monitor

Implementation sketch

Policy tests should run against routes, not promises

privacy-boundary.test.tsts

const restrictedFixture = {
  userText: "Patient: Jane Example. Diagnosis: simulated restricted condition.",
  classification: "restricted_personal_data",
};

test("restricted data never routes to public cloud model", async () => {
  const run = await executeWorkflow(restrictedFixture);

  expect(run.modelCalls).toEqual(
    expect.not.arrayContaining([
      expect.objectContaining({ providerBoundary: "public_cloud" }),
    ]),
  );

  expect(run.traceEvents.every((event) => !event.rawPayload)).toBe(true);
  expect(run.egressEvents).toHaveLength(0);
});

Redaction is not a substitute for routing control. A high-risk system should avoid sending restricted data to unauthorized endpoints in the first place.

Assurance criteria

What evidence should be reviewable

A current inventory of model, tool, telemetry, cache, and storage endpoints.
A classification policy tied to runtime routing decisions.
Synthetic sensitive fixtures that exercise every critical workflow.
Negative tests proving unauthorized egress fails closed.
Trace samples showing redaction/minimisation behavior.
Change-detection tests for new tools, vendors, and model routes.

References

NIST Privacy Framework OWASP Top 10 for LLM Applications 2025 NIST AI RMF Generative AI Profile

Related research

View all

ENT-RN-006