Appearance
Protecting your intellectual property
Your prompts are intellectual property. So is the data you put through them, the know-how encoded in how you have tuned them, and the confidential material your teams paste in while working. Sending any of it to an external AI provider is a disclosure, and most providers reserve broad rights over what they receive.
VeriPrompt protects proprietary and confidential material in five distinct places. They are independent — most companies need several — and none of them requires trusting a provider's promises:
| What you are protecting | Where | What it does |
|---|---|---|
| Personal and sensitive data | /shield/sanitize | Detects and tokenizes PII before a prompt ever leaves the perimeter, then restores it in the response. |
| Which providers may see a prompt | /ranger/routing | Routing policies decide, per prompt, which providers are even eligible — by region, by data terms, or by name. |
| The prompts themselves | /studio/repository | Encryption at rest, access profiles and full version history for stored prompts. |
| Against prompt injection | /admin/prompt-injection | Detects attempts to hijack a prompt through its own input and exfiltrate your instructions. |
| Outbound destinations | /admin/egress-policy | An allowlist of external hosts the platform may call at all. |
Put plainly: this is how you keep confidential company know-how, trade secrets and proprietary material out of external AI providers, and how you prove afterwards that it stayed out.
Where to start. If you are protecting trade secrets and proprietary know-how, the two that matter most are routing policy and the prompt repository: a routing policy stops your material reaching providers you have not vetted, and the repository stops it leaking sideways to colleagues who should not have it. If you are protecting personal data belonging to customers or staff, start with sanitization instead — see Meeting GDPR obligations for that path.
How the pieces combine
The pieces are designed to compose, and the order matters.
A prompt travels: repository → sanitizer → routing policy → provider → back. Each stage narrows what can escape.
- Access first. The prompt repository controls who may read or edit a stored prompt in the first place. A prompt nobody can export cannot be leaked by a person. See Prompt Git.
- Then content. The sanitizer removes what does not need to leave. Tokenized values are restored on the way back, so the answer is complete even though the provider never saw the original. See PII sanitization.
- Then destination. A routing policy decides which providers are eligible for what remains. This is the control that answers "our material must never reach a provider outside the EU". See Intelligent routing and Geofencing.
- Then the perimeter. The egress policy is the backstop: even a misconfigured integration cannot call a host you have not allowed.
Proving it afterwards
Protection you cannot demonstrate is hard to rely on. Two records exist for this:
/admin/prompt-logs— what was actually executed, against which provider, with a retention period you set./admin/audit-logs— who changed a policy, a permission or an access profile, and when.
Together these answer "show me that this prompt never went to that provider", which is the question that actually gets asked in a security review.
Related
- Data protection controls
- Zero-knowledge mode
- Security hub
- Policy setup wizard — guided setup for routing policies
