The Future of Enterprise Software Is AI-Native

Enterprise software is going through a structural replacement rather than a slow upgrade cycle. The old model of SaaS, built around dashboards and workflows that a human reads and acts on, is giving way to autonomous agents that read, decide, and act without waiting for a person to click anything. A support ticket used to get summarized by software and handed to a human to resolve. Now an agent reads the ticket, updates the record, files the refund, and messages the customer, start to finish, with nobody in the loop.

The change is not a matter of bolting new AI features onto old products. Large incumbents are rebuilding around AI-first engineering, while new companies built natively around agents are opening up entire market segments that the old SaaS model never touched. The money backs this up: Gartner projects that agentic AI could account for roughly a third of all enterprise application software revenue by 2035, up from a sliver of that today. It is a forecast about where the revenue in enterprise software moves next, and it sets up the question this piece spends the rest of its time on: what is this new architecture actually built on, and what did building it fast cost in security terms?

MCP as the connective tissue of AI-native enterprise architecture

The infrastructure making this possible has a name: the Model Context Protocol, or MCP. It let the agent-native enterprise happen quickly, swapping out dozens of one-off integrations for a single standard way for an agent to talk to a system. Anthropic open-sourced MCP in 2024, and it gives an agent a standard path into databases, SaaS tools, and internal systems. Before MCP existed, every one of those connections was custom-built, and building it custom meant someone, somewhere, usually had to sign off on it from a security standpoint.

That review step got skipped as MCP spread. Lower friction for developers is a genuine win, but the same lower friction makes it easier for a security review to get waved through or missed entirely, as the Lyzr guide captures precisely. Server registration outpaced security review, so scale grew without a matching increase in scrutiny.

The scale is not abstract. NimbleBrain's analysis counted 3,012 unique servers in the official MCP registry alone, with thousands more sitting in unofficial directories outside anyone's view. The protocol itself keeps evolving too: News4Hackers' coverage details the 2026-07-28 specification revision, with its release candidate locked on May 21, 2026, and the final version published July 28, 2026, a major overhaul meant to support cloud-native deployment at scale.

What makes this structurally different from the old integration model is speed. A developer can stand up an MCP server against a live production database in an afternoon. The moment an agent discovers that server, its tools become part of what the agent can actually do. Connection speed and exposure speed are now the same number.

The attack surface that opened when adoption outran security maturity

MCP was never built to enforce security on its own. The official MCP specification says so directly: the protocol "cannot enforce these security principles at the protocol level," according to the Practical DevSecOps security guide's reading of the spec. Security has to be added by whoever builds and deploys the server. Left alone, an MCP server inherits whatever permissions it was handed, and every request an agent sends flows through unchecked.

The vulnerability count shows this is not a theoretical worry. UltraViolet Cyber's advisory documented more than 40 CVEs disclosed against MCP implementations across the Python, TypeScript, Java, and Rust SDKs between January and April 2026 alone. Microsoft patched a high-severity flaw in its own MCP servers during its March 2026 security release, a bug that could let an attacker manipulate how an AI assistant talks to the services it's connected to. In April 2026, OX Security disclosed a systemic vulnerability across Anthropic's MCP SDK implementations in Python, TypeScript, Java, and Rust, affecting hundreds of thousands of vulnerable instances across a widely distributed supply chain.

Part of the problem is that nobody can check the work. A meaningful share of servers sitting in the public registry have no available source code at all, so there is no way to audit what they actually do. That gap, between how many servers exist and how many anyone can actually inspect, is the backdrop for the threat that deserves the closest look: tool poisoning, which exploits exactly the trust an agent is built to extend to the tools it's been given.

Tool poisoning: the hardest MCP threat to catch

Tool poisoning is the attack that matters most in the MCP world, because it does not exploit a bug. It exploits the thing an agent is designed to do: read a tool's description and trust it. An agent looks at that description to decide how and when to call the tool, and it treats the words in that description with roughly the same authority as its own system prompt. A malicious server can hide commands inside that description text. The model follows them, reads files it shouldn't, leaks secrets, and still hands back an answer that looks completely normal on the screen.

There's a variant of this called the rug pull. A tool gets approved once, looking harmless, and its description or behavior changes quietly afterward, turning a benign tool malicious without ever triggering a second approval. This works because MCP picks up description changes on the fly, as UltraViolet Cyber describes it, with no checkpoint forcing a re-review.

