Prompt and context data loss prevention

What it does

It controls what goes into a model. An inspection step sits between users, integrations and retrieval on one side and the model on the other, detects personal, confidential and classified content, and applies a rule: block, redact, warn or allow. Security owns the mechanism and the data owner sets the rules. It operates on every request, for approved tools, and at the network edge for traffic to tools that are not approved.

How to implement it

• Classify what must not be sent to which tools, by data type and by provider.
• Detect identifiers, financial and health data, secrets and marked documents in prompts and uploads.
• Redact or tokenise where the task can still be done without the detail.
• Apply source permissions to retrieval, so context contains only what the user may see.
• Warn the user at the point of entry, with the reason.
• Log detections and review them for patterns and for false positives.

Evidence it operates

Design: data handling rules for AI tools; the configuration of the inspection step. Operation: detection and block logs; tests with seeded restricted data; tuning records; reports of trends to the data owner.

Where it fits

In front of the model, complementing output validation and guardrails behind it. It is the primary control for personal data in prompts and context and, with output controls, for sensitive information disclosure. It supports shadow AI use by blocking restricted data bound for unapproved tools.

Limits

Detection works well for structured identifiers and poorly for sensitive meaning expressed in ordinary words. Heavy blocking pushes staff to personal devices, where nothing is inspected. Encrypted traffic to consumer tools may not be visible at all. It reduces what reaches a provider and does not govern what the provider does with the rest.