AI Runtime Security and Guardrails Buyer's Guide

AI runtime security products promise to stop prompt injection, data leakage and unsafe agent actions while your AI applications are live, but no product can make a language model reliably separate instructions from data. That gap between the promise and what is technically possible is where most buying mistakes happen. This vendor-neutral buyer's guide covers the runtime layer only: products that sit in the path of prompts, retrieved content, model outputs and agent tool calls in production. Posture management, AI discovery and governance tooling are covered in the AI Security Platform Buyer's Guide, and the engineering detail of building guardrails yourself is in the AI Guardrails and AI Firewalls Guide. It is written for security architects, AppSec leads and platform teams running a selection.

Key takeaways

Buy for impact reduction, not prevention. OWASP states it is unclear whether fool-proof prevention of prompt injection exists, and the UK NCSC says it may never be fully mitigated. A product that claims otherwise has failed your first test.
Tool-call control matters more than text filtering. For agents, the most valuable runtime control is a deterministic check on what the agent is about to do, with which identity and permissions, not a classifier score on the prompt.
Test on your own traffic. Detection rates on a vendor's benchmark tell you little. Measure detection, false positives and added latency on your applications, your languages and your retrieval sources.
Decide fail-open or fail-closed before you deploy. An inline guardrail is now a dependency of every AI feature. Know what happens when it times out, and who can bypass it.
The guardrail sees your most sensitive data. Prompts and outputs carry customer data, source code and secrets. Data residency, retention and whether the vendor trains on your traffic are first-order selection criteria.

What the category does

AI runtime security covers controls that inspect and act on AI traffic while the application is running. Analysts and vendors use overlapping labels: AI firewall, LLM firewall, guardrails, AI runtime defence, AI application protection and agent runtime security. Strip away the labels and the products do some combination of five jobs.

Control point	What it inspects	Typical actions	Main threats addressed
Input inspection	User prompts, uploaded files, conversation history	Block, redact, warn, log, route to a safer model	Direct prompt injection and jailbreaks (OWASP LLM01, ATLAS AML.T0051, AML.T0054)
Retrieved content inspection	RAG chunks, web pages, emails, documents and tool results fed to the model	Strip or quarantine instructions, tag untrusted content, drop the chunk	Indirect prompt injection
Output inspection	Model responses before they reach the user or a downstream system	Redact PII and secrets, remove links and images, enforce output schema, block	Sensitive information disclosure (LLM02), data leakage (AML.T0057), improper output handling (LLM05), system prompt leakage (LLM07)
Tool-call and action control	Function calls, MCP tool invocations, API calls an agent wants to make	Allow, deny, require human approval, constrain parameters	Excessive agency (LLM06), agent tool invocation abuse (AML.T0053)
Consumption control	Request volume, token counts, cost per identity	Rate limit, quota, throttle, alert	Unbounded consumption and denial of wallet (LLM10)

Detection methods behind these control points fall into three families: deterministic rules (regular expressions, allow-lists, schema validation, URL and domain policies), trained classifiers (prompt injection, toxicity, PII and topic classifiers) and LLM-as-judge evaluations. Deterministic controls are predictable and cheap but narrow. Classifiers are fast but probabilistic. LLM judges are flexible but slow, costly and themselves open to manipulation. Good products combine all three and let you choose per policy.

What the category does not do: it does not discover shadow AI use across your estate, assess the posture of your AI cloud resources, run scheduled red team campaigns or produce governance records for regulators. Some platforms bundle those functions, which is fine, but evaluate the runtime layer on its own merits.

When you need it

Not every AI deployment needs a dedicated runtime product. The decision depends on who supplies the content the model reads and what the model can do with it.

Situation	Runtime product needed?	Why
Internal chat assistant, no retrieval, no tools	Usually not; use platform-native content filters and logging	Low blast radius; the main risk is data entered by staff, better handled by DLP and usage policy
RAG over internal documents	Often, mainly for output redaction and logging	Retrieved documents can carry instructions; outputs can expose data a user should not see. Fix permissions first: see the Permission-Aware RAG Guide
Customer-facing chatbot	Yes	Untrusted users at volume, reputational exposure, cost abuse, brand and topic policy
Assistant that reads external email, tickets, web forms or web pages	Yes, with strong output and link controls	Indirect injection from attacker-controlled content is the dominant risk
Agents with write actions (send email, change records, run code, move money)	Yes, and tool-call control is the priority	A manipulated agent acts with real credentials; text filtering alone is not enough
Many teams calling several model providers	Yes, usually via a gateway pattern	Central policy, logging and quotas instead of one integration per team. See the AI Gateway and LLM Gateway Guide

