AI agent security

What are the best tools for securing agentic AI workflows?

Content detection judges text. Action enforcement decides operations. Gateways sanction routed traffic. Identity brokers decide whether the agent holds the credential. Observability reconstructs the week. Most production workflows need three of the five, and the tool handler is the layer most often missing.

9 min read
In short: Content detection judges text. Action enforcement decides operations. Gateways sanction routed traffic. Identity brokers decide whether the agent holds the credential. Observability reconstructs the week. Most production workflows need three of the five, and the tool handler is the layer most often missing.

What are the best tools for securing agentic AI workflows?

The right tools for securing an agentic AI workflow are the ones that reach the boundary where the failure happens, not the ones that lead a category. An agentic workflow has six boundaries, no single product covers all six, and the two that teams most often leave uncovered are the tool argument and the tool result.

The following table maps each boundary to the tools that reach it and to what those tools can't do:

BoundaryTools that reach itWhat they can't do
Inbound HTTP requestWAFs, edge bot products, Arcjet, provider guardrailsObserve the tool call that happens four steps later
Inbound prompt textLakera, HiddenLayer, Pillar, Llama Guard, ArcjetJudge whether a clean-looking request is authorized
Retrieved contentThe same detectors, called per chunkRun themselves. You place the call in the retriever
Tool argumentsArcjet, Rein Security, framework hooksBe supplied by a gateway that the call doesn't traverse
Tool resultsIn-process detectors called on the return valueBe covered by an inbound HTTP check
After the factLangfuse, LangSmith, Arize, Braintrust, DatadogChange the outcome of the run they recorded

Rows four and five have no HTTP request behind them. A tool handler receives function arguments. A queue consumer has no Request at all. A tool that attaches to a web route covers four of the six.

Content detection: judging text

Content detection products score a string for prompt injection, jailbreaks, unsafe content, or personally identifiable information (PII).

Lakera, which is part of Check Point, is a dedicated detector with a hosted API that you call before the provider. HiddenLayer, Pillar, Noma, Straiker, and Operant cover adjacent ground. Prompt Security is part of SentinelOne, and Invariant Labs is part of Snyk.

Self-hosted options change the data-residency answer. Llama Guard is a classifier that you run. Microsoft Presidio returns PII spans in-process. Guardrails AI is Guard().validate(text) in Python, and NVIDIA NeMo Guardrails is configuration plus callbacks.

Arcjet is a security library that evaluates its rules inside your application. It runs prompt-injection and sensitive-info detection from the SDK, and sensitive-info classification stays in your process, so the raw body doesn't need a second vendor to label it.

All of these share the limit of what detection is: a judgment about text. The hardest injections read as plausible business requests and carry no attack pattern. A detector that misses one of those is working as designed, which is why detection can't be the only layer. For more information, see how AI security platforms detect prompt injection at runtime.

Action enforcement: deciding operations

Action enforcement is the thin layer, and it's where an agentic workflow differs most from an ordinary web app.

The decision is whether this call, with these arguments, for this user, in this tenant, runs right now. Answering it needs the authenticated session, the parsed arguments, and application state. Those values exist inside your process and nowhere else, which is why the products that can answer it run there too.

Arcjet and Rein Security are in-code examples. Runlayer's hooks integration also runs in-process for local tool calls. Framework hooks, such as Mastra's beforeToolCall, the Claude Agent SDK's PreToolUse, and the Vercel AI SDK's guardTool, are enforcement points where you write the policy yourself.

The following handler combines a tenant-scoped lookup with an Arcjet frequency limit. Arcjet installs as a library and evaluates its rules in your own process rather than at a network hop: launchArcjet creates the client, the token bucket is configured once when the module loads, and arcjet.guard() evaluates it against one refund call and returns a single allow-or-deny decision before the lookup runs:

import { launchArcjet, tokenBucket } from "@arcjet/guard";
const arcjet = launchArcjet({ key: process.env.ARCJET_KEY! });
const refundFrequency = tokenBucket({
bucket: "issue-refund",
refillRate: 5,
intervalSeconds: 3_600,
maxTokens: 5,
});
export async function issueRefund(
args: { invoiceId: string; amountCents: number },
session: { userId: string; tenantId: string; runId: string },
) {
const decision = await arcjet.guard({
label: "tools.issue-refund",
actor: session.userId,
correlationId: session.runId,
rules: [refundFrequency({ key: session.userId, requested: 1 })],
});
if (decision.conclusion === "DENY" || decision.hasFailedOpen()) {
return { error: "Refund denied" };
}
const invoice = await invoices.find({
id: args.invoiceId,
tenantId: session.tenantId,
});
return invoice ? stripe.refunds.create({ charge: invoice.chargeId }) : null;
}

Note which line does the authorization: the tenant-scoped lookup. The guard adds the frequency limit and the audit record. A tool that gets the tenant from the model's arguments has no boundary, regardless of which vendor sits in front of it.

