Neural Inverse Govern / Data protection and privacy

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

What data protection and privacy covers.

Only what works today.

Built-in and custom patternsEvery 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 classificationAt 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 runsModel 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 viewFor 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 rulesRules 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 positivesA violation log by type and tool, statistics, an ad-hoc scan for testing patterns, and false-positive marking that is itself audited.
Reversible tokensSensitive 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 gatewayThe 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 requestsRecord access, deletion, portability and rectification requests with due dates, and move them through pending, in progress, completed or rejected.
Privacy settings by data classPer 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 pseudonymsRevealing a real identity behind a pseudonym can be disabled, or require one or two named approvers.
Loosening needs a reasonA settings change that keeps more data or exposes more identity requires a confirmation reason, and every change is recorded with its direction.
Device data retentionPer-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 regionEvery 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 credentialsTokens, API keys, endpoint device tokens and compute workers carry their region. One presented to another region is refused.
Model residencyModels 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 teamsMaintain DLP patterns and context rules, review violations and confirm where DLP is enforced.
Privacy officersSet privacy settings per data class, approve de-pseudonymisation and track data subject requests to their due dates.
Compliance teamsShow residency through the organisation's home region and the region recorded in each audit entry.
EngineersSee 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 refuseIf a scan cannot run, the request is refused. Content that cannot be scanned as text is refused at the refusing levels.
Restores need permissionRestoring a tokenised value needs its own permission and is refused when its audit entry cannot be written.
RegionA credential from another region is refused, and an organisation's home region cannot be changed.
LooseningA privacy settings change that loosens protection is refused without a confirmation reason.

Recorded

ViolationsEvery DLP violation with the surface and tool that logged it.
ChangesPattern, context rule and false-positive changes, and every privacy settings change with its direction.
RequestsEvery data subject request filed and every status change, with the subject's id and never the email.
RegionThe region that wrote each audit entry, inside the entry's hash.

Where it runs

Your data, in your region.

Deployment options
Self-hosted and in your cloudGovern runs where you deploy it; prompts, findings and tokens stay in your installation.
Air-gappedEvery DLP pattern and detector runs locally. No scan calls an outside service.
RegionsEach installation is one region with a fixed identity, checked at every start.
Hosted by usWe run it for you. Your organisation lives in the region you create it in.

What's next

Being built now.

These are in development and not part of the product today.

Scheduled retention per organisationRetention policies set by each organisation and applied on a schedule, beyond today's platform defaults.
Export of a person's dataA complete export of a person's profile, sessions, audit entries and keys for access and portability requests.
Residency rules beyond the home regionResidency rules for an organisation's data beyond the region it lives in.
Telemetry retention per organisationHot and cold retention of observability data enforced per organisation.

Talk to our team.

Neural Inverse is available by request. We work with your engineering, security and procurement teams from the first conversation.

Data protection and privacy · Neural Inverse Govern · Neural Inverse