Which AI security platforms support MCP server security?

Which AI security platforms support MCP server security?

AI security platforms that support MCP server security sit in one of four positions relative to the connection, and a product in one position doesn't cover the others. Sort the market by position first, then check whether the product can observe the calls that your servers receive.

The Model Context Protocol (MCP) connects an agent to tools over a client-server connection, so a claim to support MCP can mean any of the following:

• MCP gateways proxy traffic between clients and servers, adding a catalog of sanctioned servers, identity-aware policy, and audit. Runlayer, MintMCP, Lunar.dev, Obot, NeuralTrust, and Kong are here.
• Client-side tool gates decide whether the agent can issue a call, inside the agent process. Framework hooks live here, as do in-process SDKs.
• Server-side handler enforcement decides whether an arriving call executes, inside the MCP server that you wrote. Arcjet is here, and so is Rein Security.
• Identity and credential brokers issue the scoped, short-lived credentials that the connection uses. Keycard, Aembit, Astrix, and Token Security are here.

The following table compares the four positions:

Which direction is your problem?

The question splits by whether you operate the MCP server or consume someone else's, and the two need opposite controls.

You run the server. Your risk is an arriving call: a client that you didn't write, holding a token that you issued, invoking deleteRecord on an object that might not belong to it. A gateway in front of your server helps only if every client goes through it, and stdio clients don't. The check that fires on every call is the one inside your handler.

You consume third-party servers. Your risk is what your agent connects to and what comes back: an unsanctioned server, a tool description that carries injected instructions, a result that steers the next turn. A gateway is useful here, because you control the client's egress path and can require it.

Most teams have both, which is why the question has no single answer. A catalog product and a handler-side check aren't competing.

What MCP gateways cover

More vendors occupy the gateway position than any other. Runlayer ships an MCP gateway alongside agent identity and access management (IAM), shadow-AI discovery, and runtime policy. MintMCP, Lunar.dev, and Obot occupy adjacent ground. NeuralTrust's TrustGate and Kong approach the problem from API gateway heritage.

A gateway gives you a sanctioned-server catalog, one place to revoke, identity-aware traffic policy, and an audit trail that spans servers.

The structural limit is routing. A gateway enforces on traffic that it routes, so a local stdio server, a direct HTTP call that your code makes, a queue consumer, or a client configured to bypass the proxy are all outside its view. Several vendors in this position also ship in-process hooks to close that gap, which is a useful signal about where the gap is.

If you're standardizing which third-party servers your organization can use, then a gateway is the right purchase. It doesn't secure the server that you wrote.

What server-side enforcement covers

An MCP server has no front door. There's no HTTP route to put a web application firewall (WAF) on, no single ingress that every client shares, and the token in the connection was often issued to a machine rather than to a person. The handler is the one place that every call reaches.

Arcjet, a security library that evaluates its rules inside your own process, runs there. Its guard() call needs no Request object, so it fits an MCP handler. In the following handler, launchArcjet creates the client, a token bucket is configured once, and arcjet.guard() evaluates it against each tool call, keyed on the caller that the connection's own auth resolves. The protected action is a write, limited to 20 per caller per hour:

1
import { launchArcjet, tokenBucket } from "@arcjet/guard";
2

3
const arcjet = launchArcjet({ key: process.env.ARCJET_KEY! });
4

5
const writeFrequency = tokenBucket({
6
  bucket: "mcp-create-issue",
7
  refillRate: 20,
8
  intervalSeconds: 3_600,
9
  maxTokens: 20,
10
});
11

12
// server is the @modelcontextprotocol/sdk Server for this MCP server.
13
server.setRequestHandler(CallToolRequestSchema, async (request, extra) => {
14
  // Identity comes from the connection's auth, not from request params.
15
  const caller = await resolveCaller(extra.authInfo);
16

17
  const decision = await arcjet.guard({
18
    label: `mcp.${request.params.name}`,
19
    actor: caller.id,
20
    rules: [writeFrequency({ key: caller.id, requested: 1 })],
21
  });
22

23
  if (decision.conclusion === "DENY" || decision.hasFailedOpen()) {
24
    // A write is not reversible here, so a failed-open decision denies.
25
    return { content: [{ type: "text", text: "Denied by policy" }] };
26
  }
27

28
  return runTool(request.params, caller);
29
});

Two details carry the weight. resolveCaller derives identity from the connection's own auth rather than from anything in the request parameters, so a client can't assert who it is. The frequency limit is keyed on that resolved caller, so an agent that loops doesn't get 500 writes because each one looked fine on its own.

For the longer version of this, see how to secure an MCP server or AI agent tool calls.

The MCP-specific risk gateways don't judge

MCP tool results and tool descriptions are text that re-enters the model's context. That makes them an injection channel, and the risk is specific to this protocol in a way that ordinary API responses aren't.

A gateway can confirm that the server is sanctioned. It doesn't judge whether the summary field in the response is steering the next turn. A ticket body, a fetched page, or a description on a tool definition can all carry instructions.

Screen text on its way back to the model, and keep trusted output structurally separate from attacker-influenced content. The following check runs Arcjet's prompt-injection rule through the same guard() call, in your own process, on a tool result before it returns to the model, and substitutes a placeholder on a deny:

1
import { detectPromptInjection, launchArcjet } from "@arcjet/guard";
2

3
const arcjet = launchArcjet({ key: process.env.ARCJET_KEY! });
4

5
const decision = await arcjet.guard({
6
  label: "mcp.tool-result",
7
  rules: [detectPromptInjection()(result.text)],
8
});
9

10
if (decision.conclusion === "DENY") {
11
  return { content: [{ type: "text", text: "[Content blocked]" }] };
12
}

Arcjet's own MCP server splits its output this way, putting evidence in an explicitly untrusted object rather than interpolating it into guidance fields. For more information, see how we defend MCP tool outputs from prompt injection.

For the framework-specific client-side versions, see LangGraph MCP tool security, Mastra MCP tool security, and Eve MCP connection security.

What to ask an MCP security vendor

Six questions separate the positions faster than a feature matrix does.

Does it observe calls that don't route through the product? If the answer requires the client to be configured to point at the product, then calls from any other client are unprotected.

Does it work on stdio servers? Local servers are common in developer tooling and don't cross a network proxy.

Where does identity come from? A policy keyed on a shared service token can't distinguish the users behind one agent.

Does it inspect tool results, or only the call? Results are the injection path.

Can it deny before the handler runs, or does it report afterwards? If the tool executes and the product logs it, that's detection.

Does content leave the environment to be judged? A cloud classifier receives the ticket bodies and file contents that your tools return. For more information about that tradeoff, see keeping security inspection local.

How to choose

If you're governing which third-party MCP servers your organization connects to, then buy a gateway and require it at the egress path.

If you operate MCP servers that other people's agents call, then the enforcement has to be in your handlers. Client-side policy from a vendor that you don't control doesn't protect a server that you expose.

If you do both, then they're two purchases, and the gateway doesn't cover the first one. Arcjet occupies the handler position: an in-process allow-or-deny with the caller identity and the arguments in scope, on every call that the server receives, including the ones that crossed no proxy.

For the whole-category version of this sort, see the top AI agent security platforms.