AI runtime security

April 16, 2026 · 3 min read

"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.

The behavioural layer

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.

Why both layers belong

The inline layer and the behavioural layer are not competitors. They do different jobs and fail in different ways. Inline defenses fail when the attack does not look wrong in isolation. Behavioural defenses fail when the attack is a single obvious request that never gets a second chance. A product with one layer and not the other has a clear blind spot.

When signals from both layers combine, decisions are stronger than either layer alone. A prompt injection attempt that an inline filter catches is one event. A prompt injection attempt from an account that has been probing for a week, from a new device, with a cost pattern suggesting an attack in progress, is a different matter entirely. The behavioural context changes what the single detection means. The inline detection tells you this request is bad. The behavioural context tells you this user is bad.

One framework that grows with your product

The abuse patterns in AI products are still being discovered. Progressive jailbreaks looked different a year ago than they do now. Cost attacks evolve as model pricing changes. Indirect prompt injection is a category that barely existed before agents started retrieving untrusted content into their context. The patterns your product will face in six months are not all visible today. An open-source security framework grows with that reality. When a new attack shape appears, you write rules for it against the data you are already collecting. You do not wait for a vendor roadmap. One framework, one data model, rules that you author and own.

Your data, your infrastructure

The data that powers AI runtime security is the most detailed record of GenAI product usage your team generates. Prompt metadata, session histories, cost attribution per user, device and IP inventories, tool-use timelines for agentic workflows. This is exactly the data that AI companies are most careful about sending to third parties, and therefore belongs on-premises. You do not have to choose between behavioural monitoring and data control. You get both.

What GenAI products should implement

The gap most GenAI products have today is not on the inline layer. That layer is crowded with tooling and receives most of the attention. The gap is on the behavioural layer, where most teams have limited visibility into how their product is actually being used and abused.

Every prompt submission, every authentication event, every tool call, every cost-accruing operation — these are the events the behavioural layer runs on. Collect them, and the patterns become visible. Skip them, and at some point you might lose control over your product.

Star on tirreno GitHub