Evaluating Agentic AI Platforms for the Enterprise

The deployment numbers are striking, but not in the way vendors prefer to frame them. IDC projects active enterprise AI agents growing from 28.6 million in 2025 to more than 2.2 billion by 2030. That trajectory is not conditional on governance readiness. It is already underway, and readiness is failing to keep pace.

Only 21% of companies hold a mature governance model for autonomous AI agents, per Deloitte's 2026 State of AI report. Okta arrives at the same conclusion from a different angle: 91% of organizations already use AI agents, yet 44% have no governance framework in place. IBM's Cost of a Data Breach Report 2025 provides the sharpest data point: 63% of breached organizations lacked AI governance policies at the time of their breach. Governance absence predicts breaches. That is the business risk, not an audit concern.

Most organizations are choosing platforms before they have defined what control they need those platforms to provide. They are solving the deployment problem while deferring the governance problem to some future quarter that never quite arrives. A platform that makes deployment frictionless without making governance tractable is not solving the enterprise problem. It is obscuring it with a better demo.

There is also a signal-to-noise problem in the vendor landscape worth naming plainly. Of thousands of vendors marketing "agentic AI," Gartner found only around 130 offer genuinely agentic capability. The rest are rebranded chatbots or RPA in new packaging. This agent-washing dynamic makes capability claims unreliable as a primary evaluation filter, which is exactly why governance architecture becomes the more durable differentiator. A vendor who cannot clearly explain how their platform enforces policy at the moment of tool invocation is not in that 130.

What MCP's architecture means for enterprise risk

MCP, the Model Context Protocol, is the open standard that lets AI agents connect to external tools, data sources, and services. It has become the de facto integration architecture for agentic systems. Understanding its structure is not optional background knowledge; it is a prerequisite for evaluating any platform built on top of it.

The architecture has three tiers. A Host application embeds a Client; that Client communicates with MCP Servers via JSON-RPC 2.0; those Servers expose Tools, Resources, and Prompts to the agent. The ecosystem crossed 150 million package downloads and thousands of community-built servers by mid-2025. Enterprise agents are already connecting to this ecosystem, which means enterprise risk is already embedded in it.

The structural risk is concrete, not theoretical. Tool descriptions that agents consume are rarely shown to users at runtime. Hidden instructions can direct agent behavior in ways completely invisible to the person who initiated the task. Invariant Labs demonstrated this in April 2025: a malicious trivia-game MCP server embedded instructions targeting a WhatsApp MCP server in the same session, extracting message history through what appeared to be ordinary traffic. The EchoLeak attack, catalogued as CVE-2025-32711, exfiltrated sensitive data from Microsoft 365 Copilot via indirect prompt injection, zero user interaction, no DLP triggers. These are not edge cases in developer sandboxes. They are production enterprise deployments.

Academic analysis of nearly 8,000 live MCP servers found 40% had zero authentication and 53% expose credentials through hard-coded values in configuration files. OWASP now maintains three complementary frameworks covering model-layer, behavior-layer, and connection-layer risks. Any evaluation that addresses only one of those layers leaves the others fully open.

A platform's MCP integration approach is not a feature question. It is where most of the enterprise attack surface actually lives.

Authentication and authorization as a baseline evaluation filter

MCP's own specification declares authorization optional. That optionality has produced predictable outcomes: only 8.5% of MCP servers currently implement OAuth 2.1 authentication, despite it being the protocol's mandatory standard for remote deployments, and only 18% implement any access scoping for tool permissions. The spec said optional; the ecosystem heard unnecessary.

The specification has matured rapidly, which creates its own evaluation complexity. OAuth 2.1 with PKCE became mandatory for internet-accessible servers in November 2025. The 2026-03-15 specification revision added RFC 8707-compliant resource indicators to prevent token mis-redemption attacks. Platforms built on older authentication assumptions are already behind the current standard, and that gap is worth verifying explicitly in any vendor conversation rather than assuming recent compliance.

The most consequential development for enterprise deployment is Enterprise-Managed Authorization, stable as of July 2026. It allows organizations to provision MCP access through their own identity provider rather than through per-user OAuth consent flows. Without it, identity governance fragments across hundreds of individual consent flows that no one is auditing. At enterprise scale, that fragmentation is not a minor inconvenience; it is a control failure.

There are also remaining gaps in the specification worth knowing about. No standard currently exists for how downstream servers learn about original client authorization when traffic passes through a gateway. Machine-to-machine flows have minimal specification guidance. A platform should have explicit, considered answers to both of those gaps. If the vendor pauses and says they have never thought about it, you have learned something important.

