What is runtime application security?
Runtime application security is the practice of enforcing security controls while an application runs, at the moment untrusted input reaches your code or an action is about to execute. That is different from enforcing before deployment (scanning and testing) or after the fact (logging and monitoring). Runtime security acts in the request path, using the application's own context, to allow, block, or flag behavior as it happens.
The defining property is that a runtime control returns a decision your code acts on before proceeding. A scanner tells you about a weakness in code that you haven't shipped yet. A monitor tells you about a request that already completed. A runtime control sits between the request and its effect, and its output is an action that didn't happen.
Where does runtime sit in the security lifecycle?
Security work falls into three stages:
- Pre-runtime: static analysis, dependency scanning, penetration testing, model red-teaming. Catches issues before shipping. Can't stop an attack that arrives in live input, because it never sees live input.
- Runtime: enforcement while the application runs. The stage where a control stops an attack in real traffic.
- Post-runtime: logging, monitoring, anomaly detection, SIEM correlation. Essential for investigation and tuning. Retrospective by nature.
A complete program uses all three. Runtime is the one that teams most often lack, because it has to satisfy two constraints at once: fast enough for the request path, and holding enough application context to make a good decision. Pre- and post-runtime tools face neither constraint. For more information about that trade-off, see pre-runtime vs post-runtime AI security tooling.
What does runtime application security enforce?
The specific controls vary by application, but the common set includes the following:
- Rate limiting, constraining how often an identity can perform an expensive or sensitive operation. See the rate limiting guide for algorithm and identifier selection.
- Bot detection, distinguishing automated clients from human users, and good bots from bad.
- Attack pattern detection, covering SQL injection, cross-site scripting, path traversal, and the rest of the conventional web attack classes.
- Input validation, rejecting malformed or out-of-contract requests before they reach business logic.
- Email and signup validation, blocking disposable domains and invalid addresses at the point of account creation.
For applications with AI features, the set extends to the following controls:
- Prompt injection detection on input and on external content re-entering model context.
- Token and spend budgets keyed on an identity and shared by that key across tool calls, rather than by how many times a workflow starts.
- Sensitive-information detection on inputs, outputs, logs, and embeddings.
For more information about the AI-specific controls, see runtime security for LLM applications. See also how to detect and block attacks at runtime and how to implement the OWASP Top 10 for LLM Applications.
Why does enforcing in code matter?
Two reasons: context and reach.
Context. At the network edge you see packets, IP addresses, TLS fingerprints, and headers. Inside the application you see the authenticated user, their plan and entitlements, the route, the specific object being modified, the tenant it belongs to, and the parsed request body. That difference determines which decisions are even possible. The edge can answer "Is this request rate-limited?" It can't answer "Is this user allowed to modify this object?", because the edge doesn't know who the user is or what the object is.
This is why broken object-level authorization remains the top entry in the OWASP API Security Top 10. It is an application-context question, and perimeter tooling is structurally unable to answer it. For more information about the mechanics, see what is API abuse.
Reach. Enforcement in code extends to paths that never involve HTTP, including agent tool calls, queue consumers, workflow steps, and scheduled jobs. Perimeter tools can't see these paths, not because they are badly built but because no request passes through them. As applications take on more background and agentic work, the share of consequential actions that never cross the perimeter grows.
Application-layer runtime security vs network security
These are complementary layers, not competing products. The following table compares what each layer is positioned to know and do.
| Dimension | Network or edge security | Application-layer runtime security |
|---|---|---|
| Visibility | IP, headers, TLS characteristics, raw payload bytes | Authenticated user, entitlements, route, parsed body, target object, tenant |
| Decisions it can make | Volumetric limits, IP reputation, signature matching, geo rules | Everything the edge can decide, plus per-user, per-object, and per-action authorization |
| Coverage of non-HTTP paths | None, because there is no request to inspect | Full, because the control lives in the function being called |
| Deployment | Infrastructure change, usually a separate team | A dependency and code change, owned by the application team |
| Affected area of a mistake | Can affect all traffic to the origin | Scoped to the route or function it is applied to |
| Protects against | Volumetric DDoS, known-bad sources, generic attack signatures | Business-logic abuse, authorization failures, agent actions, targeted automation |
The practical reading is to keep the edge for what only the edge can do, which is absorbing volumetric attacks before they reach your origin. Put the decisions that need identity or business context where that context exists.
Application code vs WAF vs API gateway
| WAF | API gateway | In application code | |
|---|---|---|---|
| Primary role | Filter malicious HTTP traffic | Route, authenticate, and meter API traffic | Enforce policy inside application logic |
| Knows the authenticated user | No | Sometimes, from token claims rather than application state | Yes |
| Knows the target object | No | No | Yes |
| Covers background jobs and tool calls | No | No | Yes |
| Configuration lives in | Infrastructure | Gateway configuration or infrastructure | Version control, alongside the code it protects |
| Testable in CI | Rarely | Partially | Yes, because it is ordinary application code |
You review security rules that live in application code in pull requests, test them in CI, and deploy and roll them back with the feature they protect. Rules that live in a separate console drift from the application they defend, and teams usually find the drift during an incident. For the full comparison, see SDK-based security vs WAF vs API gateway.
How do you add runtime security to an application?
The following sequence avoids the common failure of turning on enforcement everywhere at once:
- Inventory the consequential actions. Not routes, but actions. Which operations spend money, move data, send messages, or can't be undone?
- Start with the worst few. Apply controls where a failure is most expensive, rather than uniformly across the surface.
- Deploy in dry run. Configure any control with a probabilistic component to report decisions without enforcing them until you have measured it against your own traffic.
- Decide failure behavior per action. Don't make a search endpoint and a refund endpoint fail the same way when a security dependency is unreachable.
- Enforce, then widen. Move dry-run controls to blocking on the highest-risk actions first, then extend outward.
- Record decisions with enough context to investigate. A block that you can't explain to a customer becomes a control that someone disables.
What happens when a runtime control fails?
This question distinguishes a control that survives contact with production from one that gets removed after its first outage.
Fail-open keeps the application available and the control off. Fail-closed keeps the control on and the application unavailable. Neither is correct in every case. Failing open on a login rate limit during a credential-stuffing campaign is bad, and so is failing closed on a product search page because a security API is slow.
The workable pattern is per-action configuration, a local decision path that still functions when remote state is unavailable, and a timeout short enough that a slow dependency degrades rather than hangs. Controls that can make a useful local decision, such as pattern matching, content inspection, and budgets in the application, must keep working when the network doesn't.
Where Arcjet fits
Arcjet is a runtime security platform that ships with your code. It installs as a library and runs rules inside your application. Rule analysis runs in a local WebAssembly module at under a millisecond of overhead, and a single cloud call covers the controls that need cross-request state, typically 20 ms to 30 ms. Sensitive-information detection runs entirely in the application, so request bodies are never transmitted.
When a security check can't finish (a timeout, a transport issue, or an incomplete policy), you choose what happens next. A direct guard() call returns allow with error codes rather than treating the incomplete check as a denial. Vercel AI SDK and LangChain wrappers fail closed unless you opt into continuing on error. HTTP request checks (protect()) can fail open when Arcjet's cloud can't be reached; that behavior is configurable.
Arcjet is designed to run behind existing CDNs and WAFs rather than replacing them, adding the application awareness that those layers structurally lack. It also extends to non-HTTP paths through Guards, so tool calls and background jobs use the same decision model as routes. Inbound agent traffic on HTTP routes is a bot-management problem, covered in AI agent bot management.
Summary
Runtime application security enforces controls while the application runs, in the path of the action, with the application's own context. Its distinguishing property is that the decision arrives before the effect. Pre-runtime testing reduces what you ship, and post-runtime monitoring tells you what happened, but neither is positioned to stop an action in live traffic. The controls that need identity, object, and business context, such as authorization, abuse prevention, and agent action limits, have to run where that context exists: inside the application.
Learn more: Architecture
Frequently asked questions
What is the difference between runtime application security and a WAF?
A WAF filters malicious HTTP traffic at the perimeter using IP addresses, headers, and payload signatures. Runtime application security runs inside the application, where the authenticated user, entitlements, target object, and tenant are known, so it can make authorization decisions a WAF is not positioned to make. They are complementary layers.
How do I add runtime security to my app?
Inventory the consequential actions rather than the routes, apply controls to the highest-impact ones first, deploy in dry run and measure against your own traffic, decide fail-open and fail-closed behavior per action, then move to enforcement and widen from there.
Is application-layer security a replacement for network security?
No. Keep the edge for what only the edge can do, such as absorbing volumetric attacks before they reach your origin, and put decisions requiring identity or business context where that context exists.
Can runtime security protect background jobs and agent tool calls?
Yes, and this is a structural advantage over perimeter tooling. Tool handlers, queue consumers, and scheduled jobs have no request for a proxy to inspect, so enforcement has to live in the function itself.
Application security in your code
Protect your application with Arcjet
Get runtime decisions in the request path, with the application's own context.