Arcjet AI security models - A family of custom-trained security models for coding agents
by•
Arcjet is launching a family of custom AI security models designed for analyzing AI agent activity: Arcjet Himalia 1, a general purpose prompt injection model, live today for every SDK call that uses prompt injection detection, and specialist versions designed for situations that general models handle badly, Arcjet Thebe 1 for coding agents, and Arcjet Carme 1, for autonomous security agents.
Replies
tiny classifiers for prompt injection is smart, way cheaper than frontier models 🔥 gonna be usefull for coding agents. congrats!
Since the models are fine-tuned from Qwen 3 0.6B, can you run them locally or self-hosted, or is it only through the SDK call to your API?
Does it show which line in a README triggered the alert?
a small classifier giving a verdict in milliseconds instead of sending every tool call to a frontier model is hte only way this works at scale, nobody wants to pay frontier prices just to check each prompt
how do you handle false positives with Thebe 1??? coding agents read so much weird stuff from repos and docs, i'd expect a lot of legit content to look like an injection
Thanks @thamibenjelloun, this is indeed a problem which is why we have a use-case specific model for coding agents and autonomous security agents. When the models detect something suspicious, a secondary decision model evaluates the whole session in context so we can detect whether the prompt could actually cause a risky action. This helps to significantly reduce the number of false positives.
If Himalia flags a prompt injection inside a tool result mid run, does it block just that tool output or kill the whole agent session?
@igorblink if Arcjet detects prompt injection in the tool result for coding agents, subsequent risky actions are blocked, but not the whole session. This allows the session to continue locally, but prevent the true risky actions. For custom agents where you use our SDK, you can decide how you want to proceed. You get the full result back into code so you can choose how the manage the detectors.
The distinction between Himalia being live and the specialist models being in preview is useful. Keeping the model version visible with each verdict would help teams compare behavior as those previews develop.
How does Thebe handle security tests that deliberately contain prompt injections? Curious how it distinguishes the test data from instructions aimed at the agent.
@marianna_tymchuk the training datasets are different, so we have specifically labeled training data and evals to help with accuracy. Then a secondary decision model runs on all the detections to understand the context. The prompt detection (from the prompt, tool output, API calls, etc) runs first and then the decision model evaluates whether it's a true attack or not. It's that second step that understands the context e.g. test files containing attack evals.
we do browser automation for agents and most injections I see are hidden text in the web page, not in the user prompt. do you scan tool results (page content) before the agent reads them, or only what the user types? and how much latency does it add per tool call?
Yes, @raphael_millet2 , direct prompt injection isn't really that common - it's too obvious. The main threats come from indirect prompt injection through tool results, particularly web pages and third-party APIs. Arcjet scans all the inputs, whether from prompt, tool, or API result.
Using small classifiers that return a verdict in milliseconds, with a larger model only on suspicious hits, is a sensible split. How often does that second decision step end up running in a typical session?
@neerajnathany the second decision is triggered by a detection from the first model. This is detect and verify, with two specialist models working on different context. That helps to reduce false positives.
When the small model flags a step and the big model is reading the whole session, does the agent pause and wait, or keep going while that check runs? If it keeps going, a couple of risky calls could land before the verdict comes back.
@0x47xavier we do both synchronous and asynchronous analysis, so we can block individual actions and continually scan the overall session. Analysis happens in 10s or low 100s of milliseconds, so there is minimal latency blocking the coding agent whilst it's waiting for a response.
Low 100s of ms is fine for a pause. What I'd want to see is the session-scan side. If it flags something three steps later, does the agent get told which earlier step tripped it, or does it just get stopped?