Business Case Frameworks for Enterprise AI Agent Investment

Enterprise AI agents have moved past the experimental phase. Most large organizations have at least one pilot running somewhere: it connects to internal systems, answers questions, and maybe even takes small actions on a user's behalf. What they mostly have not done is turn that pilot into something running at scale, in production, touching real systems with real consequences. Only 11 to 14 percent of enterprise agentic AI pilots make that jump. The rest stall for a consistent reason: the underlying models can do the job, but nobody built the scaffolding around them. Identity management, audit trails, access-control governance: these are the foundations that go missing, and without them, no amount of model capability moves a pilot into production.

Model Context Protocol has become the default way enterprise agents connect to the rest of the business. Anthropic open-sourced it in November 2024, and as of December 2025 it's governed under the Linux Foundation's Agentic AI Foundation, with OpenAI, Google, Microsoft, AWS, Cloudflare, and Bloomberg backing it. What enterprises report running into are the same obstacles, over and over: technical complexity mapping MCP tools onto legacy internal systems, friction between IT, security, and business stakeholders who don't agree on the right pace, and most often, simply no registry, no approval workflow, no audit layer in place before an agent gets write access to anything that matters. The honest framing for a business case has to hold two things at once: the ROI potential is substantial, but it doesn't execute itself. Governance maturity and adoption rate need to be tracked as two separate metrics, not folded into one optimistic number.

The ROI case when agents reach production

The upside, when agents do reach scale, is large enough to justify real investment in the foundations that get them there. AMD used agentic automation, and it cut HR resolution time by a large majority. These are production deployments with measurable financial outcomes.

Macquarie Bank's results, documented in the Macquarie Group 2026 Operational Briefing, show what this looks like at scale. Fraud losses dropped more than 20 percent in the first half of the 2026 financial year compared to the same period in 2025. Morgan Stanley's DevGen.AI tool, deployed in January 2025, reviewed more than 9 million lines of legacy code and freed thousands of developers from manual code translation so they could work on strategic product development instead.

Set against that, organizations that did not hit year-one ROI show a failure pattern that looks almost identical across cases. The contrast between the two groups is the clearest evidence available that governance sequencing, not model quality, determines whether an agent program becomes a Macquarie or becomes a write-off.

The threat surface agents inherit through MCP

Once an AI agent can both understand content and act on it, every piece of content that agent can read becomes a potential attack vector. Existing security tools were never built to evaluate that threat model. Web application firewalls, API gateways, and data loss prevention systems were designed to catch bad traffic patterns and known signatures. None of them were designed to ask whether an instruction buried inside a document or an email is something the agent should actually follow.

MCP's architecture is part of why this risk scales so fast. It runs on a client-server model: the AI agent acts as the client, sending requests to MCP servers that expose enterprise capabilities, databases, APIs, code repositories, email systems, internal tools, as structured, discoverable interfaces. Before MCP existed, connecting an agent to external tools meant building a custom connector for every single combination of agent and system, an N × M integration problem that scaled painfully. MCP collapses that into one protocol. That collapse makes MCP's security implications enterprise-wide in scope. MCP servers routinely aggregate credentials for multiple enterprise systems behind a single interface, so a compromised server can become a single point of failure across every system it touches and every agent that consumes it.

Two incidents show what this looks like in practice. The EchoLeak attack, tracked as CVE-2025-32711 and disclosed in mid-2025, worked like this: an attacker sent a specially crafted email to a victim. When Microsoft 365 Copilot later read that email while processing an unrelated query, embedded indirect prompt injection instructions triggered the agent to silently exfiltrate sensitive information, email summaries, chat logs, document contents, to an attacker-controlled endpoint. The user never clicked anything.

The Supabase MCP incident, documented by General Analysis, followed a different path to the same outcome. There was no credential theft in the traditional sense, no network intrusion, no software vulnerability to patch. A GitHub MCP indirect injection disclosed roughly six weeks earlier followed the same architectural pattern: an agent with elevated repository access processed a public GitHub Issue containing embedded instructions to exfiltrate private repository code.

