Octoryn Platform
Octoryn Privacy
Sensitive-data controls: detection, redaction and residency-aware handling across the AI path.
Overview
Octoryn Privacy is the set of sensitive-data controls that sit on the path between your systems, the models, and the tools an AI action touches. It detects sensitive material such as PII and PHI in prompts, retrieved context and tool inputs, applies redaction or transformation before data leaves a trust boundary, and routes work according to residency and deployment rules you set. It is intended for teams handling regulated or confidential information who need AI work to happen without sensitive fields flowing to places they should not. As a Pilot capability, it reduces exposure and produces evidence of what was detected and handled — it does not by itself make a workload eligible for any regulatory regime.
How it works
Classify at the boundary
Each prompt, retrieved document and tool payload is scanned for sensitive categories before it crosses into a model or external tool.
Redact or transform
Detected fields are masked, tokenised or dropped according to policy, so the model sees only what the task genuinely needs.
Route by residency
The action is directed to a model and deployment (managed cloud, customer cloud, private VPC, on-prem or local) that satisfies the data’s residency and handling rules.
Enforce fail-closed
If a payload cannot be classified with enough confidence, or no compliant route exists, the action is held rather than sent.
Record the handling
What was detected, which transformation applied and which route was chosen are written into the action’s evidence.
Key capabilities
Multi-point detection
Sensitive-data checks run on inbound prompts, retrieved context, tool arguments and model outputs, not just the first prompt.
Configurable categories
You define which categories matter — identifiers, health, financial, contractual — and the action for each.
Reversible tokenisation
Where a downstream result must be re-associated, redaction can use tokens that map back inside your boundary rather than destroying the value.
Residency-aware routing
Routing rules bind data categories to permitted regions and deployment patterns before a model is selected.
Evidence of handling
Each run carries a provenance record of detection results and the transformation and route applied, which is tamper-evident.
Deployment breadth
The same controls are intended to apply whether the model runs in managed cloud, your VPC, on-prem or at the edge.
What it is not
- It is not a compliance certification — controls reduce exposure but eligibility for any regulatory regime is assessed separately, per engagement.
- It is not a guarantee that no sensitive data reaches a model; detection is probabilistic and category definitions are yours to tune.
- It is not a data-loss prevention product for your whole network; its scope is the AI action path, not general egress.
Integration
Octoryn Privacy sits inline on the AI action path, so it connects to the identity, policy and tool-access layers already governing an action rather than replacing your existing systems. Detection can draw on your own category definitions and dictionaries, and routing respects the deployment patterns you already run. The exact connection points — where the boundary sits, which stores and tools are in scope, and how tokens map back — are assessed per engagement.
Deployment options
- Managed cloud
- Our cloud account
- Private cloud / VPC
- On-premises
Example use cases
- A support workflow strips customer identifiers from tickets before a model drafts a reply, then re-associates the reply inside the boundary using tokens.
- A clinical-notes summarisation task is routed only to a model deployment that satisfies the health data’s residency rules, and is held if none is available.
- A contract-review action redacts counterparty financial terms from tool inputs so an external tool never receives the sensitive figures.
Frequently asked questions
Does using Privacy make our AI workload compliant with health or privacy regulation?
No. It applies controls that reduce sensitive-data exposure and records how data was handled, which can support a compliance case. Whether a workload meets a specific regime is assessed separately, with your own legal and risk teams.Is redaction reversible?
It can be, where you need to re-associate a result. Tokenised redaction keeps a mapping inside your boundary so outputs can be re-linked; you can also choose to drop values irreversibly for categories that should never return.What happens if the system can't tell whether data is sensitive?
The action fails closed. Rather than send an unclassified payload to a model or tool, the run is held for review, so uncertainty does not become accidental exposure.
All capabilities
Octoryn Builder
Private previewBuild production applications that emit portable, reviewable source code — not a locked-in low-code runtime.
- Audience:
- Engineering teams and organisations building internal and customer-facing software.
Octoryn Runtime
Private previewA runtime for governed AI-enabled applications, connecting models, policies, tools and operational systems.
- Audience:
- Teams operating AI inside real workflows and systems of record.
Octoryn Gateway
Private previewA controlled AI gateway so model access passes through organisational policy instead of scattered API keys.
- Audience:
- Security, platform and data teams standardising enterprise model access.
