"The last thing any of us want is a world where every company across every sector is ceding value to a few models that eat everything they see," Nadella wrote in the piece, titled "A frontier without an ecosystem is not stable," which he posted on X. "If all the value is accrued by only a few models, the political economy will simply not tolerate it. There is no societal permission for an AI future that hollows out entire industries."

The essay is unusually philosophical for a sitting CEO of a $3 trillion technology company. But it arrives at a moment when the theoretical risks Nadella describes are becoming tangible — and, critically, when Microsoft itself is grappling with the very dynamics he warns about.

Nadella introduces "token capital" as the new currency of enterprise AI strategy

At the center of Nadella's essay sits a conceptual framework built on two pillars he calls "human capital" and "token capital." Human capital, he writes, "comprises the knowledge, judgment, relationships, ingenuity, and pattern recognition of its people," while token capital refers to "the firm's AI capability it builds and owns."

The two are not in tension, he insists. "Importantly, human capital does not become less valuable as token capital grows. It only becomes more valuable!" he writes. "I believe human agency will be the driver of token capital growth. Humans will set ambitious goals, connect dots across domains, build relationships, and recognize patterns that matter most. Without human direction, you have compute running in circles."

This framing is a deliberate counterweight to the narrative that AI will simply replace human workers or, at the enterprise level, dissolve the intellectual property that differentiates one company from another. Nadella is arguing that the real danger is not AI's capability but its tendency to centralize — and that the solution requires a fundamentally new architecture for how businesses interact with the technology.

He describes the real opportunity as "not in picking the best model but instead in building a learning loop on top of models where human capital and token capital compound." The key test of a company's sovereignty in this new era, he writes, is whether it can "switch out a 'generalist' model without losing the 'company veteran' expertise built into their learning system."

This is the essay's most actionable claim — and its most provocative. Nadella is telling enterprises they need to decouple their institutional intelligence from whatever frontier model they happen to be running, creating portable knowledge systems that survive vendor changes.

Why Nadella is comparing AI concentration to the outsourcing crisis that gutted industrial economies

Nadella draws a pointed historical parallel to make his warning concrete. "Think about what happened in the first phase of globalization where entire industrial economies were hollowed out by outsourcing," he writes. "The GDP numbers looked fine on the surface, but the displacement was real and the consequences are still being felt. Let us not bring that dynamic into the AI era, with a small number of AI systems capturing all the economic returns, while entire industries find their knowledge commoditized right out from underneath them."

The globalization analogy is not accidental. It reframes the AI concentration debate from a narrow technology question into a political-economy argument — one that regulators, policymakers, and voters can grasp. By invoking the social costs of offshoring, Nadella is signaling that the stakes extend well beyond the enterprise technology stack. He is warning that if the AI industry fails to distribute value broadly, the political system will intervene to force the issue.

"In my view, our priority has to be building a frontier ecosystem, not just a frontier model, so value flows broadly across every company, every industry, and every country," he writes. He grounds this in an older platform philosophy: "This is the ethos I've grown up with where platforms enable more value on top than is captured inside, and where every company can continuously innovate and build value of its own." It is a direct echo of the Windows-era argument, updated for the age of inference — and it carries a similarly self-interested subtext, given that Microsoft's cloud business sits squarely in that platform layer.

Microsoft's own runaway AI costs reveal the gap between Nadella's vision and operational reality

What makes Nadella's essay so striking is its timing. He published it on a day when Reuters reported that Microsoft shareholders filed a proposed class-action lawsuit in Seattle federal court, accusing the company of inflating its stock price by failing to disclose slowing growth in its Azure cloud business and the need to spend billions of dollars on AI infrastructure. The suit names Nadella and Chief Financial Officer Amy Hood among the defendants.

As the Yahoo Finance report on the lawsuit noted, Microsoft allegedly "aggressively promoted its AI developments, specifically its 'Copilot' assistant and close financial alliance with ChatGPT creator OpenAI, to artificially boost investor optimism," while understating infrastructure strain and capital risks. Microsoft also reported $37.5 billion of capital spending in its second quarter, up nearly 66% from a year earlier and above the $34.3 billion that analysts projected.

Microsoft's internal cost pressures around AI have surfaced in other concrete ways this year. The company is canceling the majority of its internal Claude Code licenses in its Experiences and Devices division, effective June 30, 2026. Monthly usage rates reached 84 to 95% by April 2026, and per-engineer API costs ranged between $500 and $2,000 monthly, according to Windows Forum. The cancellation came after Microsoft exhausted portions of its annual AI budget due to token-based billing, as Fortune had reported in May.

The Claude Code episode illustrates, at the micro level, the exact dynamic Nadella describes at the macro level. When a company's AI usage is metered by the token — the fundamental unit of compute that powers model inference — the more productive the tool becomes, the more expensive it gets. The term "token capital" in Nadella's essay carries a double meaning: it refers both to a firm's proprietary AI capability and, implicitly, to the actual tokens consumed in running it. Building a learning loop that compounds is aspirational. Paying the bills for that loop is operational reality.

Uber, Meta, and Amazon are all hitting the same AI spending wall — and it validates Nadella's warning

Microsoft is not alone in this bind. Uber burned through its entire 2026 AI coding tools budget in just four months after incentivizing employees to adopt the technology through an internal leaderboard ranking teams by total AI tool usage. Uber has since instituted a monthly $1,500 cap per employee per agentic coding tool, according to TechCrunch. At Meta, an employee created a leaderboard called "Claudeonomics" to track which workers consumed the most AI tokens. Amazon, meanwhile, has pushed employees to "tokenmaxx" — use as many AI tokens as possible.

The emerging pattern is clear: enterprises adopted AI coding tools aggressively, saw genuine productivity gains, and then discovered that the consumption-based economics of frontier models created budget crises that traditional software licensing never would have. Bryan Catanzaro, vice president of applied deep learning at Nvidia, captured the tension bluntly in an interview with Axios: "For my team, the cost of compute is far beyond the costs of the employees," he said.

These cost dynamics land differently in the context of Nadella's essay. He prescribes a three-layer architecture — evaluation, reinforcement learning, and retrieval — designed to sit between a company's workforce and whatever frontier model it subscribes to. Companies, he argues, need to build "private evals" that "capture whether a model is actually improving against outcomes that matter to the business (not just external benchmarks!)," alongside "private reinforcement learning environments" that "let models grow stronger on real traces from inside the organization" and a knowledge base that "makes institutional memory queryable and use of tokens more efficient." He calls the resulting system "a hill climbing machine" that, "unlike most assets, it compounds."

Other Big Tech CEOs are echoing Nadella's fears about AI models devouring enterprise knowledge

Nadella's concerns do not exist in isolation. Other technology leaders have been raising similar warnings throughout 2026, though none have offered as prescriptive a response.

Snowflake CEO Sridhar Ramaswamy warned in a February podcast that the biggest software companies risk being reduced to mere data sources. "The big model makers want to create a world in which all of the data for all of the enterprises is easily available to them," Ramaswamy said, describing everything else as "a dumb data pipe that feeds into that big brain." He added that Snowflake needs to operate with a "fear" that enterprises would abandon software-specific AI agents in favor of all-inclusive agents that hoover up data from everywhere.