Both incidents succeeded for the same reason. The agents had no way to distinguish a legitimate instruction from a malicious one embedded in content they were designed to process, and nothing in either environment was positioned to evaluate the intent behind a tool call before it executed. Conventional controls, WAFs, API gateways, DLP, SIEMs, evaluate traffic patterns and known signatures. None of them can evaluate intent, and that's why they offer no real defense against this category of attack.

The documented attack taxonomy security teams now test against in MCP environments

Tool poisoning hides malicious instructions inside tool metadata. Invariant Labs built a complete proof of concept on Cursor IDE: a hidden instruction buried in the description of a tool, in this case a simple calculator add function, directed the agent to read the user's SSH private key and transmit it to an attacker-controlled server the moment the user invoked that tool. Research benchmarks have found tool poisoning success rates against major LLM agents so high that you can treat it as a near-certain threat in any uncontrolled MCP environment. More capable models sometimes performed worse here, not better, because their superior instruction-following made them more compliant with the poisoned metadata.

Schema poisoning and tool shadowing work through manipulated tool schemas or shadow tools that intercept calls meant for a legitimate tool. Shadow MCP servers, deployed outside any formal governance process, sit invisible to security teams while carrying the same credential aggregation risk as sanctioned ones.

The dominant production risks enterprises are testing against in 2026 cluster around a short list: tool poisoning, unauthenticated or rogue MCP servers, over-scoped permissions, and unmanaged tool lifecycles. That list maps directly onto governance controls, not model-layer defenses. These are named, documented incidents involving named organizations and tracked vulnerabilities, not hypothetical research findings. This is what security investment in this space is actually protecting against.

How authentication and identity failures enable most attacks

The attacks above are not primarily model failures or flaws in the MCP protocol's design. They are the predictable result of deploying agents at scale without a coherent identity and authentication architecture.

Agents multiply credentials fast, because every new integration needs its own authentication path. Only about a quarter of enterprises have a formal, enterprise-wide agent identity strategy, and less than a fifth are highly confident their identity and access management systems can actually handle agent identities, CSA and Strata research found.

Part of the problem is structural. Agents determine their access needs dynamically, at runtime. Pre-provisioned permission sets rarely match what's actually needed. You can also manipulate agents through prompt injection, so they reveal environment variables, exfiltrate credentials, or escalate their own permissions, and that turns the agent itself into an attack surface no static credential policy can fully address.

The MCP specification does call for OAuth 2.1 with PKCE on HTTP-based deployments that implement authorization, along with HTTPS on all endpoints and discoverable authorization server metadata. The NIST NCCoE concept paper "Accelerating the Adoption of Software and AI Agent Identity and Authorization," published February 2026, frames the real requirement as a full lifecycle: identification, authentication, authorization, audit, non-repudiation, delegation, and binding agent actions back to human authority. Fixing identity closes off most of the attack paths described above. It's also, as the next section makes clear, no longer optional from a legal standpoint.

The EU AI Act, DORA, and Deployed Agents

The EU AI Act's high-risk provisions became enforceable on August 2, 2026. DORA's active supervision phase began January 17, 2025. Together, they turn the governance controls described above from good practice into legal obligation for a wide range of enterprise AI deployments already running in production.

The EU AI Act's high-risk provisions cover risk management, data governance, technical documentation, logging, human oversight, and cybersecurity resilience. Non-compliance penalties reach up to €35 million or 7 percent of worldwide annual turnover for prohibited AI practices under Article 5, and up to €15 million or 3 percent for violations involving high-risk AI systems. MCP gateways handling regulated data fall squarely inside the scope of these high-risk obligations. The tool-calling layer isn't exempt just because it sits underneath the application layer.

