Article URL: https://www.tirreno.com/bat/2026-04-16 Comments URL: https://news.ycombinator.com/item?id=47799486 Points: 1 # Comments: 0
Article URL: https://www.tirreno.com/bat/2026-04-16
Comments URL: https://news.ycombinator.com/item?id=47799486
"Runtime security" in the AI vendor pitch usually means request-time: inspect the prompt as it arrives, inspect the response as it leaves, block if either looks wrong. This is one runtime. It is where prompt injection classifiers, jailbreak detectors, toxicity filters, output moderation, and guardrails frameworks operate. Recent leaked source code from an AI application has shown that even a regex is sometimes enough to do this job.
There is a second runtime that most of the category does not address. The user's interaction with your AI product unfolds across turns, sessions, and days. An attacker's interaction unfolds the same way. The abuse patterns that matter are often shaped at this longer timescale. Progressive jailbreaks across dozens of turns where each individual turn passes content filters. Cost attacks that look fine request-by-request and devastate budgets in aggregate. Tool-use patterns drifting out of the normal envelope after an indirect prompt injection upstream. Credential-stuffed accounts being used for content generation abuse.
None of these attacks look wrong at the request level. They look wrong at the trajectory level, the economic level, or the cross-entity level. An inline defense cannot reason about the account sending the request. It sees the prompt and it does not see that this account has been probing for a week. The inline filter is right not to try — that is not its job. Its job is to decide about this request, fast. The question is who is doing the other job.
Behavioural runtime security for AI products is the layer that watches patterns across time rather than inspecting individual requests. It does not sit in the request path. It runs alongside the inline defenses, collecting events from your application as they happen, and surfaces the patterns that only become visible when you look at requests all together.
The events it needs are familiar to anyone who has instrumented an application for user monitoring: authentication events, session starts, prompt submissions with metadata, token counts, cost attribution. The patterns that matter are expressed over these entities.
tirreno is an open-source security framework built on these primitives. The event pipeline, the entity model, the rule engine, and the scoring system are the same whether you are monitoring logins against a SaaS application, API traffic on a public endpoint, or prompt submissions against an AI product. You do not need a SaaS platform or a vendor contract to run behavioural security for your GenAI. You run it on your own infrastructure, today.