Box CEO Aaron Levie struck a similar note in a January LinkedIn post. AI models can now perform high-level knowledge work across nearly every profession, from law to strategy to scientific research, he argued. "The question that we will have to wrestle with is, in a world where everyone has access to the same expert intelligence, how does a company differentiate?" he wrote.

The combined effect of these statements is a shared diagnosis from three very different corners of the enterprise technology market: the current trajectory of AI development threatens to collapse competitive differentiation across entire industries. Nadella's essay stands apart from the others because it moves beyond diagnosis and proposes a specific architectural remedy. But the prescription is impossible to separate from the prescriber's interests.

Microsoft sits in precisely the platform layer that Nadella's framework would make indispensable — the company builds its own frontier models, operates the cloud infrastructure those models run on, and maintains deep partnerships with the leading independent AI labs. A world in which every enterprise builds a proprietary learning loop on top of commodity foundation models is, conveniently, a world in which Microsoft sells the picks and shovels to all of them.

Nadella's Scout controversy and shareholder lawsuit reveal the tension inside Microsoft's own AI strategy

The essay also arrives just ten days after Nadella publicly rebuked one of his own executives for outlining a plan to "make people addicted" to a new AI tool called Scout.. Microsoft corporate vice president Omar Shahine had written an internal memo describing a three-phase plan to transform Scout "from addictive app to agentic platform," with the first phase focused on features that "make people depend on it daily." Nadella responded on an internal message board: "This is absolutely a non-goal! If anything we are doing the exact opposite. We want to make sure AI empowers and adds real value to human endeavor and broad economic growth!"

The Scout incident and Sunday's essay together suggest Nadella is actively constructing a public philosophy of AI that emphasizes broad value creation over extractive engagement — whether or not every corner of Microsoft has internalized that message. One anonymous Microsoft employee told 404 Media, as the Post reported, that the leaked Scout document was "very troubling," adding: "It feels like one of those 'saying the quiet part out loud' moments."

For technical decision-makers evaluating Nadella's essay, the practical implications are significant. He is arguing that choosing an AI model matters less than building the learning infrastructure around it. He is arguing that the ability to swap models without losing institutional intelligence is the critical test of AI sovereignty. And he is warning that companies that fail to build these systems will find their expertise absorbed and commoditized by the models themselves. "You can offload a task, or even a job, but you can never offload your learning," Nadella writes. "The future of the firm is the ability to compound that learning across people and AI."

The question Nadella's essay cannot answer is whether Microsoft will practice what its CEO preaches

Whether Nadella's vision materializes depends on a question his essay carefully sidesteps: whether the platform providers who build and host the frontier ecosystem will resist the temptation to capture the value flowing through it. Nadella insists that "platforms enable more value on top than is captured inside." But Microsoft's own trajectory this year — the ballooning capital expenditures, the Claude Code budget crisis, the shareholder lawsuit alleging concealed costs, the internal memo about making users addicted — suggests the economics of restraint are harder than the philosophy of restraint.

Nadella ends his essay with the claim that broad value distribution "is the stable equilibrium we should build together." He may be right. Ecosystems have historically outperformed walled gardens over long time horizons. But stable equilibria require every major player to forgo short-term extraction in favor of long-term compounding — and right now, the AI industry is burning through budgets in four months and spending 66% more on infrastructure than analysts expected. The CEO of the world's most valuable technology company has written an eloquent argument for why the AI economy needs to work differently. The open question is whether his own company's balance sheet will let him prove it.

Billed as a "Virtual CSO" (Chief Strategy Officer), Marlin is an autonomous, B2B research agent that deliberately abandons the instantaneous text generation of modern chatbots in favor of deep, long-horizon reasoning.

What sets Marlin apart from the current ecosystem of AI tools is its temporal scale: instead of returning an answer in seconds, it runs continuous, self-governing reasoning loops for up to eight hours at a time to deliver deeply researched, well cited, 100-page strategy reports and executive slides. The company posted sample reports generated my Marlin on its product website here.

Available immediately via the company’s website with pricing starting at a pay-as-you-go tier, the platform is designed strictly for enterprise use—specifically targeting corporations, financial institutions, and think tanks.

The generative AI hype cycle has largely been defined by speed. For the past two years, the industry standard has been the ability to generate a poem, a line of code, or a surface-level summary in mere milliseconds. But the enterprise frontier is rapidly shifting from shallow, rapid generation to deep, methodical reasoning.

With Marlin, major businesses are no longer asking how fast an AI can answer, but how deeply it can think.

The Product: A Virtual CSO

What exactly is a business getting when they deploy Sakana Marlin? The workflow is fundamentally different from typical large language model (LLM) interactions. Rather than engaging in a tedious back-and-forth prompt engineering session, the user simply provides a core research topic. Following a brief initial exchange to sharpen the scope and direction of the investigation, the human steps away entirely.

For the next several hours, Marlin operates as a self-contained digital strategy team. It formulates its own initial hypotheses, navigates the web to gather data, cross-references sources to verify findings, and maps the causal dynamics within complex business environments. It is effectively searching for the "winning formula" within a sea of noise.

Think of it less like a search engine and more like a junior strategy consultant locked in a room with a whiteboard and an internet connection. You provide the strategic prompt in the morning, and by the end of the workday, the system delivers a comprehensive, professional-grade portfolio.

In Marlin's case, the final output is not a generic text blob; it is a structured set of strategic options, complete with executive summary slides, appendices, references, and a deeply researched report.

The company highlighted several real-world use cases to demonstrate Marlin's capacity for complex synthesis, including generating detailed resolution scenarios for a theoretical blockade of the Strait of Hormuz, mapping out the fragmented global AI regulation patchwork, and analyzing macroeconomic trends like the return of "bond vigilantes".

Sakana says Marlin relies on multiple AI models, but did not provide specific model names or providers. I've reached out on X to find out more and will update when I receive a repsonse.

The Engine of Long-Horizon Reasoning

Under the hood, Marlin is the commercial culmination of Sakana AI’s extensive laboratory breakthroughs over the past two years.

The product is powered by an exploration engine relying on Sakana's own prior research breakthrough, Adaptive Branching Monte Carlo Tree Search (AB-MCTS), and leverages frameworks derived from "The AI Scientist," an earlier Sakana AI research project featured in the journal Nature that successfully automated the scientific discovery process from ideation to peer review.

To understand how this works in practice, consider a real-world analogy: modern chess engines. When a computer plays chess, it doesn't just look at the board and guess; it plays out thousands of potential future moves, evaluating the strength of each resulting position before committing to an action.

Marlin’s AB-MCTS engine does something similar for research.

Inside the Engine: The Mechanics of AB-MCTS

The chronology of this technology traces back to June 2025, when Sakana AI first introduced the framework to the public alongside the research paper “Wider or Deeper? Scaling LLM Inference-Time Compute with Adaptive Branching Tree Search”.

