Latent · security and deployment

Summary

The boundary, in one table

Deployment model	Self-hosted inside your VPC or on your own hardware. There is no hosted or multi-tenant option.
Data egress	NONE No prompts, outputs, activations, embeddings, or telemetry leave your environment.
Weight custody	NONE Latent never receives, copies, or transmits model weights.
Inbound connections	NONE The plugin opens no listening sockets and needs no ingress rule.
Generation behavior	Read-only by default. The hook observes activations and does not modify sampling unless you enable interrupt or fallback policies.
Calibration	Runs on your hardware against your traffic. The artifact is a local file and stays in your environment.
Measured overhead	1 to 2% added latency while scoring every request, under continuous batching.

Compliance

Exact status, including what is not held

Compliance status
Requirement	Status	Detail
SOC 2 Type II	PLANNED	Follows the required observation window, after Type I.
SOC 2 Type I	PLANNED	Near term.
Penetration test	PLANNED	Third-party application and API test, scheduled alongside Type I. Summary shareable under NDA.
ISO 27001	NOT HELD	Not held. Our data-path exposure is nil because nothing crosses the boundary, but 27001 certifies the ISMS behind how software is built and shipped, which is a fair thing to ask about. On the same roadmap as SOC 2.
PCI DSS	NOT APPLICABLE	Latent never receives, processes, or stores cardholder data.
HIPAA	BAA NOT REQUIRED	No PHI is transmitted to Latent. Protected data never crosses the boundary, so there is no business associate relationship to paper. A BAA can still be signed if your policy requires one.
Data residency	INHERENT	Residency is whatever your own infrastructure is. There is no Latent-side region to choose.
Insurance	AT CONTRACTING	Cyber liability and errors and omissions, bound before a pilot agreement is signed. Certificates issued with the agreement.
Security questionnaires	SUPPORTED	SIG Lite, CAIQ, and bank-specific formats. Turnaround target two business days.

Topology

What installs, and where

Latent registers through vLLM’s standard general_plugins entry point, which vLLM discovers in the engine process at startup. There is no fork, no patched binary, and no change to how you serve or route requests.

In the inference process

A read-only forward hook on the single decoder layer being scored
A probe artifact loaded from a local path you control
Per-request risk scoring, emitted as a local event

Activates only when LATENT_ARTIFACT is set. With it unset the entry point is inert, so installing the package changes nothing until you turn it on.

Alongside it

An escalation and audit service you run, in your environment
An append-only local audit log plus a local index
The review console, served from your own infrastructure

Deployed by compose or your own orchestration. Both components are yours to run, restart, and inspect.

Data boundary

What Latent receives, and what it never receives

Processed in memory, inside your process

Hidden-state activations at the scored layer
Token counts and request identifiers
Prompt and output text, only while scoring and hashing

Never transmitted anywhere

Prompts, completions, or source documents
Activations, embeddings, or intermediate tensors
Model weights or fine-tune adapters
Usage telemetry, metrics, or crash reports

On PII. Latent is built for workloads where the sensitive field is the payload rather than an accident: identity, clinical, and financial review. Because the check runs on internal state inside your process, no redaction step is needed for Latent to work, and none of the fields you would otherwise have to strip need to leave the boundary. Persisted records store prompt and output as SHA-256 digests by default. Storing raw text is opt-in and stays local either way.

Audit record

One append-only entry per scored request

Every scored request writes an event to an append-only local log with a local index for query. Nothing in the record identifies a user, and nothing in it leaves your environment.

{
  "request_id":    "req-4f2a91c7",
  "ts":            "2026-08-22T14:07:33.418Z",
  "model":         "internal-qa-8b-v4",
  "layer":         31,
  "risk":          0.8143,
  "verdict":       "escalate",
  "prompt_sha256": "9c1f...e30a",
  "output_sha256": "41b7...c8d2",
  "n_tokens":      142,
  "meta": { "probe_version": "...", "threshold": 0.72, "artifact_sha256": "..." }
}

This answers the question an examiner actually asks, which is not whether a decision was logged but whether it can be reconstructed: which probe version scored this request, at which threshold, against which artifact, at what time.

Model risk

Artifacts for SR 11-7 and equivalent frameworks

If your model risk group inventories the monitor as a model, the documentation it will ask for is produced by the system rather than assembled by hand afterwards.

Conceptual soundness	Published methodology, the layer selection procedure, and the full evidence set including negative results and measured limits.
Ongoing monitoring	Score-distribution drift telemetry against the stored calibration baseline, plus a Mahalanobis distance guard on input activations. Stated limit: in our own testing that guard proved blind to task shift, which is why score drift rather than activation distance is the primary signal. Both are published on the evidence page.
Outcomes analysis	Reviewer decisions on every escalation, retained locally, which also form the input to recalibration.
Change control	Probe version, calibration date, threshold, and artifact digest recorded on every scored request.

Subprocessors

None in the serving path

Because the monitor runs entirely inside your environment, no subprocessor handles your data during inference. Two things are worth stating anyway, because a third-party risk questionnaire will ask.

Label generation during calibration. Fitting a probe needs labeled examples. If you choose the assisted labelling path, that step calls an external model provider. You can instead supply your own labels, label against a model inside your environment, or use your existing reviewer decisions. On regulated workloads that is the default and no external call is made.
Software distribution. The package and container images ship through standard registries. You may mirror them internally and pin by digest.

Pilot

What a scoped pilot needs from you

Pilots are designed to clear as an evaluation rather than a full third-party risk assessment: one model, one review workflow, a sandbox deployment with representative traffic, no production dependency, and no live customer data.

Typically required

Mutual NDA
A completed security questionnaire
Insurance certificates, issued with the agreement
A short evaluation agreement
Architecture and data flow review

Not typically required at this tier

Full third-party risk assessment
Production change approval
Live customer data
Any inbound network exception

Security review, questionnaire, or architecture walkthrough

Direct to the person who built it.

Contact security Open the console

Security and compliance at a glance.