AI Lab Blog

Typed Decision Models Are a Security Control

September 29, 2026

Tags: AI Security, Agentic AI, Model Architecture

Every few months a new model launch promises to change everything. Most do not. But in September 2026 a startup called TypeSafe AI released something genuinely different, and it is worth a security practitioner’s attention not because it is faster or cheaper, although it is both, but because of what it refuses to do.

Jev, their first public System One model, does not generate text. You give it state and a typed question, and it returns a structured answer from an output space you defined in advance, with a calibrated probability attached. A choice, a score, a classification. Never a paragraph. Never a hallucinated JSON key. Never a tool call your code did not declare beforehand.

That constraint sounds like a limitation. In security terms it is the whole point.

Bounded output is bounded blast radius

The most dangerous property of a general LLM inside an automated pipeline is not that it is sometimes wrong. It is that it is unconstrained even when it is right. The output space of a language model is, in practice, anything that can be typed. Downstream code has to parse, validate, and defend against whatever comes back. Every prompt injection writeup, every hallucinated function argument, every “the agent called a tool that does not exist” incident traces back to the same root cause: the decision layer emits free text and something else has to interpret it.

A typed decision model inverts that. If the model can only return values from a schema you control, then a successful prompt injection cannot make it do anything outside the schema. An attacker can influence which option gets picked. That is real, and it matters. But the worst case is a wrong pick inside a validated set, not an arbitrary command executed through a parser that trusted the model too much.

This is defense in depth at the model layer. We already accept this principle everywhere else. We do not let a web request write raw SQL. We do not let a user token mint its own scopes. We should not let an untrusted input hop into a language model and come out the other side as unconstrained executable intent.

The two-brain agent

The practical architecture this enables is a split that most agent builders already implement badly with one model doing both jobs:

System Two: general LLM
- reads, writes, plans, explains, negotiates ambiguity
- slow, expensive, needs human oversight

System One: typed decision model
- routes, scores, classifies, branches, verifies
- 70-500ms, near-free, calibrated confidence

The reference here is Thinking, Fast and Slow, and the naming is honest. Kahneman’s System One is fast, automatic, and prone to systematic error unless it is constrained by deliberate checking. That is exactly what a typed decision layer is: fast pattern-judgment with guardrails. The general model does the language work. The decision model handles the branching points where software needs a reliable answer, not prose.

The TypeSafe comparison numbers are worth reading with the skepticism they themselves invite: their benchmarks are run by their own team, from their own laptops, against reference answers averaged from OpenAI and Anthropic frontier models. They publish these caveats themselves, which is more intellectual honesty than the average model launch offers. Even discounted heavily, input at $0.042 per million tokens, free output tokens, and sub-500ms responses change which problems are worth putting AI in front of.

Where this fits in security operations

In a SOC pipeline, most “AI triage” failures are not intelligence failures. They are format and confidence failures. The model usually picks a reasonable queue, but it returns that decision as prose with no calibrated confidence, so you cannot write a rule around it. An analyst either re-reads everything or trusts everything, and both options waste people.

Typed decisions fix the interface problem. Consider finding triage in a posture tool:

Question: route_finding
Options: auto_remediate | queue_critical | queue_review | suppress | escalate_analyst
Input: finding summary, resource tags, control severity, account context
Output: option + calibrated probability + confidence band
Policy: auto_remediate only above 0.97, escalate always below 0.60

The calibrated probability is the part traditional LLMs are worst at and the part automation needs most. If the model says 0.98 and it is right 98 percent of the time, you can automate the 0.98 lane and route everything else to humans with the uncertainty attached. If a frontier chat model says “I am confident,” that is decoration. RLCD, the training method behind Jev, is explicitly aimed at making that number mean something. Independent calibration audits do not exist yet. Hold the claim loosely. But the target is the right one.

What it does not solve

Be clear-eyed about the failure modes:

• Enumerability. This only works where you can define the options in advance. Novel finding categories that are not in the schema cannot be discovered. You still need a general model or a human for the unknown-unknowns.
• Garbage in, garbage routing. If the state you feed it is incomplete or adversarial, the decision will be confidently wrong within type. Typed output does not sanitize input.
• Injection still shifts probabilities. A crafted finding description can still push a decision toward suppress. Schema-bounded decisions reduce severity, not influence.
• Single vendor, two weeks old. A category of one is not a category. Wait for the second and third entrants before betting an architecture on it.

None of those caveats kill the thesis. They just place the tool correctly: a decision layer behind validation, not a replacement for judgment.

The pattern to steal

You do not need to adopt Jev specifically to benefit from the design. The transferable principle is: constrain the model’s output space to the smallest set of values the business logic actually needs, and make confidence a first-class field your policies can branch on.

If your agent stack today has an LLM emitting JSON that a downstream parser trusts, you already have a typed decision layer. You just built the safety case backwards: validation after generation instead of generation within validation. Moving the constraint inside the model, or enforcing it with a schema-strict wrapper plus calibrated confidence thresholds, gets you most of the security benefit regardless of whose model serves the request.

Fast is a nice demo. Cheap is a nice invoice. Bounded is a security control. That is the part worth keeping.