Small organisations: start with the guardrail features of your model provider or cloud AI platform, strict output link policies and least-privilege tool credentials. A separate product earns its cost once you have several AI applications or any agent with write access. Large organisations: the deciding factor is usually central policy and evidence across many teams and providers, which pushes towards a gateway or sidecar model with one policy engine.

Must-have capabilities

Coverage of all three content paths: user input, retrieved and tool-returned content, and model output. A product that only scans user prompts misses indirect injection, which is the route in most published agent incidents.
Output controls for exfiltration channels: removal or rewriting of links, images and reference-style Markdown, with a domain allow-list you manage. The EchoLeak 2025 Copilot zero-click case shows why: hidden instructions in an email got past the injection classifiers, and data left through Markdown that was not stripped.
Deterministic tool-call policy: per agent and per tool allow and deny rules, parameter constraints (for example, recipients only in your own domain), and human approval for high-impact actions. Policy must be evaluated in code outside the model, as both OWASP LLM01 and the NCSC recommend.
Identity awareness: every decision should record which user, application, agent and credential was involved. Without this, you cannot investigate or apply per-identity quotas.
Sensitive data detection that includes secrets: API keys, tokens, connection strings and private keys in prompts and outputs, not only personal data. Redaction should be reversible only where you choose.
Tunable policies per application: thresholds, actions and categories set per app and per route, with a monitor-only mode that logs what would have been blocked.
Consumption limits: per identity rate limits, token quotas and cost alerts, which OWASP LLM10 lists as core mitigations for denial of wallet.
Complete, exportable logging: inputs, outputs, intermediate states, tool calls, decisions and errors, delivered to your SIEM. This matches the logging guidance in the joint agency paper Deploying AI Systems Securely.
Explainable decisions: each block or redaction shows the rule or classifier, the score and the text span, so analysts can tune rather than guess.

Evaluation criteria

Criterion	What good looks like	How to test it
Detection quality	Published method; results on your test set for direct and indirect injection, jailbreaks and leakage	Run your own labelled corpus, including multilingual and encoded variants
False positive rate	Low enough that teams keep blocking enabled	Replay a week of real, benign traffic in monitor mode and count blocks
Latency	Added p95 and p99 latency stated and measured, including streaming responses	Load test at your peak request rate with your average prompt length
Streaming support	Output inspection that works on streamed tokens without breaking user experience	Test a long streamed response with a secret planted near the end
Agent and protocol support	Function calling formats, MCP traffic and the agent frameworks you use	Run one real agent with at least three tools through the product
Policy as code	Policies versioned, reviewed and deployed through your pipeline	Change a rule through a pull request and confirm audit history
Data handling	Region choice, configurable retention, no training on customer traffic, self-hosting option	Read the contract and data processing terms, not the marketing page
Resilience	Documented fail-open and fail-closed behaviour, timeouts and health checks	Kill the guardrail service during the POC and observe the application
Framework mapping	Findings mapped to OWASP LLM Top 10 2025 and MITRE ATLAS IDs	Check that mappings are specific, not one label on everything

Questions to ask vendors

Show us an indirect prompt injection planted in a document in our retrieval store being caught, and show us one that your product misses. What limits the damage then?
Which detections are deterministic and which are model-based? Can we run deterministic rules alone for regulated flows?
How do you handle reference-style Markdown, image URLs, HTML and encoded links in model output?
How are tool-call policies expressed? Can we constrain parameters, require approval and deny by default per agent?
What identity context do you record per decision: end user, application, agent, model credential?
What is the measured added latency at p95 for our prompt sizes, with and without an LLM judge?
What happens when your service is unreachable? Who can switch the product to bypass, and is that logged?
Where are prompts and outputs processed and stored, for how long, and are they used to train or tune any model?
How often are detection models updated, how are updates tested, and can we pin a version?
How does the product protect its own administrative interface and API keys? Who at your company can see our traffic?

Deployment and integration

Runtime products deploy in four patterns. The pattern often matters more than the detection engine because it decides what traffic is covered.

Pattern	Coverage	Strengths	Weaknesses
Inline proxy or AI gateway	All traffic routed through it	Central policy, no code change per app, quotas and logging in one place	Bypassed by teams calling providers directly; single point of failure
SDK or library in the application	Only instrumented apps	Sees application context, retrieved chunks and tool calls precisely	Needs developer adoption and upgrades per app
API called by the application	Only calls the developer makes	Flexible; easy to add to one path	Easy to forget a path; developers decide what is checked
Agent framework or MCP layer hook	Agent tool calls and tool results	Best place for action control	Framework specific; coverage changes as frameworks change. See the MCP Gateway Buyers Guide

