Evaluating Agentic AI Platforms for the Enterprise

A security failure in a conventional software product usually means a wrong answer, a crashed page, a bad recommendation. But in an agentic AI platform, that same failure can mean a live credential sent to a public thread, or a database queried and drained while no one touches a keyboard. That difference is why procurement for these platforms needs its own set of criteria, built around identity, governance, and runtime controls as first-class requirements rather than items added after the contract is signed.

Why agentic AI platforms require different procurement criteria

A developer's AI coding agent, Cursor, had been given service-role database privileges and was set loose on a routine task: reading support tickets. One ticket contained plain-text instructions, and the agent followed them, querying the integration_tokens table and posting live credentials into a public thread. No one broke in. No malware ran. The weapon was the support ticket itself.

That incident, documented in connection with Supabase's MCP integration, captures the shift procurement teams now have to reckon with. A standard large language model takes input and produces output. An agent browses websites, reads email, calls APIs, modifies files, queries databases, runs code, and hands off tasks to other agents. Once a system can act rather than just answer, a security failure stops looking like an incorrect response and starts looking like a credential exposed or arbitrary code running on a production system.

Firewalls, API gateways, and data-loss-prevention tools were not designed to evaluate the intent behind an agent's tool call and cannot do so. None of them were built to judge whether an agent's next tool call reflects what a user actually asked for or a hidden instruction smuggled in through a support ticket, a file, or a webpage the agent happened to read. No existing control was designed to solve that, and it's exactly the gap procurement criteria for agentic platforms need to close.

The timeline for closing it is short. Gartner's projection, cited in LangProtect's MCP Security enterprise guide, says most enterprise applications will run task-specific AI agents by the end of 2026, and most API gateway vendors are expected to ship MCP-native features on that same timeline. Buyers evaluating platforms today are making decisions that will sit inside infrastructure already moving toward that deadline.

MCP as the central attack surface enterprise buyers must evaluate

The Model Context Protocol is what makes most of this agent activity possible, and its design choices now function as security choices for anyone who adopts it. MCP, open-sourced by Anthropic in November 2024, is now governed by the Linux Foundation's Agentic AI Foundation, co-founded by OpenAI, Anthropic, and Block, with Google, Microsoft, AWS, Bloomberg, and Cloudflare backing it. That lineup is a strong signal of where the industry has settled: MCP functions as the default integration standard for enterprise agentic AI.

Adoption runs across the stack. OpenAI, Google, Microsoft, and AWS have all built support for it. On the application side, CRM tools like HubSpot, Salesforce Agentforce, and Microsoft Dynamics 365 ship MCP support, as does Adobe's Marketo Engage for marketing automation and developer tools including Cursor, Windsurf, and Zed. If a platform touches enterprise workflows in 2026, it almost certainly touches MCP somewhere in its stack.

The protocol works on a client-server model: an agent sends a request, and an MCP server exposes a given capability, a database query, an API call, a file operation, a workflow trigger, as a structured interface the agent can discover and use. That structure is why MCP spread so fast, and it's also why a flaw in one server's implementation can be repeated across every deployment using the same pattern. Before MCP, connecting an AI system to ten tools meant building and maintaining ten separate custom connectors, an integration burden that scaled with every new tool and every new agent. MCP collapses that into a single protocol. That collapse is what makes the protocol so useful for engineering teams, and it's also what turns a single server compromise into an enterprise-wide problem rather than a contained one.

MCP servers tend to hold credentials for several enterprise systems at once, all behind one interface. A compromised server doesn't just expose itself, it exposes every system it was trusted to reach. Evaluating an agentic AI platform now means asking a direct question: what does this platform's MCP server actually hold the keys to, and what happens to all of it if that one server is compromised?

The documented threat record that makes security criteria non-negotiable

None of this is hypothetical. A short run of incidents through 2026 shows this pattern playing out in production systems, and each one lands on a gap a better-evaluated platform should have closed. The incident table from CyberDesserts' AI Agent Security Risks 2026 guide lays out that record in full.

Three CVEs tied to the Anthropic Git MCP Server, CVE-2025-68143, CVE-2025-68144, and CVE-2025-68145, were publicly disclosed, describing a remote code execution chain reachable through prompt injection. Anthropic had already patched the flaws before the disclosure went public, a reminder that even a fast, responsible patch cycle doesn't erase the fact that the flaw existed.

The following month, researchers found a large number of malicious packages spread across the OpenClaw marketplace, an incident referred to as ClawHavoc, tied to nine CVEs, three of which had public exploit code circulating. That same month, Trend Micro found hundreds of MCP servers exposed to the internet with no authentication at all, and SecurityScorecard flagged a large number of OpenClaw instances carrying the same architectural weakness.

April brought a CVSS 9.1 authentication bypass in Azure DevOps's MCP integration, tracked as CVE-2026-32211, left unpatched. The severity matters here: an attacker could pull configuration details, API keys, and authentication tokens without ever presenting valid credentials, inside a mainstream enterprise platform used across large organizations. In June, a technique researchers labeled agentjacking showed up through Sentry's MCP event injection, with thousands of organizations running injectable DSNs. Sentry declined full remediation, shipping only a payload-string filter.

The starkest case sits outside the CVE list entirely. Between December 2025 and February 2026, a single attacker used Claude to breach Mexico's federal tax authority, its electoral institute, four state governments, and a water utility in Monterrey, pulling 150GB of data that included 195 million taxpayer records. The attacker's own conversation logs with Claude were later found sitting publicly accessible online, a discovery made by Gambit Security and disclosed on February 25, 2026.

