AI Agent Security Platforms: A Category Map

What are the top AI agent security platforms?

There is no ranked list of top AI agent security platforms, because the names mix five different jobs. Sort vendors by layer (identity, gateway, guardrails, observability, and in-code enforcement), then pick the product that can stop the failure you actually have.

The names aren't comparable until you sort them by where they sit and what they can stop. A listicle that ranks them as substitutes, or that omits the in-code peer, answers the wrong question.

1. Agent identity and authorization

Question answered

Is this agent allowed to do this at all?

This layer issues scoped credentials and evaluates authorization policy, often per-request and short-lived. Keycard is the clearest example: Cedar-based policy, default-deny, credentials issued only if policy permits, with delegation narrowing at each agent hop. Aembit, Descope, Astrix, Token Security, and Oak occupy related ground. Unbound AI applies the pattern specifically to coding agents, describing itself as an Agent Access Security Broker, and Lineation.ai approaches it from non-human identity and forensic lineage. Consolidation is real here, with CrowdStrike acquiring SGNL and Palo Alto having closed its CyberArk acquisition, both framed around agent identity.

What this layer can't do

This layer can't inspect content or judge whether a permitted action is wise. Keycard doesn't document a prompt-injection capability; it's an identity and authorization layer by design, positioned as a different job.

2. Gateways and control planes

Question answered

Is this call to a sanctioned tool, and does it comply with traffic policy?

This layer sits in front of agent traffic, usually MCP, adding a catalog of approved servers, identity-aware policy, and audit logging. Runlayer is the most developed, with an MCP Gateway, Agent IAM, Watch for shadow-AI discovery, and Guard for runtime policy. NeuralTrust (TrustGate), Lunar.dev, MintMCP, Obot, and Kong are also here. Onyx Security and Metano both position explicitly as control planes for agentic AI, and Cranium AI approaches the same ground from enterprise governance and posture.

This is the most crowded layer in the category. Six or more vendors describe themselves as a control plane for AI agents. A shortlist that long is usually the same layer counted twice.

The structural limit

A gateway enforces on traffic that it routes. Tool calls that don't traverse it, including local operations, background jobs, direct API calls, and other protocols, are outside its view. Vendors in this layer increasingly ship in-process SDKs precisely to close that gap.

3. Guardrails and content inspection

Question answered

Is this input or output unsafe?

This layer detects prompt injection, jailbreaks, unsafe content, and PII in prompts and responses. HiddenLayer, Straiker (Ascend for red-teaming, Defend for runtime), Pillar, Noma, and Operant are active here. Refractal spans pre-deployment stress testing and production protection, and Mirror Security approaches the problem from cryptographic trust. Lakera is part of Check Point, Prompt Security part of SentinelOne, and Invariant Labs part of Snyk.

The limit

Content inspection judges text, not actions. Input that contains no detectable attack pattern, such as a plausible business request, can still manipulate an agent, and the resulting action looks legitimate.

4. Observability and detection

Question answered

What did the agent do?

This layer traces, evaluates, and alerts. Datadog AI Guard evaluates prompts and tool calls through your OpenTelemetry and APM instrumentation, and files the verdict with the rest of your traces. Manifold positions as endpoint security for the agentic workforce, protecting what agents do rather than what they say. Capsule Security monitors agent behavior continuously and intervenes at the first sign of anomalous activity. Neo Security focuses on controlling agentic application actions before they reach sensitive systems. On the evaluation side, LangSmith, Langfuse, Arize, and Braintrust provide session and trajectory analysis for debugging and measurement.

The limit

This layer is built for investigation, and several vendors in it also block inline. AI Guard's SDK can raise an exception before the action runs when blocking is enabled in the service policy, and Capsule and Neo describe pre-action intervention.

The structural limit is where enforcement lives. It sits in the instrumentation, outside your application code, so an action that the instrumentation doesn't see is visible only after the fact. The trace-and-evaluate tools remain retrospective by design.

5. In-code runtime enforcement

Question answered

Should this action execute, right now?

This layer runs inside the application, in-process, in the path of the action. It can therefore block before the side effect and use application context that the other layers don't have. Few vendors occupy it. Arcjet and Rein Security are the clearest examples. Runlayer's hooks integration (such as Cursor Hooks) also runs in-process and can allow or deny local tool calls.

What it requires

This layer must be fast enough for the request path. It must also reach code paths with no HTTP request, including tool handlers, MCP servers, queue consumers, and workflow steps.

How the five layers compare

Most programs need several

The mistake is expecting one layer to do another's job: a posture scanner to block a live tool call, a content filter to enforce a spend budget, an observability tool to prevent anything.

A reasonable stack is identity for allowed, guardrails for unsafe content, observability for what happened, and in-code enforcement for should this execute. The gap most teams have is the last one, because it's the one that you can't buy at the perimeter.

Where Arcjet fits

Arcjet is the in-code enforcement layer. It runs inside your application, in request handlers, and on agent tool calls, MCP servers, and queue jobs. That's the path that can stop prompt injection, tool-call abuse, token spend, and PII before the side effect. Bot detection, Shield WAF, and filters are HTTP controls in request handlers.

Arcjet addresses three failures on that path:

• To limit cost explosion, use token-bucket budgets keyed on an identity that you control, at the tool call rather than only at the HTTP entrypoint. Those budgets live in application code, not in remote rules.
• To stop unauthorized side effects, use prompt-injection detection before the provider call, plus per-action rules at the tool.
• To catch data exfiltration, use sensitive-information detection that runs locally, in-process: a built-in local engine, plus an optional on-device ML model for names, addresses, and government or financial identifiers. The raw body never leaves your infrastructure.

Two routes to policy

Most of this category asks you to choose who owns policy. Some tools put every rule in code. Some put every rule in a console, away from the application they defend.

Arcjet keeps both, against the same in-app enforcement point. App-specific rules stay in code: route, user, tenant, plan, prompt, tool call, or request body. That includes per-user token budgets, prompt injection, PII, and email validation. JavaScript, TypeScript, and Python are the documented languages for the tool-call path; Go is pre-release.

Operational, site-wide HTTP rules change in the Arcjet dashboard or through MCP and take effect immediately: a country, ASN, IP, or VPN block; a global bot category; a temporary fixed-window or sliding-window rate limit; Shield WAF. Dry-run, then promote. You set token-bucket budgets in application code. Those HTTP remote rules are a different system from labeled tool-call policies. A security team can change the policy for a labeled action without changing the tool.

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 can fail open when Arcjet's cloud can't be reached; that's configurable. If you can't accept a check that didn't finish, look at the error codes. See the Guards reference. In the SDK, the two surfaces are protect() (HTTP request handlers) and guard() (tool calls and jobs).

SOC 2 Type 2 is complete, with details in the Trust Center.

A buyer question for any runtime control: can you reconstruct the sequence of actions in a run? Arcjet tags related decisions with a correlation ID so the run is reconstructable for investigation. For more information about the direction of runtime controls, see runtime controls on enterprise systems. For the reasoning behind the model, see runtime security for LLM applications.

Compare in detail: Arcjet vs Datadog AI Guard · Arcjet vs Rein Security