AI agent security options compared

One platform that discovers shadow AI on devices and in cloud agent platforms, routes MCP and model calls through a gateway tied to your identity provider, enforces policy down to tool arguments, and scans tool definitions, outputs and sessions at runtime.

Examples: Runlayer

• VisibilityStrongAI Watch device agent (rolled out through MDM) inventories AI clients, MCP servers, skills and agent configs; Cloud Discovery covers Copilot Studio, Azure AI Foundry, Entra Agent ID and Bedrock agents.
• AuthenticationStrongGroups sync from your identity provider; agent accounts get their own identity with machine or on-behalf-of tokens; OAuth broker per connector.
• Credential handlingStrongConnector secrets can stay in your AWS Secrets Manager and are fetched at connect time and held in memory only; short-lived, repository-scoped GitHub tokens for agents.
• Policy depthStrongAllow and deny per user, group, role or agent account, scoped to servers or tools, with conditions on tool arguments, client, scopes, annotations and session history; human approval rules.
• Runtime threat detectionStrongToolGuard scans tool definitions, outputs and intent drift; session-level AgentGuard; built-in PII, credential and invisible-character scanners; block, mask, hint or alert.
• AuditStrongEvery call recorded with user, agent and credential used; SIEM export to S3; OpenTelemetry ingest documented for Claude Code.
• Deployment effortLowHosted single-tenant, or self-hosted in your AWS account or Kubernetes; device agent goes out through your existing MDM.

A proxy between AI clients and MCP servers. Clients connect to one endpoint; the gateway authenticates the user, holds upstream credentials and decides which servers and tools each caller may use.

Examples: Docker MCP Gateway, Cloudflare MCP server portals, Lasso MCP Gateway, Aembit MCP Identity Gateway

• VisibilityPartialSees every call routed through it, nothing that bypasses it.
• AuthenticationStrongNatural place to apply the MCP authorization spec: SSO for users, OAuth to upstream servers.
• Credential handlingStrongHolds upstream tokens and injects them per request, which avoids the token passthrough the MCP spec forbids.
• Policy depthPartialTool allowlists per server or profile are standard; argument-level rules depend on the product.
• Runtime threat detectionPartialBasic gateways forward calls without inspecting them; some add scanner plugins.
• AuditStrongSingle choke point makes a complete call log straightforward.
• Deployment effortMediumEvery client has to be pointed at the gateway, and every server registered in it.

Scanners that inspect what agents do while they do it: tool definitions, call inputs and outputs, and the session as a whole, looking for injection, poisoning, drift and data leaving.

Examples: Runlayer ToolGuard, Zenity AI Detection & Response, Lakera Guard tool-call checks

• VisibilityPartialSees the sessions it is wired into.
• AuthenticationNoneRelies on another layer to say who is calling.
• Credential handlingPartialCan detect secrets in outputs and mask them; does not hold or issue credentials.
• Policy depthPartialBlock, mask or alert on a detection; not a permission model.
• Runtime threat detectionStrongIts whole job: tool poisoning, prompt injection, intent drift, exfiltration.
• AuditPartialRecords detections and the context around them.
• Deployment effortMediumNeeds a place in the call path (a gateway, an SDK or an API call per interaction) and tuning, usually alert-only first.

An API or proxy that classifies what goes into and comes out of a model: prompt attacks, jailbreaks, sensitive data, harmful content.

Examples: Lakera Guard (Check Point AI Guardrails), Prompt Security (SentinelOne)

• VisibilityPartialSees the applications that call it; some vendors add separate agent discovery.
• AuthenticationNoneAPI keys for the guard itself, not an identity layer for agents.
• Credential handlingPartialFlags sensitive data leaving in model output; does not manage credentials.
• Policy depthPartialPer-project detect or enforce; tool allow and deny lists in some products.
• Runtime threat detectionStrongDirect and indirect prompt injection, data leakage, content moderation.
• AuditPartialLogs of its own detections, exportable to a SIEM in some products.
• Deployment effortMediumEach application or gateway has to call it on every interaction.