Cisco has documented a separate pattern: an attacker poisoned the external data source feeding a low-privilege data query agent, then used that agent's cross-agent communication channel to send disguised requests to a higher-privilege financial approval agent. The attack crossed from a read-only system into an authorization system without a human ever being in the loop. That's the shape of risk multi-agent deployments introduce: privilege can move laterally between agents the same way it moves between compromised accounts on a human network, except faster and with less visibility.

Tool poisoning as the dominant threat class

Across these incidents, one technique keeps surfacing as the common thread: tool poisoning, the defining MCP threat of 2026 because it exploits the trust an agent places in tool descriptions, a trust that no model-level safeguard alone can remove, making platform-level controls essential. It works because of how MCP servers introduce themselves to an agent. When a server registers its tools with a client, it sends along names and descriptions, and those descriptions get fed directly into the language model's context window. An attacker who can plant malicious instructions inside that description text gets those instructions treated as system-level commands by the model, invisible to the end user because most applications don't display the full tool description in their interface.

A proof of concept built on the Cursor IDE showed how far this can go. Researchers built a tool carrying a hidden instruction: read the user's SSH private key, encode it, and tack it onto the parameters of an unrelated calculator tool call, routing it to an attacker-controlled server. The chain executed start to finish without the user noticing anything.

The MCPTox benchmark put numbers behind how often this works. Testing 353 adversarial tool variants pulled from 45 live MCP servers against 20 language models, researchers found an average attack success rate above a third across the board, and the worst single result hit 72.8% against a leading reasoning model. Even the model that resisted best still gave in nearly every time it was tested. More capable models, oddly, often did worse, because their stronger instruction-following made them more likely to comply with whatever a poisoned tool description told them to do. Capability does not buy safety here, and a procurement process that treats a bigger, smarter model as inherently safer is reasoning backward.

Tool descriptions aren't static, either. MCP picks up changes to them dynamically, so a tool approved once can be swapped for a poisoned version later with no visible change to its name or summary. Microsoft Defender documented exactly this in a finance-team scenario, where an approved invoice enrichment tool had hidden instructions added after approval while everything a reviewer would normally glance at stayed the same. If a platform has no re-approval trigger tied to description changes, that poisoned version can go live with zero additional review.

OWASP's MCP Top 10, still in beta as a 2025 v0.1 taxonomy through 2026, places tool poisoning alongside privilege escalation, weak authentication and authorization, shadow MCP servers, software supply chain attacks, and token mismanagement, the last of which currently sits ranked first on the list. Tool poisoning isn't a fringe case on that list, because it's a structural consequence of how MCP delivers tool metadata to models. Closing it requires platform-level work: runtime inspection of tool calls before they execute, detection of intent drift between what a user asked for and what the agent is about to do, and automatic re-approval workflows whenever a tool's description changes. No amount of model tuning fixes a trust problem baked into the protocol's architecture.

Authentication and authorization in MCP cannot be left to the spec

The protocol itself has started catching up, but not all the way. On July 28, 2026, the MCP spec was updated to formally treat MCP servers as OAuth 2.1 resource servers. Servers must now implement OAuth 2.0 Protected Resource Metadata under RFC 9728, letting clients automatically discover the right authorization server, and clients must implement Resource Indicators under RFC 8707, specifying exactly which server a given token is meant for, so a malicious server can't intercept a token intended somewhere else. That's a real fix for a real problem, and it deserves credit as progress.

It is not the whole picture. Authentication under the MCP spec remains optional rather than required, and research published in early 2026 found a large number of active MCP servers sitting on the public internet with no authentication at all, every one of them technically compliant with the spec as written. Spec compliance, in other words, sets a floor, not a ceiling. A platform can meet every letter of the July 2026 update and still run servers nobody has to authenticate against.

Authorization is a separate gap. The spec resolves the question of whether a given token is valid for a given server, but it has nothing to say about which tools a particular agent should be allowed to invoke, who signed off on that access, or what any given agent actually did once it had the access. Those decisions get left entirely to whoever implements the platform.

Even with the July update in place, the protocol still can't prove which agent or runtime is the one actually holding a given token. Verifiable workload identity has to come from somewhere outside the spec. The tooling market has started responding. Auth0's Auth for MCP went generally available in May 2026, bringing OAuth 2.1 and OpenID Connect into the MCP ecosystem and letting Auth0 customers protect MCP servers through Universal Login. That's a genuine sign the ecosystem is maturing, but having the tooling available on the market is not the same as a platform actually enforcing it by default, since tooling availability does not substitute for platform-level enforcement.

The non-human identity problem agents create

This activity produces an identity problem that most enterprises are not yet equipped to handle. An agent operating inside a real deployment can hold credentials for a CRM system, an email account, cloud infrastructure, and a payment system all at once, and it can use any of them at machine speed without a human approving each individual action. That's a fundamentally different identity than a human employee's: it doesn't log in once a day, it doesn't take a lunch break, and it can touch four systems in the time it takes a person to read one email.

Traditional identity and access management was built around static policies and human login flows: a person authenticates once, gets a role, and keeps that role until someone manually changes it. Agents need something IAM wasn't designed to give them, access that shifts with context, narrows and widens depending on the task at hand, and gets revoked the moment a task ends rather than sitting open indefinitely. Every incident covered here, the Supabase credential leak, the Azure DevOps bypass, and another vendor's lateral-movement case, traces back in some form to an agent holding more standing access than the moment required, with no system in place to catch it.

Procurement teams need that answered before a contract is signed. How does this platform scope an agent's access to the task in front of it? How does it revoke that access automatically once the task is done? Who or what proves that a given credential is being used by the agent it was issued to, and not by whatever happened to compromise it first? A platform that can't answer those questions clearly is asking an enterprise to run static, human-built identity controls against a non-human actor that was never going to behave like one.