How we compare: the criteria

Visibility

Can you see which agents, MCP servers, tools and skills are in use, and by whom?

You cannot set policy for agents you do not know about. Employees connect AI clients to MCP servers from their own laptops long before a security review happens.

• StrongFinds agents and MCP servers you did not register (on devices, in clients or in cloud agent platforms) and ties each to a person.
• PartialSees only what is routed through it or registered with it.
• NoneDoes not inventory agents or tools.

Check it yourself: Ask for an inventory of every MCP server on a test laptop that was never registered anywhere. If it is missing, visibility is partial at best.

Authentication

Is every user and every agent identified before a tool call is allowed?

An agent acting with a shared key cannot be held to one person's permissions. The MCP authorization spec builds on OAuth 2.1 so that each call carries a real identity.

• StrongUsers sign in through your identity provider (SSO), agents get their own identities, and calls carry who acted on whose behalf.
• PartialAuthenticates one side (the user, or the upstream server) but not both, or relies on shared keys.
• NoneDoes not authenticate users or agents.

Check it yourself: Make a tool call and look up the record: does it name the user, the agent and the credential used?

Credential handling

Are tokens and secrets kept out of the agent's hands, scoped and short-lived?

Agents read their own context aloud when prompted the right way. A token in a config file or a prompt is a token an attacker can ask for. The MCP spec forbids passing a client's token straight through to upstream APIs.

• StrongCredentials are held outside the agent (a vault or a broker), injected per request, scoped and short-lived; no token passthrough.
• PartialStores secrets centrally but hands long-lived ones to the agent or the client, or only detects exposed secrets.
• NoneLeaves credentials where developers put them.

Check it yourself: Search an agent's config and context for a raw API key. Then check how long a token it receives stays valid.

Policy depth

How fine-grained are the rules: server, tool, or each call and its arguments?

"Allow the GitHub server" is very different from "allow read on these repositories, and ask a human before anything is deleted". OWASP lists excessive agency as a top risk for exactly this reason.

• StrongRules per user, group and agent down to individual tools and call arguments, with human approval for risky actions.
• PartialAllow or deny at the level of a server, a tool, a network destination or a file path.
• NoneNo rules of its own.

Check it yourself: Try to write one rule: this group may call this tool only with this argument value. Count the steps it takes.

Runtime threat detection

Does it catch tool poisoning, prompt injection, intent drift and exfiltration while tool calls happen?

Access control decides who may call a tool. It cannot tell that a tool description hides instructions, or that a response is steering the agent to send data elsewhere.

• StrongInspects tool definitions, call inputs and outputs, and the session as a whole, and can block, mask or alert inline.
• PartialInspects one surface (prompts only, or network traffic only), or contains damage without detecting it.
• NoneDoes not look at what agents do.

Check it yourself: Replay the published tool-poisoning example against it and see whether the call is flagged before it runs.

Audit

Is every call recorded with who, which agent, which tool, and what happened, and can you export it?

Incident response and compliance both start with the record. OpenTelemetry's generative AI conventions give tool calls a standard shape to export.

• StrongAttributable record of every call (user, agent, tool, arguments, decision) with export to a SIEM or OpenTelemetry.
• PartialLogs of its own decisions only, or logs without user and agent attribution.
• NoneKeeps no record of agent activity.

Check it yourself: Pull yesterday's calls for one user and one agent, and send them to your SIEM.

Deployment effort

What does it take to put in place and keep running?

A control that takes a quarter to ship is a quarter of agents running without it. Effort includes upkeep: MCP and its authorization spec change several times a year.

• LowConfiguration and an existing rollout channel (identity provider, MDM, DNS). Days, not months.
• MediumRouting clients through a new component, or wiring it into each agent or application.
• HighBuilding and maintaining it yourself, or re-architecting how agents run.

Check it yourself: List every client, agent and server that must change for it to work, and who owns each.

How marks are given

Approaches are judged on what the approach can do when done well, against the MCP specification and the OWASP guidance cited on each row. Products are judged only on what their own public documentation says; where the documentation is silent, the note says “not documented” and the mark reflects that. Nothing here is based on paid placement, private briefings or customer reviews, and no prices are given: ask each vendor.

Seen a mark that no longer matches a vendor's documentation? The note beside it says what it rests on, so the gap is easy to show. Back to the comparison.