Scope & boundaries
This guide covers the four jobs sold as one category — discovering the AI already running, testing it adversarially, enforcing controls in the request path, and covering what an agent can reach rather than only what a model says.
It does not cover policy, model inventory and the evidence an auditor or regulator asks for (AI Governance & Responsible AI), watching quality, cost and drift on traffic that is behaving normally (LLM Observability & Evaluation), or the code, dependencies and pipeline the AI application is built from (DevSecOps & Application Security Testing).
Executive Summary
Every vendor here says they secure AI. Four different things are being sold under that sentence, and buying the wrong one leaves the gap you were worried about exactly where it was.
This category looks like one market and behaves like four. Discovery finds the AI already running in your organization that nobody registered. Red teaming attacks it deliberately before an outsider does. Runtime enforcement sits in the request path and blocks what should not get through. Governance turns all of it into evidence an auditor accepts. Vendors do one or two of these well and describe all four on the homepage.
The decision worth spending time on is therefore not which product is strongest. It is which of the four jobs you are actually missing — and that is answerable in an afternoon by asking who currently knows how many AI applications the organization runs. If nobody does, no amount of runtime enforcement helps, because enforcement only protects what it is deployed in front of.
Why This Became Urgent Before Anyone Budgeted For It
The forcing function is that AI adoption inside most organizations ran ahead of the register of what was adopted. Applications got LLM features, developers wired up agents with tool access, and staff started using assistants that read internal documents — all of it faster than any security function could inventory, let alone govern. Lakera frames the problem exactly this way: agents being built faster than security teams can govern them.
The exposure also changed shape when agents got tools. A chatbot that says something wrong is a content problem, and the worst case is embarrassment. An agent that holds a credential and can be steered into using it is an access problem, and the worst case is whatever that credential reaches. Noma Security frames agent security around knowing who an agent acts as, what it may do, and whether its actions match user intent — three questions that have no equivalent in the chatbot era, and that most organizations cannot answer for a single agent, let alone for all of them.
The awkward part is the timing. Almost none of this was in a budget. AI features were approved as product work, agents arrived through developer tooling that nobody procured, and the security line item for protecting them appears a year later, after the exposure exists. That sequencing has a practical consequence for buyers: the first purchase in this category is usually made under time pressure, in response to an auditor or an incident, and time pressure is exactly the condition under which the most tangible product gets bought rather than the most useful one.
Which type of AI Runtime Security & LLM Guardrails fits your organization?
Building guardrails is genuinely possible here and genuinely a trap. Open frameworks exist — Guardrails AI is a Python framework for building reliable AI applications — and a competent team can validate inputs and outputs without buying anything. What a team cannot easily build is the adversarial research: the catalog of attacks that work this month, maintained by people whose job is finding new ones.
The line falls in a specific place. Input and output validation is a solved engineering problem and a team can own it indefinitely; Guardrails AI is a Python framework for building reliable AI applications, and for a single application with predictable traffic it is a reasonable answer. What decays is coverage. The attacks that matter shift, and a validation layer written in a sprint eighteen months ago protects against the attacks that were known eighteen months ago. Buying, in this category, is mostly buying somebody else's obligation to keep up — which means the renewal question is not whether the product still works, but whether the vendor's research output is still moving.
| Job | What it is for | What it will not do |
|---|---|---|
| Discovery & posture | Finding AI applications, agents, models and tools already in use | Stop anything. It tells you what exists, which is a prerequisite rather than a control. |
| Red teaming | Attacking your own systems before someone else does | Protect production. It produces findings, and findings need somebody to fix them. |
| Runtime enforcement | Blocking attacks in the request path while the system runs | Find what it is not deployed in front of. |
| Governance & evidence | Turning controls into something an auditor accepts | Improve security by itself. It documents the posture you already have. |
| Open-source guardrails | Input and output validation you write and own | Keep pace with adversarial research, which is the part that decays. |
How do you evaluate AI Runtime Security & LLM Guardrails?
Score these products on coverage and on what they cost you in latency, because those are the two axes where the marketing is least useful. Every vendor detects prompt injection in a demo. The questions that separate them are what they see, what they miss, and what they add to every request.
Four things separate these products once the demos are over, and none of them appear on a feature grid. The first is what the product can see: a guardrail deployed as a library sees the calls the application makes to it, a gateway sees everything routed through it, and a network-level control sees traffic without either — Cisco states that it enforces AI security at the network level without agents or libraries, which is a genuinely different coverage model with a genuinely different set of blind spots. The second is what happens on a false positive, and whether the answer is configurable per policy or global. The third is whether agent actions are in scope at all, or only model inputs and outputs; Straiker offers runtime guardrails that detect and block prompt injection, data leakage and tool manipulation in real time, and that third term is the one that separates agent coverage from prompt coverage. The fourth is the research cadence behind the detection content, which is the hardest to evaluate and the one that determines whether the product is still worth its price in year three.
| Capability | What it does | Buyer translation |
|---|---|---|
| AI discovery | Inventories models, applications, agents and tools in use | The prerequisite for everything else. HiddenLayer offers discovery for visibility into AI assets across environments. |
| Runtime enforcement | Inspects and blocks in the request path | Straiker offers runtime guardrails that detect and block prompt injection, data leakage and tool manipulation in real time. |
| Agent and tool security | Covers what an agent can reach, not just what it says | The newer half of the category. Noma Security frames it around whether an agent's actions match user intent. |
| Continuous red teaming | Attacks your systems on a schedule rather than once | Adversa AI offers continuous red teaming for large language models; a point-in-time test ages badly in this field. |
| Deployment topology | Whether it sits inline, as a gateway, or beside the traffic | Decides the latency cost and the blast radius when it fails. Cisco states that it enforces at the network level without agents or libraries. |
| Policy enforcement | Turns a written rule into a runtime control | Fiddler offers models for evaluation and real-time policy enforcement. |
| Supply chain validation | Checks model provenance and integrity before deployment | HiddenLayer validates model integrity and supply chain before deployment — a control that only exists pre-production. |
Which vendors lead in AI Runtime Security & LLM Guardrails?
The camps below are the four jobs plus the two places they get sold from. Vendors move between them — almost everyone is adding discovery — but the camp still tells you what the product was built to do, which is usually what it does best.
One caution about how this market presents itself. Every vendor here now describes the full lifecycle — Lakera describes securing AI agents from discovery to runtime, Cranium describes one platform for AI security, governance and agents, Palo Alto Networks describes a platform spanning development to deployment — and read literally, the category contains a dozen products that all do everything. They do not. The claims are usually true in the sense that some capability exists under each heading; they are misleading in the sense that depth is wildly uneven across those headings, and the depth is almost always concentrated where the company started. Ask each vendor which of the four jobs they would lose a competitive evaluation on. The ones that answer are worth more of your time than the ones that do not.
| Vendor | Approach | Where it fits |
|---|---|---|
| Adversa AI | Adversarial testing | Teams that need findings on a schedule rather than a point-in-time report |
| Zenity | Agent-native security | Organizations where agents hold identity and take consequential actions |
| HiddenLayer | Discovery & posture | Estates where the first job is finding the AI nobody registered |
| Fiddler | Observability-led | Teams whose AI already sits under an evaluation and monitoring platform |
| Lakera | Runtime guardrails | Production applications needing enforcement from discovery through runtime |
| Palo Alto Networks | Security incumbents | Buyers consolidating onto a platform they already run |
One representative of each approach is named here; the category runs to roughly two dozen vendors, and several occupy more than one camp. The camps were written before the vendors were chosen, and no placement here is for sale. Any vendor in this category can speak for themselves in the Spotlight below.
How much should you budget for AI Runtime Security & LLM Guardrails?
Published pricing is rare in this category, which is itself worth knowing before the evaluation starts: almost every vendor here quotes, and the quote is shaped by what they can measure about your estate. That makes the discovery step commercially significant as well as technically necessary — you cannot be quoted accurately for protecting an estate nobody has counted.
Two costs sit outside every pricing table and routinely exceed the license. The first is triage. An inline control that inspects production traffic produces a queue, somebody has to work that queue, and the volume is a function of your traffic rather than of anything the vendor charges for. Budget a person's fraction, and ask in the pilot what the false positive rate was on real requests rather than on the vendor's corpus. The second is latency, which is a cost paid in product rather than in dollars: an enforcement layer in the request path adds to every response, and if the application is customer-facing that shows up as conversion before it shows up anywhere in finance. Fiddler markets its guardrails as the industry's fastest for enforcing enterprise AI policies, which tells you the vendors know this is the axis buyers push on. Measure it yourself, under your own load, before the contract rather than after.
| Basis | You are charged for | Grows with | Where it goes wrong |
|---|---|---|---|
| Per application or endpoint | Each AI application under protection | Adoption | Success. Every new AI feature is a new line. |
| Per agent | Each registered agent | Agent proliferation, which is fast | Estates where agents are created by developers rather than procured |
| Per request or token inspected | Volume through the guardrail | Traffic | Consumer-facing applications, where volume is the product |
| Per seat | People covered | Headcount | Nothing much. It is the most predictable unit here. |
| Platform subscription | A tier, with capacity bands | Whatever the band is measured on | Bands discovered at renewal rather than at signing |
| Red teaming engagement | Tests run, or a subscription to continuous testing | Scope | One-off engagements, which age out of relevance quickly |
| Open source | Nothing, and your team's time | Maintenance burden | Adversarial coverage, which decays without someone owning it |
Pricing in this category is predominantly quoted rather than published, so this section describes the metering bases vendors use rather than rates. Where a vendor does publish, the guide quotes the published figure and says so.
How long does implementation take for AI Runtime Security & LLM Guardrails?
The order matters more here than in most categories, because the first phase determines whether the rest is scoped correctly. Nearly every disappointing deployment in this category began by protecting the applications security already knew about.
Run discovery before choosing an enforcement product. The output is a count, and the count is almost always larger than expected — which changes both the shortlist and the quote. Buying enforcement before this step means sizing against a number nobody verified.
Attack the highest-exposure applications, especially any agent holding credentials or write access. This produces the evidence that funds the rest of the program, and it establishes a baseline the enforcement layer can later be measured against.
Deploy inline on one high-value application in monitor mode before blocking mode. Track what would have been blocked and check whether it should have been. A control that generates false positives at this stage will be disabled at scale, so this is the phase that decides whether the purchase survives.
Widen coverage application by application, and connect the output to whatever produces your audit evidence. Re-run discovery quarterly — the inventory decays continuously, because the thing generating it is developers shipping features.
A security control that inspects AI traffic is not itself an AI system making decisions about people, so the heavier obligations attach to what it protects rather than to the control. What does attach follows the data: an inline guardrail sees every prompt and every response, which routinely include personal data and occasionally credentials. Retention, residency and access control on that inspection path are the real questions, and they are frequently under-specified because the product is bought as security rather than as a data processor.
Classified under the EU AI Act's risk tiers, as they apply to a protective control rather than to the AI system it sits in front of
What should you ask vendors about AI Runtime Security & LLM Guardrails?
Most of these have an answer the vendor knows. The ones that produce a pause are the ones worth the meeting.
-
Can anyone produce a current list of AI applications and agents in use?Yes Move to enforcement and testing. You know what you are protecting.No Buy discovery first. Enforcement protects what it is pointed at, and you cannot point it at what nobody has counted.
-
Do any of those agents hold credentials or take actions?Yes You need agent-native coverage — identity, tool access, MCP. Prompt-level guardrails do not reach this.No Prompt and output guardrails are the right scope, and the market for them is mature.
-
Is the driver an audit rather than an incident?Yes Look at the governance platforms first; this category produces controls, not evidence.No Enforcement and testing, in that order, on the applications discovery ranked highest.