Microsoft Incident Response and its Defender research team laid out how this plays out inside a real company in mid-2026. A finance team's agent connects to a third-party invoice enrichment tool, approved once, never given a real security review afterward. An attacker updates the tool later, keeping its visible name and summary untouched, but buries a hidden instruction in the description telling the agent to grab unpaid invoices and attach them to the next outbound call. Nothing about the tool looks different to a human glancing at it. The agent just starts quietly leaking financial data as part of its normal workflow.

The most counterintuitive part of this research: more capable models often perform worse against tool poisoning, not better. Their stronger instruction-following made them more likely to comply with malicious text buried in a tool's metadata, not less. Capability is not a defense here, and in some cases it is the opposite.

NimbleBrain's analysis describes how Invariant Labs proved the real-world version of this against Claude Desktop, pulling private repository source code out through a prompt injection payload planted inside a public GitHub issue, processed by the official GitHub MCP server. MCP's own security guidance has since caught up to the problem on paper: the ITECS analysis states that tool descriptions should be treated as untrusted unless they come from a server the deployment explicitly trusts. Acting on that guidance takes controls that most deployments simply have not built.

The credential and authentication gap underneath the agent stack

Tool poisoning is a runtime attack. Weak authentication underlies the runtime attacks described so far. Weak authentication across most MCP deployments is the default setting most servers ship with, not a misconfiguration a patch fixes, and static credentials make that default permanent.

NimbleBrain's analysis of the full MCP registry found that 91.5% of servers rely on static API keys, the kind stored in.env files, mcp.json configs, and plain environment variables, with only a small fraction using OAuth. Static keys don't expire on their own. When a developer leaves a company, the MCP credentials tied to that person's work keep working indefinitely. Those API keys typically grant full access, with no scoping to a narrower task, no time limit, and no rotation schedule.

The overpermissioning that results is not an accident of rushed development. NimbleBrain documents cases like a calendar server built only to read events that instead requests write access to Drive, Gmail, and the Admin Console, broad access simply because it's easier to build against, not because the task needs it. Research from Astrix Security backs this up at scale: NimbleBrain's review of the research found that the large majority of MCP servers require some form of credential, but very few scope that credential down to the minimum the task actually requires.

Stacking enough of this up compounds the exposure fast. A single agent can hold live credentials for a CRM, an email account, cloud infrastructure, and a payment system all at once. Traditional identity and access management was built around static policies and a human logging in. It was never designed for a system that needs different privileges from one task to the next, second by second.

Why audit logging absence makes MCP deployments structurally non-compliant

None of this would be as serious if it were at least visible after the fact. It isn't visible after the fact. A standard MCP deployment does not produce audit trails that satisfy any major compliance framework, and that gap is a present legal exposure for any regulated enterprise running one today, not a future risk sitting on a roadmap somewhere.

Picture an MCP server pulling thousands of customer records and sending them to an outside endpoint. In most deployments, nobody logs that it happened at all. There's no record of which agent called which tool, what parameters it sent, what data came back, or whether the server actually did what it was supposed to do. NimbleBrain's analysis notes that SOC 2, HIPAA, and GDPR each require an audit trail for system access, in their own way, and a standard MCP deployment fails all three of those requirements at once.

A compliant deployment needs a trail that captures which human user a request started with, what reasoning the agent used to act, what data it returned, and whether it checked an access policy before acting. Standard MCP servers produce none of that on their own. Some early work is underway to close this: tracing agent execution with OpenTelemetry across MCP pipelines is gaining attention as a path to real auditability, per coverage from sources including SigNoz and the MCP GitHub community, though adoption of that pattern is still the bottleneck holding it back.

As adoption spreads, governance becomes infrastructure rather than an optional add-on. The speed that made MCP valuable, standing up a server in an afternoon and putting its tools in front of an agent immediately, is the same speed that outran the controls meant to catch a misbehaving tool or an overpermissioned credential before it caused damage. Closing that gap takes something that sits at the point of connection itself, enforcing policy and logging access as servers get discovered and used, rather than trying to audit the damage afterward. The enterprises that treat this as infrastructure, not an afterthought, are the ones that get to keep the speed MCP made possible without inheriting the exposure that came bundled with it.