An employee’s AI request
Code applies the action.
Explore this article 6 chapters
The next frontier of workforce AI security is making better decisions at the moment employees use AI. I want controls that understand the request, apply the right policy and keep people moving.
That is why Jev, introduced by TypeSafe AI, caught my attention. Its approach to fast, structured decisions points to an opportunity: bring more contextual judgment into the small window between an employee's action and its consequences.
Why Jev?
Jev interests me because it combines natural-language understanding with a model trained for decisions. TypeSafe describes parallel typed outputs, without generating an answer token by token. Questions supplied with each request define the judgments to make, and the results give software structured signals it can use.
That is a useful design for frequent, bounded policy checks. The architectural opportunity is to move control closer to each employee action, with enough context to make a useful decision and little enough delay to preserve the experience. It still needs testing against alternatives on the same policies.
How Jev compares
These categories overlap: a detector can combine rules and models, and a guard model can be an LLM. I would choose by the decision each layer needs to make. Code still owns enforcement.
Jev-style decision modelsText-based judgments with flexible criteria and typed probabilities.
Jev evaluates text against request-defined criteria using shared model weights. Its documentation describes typed probabilities for bounded judgments, without generated explanations. That suits changing policy questions. File parsing, redaction and enforcement remain surrounding software; accuracy, latency and thresholds still need evaluation on the intended data.
General-purpose LLM judgesBroad reasoning and explanations, with structured outputs available.
Useful when a check needs broader reasoning or an explanation. Supported LLM APIs also offer schema-constrained JSON; that format is not unique to Jev and can still contain mistakes. Measure quality, latency and cost for the selected model and settings.
Rules and pattern matchingExplicit conditions with predictable, inspectable outcomes.
Use exact rules for allowlists, destinations, known formats and explicit access conditions. Open Policy Agent evaluates policy over supplied data; it does not infer hidden intent from prose by itself. Rules are predictable within their definitions, but miss violations those definitions do not represent.
PII and secret detectorsFind sensitive spans and recognisable credentials.
Presidio finds sensitive spans with patterns, entity-recognition models and validation; Gitleaks targets secrets with rules. Their findings can guide redaction workflows. Their configured coverage can miss unfamiliar data, and finding an entity does not by itself decide whether sharing it is permitted.
Dedicated guard modelsSpecialised safety or attack detection within a defined scope.
Llama Guard assesses content against a defined safety taxonomy, while Prompt Guard targets attempts to override instructions. Useful when that training scope matches the check. Their documented domain and adversarial limitations still matter, and a model verdict alone cannot establish that a request was safely enforced.
Context changes the decision
Illustrative policy examples
Same topic. Different intent.
Example policy: allow education, prohibit credential theft.
“Explain why this email is phishing for our staff awareness session.”
Does this request help steal credentials?
No
Allow
The request helps people recognise phishing. It does not help steal credentials.
Consider a policy that permits security education but prohibits assistance with credential theft. “Explain why this email is phishing” and “Make this credential-harvesting email more convincing” share vocabulary, but request very different help. A contextual check can assess what the assistance would enable. These are synthetic examples of a policy distinction, not measured Jev results. TypeSafe's guardrail cookbook shows how classification and severity scoring can support this kind of bounded judgment.
A better signal for policy
A structured distribution gives policy code more to work with than a single label. Different checks can have different thresholds, reflecting the consequences of a missed violation or an unnecessary block. Ambiguous results can trigger deeper evaluation. The security team still defines the action; the model supplies a signal. This makes the trade-offs explicit and gives teams something concrete to evaluate against their own policies.
Illustrative data · 12 synthetic requests · Not Jev measurements
Move the blocking threshold
A request is blocked when its estimated probability of a policy violation meets or exceeds the threshold.
1 / 6
Legitimate requests blocked
2 / 6
Violations below threshold
5 of 12 requests blocked at 70%.
Below the threshold, requests pass in this simplified example. A real system can add a review step.
Inspect the illustrative data
Six legitimate requests and six policy violations. These fixed scores illustrate threshold trade-offs, not measured model performance.
| Request | Actual status | p(violation) | Decision |
|---|---|---|---|
| L1 | Legitimate | 8% | Passes |
| L2 | Legitimate | 18% | Passes |
| L3 | Legitimate | 31% | Passes |
| L4 | Legitimate | 55% | Passes |
| L5 | Legitimate | 68% | Passes |
| L6 | Legitimate | 88% | Blocked |
| V1 | Policy violation | 46% | Passes |
| V2 | Policy violation | 62% | Passes |
| V3 | Policy violation | 74% | Blocked |
| V4 | Policy violation | 81% | Blocked |
| V5 | Policy violation | 92% | Blocked |
| V6 | Policy violation | 97% | Blocked |
Those signals need validation. Jev's separate confidence property describes distribution concentration, not the probability an answer is correct. Calibration is measured across predictions and cannot guarantee an individual outcome. TypeSafe also explicitly acknowledges in its Jev 1.13 limitations that adversarial content can steer answers. Security evaluations must therefore measure false positives, missed violations and resistance to manipulation alongside latency.
The standard innovation must meet
I see the strongest architecture as a combination of specialised controls. Deterministic detectors handle known patterns and explicit restrictions. Contextual models answer bounded questions about meaning. Policy code applies the decision, and enforcement must remain reliable when a model is uncertain or unavailable. Each layer has a defined job, and the protection system must be tested as a whole.
Privacy belongs in that architecture from the start. A guardrail may inspect precisely the information it is protecting. Processing location, access, retention and training use are engineering requirements. Any model considered for that role needs a secure deployment path and data-handling arrangements that meet customer requirements. A faster decision has value only within a protection system customers can trust.
Our direction at Aona
At Aona, we are investigating this class of model for accurate, high-speed guardrail classification. Jev is an interesting example of the direction, and our focus is the capability this approach could enable for protecting employees' AI use.
We will propose a future offering when we can demonstrate effective protection through deployment options that meet our security and privacy requirements. My ambition is to make contextual protection a natural part of every relevant employee interaction with AI. Faster decision models could help us get there, built on that foundation.
Sources behind this perspective 12 primary sources
- Jev, introduced by TypeSafe AI
- parallel typed outputs
- documentation
- schema-constrained JSON
- Open Policy Agent
- Presidio
- Gitleaks
- Llama Guard
- Prompt Guard
- guardrail cookbook
- confidence property
- Jev 1.13 limitations
The interactive examples are authored illustrations, not measured Jev outputs. Sources reviewed 22 September 2026.