The questions to press on are specific: Does the platform delegate authentication to the enterprise IdP through SSO and SCIM, rather than managing its own credential store? Does it use token exchange via RFC 8693 rather than passing OAuth tokens directly? Does it implement PKCE for all client-side flows? Does it support Just-in-Time credential provisioning rather than long-lived static secrets? Platforms that hardcode credentials or rely on static API keys in configuration files are out.

Credential management across the agent fleet

AI agents are a primary driver of what the industry now calls Non-Human Identity sprawl. They create, use, and replicate credentials at machine scale, usually with no lifecycle management attached to any of it.

GitGuardian's State of Secrets Sprawl 2026 report found 28.65 million hardcoded secrets added to public GitHub repositories in 2025, a 34% year-over-year increase. AI-related secrets accounted for more than 1.27 million exposures within that total, representing 81% year-over-year growth, the fastest of any single credential category. In MCP's first year of adoption specifically, 24,008 unique secrets appeared in MCP configuration files on public GitHub, partly because quickstart guides normalized hardcoding API keys as the path of least resistance. The documentation taught the bad habit.

The window between exposure and exploitation is narrow. Attackers exploit exposed AWS credentials within an average of 17 minutes. Nearly a quarter of organizations take more than 24 hours to rotate them. The damage happens in the gap between those two numbers. Beyond that, 92% of organizations report their current IAM tools cannot manage AI agent identities, so the credential problem does not have an existing solution most organizations can simply apply.

The agent-specific lifecycle risks differ from traditional credential risks in ways that matter operationally. Credentials issued for pilots or proofs-of-concept persist after the agent is decommissioned, because no one owns the revocation process. Broadly scoped tokens accumulate with no rotation schedule. Credentials replicate across environments through the agent's own behavior, creating exposure that no manual audit will fully surface.

Does the platform issue short-lived, scoped credentials per task rather than long-lived tokens? Does it support automatic rotation and revocation through policy rather than manual processes? Does it provide a credential inventory covering every agent in the fleet, including the ones never provisioned through IT? SPIFFE/SPIRE for cryptographic workload identities is the emerging standard worth tracking. Platforms aligned to that direction handle machine-to-machine identity more robustly than those relying on shared secrets.

Runtime threat detection for MCP-specific attack patterns

Preventive controls are necessary and not sufficient. Even Claude 3.7 Sonnet, the best-performing model in adversarial testing, refused less than 3% of malicious requests. Safety alignment does not stop attacks that use legitimate tools for unauthorized operations. Multi-turn prompt injection attacks achieved success rates as high as 92% across eight open-weight models in 2025 testing. Single-turn protections provide substantially less assurance in extended sessions involving memory and tool access.

The attack categories runtime detection must cover are specific to the agentic context, and they are worth enumerating precisely because vendors tend to blur them together.

Tool poisoning embeds hidden instructions inside tool descriptions, redirecting agent behavior before the task even begins. Prompt injection embeds instructions in content the agent retrieves, including emails, documents, and web pages, hijacking the agent's goal mid-session. Intent drift describes behavior that deviates incrementally from a defined task across a multi-turn session; each individual step looks unremarkable, but the compound effect is unauthorized action by the end. Data exfiltration disguised as normal tool calls is the EchoLeak pattern: outbound data movement that triggers no DLP rules because it occurs at the tool-call layer, below where DLP operates. Agent-to-agent impersonation occurs when a compromised agent inserts hidden instructions into output consumed by a downstream agent. Supply chain tampering involves malicious updates to MCP server schemas, dependencies, or configuration files after an integration has already been approved.

One in three agent framework CVEs analyzed from the National Vulnerability Database involves identity, credential, or access control flaws. Detection must cover the identity layer, not just the content layer.

The evaluation questions for runtime detection center on enforcement timing and scope. Does the platform inspect tool descriptions at load time and continuously at runtime, rather than only during initial onboarding? Does it detect behavioral deviation across multi-turn sessions, or only flag individual suspicious calls in isolation? Does it monitor outbound data patterns at the tool-call level? Does it enforce policy at the moment of tool invocation, before execution, rather than alerting after the action has already occurred? A platform with no runtime enforcement at the tool-call layer is asking the enterprise to trust that agents behave correctly. The empirical testing record does not support that trust.

Audit logging and traceability as a governance requirement, not a reporting feature

Audit logging for AI agents is structurally different from application logging, and the distinction matters more than most procurement conversations acknowledge. The relevant unit of accountability is not a user action or an API call. It is a tool invocation tied to a specific identity, intent, policy decision, and session context. Producing evidence that satisfies that standard requires a different architecture than what most application logging pipelines generate.

