# Data protection and privacy · Neural Inverse Govern > Data loss prevention that acts by the data's classification wherever AI touches it, privacy settings and data subject requests, and organisations bound to the region they live in. Source: https://neuralinverse.com/govern/dlp-privacy/ --- ![](/photos/team.jpg) [Neural Inverse Govern / Data protection and privacy](https://neuralinverse.com/govern/) # Sensitive data is redacted or refused before it leaves. Data loss prevention that acts by the data's classification wherever AI touches it, privacy settings and data subject requests, and organisations bound to the region they live in. DLP Built-in and custom patterns Action Set by the data's classification Tokens Reversible, encrypted, audited Requests Access, deletion, portability, rectification Residency One home region per organisation Overview Govern runs one DLP engine on every path where AI meets your data, and the action it takes follows the classification of the project and request rather than the pattern alone. Privacy settings decide what is captured, for how long and who may reveal a pseudonym. Data subject requests are tracked to their due date, and every organisation is bound to the region it was created in, which every audit entry records. [What it does ↓](https://neuralinverse.com/#capabilities)[How it works ↓](https://neuralinverse.com/#workflow)[Enforced and recorded ↓](https://neuralinverse.com/#enforcement)[Where it runs ↓](https://neuralinverse.com/#where)[Get started ↓](https://neuralinverse.com/#get-started) What it does ## What data protection and privacy covers. Only what works today. - **Built-in and custom patterns:** Every scan runs the built-in patterns, which you can list by name, type and classification, plus your organisation's own. Pattern changes are audited without the expression itself. - **Action by classification:** At public and internal, a finding is redacted and the request continues. At confidential, restricted or in a regulated project, the request is refused. - **Where DLP runs:** Model gateway prompts, and answers when output DLP is on; agent-to-agent traffic in both directions; MCP tool calls; context sources; skills; the console assistant; source control governance; and app activity from the Neural Inverse apps. - **Enforcement view:** For each surface, whether this installation enforces DLP there and how many violations it logged in the last 30 days, derived by the server rather than configured by hand. - **Context rules:** Rules by agent role, data class and destination that allow, block or redact, for cases where the same data may go to one place and not another. - **Violations and false positives:** A violation log by type and tool, statistics, an ad-hoc scan for testing patterns, and false-positive marking that is itself audited. - **Reversible tokens:** Sensitive values can be replaced with tokens and stored encrypted, with the token store re-encrypted hourly. Restoring a value needs its own permission, and every restore is audited. - **Sensitive-data detection in the gateway:** The AI Gateway can also detect PII, health data, payment cards and credentials with checksum validation, and redact them or replace them with tokens that are restored only for the caller. - **Data subject requests:** Record access, deletion, portability and rectification requests with due dates, and move them through pending, in progress, completed or rejected. - **Privacy settings by data class:** Per organisation and data class: what is captured (identity, commands, or prompts too), retention, the legal basis, how erasure requests are handled and whether exports show names or pseudonyms. Presets give a starting point. - **Pseudonyms stay pseudonyms:** Revealing a real identity behind a pseudonym can be disabled, or require one or two named approvers. - **Loosening needs a reason:** A settings change that keeps more data or exposes more identity requires a confirmation reason, and every change is recorded with its direction. - **Device data retention:** Per-organisation retention of device data, legal holds on the organisation, a device or a person that win over retention, and erasure of a person from device data. - **Home region:** Every organisation belongs to the region it was created in, and that cannot be changed. The installation checks at every start that each organisation has one. - **Region-bound credentials:** Tokens, API keys, endpoint device tokens and compute workers carry their region. One presented to another region is refused. - **Model residency:** Models can be pinned to regions and limited by classification, and a project's residency policy refuses any model outside it. Every audit entry records the region that wrote it, inside its hash. How it works ## How content is checked before it leaves. The same steps on a model prompt, an MCP tool call or an agent-to-agent message. 1. Classify The request carries the classification of its project and data. 2. Scan Every text part is scanned with the built-in and organisation patterns. 3. Act Findings are redacted at lower classifications and refused at confidential and above. Content that cannot be read as text is refused, not passed. 4. Tokenise Where configured, values are replaced with tokens restored only for the caller. 5. Review Security reviews violations and marks false positives; each mark is audited. 6. Record The finding is logged with the surface and tool that found it. Who uses it ## Built for every role that answers for AI. - **Security teams:** Maintain DLP patterns and context rules, review violations and confirm where DLP is enforced. - **Privacy officers:** Set privacy settings per data class, approve de-pseudonymisation and track data subject requests to their due dates. - **Compliance teams:** Show residency through the organisation's home region and the region recorded in each audit entry. - **Engineers:** See a clear refusal when a prompt carries data its classification does not allow, and why. Enforced and recorded ## Refused when unsure, recorded every time. DLP and residency are decided by the server; a check that cannot run is a refusal. Enforced - **Scan or refuse:** If a scan cannot run, the request is refused. Content that cannot be scanned as text is refused at the refusing levels. - **Restores need permission:** Restoring a tokenised value needs its own permission and is refused when its audit entry cannot be written. - **Region:** A credential from another region is refused, and an organisation's home region cannot be changed. - **Loosening:** A privacy settings change that loosens protection is refused without a confirmation reason. Recorded - **Violations:** Every DLP violation with the surface and tool that logged it. - **Changes:** Pattern, context rule and false-positive changes, and every privacy settings change with its direction. - **Requests:** Every data subject request filed and every status change, with the subject's id and never the email. - **Region:** The region that wrote each audit entry, inside the entry's hash. Where it runs ## Your data, in your region. [Deployment options](https://neuralinverse.com/deployment/) - **Self-hosted and in your cloud:** Govern runs where you deploy it; prompts, findings and tokens stay in your installation. - **Air-gapped:** Every DLP pattern and detector runs locally. No scan calls an outside service. - **Regions:** Each installation is one region with a fixed identity, checked at every start. - **Hosted by us:** We run it for you. Your organisation lives in the region you create it in. Get started ## Set it up with the documentation. - [Guardrails and DLP](https://neuralinverse.com/docs/govern/guardrails/) - [Classification](https://neuralinverse.com/docs/context/classification/) - [Model access and regions](https://neuralinverse.com/docs/govern/model-access/) - [Security architecture](https://neuralinverse.com/docs/security/) What's next ## Being built now. These are in development and not part of the product today. - **Scheduled retention per organisation:** Retention policies set by each organisation and applied on a schedule, beyond today's platform defaults. - **Export of a person's data:** A complete export of a person's profile, sessions, audit entries and keys for access and portability requests. - **Residency rules beyond the home region:** Residency rules for an organisation's data beyond the region it lives in. - **Telemetry retention per organisation:** Hot and cold retention of observability data enforced per organisation. Related [AI Gateway → Approved models, DLP, guardrails, budgets and rate limits for every model request.](https://neuralinverse.com/govern/ai-gateway/)[Context for agents → Governed, attributed context from your code, issues and team knowledge.](https://neuralinverse.com/govern/context/)[Compliance and evidence → Framework rule packs, checks, hashed evidence records and project policies, as evidence toward your controls.](https://neuralinverse.com/govern/compliance/) ![](/photos/team.jpg) ## Talk to our team. Neural Inverse is available by request. We work with your engineering, security and procurement teams from the first conversation. [Request access](https://neuralinverse.com/contact/?topic=access)[Contact us](https://neuralinverse.com/contact/)