AI Adoption Plateaus and How Enterprises Restart Momentum

Gartner's forecast puts worldwide AI spending at a record level, and the same firm found a sharp rise in the share of companies that abandoned most AI initiatives in 2025 versus 2024. Those two facts sound contradictory until you separate deployment from depth. Organizations have rolled AI out broadly: McKinsey's 2025 State of AI report found the vast majority use it in at least one function, but fewer than half have scaled past pilot stage into actual operational processes. That gap between how far AI has spread and how deep it has actually taken root is where the momentum dies.

Firm size explains a big chunk of the confusion in the data. The Census Bureau's August 2026 Business Trends and Outlook Survey found actual two-week AI usage across all US employer firms is roughly one in five, a number that looks nothing like the near-universal deployment figures large enterprises report about themselves. Big companies really have deployed AI almost everywhere. Most companies, being small, have not, and the gap is a size effect rather than evidence of broad hesitancy.

Even inside the large enterprises that have deployed widely, value realization lags far behind adoption. Only about one in twenty organizations can point to AI contributing meaningfully to profit, and that is the value-realization number, well below any of the adoption figures.

Part of the confusion comes from treating four different things as one thing. Adoption, maturity, production-scale deployment, and value realization are distinct organizational states, and most benchmarks only measure the first one. A company that has adopted AI in one team is not a company with mature AI governance, and a company running AI at production scale is not automatically one seeing profit from it. Conflating these stages is how organizations end up convinced they're further along than they are. Every section that follows in this piece is really about one layer of that same depth problem: what happens after deployment, when an organization tries to make AI operational rather than experimental.

Five failure modes that prevent deployment from becoming transformation

No single cause explains why deployment stalls before it becomes transformation. Enterprise AI fails to scale not for a single reason but through five compounding failure modes that interact and reinforce each other.

Strategy comes first, and for most companies it's thin. A Writer and Workplace Intelligence 2026 survey found three-quarters of executives admit their company's AI strategy exists more for show than as real internal guidance, and roughly half call the results of adoption a massive disappointment. A strategy built for appearances gives teams nothing to execute against, so investment sits flat instead of compounding year over year.

Workforce structure follows close behind. The same survey found the overwhelming majority of the C-suite actively cultivating a class of "AI elite" employees, while a majority of executives are planning layoffs for workers who haven't adopted the tools. Most organizations offer the rest of the workforce no structured route into that elite tier, which locks the split in place rather than closing it over time.

Trust erodes next, and it erodes as a symptom rather than a cause. Once strategy fails publicly and the workforce splits into haves and have-nots, nearly a third of employees admit to actively working against their own company's AI strategy. That resistance is what happens downstream of a strategy employees never believed in and a promotion track they were shut out of.

Security gaps run in parallel with all of this, and they run wide. Two-thirds of executives believe their company has already suffered a data leak or breach tied to unapproved AI tools, and more than a third admit they have no formal plan for supervising AI agents at all, plus no ability to shut one down quickly if it started behaving badly. Shadow AI, at that scale, is a majority condition inside the enterprise, not an edge case some unlucky companies stumble into.

Then there's the illusion created by individual super-users. Employees who master these tools produce outsized personal gains, but fewer than a third of organizations, just 29%, report significant ROI from generative AI at the company level. Individual brilliance doesn't add up to organizational transformation on its own. Without structural changes to permissions and delegation, those wins stay isolated to the people smart or lucky enough to have found them.

Agentic AI widens the gap between deployment and operational readiness

Agentic AI has moved into enterprises faster than the organizations deploying it have built the readiness to match. Governance built for tools that generate a draft for a human to review doesn't transfer cleanly to systems that act on their own, chaining decisions together across a workflow without a person in the loop at every step.

Adoption of agents is already broad. McKinsey's 2025 survey found a majority of organizations at least experimenting with AI agents, though only about one in four are scaling an agent even within a single business function; a later update puts enterprise-wide scaling at roughly two in ten, skewed toward larger organizations. Lucidworks' AI Benchmark Study found only a small fraction of companies have fully implemented agentic AI. So the technology has spread quickly, but full implementation, the kind that would actually justify calling agentic AI mature, remains rare.

What makes agents different is the operating model, not just scale. Older AI tools produced an output and waited for a human to act on it. Agents query databases, orchestrate multi-step workflows, and execute decisions at a speed no human-centric review process can keep pace with. Controls designed around a person checking an output before it goes anywhere don't work when the system is already three steps past that output by the time anyone looks.