DORA adds a different kind of pressure: continuous monitoring and integrity-protected audit trails, which shift the burden of proof from having a plan on paper to proving, in real time, that the plan works. Audit logging, human-in-the-loop controls for high-risk actions, and traceable agent identity are not optional enhancements to fund later, once budget frees up. They are legal prerequisites for operating in regulated environments, and their absence is a documented reason pilots stall before reaching production.

The four-layer governance architecture that separates stalled pilots from production deployments

The controls enterprises are converging on in 2026 form a coherent four-layer architecture rather than a loose checklist of isolated tools, and each layer closes off a specific category of the failures already described.

Layer one is inventory and registry: an MCP registry that maps every server and every tool to an owner, a version, a data classification, a permission set, an approval rule, and a kill switch. Independent scans consistently find a meaningful share of live MCP servers running with no authentication. Teams need to know what's actually running before they can govern any of it.

Layer two is identity and authentication: OAuth 2.1-based identity binding gives agents scoped user permissions drawn from the authenticated user, eliminating standing credentials.

Layer three is policy enforcement and access control: an enforced tool allowlist for each agent, a centralized MCP gateway giving security teams one place to see everything, and mandatory human-in-the-loop approval for destructive or irreversible actions, database deletions, financial transactions, bulk record changes, outbound data transfers. Every documented incident above succeeded because no control was positioned to evaluate intent before execution happened. Unapproved dynamic tool additions need to be blocked outright, and any change to a tool's list should be treated as a security-relevant configuration change requiring the same review a production code change would get.

Layer four is runtime detection and audit: real-time detection purpose-built for MCP-specific threats, tool poisoning, prompt injection, intent drift, exfiltration, backed by tamper-proof audit logs and full tracing. Article 12 of the EU AI Act makes tamper-proof, traceable audit logs a legal obligation for high-risk deployments. Recording server identity, tool definition version, caller, user, scopes, arguments, result, and approval status is the minimum bar for satisfying both internal governance and external audit review.

Building the business case: security and governance as ROI enablers

A credible business case for enterprise AI agent investment has to model governance infrastructure as a prerequisite for realizing ROI, not as a tax that eats into it. The evidence is consistent: governance-light deployments fail to reach the production scale where the returns documented earlier actually get generated. Governance belongs in the business case as a precondition, not an afterthought bolted on once leadership asks hard questions.

The cost of stalling deserves its own line in the model. A complete business case quantifies what it costs to never reach production, alongside what it costs to build the governance layer that gets a program there.

Regulatory exposure belongs in the model as a hard cost, not a vague risk factor. Organizations operating in regulated industries face EU AI Act non-compliance penalties up to €35 million or 7 percent of worldwide turnover, and DORA's active supervision phase is already in force. Governance infrastructure that satisfies these requirements works as insurance against a quantifiable penalty, so finance teams should weigh it against other capital requests that way.

Security teams deserve to be framed as the function that enables ROI, not the function that slows it down. The same controls described throughout this piece, the MCP registry, identity binding, policy enforcement at the tool-call level, runtime detection, are what let the other 95 percent of employees, not just power users and developers, access agents safely. The business case for a unified governance platform is also the business case for adoption across the whole organization, not just a narrow group of early adopters.

Investment should move in three phases, and they track the four-layer architecture. Phase three is runtime and compliance: layering in real-time detection, tamper-proof audit logging, and full tracing, which is what makes a deployment defensible under EU AI Act and DORA review and gives security teams the evidence base to expand agent access with confidence over time.

The decision heuristic for evaluating platform options comes down to integration seams. A fragmented stack built from a separate agent builder, a separate MCP gateway, and a separate security tool requires integration work at every seam between them, and produces audit gaps at every one of those boundaries. If you build governance controls into the same platform as the enablement layer, they work best for enabling production scale. Security and ease of use stop competing with each other once the architecture is unified from the start, and a unified architecture is what turns a business case from aspirational into executable.