Map every data path before setting rules
Begin by tracing the full lifecycle of any prompt or file the assistant can access. Record user input length and attachments, local directory reads, clipboard or browser connectors, model call mechanisms (IPC or HTTPS), vector stores, logs, and any third-party plugins. Distinguish encrypted paths from plaintext ones and note where data becomes persistent versus ephemeral.
This map reveals the highest-risk surfaces. For example, a local model using IPC still risks leakage through shared memory or log files, while a remote fallback over HTTPS adds network exposure. The exercise also identifies human approval points where irreversible actions such as sending email or executing code can be gated.
- List every connector that can push or pull data across application boundaries.
- Note whether logs capture full prompt bodies or only metadata by default.
- Flag any path that writes embeddings or chat history to disk without encryption.
Define what must remain strictly local
Once paths are visible, classify data by sensitivity. Source code, internal documents, and personal identifiers should never leave the device unless explicitly authorized. System prompts and retrieved context that contain proprietary material also belong inside the local trust boundary.
Apply the principle of data minimization: send only the fields or passages required for the immediate task. Over-broad context windows flatten trust domains and make it impossible for the model to distinguish trusted instructions from untrusted data. [owasp.org](https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html) highlights this architectural fusion of control and data planes as a primary failure mode.
- Keep raw documents and embeddings on-device when they contain regulated or proprietary content.
- Disable automatic clipboard or email connectors unless a documented business need exists.
- Require explicit user confirmation before any file write-back occurs.
Control what plugins and tools may transmit
Every tool invocation or sub-agent handoff is an exfiltration boundary. Even benign-looking plugins receive the active conversation context, which may include secrets or attachments. Inventory each integration, record what payload it receives, where data is stored, and the retention period.
Enforce least privilege by scoping tool permissions to the narrowest set of actions and data fields. Use allowlists and human-in-the-loop approval for high-risk operations. When a plugin must receive context, strip unnecessary fields first and log the exact payload size and destination.
- Maintain a registry of every MCP server or connector with its data-handling policy.
- Default to minimal payload mode; expand only after review.
- Route high-risk actions through an approval step that records the decision ID.
Set retention and logging boundaries
Debugging often captures full prompts and outputs, creating long-lived copies of sensitive material. Adopt least-logging defaults that record only metadata unless a specific incident requires more detail. Tokenize or redact PII and secrets before any log line is written.
Apply short time-to-live values to traces, KV caches, and session memory. Delete or anonymize derived assets such as embeddings when the source data is removed. Align these rules with applicable privacy regulations so data-subject requests can be fulfilled with traceable evidence.
- Disable full-body logging by default; enable only with explicit approval.
- Expire debug traces after 30 days or upon case closure, whichever comes first.
- Provide an export and purge workflow for any stored conversation history.
Audit and maintain the boundary over time
Boundaries degrade when new plugins, model updates, or workflow changes are introduced without review. Schedule periodic re-mapping of data flows and re-validation of plugin permissions. Verify that administrators lack standing broad access to model weights or vector stores.
Test whether outputs can leak secrets through retrieval reuse or context bleed. Confirm that open-source inference engines and drivers receive patches on a defined cadence. These checks turn the initial boundary definition into an ongoing operational practice rather than a one-time document.
- Re-run the data-flow map after any major model or plugin update.
- Include boundary compliance in change-control reviews.
- Document exceptions with compensating controls and expiration dates.