Gateways and control planes: sanctioning traffic

Gateways and control planes sanction the traffic that they route. Runlayer ships an MCP gateway, agent identity and access management (IAM), shadow-AI discovery, and runtime policy. MintMCP, Lunar.dev, Obot, NeuralTrust, and Kong occupy related ground. Onyx Security, Metano, and Cranium AI position as control planes and governance.

A gateway gives you what an SDK doesn't: one catalog of approved servers, one place to revoke, and an audit trail that spans applications you don't own.

The structural limit is routing. A local tool call, a background job, a direct API call, or a client configured around the proxy doesn't reach it. That's not a product flaw. It's what a proxy is.

For the MCP-specific version of this comparison, see which AI security platforms support MCP server security.

Identity: deciding whether the agent holds the credential

Identity brokers decide whether the agent holds a credential at all. Keycard is one example, with Cedar-based policy, default-deny, and delegation that narrows at each agent hop. Aembit, Descope, Astrix, Token Security, and Oak occupy related ground. Consolidation is real here: CrowdStrike acquired SGNL, and Palo Alto Networks closed its CyberArk acquisition, both framed around agent identity.

This layer is a stronger control than it sounds, because an agent with no write token can't perform a write, whatever it's instructed to do. It can't judge whether a permitted action is appropriate in context.

For the design patterns, see AI agent on-behalf-of identity.

Observability: reconstructing what happened

Observability tools reconstruct what an agent did. Langfuse, LangSmith, Arize, and Braintrust provide trace and trajectory analysis. Datadog AI Guard evaluates prompts and tool calls through OpenTelemetry instrumentation, and it can raise an exception before the action when blocking is enabled in the service policy. Capsule Security and Neo Security describe pre-action intervention.

You need this layer. Without traces, you can't answer what the agent did last Tuesday, and that question arrives during an incident and during an audit.

Where the enforcement lives is the thing to check. Instrumentation-based blocking covers the calls that the instrumentation wraps. A path that it doesn't wrap is visible afterwards. For the vendor-specific tradeoff, see Datadog AI Guard compared with Arcjet.

A workable shortlist

Most production agentic workflows need three purchases rather than one platform:

  1. A check in the tool handler. It can deny with the session in scope. This is the layer that's most often missing, and the incident that motivates the project usually lands here. Arcjet, Rein Security, or policy that you write into framework hooks fits.
  2. A detector on every text boundary. Inbound messages, retrieved chunks, and tool results. Check whether it runs in your process or ships the body out, because that decides what you can say about data residency.
  3. Traces. They answer the question that arrives the week after an incident. Any of the observability tools fits.

Add a gateway when you're governing which third-party servers the organization can use, and an identity broker when agents hold long-lived credentials that you'd rather scope down.

Two shortlists go wrong in predictable ways. One buys only a control plane and ships the chat route with no scan. The other buys only a detector and leaves issueRefund open to anything that passes it.

Questions that separate the layers

  • Can you call it from a function, or does it need traffic routed to it?
  • Does it return a decision in time to stop the side effect, or a label that you read afterwards?
  • Does it use the identity that you already authenticated, or one that it issues?
  • Does the raw body leave your environment to be judged?
  • Does it work where there's no HTTP request, such as tool handlers, MCP servers, and queue consumers?
  • Who authors the rule, and does changing it need a deploy?
  • What happens when the check times out, and can you choose per action?

For the layer-by-layer vendor map, see the top AI agent security platforms. For the pre-runtime and post-runtime timescales, see pre-runtime versus post-runtime AI security.

Frequently asked questions

What are the best tools for securing agentic AI workflows?

Most production workflows need three: something in the tool handler that can deny with the session in scope, a detector on every text boundary, and traces for the week-after question. Add a gateway when governing third-party servers, and an identity broker when agents hold long-lived credentials.

Which boundaries do agentic workflows have?

Six: the inbound HTTP request, the inbound prompt text, retrieved content, tool arguments, tool results, and the after-the-fact record. Tool arguments and tool results have no HTTP request behind them, so any tool that attaches to a web route covers four of six.

Why isn't a detector enough on its own?

Detection returns a judgment about text. The hardest injections read as plausible business requests and carry no attack pattern. A workflow where a missed detection still can't produce an unauthorized refund is in a better position than one with a better classifier and an open tool.

What can a gateway not see?

Traffic that it doesn't route. A local tool call, a background job, a direct API call, or a client configured around the proxy doesn't reach it. That isn't a product flaw. It's what a proxy is.

How do I tell the layers apart when evaluating?

Ask whether you can call it from a function or it needs traffic routed to it, whether it returns a decision in time to stop the side effect, whether it uses the identity you already authenticated, whether the raw body leaves your environment, and whether it works where there's no HTTP request.

AI runtime security in your code

Protect your AI agent workflows with Arcjet

Arcjet guards run inside the tool, so the allow or deny arrives before the side effect rather than after it.