Regulatory-grade audit evidence for agentic AI requires several distinct components. Every tool call must be attributed to a specific human or machine identity, not just an agent name. The policy state at the time of the call must be recorded: which rules were in force and which were evaluated. The intent context must be captured: what task the agent was executing when the call occurred. Logs must be stored in tamper-proof environments that the agent or a compromised component cannot modify. For multi-agent workflows, full distributed tracing across the entire chain is required, not just visibility into the initiating agent.

The practical stakes of getting this wrong were illustrated by a significant government breach spanning late 2025 into early 2026, where a single attacker used an AI agent to compromise multiple government entities across a federal tax authority, electoral institute, state governments, and a utility. Without adequate traceability, organizations in incidents like that cannot determine scope, sequence, or attribution.

OpenTelemetry tracing is the emerging standard for distributed agent observability. Platforms that implement OTEL tracing produce audit data compatible with existing enterprise SIEM and observability stacks, rather than requiring a separate pipeline that gets built once and then quietly abandoned when the team that built it turns over.

Does the platform produce identity-attributed, policy-contextualized logs per tool invocation, rather than aggregated session logs? Are logs stored outside the agent's own execution environment and protected from tampering? Does it support OTEL tracing for multi-agent workflows? Can it produce audit evidence in formats that satisfy the organization's specific compliance requirements? For regulated industries, these are table stakes.

Discovery and inventory of what is already running

Shadow AI substantially expands the undiscovered agent and Non-Human Identity surface, and it does so quietly. Employees connect MCP servers and deploy agents outside IT visibility, creating integrations that never appear in any platform inventory. The NHI population across the industry grew 44% year-over-year between 2024 and 2025 per Entro Labs research, and much of that growth is invisible to IAM tools that were never designed for machine-scale identity. Gartner predicts that 40% of enterprise applications will embed task-specific AI agents by end of 2026, up from less than 5% in 2025. The inventory problem will expand faster than any organization can track manually.

A platform evaluation that covers only what IT deploys misses the agents that create the most governance risk, because those are precisely the ones that were never reviewed.

The questions for this layer are about continuous coverage, not periodic scanning. Does the platform continuously discover MCP server connections across the environment, including connections it did not provision? Does it surface unapproved or shadow integrations, or does it treat unknown connections as simply out of scope? Does it maintain a live inventory of agents, their tool permissions, and their credential state? Can it detect when a previously approved MCP server has been updated or replaced? That last scenario, where a trusted server becomes malicious after it has already passed review, is a known supply chain attack vector, not a hypothetical one.

Continuous discovery is the prerequisite for every other control in this framework. Controls that depend on inventory are only as effective as the inventory is complete. An incomplete inventory is not a partial solution. It is a false sense of coverage.

Enablement architecture and the 95% of employees who are not developers

A governance-heavy platform that developers find cumbersome and non-technical employees cannot navigate at all does not reduce shadow AI. It creates the conditions for it. When the sanctioned path is difficult and the unsanctioned path is three clicks, most people take the three clicks. That is not a culture problem. It reflects a design failure, and blaming employees for it is a way of avoiding accountability for the platform choice.

The population that matters here is large. The overwhelming majority of employees at any enterprise are in finance, legal, operations, customer success, HR, and similar functions. They have genuine, legitimate use cases for agentic AI, and they will find a way to use it whether or not IT has designed a safe path for them to do so. A PwC survey of 300 executives from May 2025 found 88% view AI agents as an opportunity to automate significant portions of work in the coming years. That appetite exists at every level of the organization, not just in engineering.

The enablement architecture question is not whether non-technical employees will use agents. They will. The question is whether the platform makes the compliant path the easy path: a curated, pre-approved catalog of agents and tool integrations that employees can activate without submitting a ticket; natural language interfaces that do not require users to understand the underlying technical architecture; guardrails enforced at the infrastructure level, so that a user cannot accidentally configure a connection outside policy even if they wanted to.

For developers, the enablement question shifts to SDK quality, documentation depth, and how much overhead governance adds to the development loop. A governance framework that doubles the time it takes to ship an agent will be routed around. The platforms that get this right make security and observability defaults rather than additions bolted on at the end.

The most honest evaluation method here is observational. Put the platform in front of a non-technical employee with a real use case and watch what happens. Count the steps between intent and action. Measure how much policy is enforced invisibly versus how much depends on the user making correct choices at each decision point. The more the platform relies on user judgment to stay compliant, the more it is describing compliance rather than enforcing it.