Jev Security and Privacy: What Leaves Your Systems, and What Shouldn't

Somewhere between the demo and the deployment, someone from security asks the only question that matters: what exactly are we sending, and to whom? This page is for arriving at that meeting prepared. One scope note up front, in this site's standing spirit: TypeSafe AI's own terms, retention policies, compliance certifications, and data-handling commitments are theirs to state at docs.typesafe.ai, and they're what your vendor review should cite. What this page owns is the architecture side: the patterns, cataloged across the directory, that determine how little you need to send in the first place, which is the half of the security posture you control regardless of any vendor's answers.

Principle one: verdicts need less than generation does

A structural privacy advantage hides in the decision-model shape: a judge needs only enough context to rule, and returns only a closed answer, no free-text channel echoing your data back, transformed. That enables minimization by design: send the fields the question needs, not the record (judge questions about "does this message contain cancellation language" need the message, not the customer's account object); redact or tokenize identifiers before transit where the judgment doesn't depend on them (category verdicts rarely need names; entity resolution does, so scope that pipeline's review separately); and prefer derived signals over raw payloads when they carry the judgment.

The template case is the screenshot-free computer-use build: local OCR reads the screen, only extracted text travels, raw pixels never leave the device. Generalized: cheap local perception, remote verdicts on the minimum text, a pattern that applies to documents, transcripts, and sensor streams, and one your security team will recognize as data-flow design rather than vendor trust.

Principle two: the verdict layer is also a defense layer

Covered fully in their own pages, assembled here as posture: injection screening judges untrusted input before capable models read it, guardrails judge outputs for leakage (system-prompt fragments, cross-customer data, internal identifiers) before anything ships, and verification gates stand before irreversible actions. The structural argument repeats deliberately: a closed-answer model with no tools, no secrets, and fixed questions is the least injectable, least abusable component in the stack, which is exactly what you want touching untrusted data first.

Principle three: logs are both your audit trail and your liability

Verdict logs (input hash or reference, verdict, confidence, question version, per production discipline) are what make the system auditable, and, if they contain raw inputs, they're also a second copy of your sensitive data with its own retention problem. Log references and redacted excerpts where possible, apply your data-retention classes to verdict logs explicitly, and gate log access like the source data. For regulated contexts, the compliance-flavored rules apply: human review on consequential verdicts, versioned questions as your documented decision procedure, and the humility to keep model verdicts advisory wherever a regulator would ask "who decided?"

The honest residual: any external API call is a trust decision your vendor review must close (retention, training-use, residency, certifications, at the official docs), adversarial inputs will probe whatever you deploy per the spam page's standing warning, and minimization reduces exposure without abolishing it. Architecture buys you the strong posture; diligence buys you the rest.

Frequently asked questions

What data does a Jev-based pipeline send externally?

Whatever you put in the question, which is the point: well-designed pipelines send the minimum fields a verdict needs, redacted where identity is irrelevant, with raw documents and pixels kept local behind extraction.

Is a decision model safer than a chat model for sensitive data?

Structurally friendlier: no free-text output channel to leak through, no instruction-following surface to hijack, and smaller payloads by design. Vendor-level guarantees still come from the vendor, not the architecture.

How do we handle PII in verdict pipelines?

Minimize before transit, tokenize where judgments don't need identity, scope identity-dependent pipelines (resolution, fraud) for separate review, and apply retention classes to verdict logs as data, because they are.

What should our vendor security review ask TypeSafe?

Retention and training-use policy, data residency, certifications and audit reports, incident and deletion processes, per the official documentation. This page's patterns reduce what rides on those answers; they don't replace asking.