Running agents, MCP servers and the code they write in containers, gVisor or microVMs with restricted file system and network access, so a compromised agent can do less.

Examples: Containers with restricted privileges, gVisor, Firecracker microVMs, coding-agent sandboxes

• VisibilityNoneIsolates what it runs; does not find anything else.
• AuthenticationNoneNo identity layer.
• Credential handlingPartialKeeps host secrets out of reach; secrets passed into the sandbox are still exposed.
• Policy depthPartialFile system and network allowlists, not per-tool rules.
• Runtime threat detectionPartialContains the damage of an attack without detecting it; network egress rules can stop some exfiltration.
• AuditPartialProcess and network logs, without the user or the tool call behind them.
• Deployment effortMediumStraightforward for servers you run; hard for agents running inside desktop apps you do not control.

Giving each agent its own identity and short-lived, scoped credentials from a vault or identity platform, instead of shared API keys in config files.

Examples: Microsoft Entra Agent ID, Aembit, HashiCorp Vault, OAuth token exchange

• VisibilityPartialKnows every agent that was given an identity, not the ones that were not.
• AuthenticationStrongIts core: OAuth flows for agents acting alone or on a user's behalf.
• Credential handlingStrongShort-lived, scoped, injected credentials; nothing long-lived in the agent.
• Policy depthPartialConditional access and scopes; per-tool rules only where it fronts MCP servers.
• Runtime threat detectionNoneDecides access, does not inspect content (some delegate inspection to another vendor).
• AuditPartialSign-in and access decision logs, not the content of each call.
• Deployment effortMediumEach agent and each server needs to be wired to the identity layer.

Finding the AI clients, MCP servers, skills and agents people already use, on devices, in browsers and in cloud agent platforms, and routing them into a sanctioned path.

Examples: Runlayer AI Watch, Zenity AI Observability, Lakera Agent Discovery, Lasso MCP discovery

• VisibilityStrongIts whole job: an inventory tied to devices and people.
• AuthenticationNoneFinds; does not authenticate.
• Credential handlingPartialCan flag plaintext tokens in MCP config files; fixing them is another step.
• Policy depthPartialSome tools can block or quarantine on devices; most report and leave remediation to you.
• Runtime threat detectionNoneAn inventory, not an inspection of calls.
• AuditPartialA record of what was found and when.
• Deployment effortLowA device agent through MDM, a browser extension, or API connections to cloud platforms.

Blocking AI clients, model APIs and MCP servers at the network, browser or endpoint, with exceptions granted case by case.

Examples: Secure web gateway deny lists, MDM application blocks, firewall rules

• VisibilityPartialSees attempts against the destinations it knows about.
• AuthenticationNoneNo identity for agents; the rule applies to everyone.
• Credential handlingNoneDoes not touch credentials.
• Policy depthPartialAll or nothing per destination or application.
• Runtime threat detectionNoneNothing runs, so nothing is inspected; local MCP servers over stdio never touch the network gate.
• AuditPartialLogs of blocked requests.
• Deployment effortLowRules in tools you already run.

Writing your own auth and access plumbing: an internal MCP proxy, OAuth integrations per server, a secrets path, logging and policy code.

Examples: Internal proxy on open-source gateways, custom OAuth clients, home-grown policy engine

• VisibilityPartialCovers what you route through what you build; device discovery is a separate project.
• AuthenticationPartialAs good as your implementation of the MCP authorization spec, and its next revision.
• Credential handlingPartialPossible to do well with a vault; easy to end up with shared service keys.
• Policy depthPartialWhatever you write and maintain.
• Runtime threat detectionNoneDetection models for poisoning and drift are rarely built in-house.
• AuditPartialWhatever you log, in whatever shape you choose.
• Deployment effortHighOngoing engineering time to build, plus upkeep for every new server, client and spec change.