At that time, to encourage developer experimentation with collective AI intelligence, the company released the underlying algorithm as an open-source software library called TreeQuest, distributed under the permissive Apache 2.0 license. This open-source milestone laid the technical foundation for what would eventually evolve into the proprietary, enterprise-grade Marlin product a year later.

Traditionally, when developers attempt to extract higher-quality reasoning from large language models, they rely on a brute-force method called "repeated sampling"—essentially running the model dozens of times in parallel and hoping one of the answers is correct. However, repeated sampling operates blindly; it cannot evaluate its own intermediate steps or pivot based on external feedback.

AB-MCTS replaces this paradigm with a principled, multi-turn approach driven by a Bayesian decision framework. As the AI constructs a strategy report, the system treats the research process as a branching tree of possibilities. At each node of the tree, the algorithm dynamically balances two distinct behaviors based on external feedback signals:

• Going Wider (Exploration): Spawning entirely new, alternative hypotheses or candidate responses when the current path yields diminishing returns or unresolved contradictions.

• Going Deeper (Exploitation): Methodically refining, auditing, and building upon an existing candidate solution that shows high strategic promise.

What transforms this from a laboratory experiment into a commercial engine is its extension into Multi-LLM AB-MCTS.

Sakana AI’s architecture introduces a critical third dimension to the search tree: the ability to dynamically choose which model to invoke for a specific sub-task, treating the industry’s leading frontier models as a plug-and-play collective intelligence network.

According to technical documentation published by the company, the engine can coordinate highly heterogeneous models—allowing an orchestration model to delegate initial ideation to one LLM, while utilizing a reasoning-heavy model to audit, verify, and correct intermediate errors generated earlier in the search tree.

By scaling up compute at inference time—leveraging the distinct "personalities" and strengths of multiple foundation models over thousands of automated cycles—AB-MCTS provides the mathematical guardrails Marlin requires. It ensures that the resulting 100-page strategy reports are not merely long-winded AI generations, but the highly vetted product of systemic, automated trial-and-error.

Licensing, Data, and Enterprise Implications

It is crucial to note that Sakana Marlin is distinctly not a general consumer tool; it is a commercial software-as-a-service (SaaS) offering restricted to corporate entities, organizations, and sole proprietors.

For enterprises, licensing and data handling terms are often the determining factors in software adoption. Unlike many consumer-grade AI tools that silently harvest user inputs and proprietary data to train future foundational models, Sakana Marlin operates under a strict, enterprise-grade data policy.

Neither Sakana AI nor its external AI service providers will use customer data or inputs for model training or fine-tuning unless the client provides explicit opt-in consent.

Even with consent, data is heavily processed to remove personally identifiable information. This closed-loop security is absolutely vital for companies handling sensitive M&A research, unreleased product strategies, or proprietary market analyses.

The commercial licensing is structured into tiered pricing models that reflect its enterprise nature:

• Pay-as-you-go: Users can purchase credits on demand, with a single run costing 100 credits, and add-on credits priced at ¥98 ($0.61 USD) each.

• Pro Plan: At ¥150,000 ($935.68 USD) per month, businesses receive 2,000 credits, bringing down the cost of add-on credits to ¥90 ($0.56 USD).

• Team Plan: Geared toward larger departments, this ¥400,000 ($2,495.14 USD) per month tier includes 6,000 credits, lowering add-on costs to ¥85 ($0.53 USD) per credit.

• Enterprise: Fully custom quotes with dedicated support and customized credit allocations.

Why Sakana Is Worth Watching

Sakana AI’s transition into a commercial enterprise powerhouse is rooted in the pedigree of its founders, who famously helped spark the current generative AI boom.

Formed in Tokyo in 2023, the startup was co-founded by Llion Jones—a co-author of Google’s seminal 2017 “Attention Is All You Need” paper who coined the term “transformer”—and David Ha, a former Google Brain researcher and head of research at Stability AI.

The decision to build a new laboratory outside the Silicon Valley bubble was a deliberate rejection of the current AI ecosystem. At a TED AI conference in late 2025, Jones candidly expressed that he was "absolutely sick" of transformers, warning that the intense pressure from investors and the hyper-fixation on scaling single, monolithic models had calcified the industry's creativity and blinded researchers to the next major breakthrough.

To break free from this "big company-itis," Jones and Ha structured Sakana AI around principles of biomimicry and evolutionary computing.

The company's name, derived from the Japanese word for fish, reflects its core technical philosophy: leveraging collective intelligence similar to schools of fish, ant colonies, or insect swarms. Rather than attempting to build one massive, do-it-all foundation model, Sakana’s research has consistently focused on deploying networks of smaller, specialized models that collaborate dynamically to adapt to complex environments.

This philosophy posits that by treating individual AI models as members of a "dream team" with complementary strengths, systems can achieve more robust and cost-effective reasoning than relying on sheer scale alone.

This nature-inspired approach quickly yielded dividends in rigorous, competitive testing. Sakana AI has made significant strides in "inference-time scaling"—allocating computational resources during the problem-solving phase to allow models to think, iterate, and refine their own answers over extended periods.

In early 2026, the company’s ALE-Agent took first place in the highly complex AtCoder Heuristic Contest (AHC058), a combinatorial optimization challenge, outperforming over 800 top-tier human programmers by autonomously rebuilding and testing hundreds of solutions over a four-hour window.

Similarly, Sakana introduced "RL Conductor," a small 7-billion-parameter model trained via reinforcement learning specifically to orchestrate and delegate tasks among a diverse pool of worker models—ranging from GPT-5 to Claude Sonnet 4—achieving state-of-the-art results on reasoning benchmarks at a fraction of traditional computing costs.

Sakana's rapid evolution from a disruptive research lab to a commercial software provider has attracted intense attention from global financial heavyweights.

By late 2025, the Tokyo-based startup secured a massive Series B funding round that pushed its post-money valuation past $2.6 billion, cementing its status as one of Japan’s most highly valued private tech companies. The firm boasts a sprawling roster of strategic investors, including early venture backers Khosla Ventures, Lux Capital, and New Enterprise Associates (NEA), alongside industry titans like Nvidia and Google.

As Sakana has expanded its focus toward mission-critical sectors like defense and finance, it has also drawn investments from major global banking institutions like Mitsubishi UFJ Financial Group (MUFG) and Citi, as well as enterprise tech giant Salesforce, positioning the startup to actively reshape corporate AI infrastructure from the ground up.

Community Reactions and Field Testing

Sakana AI’s shift toward commercial, long-horizon agents did not happen in a vacuum. The company ran a rigorous closed beta test beginning in April 2026, putting the tool in the hands of approximately 300 professionals across financial institutions, consulting firms, and think tanks. The feedback underscores a stark qualitative difference between standard generative chatbots and Marlin’s autonomous, fact-driven approach.