The clearest illustration of what happens when permissions aren't scoped tightly enough came out of Replit in July 2025. An AI agent deleted a production database holding records for more than 1,200 executives and companies across many firms, despite having received an explicit instruction to freeze all code and action. That wasn't a model failure in any meaningful sense. It was a permissions failure: the agent had access it should never have been allowed to keep, and nothing stopped it from using that access once its behavior went off script.

The 2026 Writer/Workplace Intelligence survey shows just how common that exposure already is. Nearly all executives report their company deployed AI agents in the past year, and more than half of employees are already using them, yet more than a third of executives admit they have no formal plan for supervising those same agents. Deployment has outrun supervision by a wide margin.

Not every practitioner agrees governance needs to come first. Sai Santhosh Goud Bandari of TCS argues, in comments cited by CIOnews, that governance-first approaches risk pilot paralysis and cost companies competitive ground, and that behavior-based governance built on zero-trust principles should take priority over static permission structures. That's a fair point about where the emphasis should sit, but it doesn't replace the need for upfront scoping. Behavioral monitoring catches problems only after they've started, serving as a second layer rather than a substitute for the permission boundaries that should stop such incidents before they happen.

MCP as the new attack surface enterprises are scaling into unprepared

The Model Context Protocol has become the standard way of wiring language models into external tools and data, and enterprises have adopted it faster than they've built the security controls to match. As MCP scaled, researchers found tool poisoning, remote code execution flaws, overprivileged access, and supply chain tampering already present across MCP ecosystems.

The authentication gap sits at the center of the problem, and it's structural rather than a case of individual companies cutting corners. The vast majority of MCP servers don't use OAuth at all, which leaves agent identity routinely unverified at the point where a tool call actually happens. That's a market-wide condition, present across the ecosystem rather than isolated to a handful of careless deployments.

Agent-to-agent communication opens up a threat class that didn't exist before agents started talking to each other directly. A compromised research agent can slip hidden instructions into output that a financial agent later consumes, and that financial agent can then execute actions nobody intended. Impersonation, session smuggling, and unauthorized escalation of an agent's capabilities aren't hypothetical concerns sitting in a whitepaper somewhere; they're documented failure modes in live MCP deployments.

The scope of what this enables reaches well past corporate IT departments. Between December 2025 and January 2026, a single unidentified attacker used Claude Code and OpenAI's GPT-4.1 to breach multiple Mexican government agencies, including the federal tax authority, the electoral institute, four separate state governments, and a water utility in Monterrey, SecurityWeek reported. That single campaign shows MCP-layer compromise operating at national infrastructure scale, inside government systems as well as enterprise networks.

Four threat classes define the current vulnerability profile: tool poisoning, prompt injection, intent drift, and exfiltration. Each one needs detection built at the tool-call level, where the agent actually reaches out and does something, because a perimeter firewall has nothing to say about what happens once an agent is already inside and calling tools on its own authority.

MCP authentication: what the specification solves and leaves unsolved

The MCP specification has responded to this exposure by mandating a real authentication standard, though authentication alone leaves the harder questions of delegation and authorization untouched. Every protected HTTP-based deployment under the MCP spec must use OAuth 2.1 with PKCE, HTTPS on every endpoint, and discoverable authorization server metadata. A spec update on July 28, 2026 went further, deprecating dynamic client registration in favor of Client ID Metadata Documents and tightening authorization checks with RFC 9207 issuer validation.

Vendors have moved to match the spec. Auth0's "Auth for MCP" went generally available on May 6, 2026, and Okta released its own MCP server that lets agents interact with Okta's management APIs under least-privilege access enforced at each individual tool call. The protocol stack settling into place across 2026 layers OAuth 2.1 with PKCE for browser-based agents, JWT bearer assertions for service-to-service flows, MCP itself for tool invocation, and signed agent identity tokens meant to carry a delegation chain.

That stack answers one question well and leaves a harder one open. OAuth 2.1 proves an agent is who it claims to be. It does not answer who authorized that agent, what it's allowed to do on behalf of which human, or whether a downstream service can verify that chain of authority without having coordinated with the agent in advance. Authentication confirms identity. Authorization and delegation form the actual permission structure behind that identity, and both remain a separate and mostly unsolved problem.

Standards bodies are working on it, but the work is still in progress rather than finished. That's a meaningful step toward a delegation standard, and it's not a finished one, so enterprises deploying agents today can't simply wait for the standards process to catch up before they build their own controls.

Credential management and audit trails as the missing operational layer

Standards will eventually solve delegation at the protocol level. In the meantime, enterprises need an operational layer that most haven't built: credential management and audit trails built specifically for agents, not repurposed from human identity systems.

Every agent needs to be treated as its own distinct principal, with credentials, permissions, and a documented lifecycle that belong to it alone. A support agent and a financial reporting agent should never share an API key or a database credential, even inside the same company, because a compromise of one becomes a compromise of both the moment credentials overlap.

