ShinrAISemantic Encryption
in Your Cluster
The ShinrAI Platform sits between your applications and any LLM as a drop-in, OpenAI-compatible layer. Your cluster, your keys, any model: text is protected on the way out and restored on the way back — live, mid-stream. Nothing sensitive leaves your perimeter.
Integrate with One Endpoint Change
Point your existing OpenAI-style client at ShinrAI instead of the provider. That is the whole migration.
# before: your app talks to the provider directly
base_url = "https://api.openai.com/v1"
# after: your app talks to ShinrAI — same protocol, same streaming
base_url = "https://shinrai.your-cluster.internal/v1"
# what happens in between (per request):
stage 1 static screen regex · hash pools · gazetteers · <1 ms
stage 2 neural detection multilingual encoder · tiers + origin + gender
replace realm-matched ~0.4 ms per draw · injective session map
forward to any LLM OpenAI · Anthropic · your gateway · OpenRouter
restore mid-stream the map never leaves your sideProxy mode
An OpenAI-compatible chat endpoint with server-sent streaming. Encryption outbound, restoration inbound — even when a pseudonym splits across two network chunks, the rolling restore buffer catches it.
REST mode
Direct /api/encrypt and detection endpoints for pipelines that want protection without proxying — batch de-identification, ETL steps, document stores. Detections merge deterministically: user rules first, then static, then neural.
Policy per deployment
Replacement mode — preserve, mask or neutralize — is configurable per entity type and per customer. Language-to-model routing is automatic and per-request overrides are tolerated, never a hard error.
Predictable in Production
Privacy infrastructure must be the most predictable component in the cluster.
Graceful degradation, never fail-open leaks
If the neural stage is saturated or breaks, requests shed to the deterministic static path — structured PII keeps getting caught. A circuit breaker (5 failures, 30 s cooldown) guards the model; a broken breaker costs 2.1 ms p95, not an outage.
Health you can probe
Dedicated liveness, readiness and combined health endpoints plus a metrics envelope per pod. An external watchdog deployment ships in the same chart.
Models as a stable image layer
Model weights live in their own container layer below the application code — code deploys never re-pull gigabytes. Registry back-connect and pinned digests support customer-appliance installs.
Automatic language routing
Requests route to the best model generation per language automatically. Long texts beyond the neural window skip to the static path instead of erroring; sliding windows cover documents up to 128k tokens.
What Do I Need to Run It?
The short answer: RAM and a fast CPU — or a GPU. Both work. Pick your case:
Workload
Detection depth
Hardware
All figures from measured deployments: resident memory after inference, Helm chart resource schemas and the published serving benchmark. RAM is the dimension that decides — CPU speed then sets your latency, and a GPU buys the tightest tail latencies. Even a 2016-class datacenter GPU serves two model generations in ~4.5 GB VRAM.
Throughput and Scale
Archive pipelines scale horizontally — each engine replica adds the same throughput, and shed traffic degrades to the static path instead of queueing. De-identifying a clinical archive is a replica count and a weekend, not a data export.
Security Controls
No server-side mapping store
The replacement map travels with the client and is inverted per session. The platform cannot decrypt yesterday’s traffic — there is nothing stored to decrypt with.
Content-free logging
Logs carry counts and types only — “6 entities in 96 ms”, never the entities. No plaintext retention anywhere in the pipeline.
Secrets wiped after boot
Configuration files and environment secrets are wiped after load into a memory-only secure store — a shell on the pod finds no keys and no detection internals on disk.
Hardened by default
Non-root containers, slim base images, pod disruption budgets, allow-listed CORS, pinned model digests. Air-gapped installs run the neural stage fully in-process — data never leaves the pod.
Onion Routing: Anonymous at the Provider
ShinrAI removes identities from the text. The optional onion-routing layer removes your identity from the request itself.
Multi-hop request routing
Requests reach the AI provider over multiple independent hops and model access paths. No single hop sees your origin and your request together.
No attribution via billing or origin
Provider billing accounts, IP addresses and country of origin no longer point at your organization or person. Nobody learns that your company is asking — or from where.
Built on llmproxy
The layer runs on llmproxy, the low-level C++ proxy engine behind the Secure AI Suite — high throughput, minimal added latency, streaming preserved end to end.
Demo, setup and operation
Optional on top of any ShinrAI deployment — the highest security level our enterprise customers run. We demonstrate it live and set it up with your team as a paid service.