What is the difference between pre-runtime, runtime, and post-runtime AI security?
AI security tooling clusters at three points in the application lifecycle. Pre-runtime works before deployment: scanning code and models, checking dependencies, red-teaming, evaluating prompts in a test harness. Runtime works while the application runs, enforcing a decision at the moment untrusted input meets the model or an action is about to execute. Post-runtime works after the fact: logging, tracing, evaluation, and anomaly detection.
Being precise about which problem each stage solves prevents an expensive category error: buying a tool from one cluster to solve a problem that only another cluster can address. The most common version of that error is expecting pre-runtime testing or post-runtime monitoring to stop an attack arriving in live traffic. Neither can, and neither claims to on close reading, but procurement often reads them as interchangeable "AI security."
What does each stage actually cover?
| Stage | Typical tooling | What it prevents | Structural limit |
|---|---|---|---|
| Pre-runtime | Static analysis, dependency and model scanning, red-teaming, prompt evaluation harnesses, benchmark suites | Ships fewer vulnerable dependencies, weak prompts, and known-bad model behaviors | Never sees live input, so it cannot stop an attack that arrives after deployment |
| Runtime | In-code enforcement, input and output inspection, budgets, action-level authorization | The action itself: the tool call that does not execute, the data that does not leave | Must be fast enough for the request path and needs application context to decide well |
| Post-runtime | Logging, tracing, LLM observability, evaluation, anomaly detection, SIEM integration | Nothing directly. It shortens time-to-detection and makes investigation possible | Retrospective by nature, so it tells you an action happened after it happened |
A complete program uses all three. They are not substitutes. Only runtime enforcement can prevent an outcome in real time.
Detection and enforcement are different products
Many tools describe themselves as "runtime" when what they do is detection.
- Detection observes and reports. Its output is an alert, a score, or a trace. Its value is investigation, measurement, and tuning.
- Enforcement sits in the path and returns a decision that your code acts on before proceeding. Its output is an action that didn't happen.
Only one prevents the outcome.
The confusion is understandable, because detection tooling frequently runs during runtime. Such a tool is temporally runtime but functionally post-runtime. A model-output classifier that scores every response and writes findings to a dashboard is operating live, but if the response has already been returned to the user, then it hasn't prevented anything.
How do you tell detection and enforcement apart?
One question separates them reliably:
If this tool fires, does the action still execute?
If the answer is yes, it is detection, regardless of how it is marketed. If the answer is no, meaning your code receives a decision and acts on it before proceeding, it is enforcement.
Two follow-ups sharpen the test further. Where does the decision arrive? Enforcement returns a value into your application's control flow, while detection writes to a separate system. And what happens when the tool is unavailable? An enforcement layer forces you to answer that question explicitly, because the application can't proceed without a decision. A detection layer can be down for an hour and the application never notices, which is precisely the property that makes it unsuitable as a control.
Where do common tool categories fall?
| Category | Stage | Detection or enforcement | Best used for |
|---|---|---|---|
| Model and dependency scanners | Pre-runtime | Detection | Supply chain and known-vulnerable components |
| Red-teaming and eval harnesses | Pre-runtime | Detection | Measuring model behavior before release |
| WAF and edge proxy | Runtime | Enforcement | Network-layer and inbound HTTP threats |
| AI gateway | Runtime | Mixed | Provider routing, token accounting, model traffic policy |
| In-code controls | Runtime | Enforcement | Action authorization, budgets, input and output inspection |
| LLM observability platforms | Post-runtime | Detection | Tracing, evaluation, regression measurement |
| SIEM and anomaly detection | Post-runtime | Detection | Investigation and correlation across systems |
The gateway row is genuinely mixed, so read it carefully when you evaluate a gateway. An AI gateway can enforce on model traffic by rejecting a call, capping tokens, or routing away from a provider, which is real enforcement within its scope. What it typically can't do is authorize the tool call that the model's response triggers, because that execution happens inside your application after the gateway has returned.
Why does the enforcement layer get skipped?
It is the hardest of the three to add, for two reasons that pull against each other.
It must be fast enough to sit in the request path. Latency added here is latency that every user experiences, so the budget is small: single-digit or low-tens of milliseconds for most controls, and a hard ceiling on anything in a synchronous flow.
And it needs application context to make a decision worth making, including the user, the tool, the arguments, the target object, and the tenant. Edge tools can enforce but lack that context, because they see an HTTP request rather than an authorization question. Pre- and post-runtime tools have all the context in the world but can't intervene in time.
The result is a gap that is easy to miss on an architecture diagram, because both neighbors are occupied. A team with a WAF at the edge and an observability platform on the backend can reasonably believe the middle is covered, right up until an agent takes an authorized-looking action that neither layer was positioned to stop.
How do you evaluate AI security tools?
The following questions tend to separate the options:
- If this fires, does the action still execute? The enforcement test described earlier.
- What context does it have at decision time? Can it see the authenticated user and the specific object being modified, or only the request envelope?
- Where does inspection happen? Cloud-side inspection means your request bodies or prompts leave your environment to be analyzed, which is a data-residency question before it is a security one. See keeping security inspection local.
- What is the latency, and is it in the synchronous path?
- What happens when it is unavailable? Fail-open, fail-closed, and whether that is configurable per action.
- Does it cover non-HTTP paths? Tool calls, MCP servers, queue consumers, and scheduled jobs have no request object for perimeter tooling to inspect.
- Can it run in dry run first? Any probabilistic control must be measurable against your own traffic before it starts blocking.
The OWASP Top 10 for LLM Applications is a useful cross-check on coverage claims. Map each vendor's stated protections onto those risks and note which ones nothing in your stack addresses. For more information about runtime prompt-injection detection on LangChain, LlamaIndex, and Vercel AI SDK apps, see prompt injection protection for those stacks.
What does a complete program look like?
Defense in depth here means having all three stages and being honest about which layer is actually stopping a given attack.
Pre-runtime reduces what you ship. Runtime stops what arrives. Post-runtime tells you what happened and feeds tuning back into the other two. The feedback loop between post-runtime measurement and runtime enforcement is the part that teams most often leave unbuilt. Detection data tells you where to set a threshold. Without it, enforcement thresholds get chosen arbitrarily and then never revisited.
A reasonable sequence for a team adding AI security to an existing application starts with instrumentation, so you can see what your traffic actually looks like. Then add enforcement in dry run against the risks that you can already articulate, measure the result, and enforce, starting with the actions whose consequences are worst.
Where Arcjet fits
Arcjet is the runtime enforcement layer: budgets against cost explosion, prompt injection detection against unauthorized side effects, and local sensitive-information detection against data exfiltration. Each returns a decision that your code acts on before it proceeds. It runs in non-HTTP paths through Guards, so tool calls and queue jobs use the same decision model as HTTP routes.
Arcjet doesn't replace pre-runtime scanning or post-runtime observability. It fills the gap between them.
A direct Guard call fails open (allow with error codes). Vercel AI SDK and LangChain wrappers fail closed unless you opt into continuing on error. HTTP request checks can fail open when Arcjet's cloud can't be reached; that behavior is configurable.
Summary
Pre-runtime, runtime, and post-runtime tooling solve different problems and are not substitutes. Within runtime, detection and enforcement are also different: only enforcement returns a decision that your code acts on before the action executes. When evaluating any tool that markets itself as runtime AI security, ask whether the action still happens when it fires. Everything else follows from that answer.
Learn more: AI runtime protection
Frequently asked questions
What is the difference between detection and enforcement in AI security?
Detection observes and reports, so its output is an alert, score, or trace. Enforcement sits in the path and returns a decision your code acts on before proceeding, so its output is an action that did not happen. The test is simple: if the tool fires, does the action still execute? If yes, it is detection regardless of marketing.
Is an AI gateway enough to secure an AI application?
No. An AI gateway governs traffic between your application and model providers, and can enforce within that scope. It typically cannot authorize the tool call the model's response triggers, because that executes inside your application after the gateway has returned.
Why do teams skip the runtime enforcement layer?
It is the hardest layer to add, because it must be fast enough to sit in the request path while also holding the application context needed to make a good decision. Edge tools can enforce but lack context; pre- and post-runtime tools have context but cannot intervene in time.
Do I still need pre-runtime scanning and post-runtime observability?
Yes. They are not substitutes for each other. Pre-runtime reduces what you ship, runtime stops what arrives, and post-runtime tells you what happened and supplies the measurement that sets runtime thresholds sensibly.
AI runtime security in your code
Protect your AI agent workflows with Arcjet
A decision in the path before the action runs. Get runtime enforcement you act on before the tool call.