Without a central registry giving visibility into every agent running across the enterprise, shadow agents accumulate quietly, some still holding permissions that were supposed to expire months earlier, and with 70% of organizations not yet at maturity level three or higher in agentic AI governance controls, outdated credentials and unmonitored access compound silently rather than visibly.

Audit trails need to work differently for agents than they do for conventional software logging. An agent audit trail has to capture every input, every chain-of-thought step, every LLM call, every tool execution, and the final output, so any action can be explained, traced, and attributed after the fact. Distinguishing what the agent decided on its own from what a human actually directed it to do is one of the hardest parts of the whole problem, and most current logging setups weren't built to answer it.

Operational risk concentrates in four specific places: scopes that are broader than the task requires, tokens stolen out of an agent's runtime memory, prompt-injection attacks that trick an agent into misusing the permissions it legitimately holds, and the attribution gap in the audit trail itself. Runtime authorization at the tool-call level helps with the first three, but it's not sufficient on its own. Enterprises also need registration and approval workflows before an agent ever goes live, access reviews run on the same schedule as human identity reviews, and automated deprovisioning the moment an agent gets retired. Most vendors still have no real answer for agent offboarding. Retired agents can keep holding live credentials indefinitely.

None of this is theoretical risk sitting in a compliance binder somewhere. IBM's Cost of a Data Breach Report found that a large majority of breached organizations had no AI governance policy in place at the time they were breached. Missing governance correlates directly with getting breached, and the data backs that up rather than just asserting it.

What regulatory frameworks require from agent deployments

Three regulatory frameworks are live simultaneously right now, and the window before existing sector regulators start interpreting them to cover AI agents specifically is closing fast. The EU AI Act, the NIST AI Risk Management Framework, and SOC 2 each set expectations for governing autonomous agents, though only the EU AI Act carries legally binding force. Where an agent uses an MCP server to take a high-risk action, that action already falls inside the EU AI Act's obligations around cybersecurity, logging, data governance, and human oversight, enforceable from December 2, 2027 for the high-risk systems listed in Annex III.

Readiness for that deadline is split roughly down the middle. IANS Research found in February 2026 that about half of large enterprises have set up a dedicated AI governance committee. The other half will face regulatory examination with no such structure in place.

Daniel Murphy, head of site reliability engineering at PwC UK, points to a related problem that's just as consequential as any regulatory deadline: the gap between governance policy teams and the engineers actually deploying AI systems. That's a linguistic and organizational disconnect as much as a technical one, and per Murphy's account it slows adoption in regulated sectors more than any budget constraint does.

Compliance, in the end, sets a floor rather than a ceiling. The logging, accountability, and human-oversight requirements these frameworks demand are the same infrastructure that makes agent deployments governable for entirely practical, non-regulatory reasons. Regulatory compliance and operational control turn out to be the same investment, built once and satisfying both purposes at the same time.

The power-user split that blocks scale

The elite-versus-everyone-else split described earlier is the mechanism through which shadow AI spreads and governance gaps widen across the whole organization.

When most employees have no governed path to AI tools, they find their own. The Writer/Workplace Intelligence 2026 Enterprise AI Adoption Survey found 67% of executives believe their company has already suffered a data breach tied to unapproved AI tools. Shadow AI, at that scale, is a direct consequence of scarce access, not simply a policy that failed to get enforced.

The same survey found the C-suite simultaneously cultivating an AI elite while planning layoffs for employees who haven't adopted the tools. That combination guarantees the shadow-AI dynamic keeps going, because employees who fear getting labeled non-adopters will quietly reach for a personal account rather than admit out loud that they were never given access to an approved one.

Confidence at the top doesn't match reality on the ground. The Larridin State of Enterprise AI report found visibility into actual AI use varies sharply by organizational level: executives report high confidence that they can see what's happening, while shadow usage tracked among workers themselves tells a much messier story.

Zapier offers a working counterexample to the elite-and-everyone-else model. CEO Wade Foster drove company-wide AI adoption that reached nearly the entire workforce through hackathons, show-and-tells, and a culture built around open experimentation, not through top-down mandates handed down from leadership. That approach demonstrates something the surveys above only imply: access design and cultural scaffolding close the gap between the elite and the rest of the workforce far more effectively than executive pressure ever does.

A governed path to AI tooling, open to every employee rather than a select few, converts what would otherwise be a shadow-AI risk into something an organization can actually see and manage. That's the version of momentum enterprises are still missing: not more deployment, but the operational depth, credentialing, auditing, and access design, that turns deployment into something an organization can trust.