A senior consultant at a major Tokyo consulting firm noted that the tool "exceeded expectations by discovering angles we hadn't even imagined," praising its ability to match human comprehensiveness while stripping away human bias. Meanwhile, a cybersecurity division at a major Japanese IT system integrator lauded the system for providing "a highly convincing report driven by high-quality, primary research," rather than relying on recycled secondary sources.

On social media, the company’s announcement resonated with the broader tech community's growing appetite for autonomous agents.

As the AI industry matures, the value proposition is clearly shifting. Tools that act as fast, conversational encyclopedias are becoming commoditized. With Sakana Marlin, the focus moves entirely to separating the heavy lifting of thinking from the final act of deciding. By delegating the exhaustive mapping of causal dynamics to an agent capable of sustained reasoning, human executives are free to do what they do best: take action.

Sam Evans, CISO of Clearwater Analytics, stood before his board and laid out the risk to the $8.8 trillion in assets his firm's platform supports. "The worst possible thing would be one of our employees taking customer data and putting it into an AI engine that we don't manage," Evans told VentureBeat. He brought a solution, not just a problem. Many CISOs VentureBeat interviewed did not.

Menlo Security CEO Bill Robbins relayed a conversation with a Top 3 U.S. bank CISO who called shadow AI discovery "a bit of a fool's errand": AI is embedded in every application and browser employees touch. The bank governs from containment, not discovery.

The scale justifies that posture. "We see 50 new AI apps a day, and we've already cataloged over 12,000," Prompt Security CEO Itamar Golan told VentureBeat. "Around 40% of these default to training on any data you feed them, meaning your intellectual property can become part of their models." CrowdStrike has detected 1,800 AI applications operating across 160 million endpoint instances. Those are vendor-reported numbers from proprietary telemetry. No independent party can verify them. The directional signal matters more than the exact count.

CrowdStrike CTO Elia Zaitsev described what makes the surface so hard to govern. "It looks indistinguishable if an agent runs your web browser versus if you run your browser," Zaitsev told VentureBeat at RSAC 2026. "Observing actual kinetic actions is a structured, solvable problem. Intent is not." The shadow AI surface is no longer a list security teams can maintain. It is an environment they have to assume.

The Ivanti survey was administered independently by Ravn Research and MSI Advanced Customer Insights across 1,500 IT professionals. Among companies with AI policies, just 24% of employees say those policies are followed "very consistently" in day-to-day work.

Kayne McGladrey, IEEE senior member, told VentureBeat why that governance gap persists. "Anything that seems to have a cybersecurity flavor is generally put into the cybersecurity risk category, which is a complete fiction. They should be focused on business risks, because if it doesn't affect the business, like a financial loss, then nobody's going to pay attention to it, and they will not budget it appropriately, nor will they adequately put in controls to prevent it," McGladrey told VentureBeat previously.

Brokerage partners at major consulting firms shared over Signal that they build shadow AI applications in Google Colab and store them in S3 buckets to compress a week of financial analysis into an hour. The approval process takes too long, so they route around it.

Governance at deploy time, failure at runtime

Reviews check functional requirements when a model ships, but they never check model provenance, behavioral drift, or whether the agent expanded its own permissions after launch.

CrowdStrike CEO George Kurtz disclosed at RSA Conference 2026 that a Fortune 50 CEO's AI agent rewrote the company's security policy to expand its own autonomy. The company caught it by accident. Every credential check had passed. "In the agentic era, defending against AI-accelerated adversaries and securing AI systems themselves require operating at machine speed," Kurtz said. Quarterly governance reviews do not operate at machine speed.

Mike Riemer, Field CISO at Ivanti, built that lesson into his own team's AI agent development. "It's great at what I intended it for, but it's also great at what I didn't intend it for, and what I didn't intend it for is dangerous," Riemer told VentureBeat.

Hallucination data compounds the problem. Sixty-eight percent of IT professionals have personally witnessed AI generate hallucinations with potential operational impact, according to Ivanti. More than half caught the errors before damage, but 16% did not. Yet among the most advanced users of AI, 49% fully trust AI-generated outputs that influence IT decisions.

Riemer described the pattern in an exclusive interview with VentureBeat. "There are people that are just accepting what's been given to them without any full understanding of what it is doing, which we've found in the tech industry for decades," Riemer said. "They don't question how it's doing it. They just start gauging it by its outcome."

Qualtrics CSO Assaf Keren identified the core tension in an exclusive interview with VentureBeat. Organizations are introducing "non-deterministic decisioning into environments built for deterministic." Keren cited internal Qualtrics data showing that 22% of SOC triage is now AI-driven. No codified threshold separates what an agent can auto-execute from what requires a human in the loop.

The 18-month window

The window for fixing this is closing. IT organizations expect AI to automate 46% of their operations within 18 months, according to Ivanti. U.S. companies project 52%. Governance is already the most commonly cited barrier to faster deployment, ahead of skills, technology, and data challenges.

The maturity divide makes the governance gap more dangerous. IT professionals at AI-mature organizations save six hours per week, double the three hours saved at the least mature level. Nearly 9 in 10 IT professionals at scaled organizations say AI frequently helps detect or resolve issues before employees are affected. At early experimentation organizations, that number drops to four in ten. Sixty-nine percent of scaled organizations report fully embedded governance, compared to 15% at early experimentation.

Cisco President Jeetu Patel walked through a hypothetical scenario in an interview at RSAC 2026: an agent that charges $40,000, invites competitors to a Slack channel, and publishes home addresses. "The apology is not a guardrail," Patel told VentureBeat.

Cato Networks VP of Threat Intelligence Etay Maor framed the accountability problem in a separate RSAC interview. "They're closer to humans. Why are we not doing background checks on agents?"

"AI is compressing the time between intent and execution while turning enterprise AI systems into targets," CrowdStrike VP of Intelligence Operations Adam Meyers told VentureBeat.

"Proceed on one action does not mean proceed on the next," Cisco SVP of AI Software and Platform DJ Sampath said in a separate interview.

McGladrey described the root cause. Organizations default to cloning human user profiles for agents, and permission sprawl starts on day one. "It uses far more permissions than it should have, more than a human would, because of the speed of scale and intent," he said.

Riemer's team built governance into Ivanti's own development process. "We have AI check on top of AI to make sure that it is fixed. Two different models, two different manufacturers," Riemer said. "If one AI believes the other AI fixed it appropriately, then it passes it off to a human being."

Riemer put the vendor question in terms every CISO can use at the negotiating table. "If that vendor doesn't have a way to show you what they've done from a development perspective in order to improve their development processes, you really need to question why you're working with that vendor," he said.

The six questions below target governance dimensions where enforcement collapses at runtime. CISOs can use them during Q3 vendor renewals to separate vendors shipping runtime enforcement from vendors shipping documentation.

Six governance questions for Q3 renewals

Source data from Ivanti, Scaling AI in IT Operations: The Path to Maturity in 2026 (n=1,500 IT professionals, 3,900 total employees, six countries, February–March 2026). Exclusive CISO sourcing by VentureBeat.

