What changes when context is filtered before a prompt?

Privacy claims are often phrased as properties of an AI model: whether it remembers a sensitive detail, repeats one, or trains on a conversation. A local context engine has an earlier and more observable boundary. Before a model receives a prompt, which records have been placed in it?

If a record was not authorized for a given assistant, including it in the prompt is already a disclosure to that destination. A model may never mention it in its answer, but omission from the answer does not undo disclosure. That makes prompt assembly an important place to test permission controls independently of model behavior.

Zortex's stated product direction is local-first context with a user-controlled view for each AI. The following test isolates destination-aware filtering in a deterministic prompt assembler. It runs independently of Zortex's gateway, operating-system controls and third-party models.

Dataset and run: October 9, 2026, with constructed canary values and explicit grants; each selected record ID is preserved in the raw output.

Question

How many generated prompts contain a record that should not be shared with the selected AI when the assembler uses (a) no filtering, (b) a coarse keyword rule, or (c) explicit destination grants? And does the filter preserve a record the selected destination is permitted to receive?

The two metrics are separate. A privacy gate can eliminate forbidden records by stripping everything, yet be useless for answering questions. We therefore measure both unauthorized record presence and authorized evidence preservation. This does not ask an AI to generate any text.

Setup

The test contains 96 independent requests across three invented assistant destinations. Each request has four generated records: one task-relevant record granted to its destination, one harmless record available to all destinations, and two records granted only to a local-only destination.

The two forbidden records carry visible CANARY-... markers, so detection is exact and does not depend on interpreting prose. The relevant allowed record carries ALLOW-... as its answer-evidence marker. Some permitted records also have a confidential flag, reflecting the fact that a word such as confidential does not tell us which assistant the user has authorized.

Three assemblers are evaluated against the same records. No filter sends every record. Keyword redaction removes records flagged confidential but ignores destination metadata. Scope gate admits only records whose explicit destination set includes the current assistant. The raw file contains every selected record ID and both evaluation booleans for each policy.

We count a prompt as unauthorized if even one forbidden canary is included. We count it as useful if the specific allowed evidence marker survives. No token values, customer information, credentials, or real connected accounts are used.

Results

The chart displays the count of prompts that contain unauthorized context, where lower is better.

No filter        | ████████████████████████ 96 / 96
Keyword rule     | ████████████████████████ 96 / 96
Destination gate |                          0 / 96

Unauthorized canary inclusion for 96 generated prompt-assembly requests under three explicit policies.

The coarse rule does not solve the authorization problem. At least one forbidden record survives in every request, even though the rule also discards some legitimate evidence. A destination-aware allowlist separates those concerns in this fixture: no forbidden record reaches the assembled context, while the intended record remains available in all requests.

This result isolates one invariant: explicit destination grants can prevent unauthorized records from entering a prompt while preserving permitted evidence. The raw canary cases make a later grant-filtering regression observable.

Derived context must carry its permissions

A real personal model has derived facts. A model might infer a salary range from a promotion email even if the original salary document is withheld. A graph relation can reveal that two names refer to the same person. A quoted message can carry sensitive text into a document with broader permissions. Correct record-level grants do not automatically assign correct permissions to summaries, embeddings, cached context, or provenance chains.

Permissions also change. A user may revoke access while a connector has old cache entries or while a request is already being assembled. The distinction between permission at indexing time and permission at delivery time matters. An on-device filter should be tested on the actual outbound payload, not only on stored metadata.

Finally, the word on-device is not by itself a security guarantee. A local program can still send unauthorized context over a network if its policy check is wrong. Conversely, a remote gate could enforce a correct policy if trusted and verified. The boundary we are measuring is what leaves the controlled context service for the chosen destination.

Measurement scope

The generated records and permission sets are deterministic and internally consistent. There is no malicious connector, schema migration, prompt injection, malformed payload, account compromise, or alternate egress path. Our simulated assistants do not retain, log, train on, or respond to the content. We cannot infer anything about the probability of a generated answer leaking personal details.

The keyword baseline uses a coarse confidential flag; it ignores destination identity, the variable being tested. The scope gate is given correct labels rather than having to derive them. The test establishes a narrow invariant for destination-based prompt assembly: excluded records do not enter the selected outbound prompt.

Testing the outbound bytes

Move the canary test to the actual context-assembly interface. Generate nested citations, summaries, stale grants, quoted secrets, and revocations during an in-flight request. Capture the exact bytes prepared for each destination, include cache and logging paths, and fail closed when ownership or permission is unknown. Then evaluate generative leakage separately, with model outputs and retention questions kept distinct from the outbound-prompt boundary.

The runner and per-request record selections are in experiments/prompt-permissions/. experiments/run.py implements all three policies without making an external request.