When we built agents to investigate AWS GuardDuty alerts at HackBCN in 2024 , I kept coming back to a basic problem. A nice incident summary is useful, but the real value is deciding what to do with an alert, finding enough context to trust that decision, and doing it quickly enough to matter.
That is why I paid attention to Jev, the new model from TypeSafe. It does not chat. It does not generate a report. You give it some context and a set of questions with defined answer types. It gives you answers your code can use, along with probabilities.
For example, instead of asking, “Please analyze this alert and tell me what to do,” you might ask:
- Does an approved change explain this activity?
- Is there evidence of credential theft?
- How strong is the evidence, from weak to strong?
- Which queue should receive the case?
Jev can answer those questions in one call. Your playbook still decides what happens next. The docs call the three question types Noul (yes/no probability), Score (a rating on a defined scale), and Choice(one option from a list). The questions run in parallel, so you are not waiting for a chatbot to write and parse several paragraphs.
TypeSafe claims responses in 70 to 500 milliseconds and a price of $0.042 per million input tokens, with no charge for output tokens. Those are TypeSafe’s numbers, and Jev is still in early access. I would want to test it on my own security data before trusting the claims. Still, if the speed and price hold up, this could make AI judgment cheap enough to use throughout a security workflow, not just at the end when someone asks for a summary.
TypeSafe’s quick-start example shows the difference: defined answers and probabilities, not a block of generated text.
TypeSafe already has a security example
The company published a security incident workflow that starts with an alert and joins it with asset details, tickets, registered devices, maintenance windows, and authorizations. Jev judges whether the activity looks unauthorized, whether a record explains it, and how strong the evidence is. Code then chooses whether to close the alert, queue it, or take action. If it moves toward action, the workflow checks credentials, sessions, mailboxes, processes, network traffic, and possible spread.
This is the part I like. Jev does not get to invent a new response plan. It answers narrow questions; the team defines the playbook.
Where I would try it
SOC alert triage. This is the obvious starting point. Give Jev an alert plus the asset and change context, then ask whether it is likely to be real and how urgent it is. Start by sorting the queue. I would be much more cautious about letting it close or contain incidents automatically.
Malware analysis. Let the sandbox and EDR do their jobs first. Then ask narrow questions about the behavior they observed: persistence, credential access, lateral movement, or exfiltration. This could help decide which samples deserve a closer look from an analyst or reverse engineer. It is not a replacement for actually analyzing the sample.
Email security. A suspicious email is rarely just about one bad URL. The sender, authentication results, attachment, wording, recipient, and recent conversation all matter. Jev could add a quick semantic check to those existing signals, especially for messages that land between “obviously safe” and “obviously phishing.” You would need to watch false positives carefully. Blocking a genuine customer or payroll message can cause real damage.
Network and API traffic. I would use it to inspect selected requests or sequences, such as suspected credential stuffing or unusual data movement. I would not put a model call in front of every packet. Even a few hundred milliseconds is too slow for that. The more realistic use is to enrich a suspicious session or request, with a timeout and a fallback if the service is unavailable.
Identity and cloud alerts. Is a new privilege grant covered by a change ticket? Does a login anomaly match known travel or a registered device? Is a cloud action unusual for this account? Those are small judgments that could help an analyst get to the right cases sooner.
Security agents. This one may matter most over time. Agents can read logs, search threat intelligence, call tools, and suggest fixes. They also make mistakes, and attackers can plant instructions in the material they read. A fast judge could check a proposed tool call before it runs: Is this action authorized? Could it expose a secret? Is there enough evidence for it? TypeSafe has published an agent-trace workflow that reviews completed runs, and Vercel’s Jev integration describes similar uses for routing and guardrails.
The agent-trace example checks whether an agent stayed within its permissions and whether the task was actually completed.
I would not rely on Jev alone to secure an agent. Tool permissions, scoped credentials, sandboxing, and approval for high-impact actions still need to be enforced by the system around it. A second model saying “looks fine” is useful evidence, not a security boundary.
The bit I would be careful with
TypeSafe says Jev “can’t hallucinate.” What that means here is that it cannot return an answer outside the options you gave it. That is useful. Your code will not receive a surprise paragraph when it expected a label. But Jev can still pick the wrong label.
There is a good reminder of this in TypeSafe’s own security examples. In a case involving an LSASS memory dump, Jev chose NOTIFY USER while the comparison models chose REVOKE SESSIONS. The reference is based on other models, not confirmed incident ground truth, so the example does not prove which action was right. It does show that a valid answer is not necessarily a safe answer.
TypeSafe is fairly open about the limitations of its evaluations. The headline speed and cost comparisons may be at the high end of what teams see in practice. Its team wrote the workflows, and the reference answers come from other AI models. Its confidence guidance also says thresholds should depend on the risk of the action.
So my first experiment would be simple: pick one alert family, replay a set of old cases with known outcomes, and run Jev in shadow mode. Measure the misses, false alarms, latency, and what happens when it is unsure or unavailable. Only after that would I consider automating a small, low-risk part of the workflow.
I do not think Jev will replace analysts, malware sandboxes, or security rules. What interests me is something less flashy: putting a quick judgment in the many places where security teams currently wait for a human to sort the obvious from the interesting. If Jev proves reliable enough for those specific jobs, that could be a big deal.