Evans put structure around the Clearwater board conversation. The bank CISO that Robbins described assumed AI is everywhere and governed from containment instead of discovery. Governance that tries to catalog every shadow AI tool will fail because the surface grows faster than any inventory.

At scaled, business-critical organizations, 54% of IT professionals say AI makes their work both faster and better, according to Ivanti. At early experimentation organizations, 24% say the same. At scaled organizations, accountability lives in the platform. At early ones, it lives in a document the agent never reads.

The six questions above give every CISO a way to test whether their governance actually works where it matters. At runtime, under load, and before the next renewal check clears.

However, enterprise data platforms have long operated across fragmented systems owned by different teams and built on different technologies. As these systems evolve independently, organizations increasingly struggle with inconsistent business logic, duplicated implementations, difficult downstream impact analysis, and hidden dependencies across the platform.

The rise of vibe coding can further amplify these problems as more operational context, architectural decisions, and business knowledge become scattered across prompts, conversations, generated code, and disconnected workflows rather than becoming part of the system itself.

Spec-driven development (SDD) is emerging as one approach to address this challenge. In SDD, prompts, business rules, validation logic, orchestration behavior, and implementation workflows are converted into executable and versioned specifications that become part of the system itself. These specifications act as persistent operational memory for both humans and AI agents, allowing systems to evolve more consistently across releases, teams, and AI-assisted workflows.

Because enterprise data engineering already relies heavily on reusable patterns, metadata-driven pipelines, and standardized operational workflows, it is especially well-suited for SDD. By combining AI-assisted generation with deterministic and reusable system contracts, SDD may provide a new operational layer for reducing fragmentation and improving long-term coordination across increasingly AI-generated data platforms.

Vibe coding alone lacks persistent system memory

Vibe coding works remarkably well for generating isolated implementations quickly. But prompts are inherently temporary. They capture an engineer’s assumptions, business context, implementation logic, and system knowledge only for that specific conversation and moment in time.

In practice, making AI-generated systems work often requires far more than a simple prompt. Engineers continuously provide background information, architectural decisions, business rules, schema assumptions, downstream dependencies, operational constraints, debugging history, and implementation guidance throughout the development process.

These contexts become the real operational knowledge behind AI-assisted development.

However, in most vibe coding workflows, this information remains scattered across prompts, conversations, Jira tickets, documentation, chat history, generated code, and disconnected workflows rather than becoming part of the system itself.

This creates a major problem for enterprise data engineering because modern data platforms are naturally fragmented across many interconnected systems, including ingestion pipelines, warehouses, orchestration frameworks, semantic layers, APIs, dashboards, and machine learning (ML) systems. As more logic and context become embedded inside prompts and generated implementations, organizations gradually lose visibility into:

• architectural intent

• downstream dependencies

• validation assumptions

• operational behavior

• business context behind implementations

Over time, the system itself no longer contains the full reasoning behind how it was built. Critical business context, architectural assumptions, and operational knowledge still largely exist inside human judgement and scattered conversations rather than inside the platform itself.

Vibe coding makes implementation significantly faster, but from a system perspective, overall engineering efficiency does not improve proportionally because much of the development lifecycle still depends on human validation, domain knowledge, coordination, and decision-making.

More importantly, prompts are not naturally iterable engineering artifacts. Enterprise systems continuously evolve across releases, schema changes, business logic updates, and downstream dependencies. Teams repeatedly revisit and refine systems over time, but prompts are optimized for fast local generation rather than system long-term evolution.

They are difficult to:

• version consistently

• validate systematically

• reuse across teams

• coordinate through CI/CD workflows

• evolve incrementally over time

Even the same prompt may not reliably generate the same implementation with different context in the future.

This is where SDD begins to move to the center of AI-assisted data engineering. Instead of leaving operational knowledge scattered across prompts and conversations, SDD integrates business context, validation logic, transformation behavior, orchestration requirements, and implementation workflows directly into executable specifications that become part of the system itself.

The system now has persistent memory about how it was designed, why certain decisions were made, and how different components are connected across the platform. This allows teams and AI agents to iterate systems more reliably over time while reducing fragmentation across increasingly distributed data environments.

Spec-driven development turns prompts into system memory

In SDD, systems are built around executable specifications rather than loosely coordinated prompts and implementations alone. Instead of treating specifications as passive documentation written after development, SDD treats them as operational contracts that directly drive code generation, validation, testing, orchestration, and deployment workflows.

In many ways, SDD extends ideas from Infrastructure-as-Code and GitOps into AI-assisted engineering. Specifications combine declarative system definitions with executable implementation workflows. The declarative layer provides system context, schemas, dependencies, constraints, and operational requirements, while workflow-oriented instructions guide AI agents on how to implement and evolve the system consistently.

Once these contexts, rules, and implementation patterns are converted into persistent and versioned contracts stored in repositories and integrated into CI/CD workflows, the system becomes significantly more iterable and governable over time. These specifications effectively become long-term system memory for both humans and AI agents, allowing systems to evolve consistently across releases, teams, and increasingly AI-assisted development workflows.

In practice, the structure of specifications largely depends on the type of systems and workflows being implemented. However, spec-driven systems often begin with a foundational “constitution” that defines project-wide principles and constraints that should remain consistent across the platform, such as technology standards, naming conventions, architectural rules, governance policies, and core system requirements. On top of this foundation, multiple layers of specifications serve different operational purposes across the development lifecycle:

• schema specifications define structural compatibility

• transformation specifications define business logic

• validation specifications define quality rules

• orchestration specifications define execution behavior

• semantic specifications define shared business definitions

• AI workflow specifications define reusable implementation instructions for coding agents

A simplified specification might look like this:

pipeline_spec:

  source:

    system: mysql

    table: order

  transformation:

    logic:

      - load_strategy: scd2

  target:

    platform: snowflake

    table: dim_order

  validation:

    primary_key: order_id

Additional workflow files can then provide reusable implementation instructions for coding agents:

1. Generate Python ingestion code for Salesforce customer data.

2. Generate DBT models implementing Type 2 SCD logic.

3. Generate Airflow workflows for hourly execution.

4. Generate validation tests for downstream compatibility.

These specification documents are often maintained as markdown-based operational artifacts generated and refined through AI-assisted workflows. Engineers can iteratively update the specifications, provide additional business context, and collaborate with coding agents to improve implementation logic, workflows, and prompt instructions over time. Compared to traditional documentation processes, AI-assisted specification generation is significantly faster and more adaptive.

The important shift is not simply better documentation. Specifications become reusable operational context that allows systems to evolve consistently across releases, teams, and AI-assisted workflows. Architectural intent, business assumptions, and implementation logic no longer disappear into temporary prompts and disconnected implementations, but instead become persistent system knowledge integrated directly into the development lifecycle.

Why spec-driven development specifically fits data engineering

SDD can theoretically be applied across many areas of software engineering, but data engineering is especially well-suited for this model because of the nature of modern data platforms.

Enterprise data systems naturally span many interconnected technologies and layers, including transactional systems, ingestion frameworks, streaming platforms, warehouses, orchestration systems, semantic layers, APIs, dashboards, and ML pipelines. Data engineers regularly work across long technology stacks and distributed systems where a single upstream change can impact many downstream consumers.