A phased rollout that works in practice:

Inventory and choose two pilot applications: one customer-facing assistant and one agent with tools. Record which model providers, credentials and retrieval sources each uses.
Close the bypass routes first: restrict model provider API keys so production traffic must pass the chosen control point. Treat those keys as non-human identities with owners and rotation. See the LLMjacking Guide.
Run in monitor-only mode for two to four weeks: log every would-be block, review a sample daily and tune thresholds per application.
Enable deterministic controls in block mode first: link and domain policy, secret redaction, schema validation and tool-call deny rules. These have predictable false positive rates.
Enable classifier blocking per route: start where the content supplier is untrusted (public chat, inbound email) and keep monitor mode for trusted internal flows until false positives are understood.
Wire logs and alerts to the SOC: forward decisions, tool calls and failures to the SIEM with identity fields, and write detection rules for repeated blocks from one identity.
Define rollback: a documented, logged bypass switch per application, owned by a named role, with a time limit and automatic re-enable.

Metrics that show it is working: percentage of AI production traffic passing the control point; false positive rate per application after tuning; added p95 latency; mean time to tune a reported false positive; number of high-impact tool calls blocked or sent for approval; and number of direct provider calls detected outside the control point.

Pitfalls

Treating the guardrail as the only control: an agent that holds broad credentials stays dangerous whatever the filter does. In the ForcedLeak Agentforce case, instructions in a public web form led an agent to query other CRM records with its own access, and data left through an expired domain still on an allow-list. Least privilege and a maintained URL allow-list were the fixes that mattered.
Phrase deny-lists: blocking strings such as "ignore previous instructions" gives false comfort; the NCSC notes attackers can rephrase endlessly.
Scanning only the user prompt: leaves retrieved content and tool results, the indirect injection path, unchecked.
Unmeasured fail-open: timeouts default to allow and nobody notices that the guardrail has been silently skipped for days.
Logging without ownership: prompts and outputs are logged in full and become a new store of sensitive data with no retention policy or access control.
Benchmark-driven selection: choosing on a vendor leaderboard result rather than your own corpus and languages.

Red flags

Claims to prevent all prompt injection or to make an agent "safe" without changes to permissions.
No way to see why a request was blocked.
Vague answers on where prompts and outputs are stored or whether they train vendor models.
Tool-call control that is only a classifier score, with no deterministic deny-by-default option.
No support for retrieved content or tool results, only user prompts.
Latency figures quoted only as averages, or only without streaming.

Proof of concept

Build a labelled test set of 300 to 1,000 cases: direct injection, indirect injection inside documents and emails, jailbreaks, secret and PII leakage, exfiltration through links and images, and an equal volume of normal traffic from your logs.
Run each shortlisted product against the same two pilot applications in monitor mode with identical policies.
Measure detection rate per attack class, false positive rate on benign traffic, p95 and p99 latency, and analyst time to explain five random decisions.
Run an agent scenario: an injected instruction that tries to send data to an external address. Confirm the tool-call policy stops it even when the text detector does not.
Run failure tests: stop the service, exceed quotas and push a policy change through your pipeline.
Have legal and privacy review the data processing terms before scoring is final.

Buyer checklist

Runtime scope agreed: which applications, agents and content paths are in scope, and which are left to posture or governance tooling.
Model provider keys restricted so production traffic cannot bypass the control point.
Input, retrieved content and output inspection all demonstrated on your data.
Deterministic tool-call policy with human approval for high-impact actions demonstrated on a real agent.
Link, image and domain allow-list controls tested against Markdown and encoded variants.
Latency, streaming and fail-open or fail-closed behaviour measured and documented.
Logs with identity fields reaching the SIEM, with retention and access control agreed.
Data residency, retention and no-training terms in the contract.
Rollback and bypass switch defined, owned and logged.
Coverage mapped to OWASP LLM Top 10 2025 and MITRE ATLAS, and to NIST SP 800-53 SI-4, SI-10 and AU-6 for audit evidence.

Standards and references

How NHI Mgmt Group can help

We provide independent AI security and agentic AI identity advisory and evaluation support, including test set design and proof of concept scoring for runtime controls. Browse vendors in our products directory or contact us.

AI Runtime Security and Guardrails Buyer’s Guide: How to evaluate prompt, output and agent controls