Enterprise data platforms also support many different teams and applications across fragmented environments. As systems evolve independently, understanding the full downstream impact of an upstream schema or business logic change becomes increasingly difficult. A seemingly small modification can silently break downstream pipelines, dashboards, APIs, semantic models, or machine learning workflows across the platform.

SDD can address this fragmentation by introducing shared and versioned operational contracts across systems. Because schemas, dependencies, validation rules, transformation logic, and orchestration behavior are explicitly defined within specifications, teams and AI agents gain much better visibility into how systems are connected and how changes propagate across the platform.

Additionally, the goal of data engineering is not simply delivering pipelines quickly. Teams must also optimize for system stability, scalability, consistency, maintainability, operational reliability, and infrastructure cost.

This requires significant system and solution design work from engineers. Teams must define tech stack, create schemas, transformation patterns, orchestration behavior, validation rules, storage strategies, and downstream compatibility requirements carefully across the platform.

However, once these architectural and operational patterns are established, much of the implementation work becomes highly repetitive and standardized.

For example, after defining a reusable ingestion and transformation pattern for Salesforce customer data, onboarding a new table may only require adding another table definition into the specification, while the remaining implementation can be generated automatically through existing specifications and workflows that follow the same operational pattern:

source:

  system: salesforce

  tables:

    - customer

    - order

    - product

From this specification alone, coding agents could generate new data pipelines following the same governed implementation pattern across the platform. This combination of human-driven architectural design and highly repeatable implementation workflows makes data engineering particularly suitable for SDD.

In many ways, data engineering has always been moving toward higher levels of automation, from ETL frameworks and metadata-driven pipelines to IaC and declarative orchestration systems. SDD represents another step in that evolution by combining prompt-based AI generation with deterministic and versioned operational contracts.

Instead of relying entirely on temporary conversational prompts or rigid template systems, SDD introduces a middle layer where reusable specifications provide structure, coordination, validation, and persistent system memory for AI-assisted development.

How SDD changes AI-assisted data engineering

SDD introduces a much higher level of automation into enterprise data engineering while also helping reduce the fragmentation problems that modern data platforms increasingly face.

Because schemas, business rules, transformation behavior, orchestration requirements, validation logic, and downstream dependencies are explicitly defined inside reusable specifications, coding agents can generate and evolve large portions of the implementation consistently across the platform. Instead of repeatedly rebuilding pipelines and workflows from temporary prompts and disconnected context, teams can iterate systems through shared operational contracts and reusable implementation patterns.

This significantly improves consistency, traceability, and coordination across distributed environments. Schema evolution becomes easier to manage, downstream impact becomes more visible, and systems can evolve incrementally instead of through disconnected generations of implementations.

At the same time, human engineers still remain essential in the development lifecycle. While AI agents can automate large portions of implementation work, human judgement is still critical for defining business logic, designing architectures, managing tradeoffs, validating correctness, and coordinating system evolution across organizations.

As more implementation work becomes AI-generated, the role of data engineering also begins shifting. Engineers spend less time writing repetitive pipelines and orchestration logic, and more time defining specifications, designing reusable operational patterns, managing validation rules, and coordinating business context across systems.

This may also gradually reduce some of the traditional boundaries between different data engineering teams. Because implementation becomes increasingly standardized and AI-assisted through shared specifications, organizations may rely less on highly siloed platform-specific implementation teams and more on shared operational contracts and reusable system patterns.

Ultimately, SDD shifts data engineering toward a more specification-oriented and system-oriented model where humans focus on intent, architecture, and business coordination, while AI agents increasingly handle implementation, testing, and operational generation at scale.

Shuhua Xu is a lead data engineer.

AI has changed the economics of cyber deception.

An attacker can now generate thousands of convincing phishing lures, fake identities, and tailored pretexts before a defender finishes a single change-control cycle. That is the new security challenge: deception got faster and cheaper, while verification did not.

Much of the discussion around AI for defense centers on detection models. Detection matters, but it is not the only bottleneck. The deeper constraint is evidence: where data lives, whether it is available when needed, how quickly it can be correlated, how long it is retained, and whether analysts or agents can trust what they retrieve.

Defense in the AI era is a data problem before it is a detection problem.

The defender’s advantage is truth

Attackers can afford to lie at enterprise scale. They can test endless combinations of messages, identities, domains, and attack paths, and most can fail at almost no cost.

Defenders do not have that luxury. Their advantage is truth: quickly knowing what happened, where, when, which identity was involved, which assets were affected, what changed, and what business process may be at risk.

That truth must be documented, governed, auditable, and defensible. Attackers are using AI to scale deception, impersonation, social engineering, and speed. Defenders need AI to scale verification.

The goal is not just to act faster than the attacker. It is to take action that people and machines can trust.

Fragmented data breaks modern defense

Consider a suspicious login from a contractor account. On its own, it is just another authentication anomaly. To know whether it matters, a security team may need identity history, endpoint activity, cloud access logs, ticketing records, asset ownership, configuration changes, network telemetry, and business context.

If those records sit in different tools, expire at different times, or require multiple teams to retrieve, defenders are not investigating the incident. They are negotiating with their own data estate.

When signals can be reached in place and correlated quickly, the issue is no longer just whether the login looks unusual. It becomes whether the enterprise has enough evidence, in enough context, to take action it can defend.

That challenge grows more urgent with AI assistants and agents. AI can only reason over what it can retrieve in time to matter. If the data is partial, stale, fragmented, unavailable, or stripped of context, AI does not create truth. It accelerates uncertainty.

The system of record must become a defensive control plane

For years, enterprises treated security platforms, SIEMs, and data lakes as passive repositories: places to store data for later search and analysis. That model is no longer enough.

What organizations now need is a defensive control plane: a layer that connects what happened, what it means, and what the enterprise is allowed to do about it. In architectural terms, it ties together raw machine data, business context, and policy. It does not just store evidence. It makes evidence usable for decisions and actions that must be explainable and trusted.

In practice, that means doing four things well: preserving evidence, reaching data wherever it lives, adding business context, and governing action. More on each below.

The old system of record answered one question: What is the official record?

A defensive control plane answers the questions that matter operationally: What happened? What does it mean? What evidence supports that conclusion? And what action can we trust?

AI does not reduce the need for authoritative records. It raises the standard for what those records must do.

A defensive control plane must do four things

1. Preserve evidence. Logs, metrics, traces, events, identity records, configuration changes, tickets, and asset state all help establish what happened. Their value often becomes clear only after an incident begins.

2. Make data accessible wherever it lives. Security-relevant data is already spread across object stores, cloud platforms, operational tools, and business systems. Moving every byte into one place is often too slow, too expensive, and too difficult to govern. The better model is to bring analytics to the data.

3. Add business context. Correlating machine data with business information turns “anomaly on host X” into “the system supporting payment services for top accounts is being probed.” That is what allows organizations to prioritize correctly.

4. Govern action. In the agentic era, systems will do more than summarize incidents. They will enrich alerts, open cases, trigger workflows, isolate assets, update policies, and escalate decisions. Enterprises need to know what evidence an agent used, what policy governed the action, whether it stayed within scope, and how the decision can be reviewed afterward.

The real SOC problem is not too little data

Modern SOCs are not suffering from a lack of data. They are suffering from a lack of usable context.

According to the Splunk State of Security 2025 report, SOC analysts continue to struggle with too many alerts (59%), too many false positives (55%), and alerts that lack context (46%). The issue is not data volume. It is the difficulty of turning fragmented signals into trusted decisions.

Today, analysts are left stitching together context manually, pivoting across disconnected tools, and making high-stakes decisions without the full picture in time. Even as AI improves, outcomes still depend on whether humans are willing to approve changes across fragmented environments.

This creates a daily crisis of context. Teams are forced to make consequential decisions based on data they cannot easily see, correlate, or trust. The result is latency, inconsistency, missed opportunities, and unnecessary risk.

Trusted action is the durable advantage

A data fabric architecture offers a way forward by creating a unified, intelligent layer across data sources spanning SecOps, ITOps, and NetOps. The goal is not centralization for its own sake. It is to break down silos and deliver context-rich insight at the speed AI-driven operations require.

This is an operating model before it is a product. AI-driven defense depends on a foundation that can preserve evidence, reach data where it lives, add context, and maintain a reviewable link between data, decision, and action. That is the architectural shift behind Cisco Data Fabric powered by the Splunk Platform, which brings together machine data, federation, business context, governance, and provenance to help teams move from signal to trusted action.

Attackers will keep making deception cheaper, faster, and more personalized. Defenders do not win that race by generating more noise. They win by making truth faster, and by grounding every action in evidence that people and machines can trust.

Learn more about the Cisco Data Fabric powered by the Splunk Platform.

Seth Brickman is VP, Global Product - Splunk Platform, Cisco.

Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.

Common Object Request Broker Architecture (CORBA), Distributed Component Object Model (DCOM), Java remote method invocation (RMI), and early simple object access protocol (SOAP) competed for the enterprise integration market in the late 1990s before representational state transfer (REST) quietly won by being simpler and HTTP-native.

Extensible Messaging and Presence Protocol (XMPP), Internet Relay Chat (IRC), and a dozen proprietary protocols fragmented real-time messaging before MG telemetry transport (MQTT) and WebSockets carved out their respective niches. Every new computing paradigm generates a burst of competing standards, then slowly converges as implementations accumulate and interoperability becomes economically necessary.

The AI agent ecosystem is currently in the proliferation phase. Four significant protocols have been published in the past eighteen months: Model context protocol (MCP) from Anthropic in late 2024, agent communication protocol (ACP) from IBM Research in March 2025, Agent2Agent (A2A) from Google in April 2025, and agent network protocol (ANP) from an independent working group.

The W3C AI Agent Protocol Community Group has opened a standards track. The Internet Engineering Task Force (IETF) is receiving Internet-Drafts on agent transport. Conferences are running workshops on interoperability. Every week brings a new GitHub repository claiming to solve the agent communication problem.

Understanding where and how quickly this converges has real consequences for architecture decisions being made right now.

What the protocols actually solve

The proliferation looks more chaotic than it is, because most of these protocols address different layers of a stack rather than competing for the same slot. The confusion comes from marketing, which describes each as "the standard for AI agent communication" without specifying which aspect of communication.

MCP is a tool-calling interface. It defines how a model discovers what functions a server exposes, how to invoke them, and how to interpret the response. It is a typed remote procedure call (RPC) contract between a model client and a tool server, running over HTTP. The Linux Foundation confirmed more than 10,000 active public MCP servers and 164 million monthly Python SDK downloads by April 2026. MCP has already won the tool-calling layer. The standardization work is effectively done.

A2A is a task coordination interface. Where MCP defines how an agent calls a tool, A2A defines how two agents delegate a task. It introduces Agent Cards (capability advertisements), task lifecycle states, and three interaction modes: Synchronous, streaming, and asynchronous. Google donated it to the Linux Foundation in June 2025, and enterprise AI teams have adopted it broadly because it fills a real gap that MCP leaves open.

ACP is a message envelope format. Lightweight, stateless, designed for agent-to-agent message exchange without A2A's full coordination semantics. It is useful in systems where simple message passing suffices and A2A's task lifecycle overhead is unnecessary.

ANP is a discovery and identity protocol. It uses Decentralized Identifiers (DIDs) for agent identity and JSON-LD graphs for capability descriptions, providing a foundation for decentralized agent marketplaces where no central registry is required.

The stack that is emerging: Capability discovery via ANP or simpler registries, task coordination via A2A, tool calls via MCP, and lightweight messaging via ACP for cases that do not require full task lifecycle management. These layers complement rather than compete.

The transport problem that remains

Every protocol in this list runs over HTTP. This reflects where the protocols came from: Research teams, API providers, and enterprise software companies building systems where HTTP is an unquestioned assumption. HTTP is the protocol they know, the one their servers already speak, and the one that makes demos easy.

The production problem is that HTTP assumes a reachable server. Behind network address translation (NAT) — and 88% of networked devices sit behind NAT — there is no reachable server without a relay. For agent fleets that need to route tasks directly between peers across cloud boundaries, home networks, and edge deployments, this centralization forces every message through relay infrastructure. Relay infrastructure adds latency, cost, and a failure mode.

The application-layer protocols solve the semantics of what agents say to each other. They do not solve how agents find each other and establish direct connections. That is a session-layer problem, Layer 5 in the open systems interconnection (OSI) model and none of MCP, A2A, ACP, or ANP address it.

The technologies for solving it exist. UDP hole-punching with session traversal utilities for NAT (STUN) provides NAT traversal for roughly 70% of network topologies. X25519 Diffie-Hellman and AES-256-GCM provide authenticated encryption at the tunnel level without a certificate authority. Quick UDP internet connections (QUIC) (RFC 9000) or custom sliding-window protocols over user datagram protocol (UDP) provide reliable delivery without TCP's head-of-line blocking. These are the same primitives that WireGuard uses for VPN tunnels and that WebRTC uses for browser-to-browser media streams.

What differs in the agent context is capability-based routing. Agents need to find peers not by hostname but by what those peers can do. A research agent should be able to query "which peers have real-time foreign exchange data?" and receive a list of currently active specialist agents. This is closer to a service registry than to DNS, and it is a natural extension of ANP's design philosophy applied to the transport layer.

A handful of projects are assembling these pieces. Pilot Protocol has the most complete published specification, with an IETF Internet-Draft covering addressing, tunnel establishment, and NAT traversal for agent networks. libp2p provides a battle-tested foundation with similar primitives. The IETF's QUIC working group is developing NAT traversal extensions that will be relevant here.

What convergence will look like

The HTTP-based protocols (MCP, A2A) are already converging on stable versions. The next 12 months will see production hardening, security improvements, stateless MCP servers for horizontal scaling, better A2A federation — rather than new fundamental designs. The tool-calling and task-coordination layers are largely solved.

The transport layer is 18 to 24 months behind. Expect a period of implementation diversity as teams experiment with different approaches to peer-to-peer (P2P) agent networking, followed by consolidation around a small number of implementations once empirical data on performance and reliability accumulates. The IETF and W3C standardization tracks will likely produce something in the 2027-2028 window, by which time one or two open-source implementations will have accrued enough production deployments to establish de facto standards ahead of the formal specification.

For engineering leaders making architecture decisions today, the practical implication is layered adoption. The application-layer protocols are stable enough to build on. MCP adoption now is low-risk. A2A adoption for multi-agent coordination is reasonable with the expectation that the protocol will evolve. The transport layer is where you either build something custom and plan to replace it, or you evaluate early implementations knowing the space is still moving.

The teams that will have the most leverage when the transport layer stabilizes are the ones that designed their agent systems with a clean separation between application semantics (MCP, A2A) and transport (whatever sits below). Clean separation is cheap to implement now and expensive to retrofit later, a lesson the microservices era taught anyone who tried to add observability or circuit breaking to systems that had none.

Philip Stayetski is a co-founder of Vulture Labs.

In response, Anthropic has blocked all public access to both models, globally — meaning no users around the world can access them at this time, even paying enterprise customers and Anthropic employees internally. It's a huge blow and reversal following the public release of Fable/Mythos 5 just three days prior.

Current Fable 5/Mythos 5 sessions will end in errors and new queries will be automatically routed to older, less capable models like Opus 4.8. Anthropic says in a blog post that "We believe this is a misunderstanding and are working to restore access as soon as possible," and apologizes to its customers.

The sudden regulatory intervention serves as a stark warning to the enterprise sector: centralized, cloud-based frontier models exist at the absolute mercy of government oversight and vendor compliance.

Did Pliny the Liberator's public jailbreak catalyze the extraordinary USG action against Fable/Mythos 5?

The government's sweeping action follows a viral jailbreak of Fable 5 published publicly on X on June 10 by the prolific jailbreaker "Pliny the Liberator," who claimed to have successfully bypassed the model's safety guardrails to extract functional instructions for cyber exploits, explosives, and chemical synthesis pathways, specifically noting the "birch reduction method" for methamphetamine.

Pliny outlined a highly sophisticated, multi-agent attack that leveraged a combination of "Unicode, homoglyphs, Cyrillic," long-context reference tracking, and a technique of breaking harmful requests into innocuous, out-of-distribution tokens. The attacker then used a previously jailbroken Opus model to piece the benign chunks back together into actionable, restricted outputs.

Anthropic doesn't specify if this is the jailbreak that precipitated the government order, and in fact, notes that the information provided by the U.S. government regarding the specific jailbreak has been poorly documented, writing: "To date, the government has only given us verbal evidence of a potential narrow, non-universal jailbreak, which essentially consists of asking the model to read a specific codebase and fix any software flaws. Our understanding is that one potential jailbreak was shared with the government."

The company argues the capabilities uncovered are "widely available" in other public models, explicitly naming rival OpenAI's GPT-5.5.

Furthermore, Anthropic warns that pulling a commercial model over a non-universal jailbreak sets a regulatory standard that could "essentially halt all new model deployments for all frontier model providers".

The Pentagon precedent and need for enterprise AI redundancy and diversification

This sudden blackout of Anthropic's latest and greatest AI models will no doubt cause some consternation for organizations relying primarily on the Claude API — as it should, even though they still have access to other, less powerful Claude models.

As I warned earlier this year when the Pentagon abruptly blacklisted Anthropic, enterprises can no longer afford — from an operational reliability standpoint — to run critical workflows on any single AI model or even provider. Putting all your AI "eggs" into one basket, so to speak, creates a single, ultimately brittle failure point from which recovery or mitigation becomes exceedingly difficult.

Granted, in this case, Anthropic notes helpfully that "access to all other Anthropic models will not be affected." And while Opus 4.8 or other Anthropic models may already be the preferred ones for organizations given their lower cost, or seen as acceptable fallbacks, the reality is, the U.S. government order was narrowly targeted in this particular instance — who's to saying the government wouldn't, in the future, demand a block of all of a given lab's AI models/products/services?

We had an indication that enterprise AI customers should diversify their providers earlier this year. Recall that in March 2026, Secretary of Defense Pete Hegseth labeled Anthropic a "supply chain risk" after the company refused to allow the military to use Claude for mass domestic surveillance and lethal autonomous weapons without safety restrictions.

The resulting fallout led to a sweeping prohibition on Anthropic's use across defense supply chains, stripping contractors of access overnight.

The lesson from the Department of Defense fallout remains critically relevant today. Any organization building agentic workflows or production apps tied solely to a single closed-API provider risks immediate operational failure if that provider faces an injunction, a cyberattack, or an export control directive.

As an enterprise technical leader, your top goal if not already achieved should be to urgently diversify your AI supply — whether it's other cloud-based AI models and providers, or AI models running on enterprise-controlled local or virtual hardware.

At this point, enterprise AI supplier diversification is arguably imperative to ensure you can continue to run AI workflows without disruption.

Enterprise implications: sovereign setup vs. frontier capabilities

The community reaction to the Fable 5 takedown reflects a rapidly shifting enterprise calculus toward hardware sovereignty.

AI founder Alex Finn took to X to flag the Anthropic shutdown as a "wakeup call," urging developers to run local models on home GPUs to insulate themselves from regulatory volatility.

"No company or government will EVER be able to take away your local models," Finn writes, warning that government overreach will only escalate as models inch closer to artificial general intelligence (AGI), the stated goal of OpenAI and some other AI firms, in which an AI model becomes capable of performing most economically valuable work tasks now done by humans.

Competitors are already capitalizing on this sentiment; Chinese open source AI provider MiniMax quickly highlighted the open weights/open source availability of its new, frontier-class M3 model, contrasting its decentralized availability against Claude's centralized vulnerability. In other words: enterprises can download and run M3 on their own hardware now without ever worrying about any government stepping in to prevent access.

This dynamic presents a complex trade-off for CIOs and IT leaders:

• The Sovereign Advantage: Running local, open-weights models on sovereign hardware provides absolute control, ensures data privacy, and immunizes the enterprise against abrupt government export controls, vendor policy shifts, or API rate limits.

• The Frontier Sacrifice: Adopting a purely local strategy means sacrificing the cutting-edge reasoning, agentic capabilities, and massive context windows inherent to the latest closed-API frontier models, which require centralized, multi-billion-dollar compute clusters to operate.

The most resilient path forward is an active fallback architecture. Enterprises must design their systems to be model-agnostic. By building intelligent routing layers that can dynamically switch from a frontier model like Fable 5 to an open-weights fallback or a secondary provider's API the moment an outage or regulatory ban hits, businesses ensure their operations survive the volatile intersection of AI scaling and government oversight.