Snowflake announced Cortex AI Gateway on Tuesday, a centralized control layer designed to govern how AI agents — including those built by competitors like Anthropic’s Claude Code and Cursor — access enterprise data, tools, and models. Alongside the gateway, the company unveiled a first wave of security integrations with 1Password, Aembit, Linx Security, SailPoint, and Saviynt, an unusual coalition of identity vendors who often compete with one another, now aligned around a shared trust model for autonomous agents.

The announcement, made from the company’s no-headquarters base in Bozeman, Montana, is Snowflake’s most aggressive move yet to position itself not merely as the place where enterprise data lives, but as the control plane that decides what AI agents are allowed to do with it.

“The next era of AI won’t be built through more walled gardens. It will be built through secure agent interoperability,” Mayank Upadhyay, Snowflake’s chief security and trust officer, told VentureBeat in an exclusive interview. “If every vendor builds a closed ecosystem of agents, enterprises simply recreate the fragmentation they’ve spent years trying to solve. Instead of breaking down silos, they create a new generation of AI silos that limit innovation and make it harder to scale AI across the business.”

Why decades-old enterprise security models break when AI agents become the actors

The core argument animating today’s announcement is that decades of enterprise security architecture rests on an assumption that no longer holds — that the actor behind every access request is a person.

“Traditional security was built for a world where humans were the actors. AI agents change that completely. For decades, security models assumed people would access one application at a time, operating at human speed and within relatively defined boundaries,” Upadhyay said. The deeper issue, he argued, is not novelty but exposure: “The challenge isn’t that AI creates entirely new security problems. It’s that AI exposes the blind spots we’ve always had.”

Organizations have never had perfect visibility into every API, dataset, and workflow, Upadhyay noted, and at human speed those gaps were manageable. Agents operating at machine speed can “combine access across systems and act on permissions that were never intended to be exercised together, amplifying those longstanding risks.” His conclusion: “In the agentic era, trust can’t be a one-time decision made at login. It has to be continuously verified through every agent, every action, and every interaction across the enterprise.”

Nancy Wang, chief technology officer of 1Password, described the failure mode in more visceral terms. When agents first arrived, she told VentureBeat, the default pattern was dangerously simple: “Let me just give the agent my credentials and it can just act as me… let’s imagine you’re the head of security or the head of IT, and you have access, especially admin access, to all of the systems. Well, now suddenly your agent now has admin access to all of the systems, and so it could exfil data… if it’s subject to a prompt injection, for example.”

The audit trail becomes equally useless, she added: “Imagine the audit logs show that Michael sent a couple million dollars to an offshore account… It raises eyebrows when, in fact, it could just be an agent going off the rails and doing things that you never authorized.” Her prescription, and the premise of 1Password’s integration with Snowflake, is blunt: “Agents need their own identity.”

Inside Cortex AI Gateway: how Snowflake plans to govern agent access and rein in runaway AI costs

Cortex AI Gateway, which will enter public preview soon, functions as a connective layer for what Snowflake calls “all trusted agent activity.” It governs both first-party agents built inside Snowflake, such as Snowflake CoWork and CoCo, and third-party agents built on external platforms. With support for more than 100 MCP servers — the Model Context Protocol connectors that have become the de facto standard for wiring agents to enterprise tools — the gateway centralizes access policies, authentication, permissions, and audit logging in a single place.

The gateway also addresses a less glamorous but increasingly urgent problem: runaway AI spending. It gives IT and finance teams a unified view of AI consumption, attributes costs to the specific teams, agents, or workloads driving them, and enforces spending limits before bills spiral.

Upadhyay described how those costs compound in practice. “AI is dynamic. Agents can invoke multiple models, call different tools, and execute multi-step workflows, creating consumption patterns that can change from one task to the next. For example, an enterprise may deploy an AI assistant to help employees answer internal questions. A simple request that only requires retrieving a document could unintentionally be routed through a more expensive reasoning model, trigger additional searches across multiple systems, or invoke unnecessary workflows.” At scale, with thousands of employees and hundreds of agents, small inefficiencies become significant line items.

The gateway builds directly on Snowflake’s May 2026 acquisition of Natoma, a 27-person startup whose centralized MCP gateway enforced identity, policy, and audit at the tool-call level. Forbes reported at the time that the deal — announced the same day as Snowflake’s $1.33 billion quarterly product revenue report and a $6 billion AWS compute commitment — was the smallest of the day’s three announcements by dollar value but the most revealing about where Snowflake believes the next platform fight sits: not in the data warehouse, but in the layer that decides what an agent may touch and records what it did.

Dual attribution and task-scoped access: the technical blueprint for trusting autonomous agents

The technical centerpiece of the partner integrations is what Snowflake calls dual attribution. “By logging both the verified non-human identity of the agent and the specific human who authorized the task, we ensure task-scoped access and complete auditability for every action taken across the enterprise,” Upadhyay said. That answers a question that has stumped security teams: when an agent takes an action, whose action is it? The Snowflake model says the answer is both — the agent’s, and the human’s who delegated the task — and both must be recorded.

Task-scoped access is the companion principle. Rather than inheriting a user’s full standing permissions, an agent gets access only to what a specific task requires. Upadhyay acknowledged the obvious objection — agents are dynamic and their next step often isn’t known in advance. “The goal isn’t to predict every action an agent will take. It’s to ensure that every action an agent takes is evaluated in real time against the appropriate policies, scope, contextual signals, and the original intent of the user,” he said.

Wang explained how 1Password’s piece works at the protocol level, pointing to emerging standards like OIDC-A: “the human, for example, first authorizes the agent to do a specific task, and then what that means is the agent will then receive sort of the delegated task specific token… as part of that token, that is where you learn of the original sort of delegator identity and also the intent behind the task.”

The intent-preservation problem is subtle, she noted, because enterprise tasks decompose into enormous chains of individual operations. “When they’re accessing a table, you know that it’s acting on behalf of the original intent that you gave that agent… a task might be a compilation of hundreds, maybe even thousands, individual actions.” Keeping that intent intact across every step in the chain — and flagging the moment an agent deviates from it — is what the coalition is ultimately trying to standardize.

SailPoint’s field report: the three ways enterprise identity systems fail against AI agents

Chandra Gnanasambandam, SailPoint’s EVP of product and chief technology officer, brought the perspective of a vendor that has watched enterprises break their identity stacks against this problem for more than a year. SailPoint has been in the machine and agent security market for roughly 18 months, he said, with more than 100 customers on its agent identity product — enough of a sample to catalog the recurring failures.

The first is scale-driven shallowness. An average Fortune 500 company has roughly 16,000 employees, and SailPoint is seeing human-to-non-human identity ratios of at least 10 to 1 — before counting the tools and APIs each agent touches, which multiply the count again. “You will get into a million plus non-human identities. Mapping the permissions that each of them get to the 16,000 humans is a completely non-trivial task,” he said. Most companies punt, mapping agents to humans at the directory-group level. “That is grossly insufficient. You want to have fine grain context. Like I said, it’s not access to Snowflake. It’s access to what column and what data inside Snowflake you need.”

The second failure mode is drift. Modern models are relentless goal-seekers, and that persistence cuts both ways. “When you tell them get this done, the underlying models are so powerful now. Even the weaker models are so powerful. They will go find a way to get it done… They will go find the vulnerabilities to bypass the permission to get it done,” Gnanasambandam warned. The answer, he argued, is runtime monitoring of the entire interaction chain, compared continuously against policy, with automatic intervention when an agent escalates beyond what its human delegator authorized.

The third is missing data context. Many vendors, he argued, announce splashy integrations with big application platforms while ignoring where the actual risk concentrates. “That’s not where the risk lies. Risk lies in sensitive data, so the details matter here… Can you map specific columns and rows in Databricks, Snowflake, Redshift, Oracle… into the agent context and the human context? And if you can’t do that, you are going to have gaps and holes.”

SailPoint’s answer required tearing out two decades of architecture. “We rewrote our underlying data and object model to treat AI identity as a first-class object, because for 20 years, SailPoint had a data model and object model that supported the human identity, and AI identities are fundamentally different,” Gnanasambandam said, describing 12 to 18 months of deep engineering work. The result is what he calls a unified lineage: “From human to master agent to sub agent to tool to application to data. That’s what I call the steel chain. That is in one data model, one platform.”

Why rival identity vendors joined Snowflake’s coalition — and what each side gets out of it

Perhaps the most striking aspect of today’s announcement is the roster. 1Password, SailPoint, Saviynt, Okta, and Aembit compete for overlapping identity and access budgets. Snowflake convinced them to build against a common trust framework anyway.

“The reason we brought together leaders across the security ecosystem is because no single company can solve the agent security challenge alone. AI agents can’t deliver real value if they only operate within the boundaries of one platform,” Upadhyay said. His broader thesis frames the whole strategy: “Nobody wants to replace data silos with AI silos.”

Wang offered a pragmatic division of labor: “We bring the trust, and Snowflake brings a system of record.” She framed the collaboration as classic defense in depth — “there are data level controls, and there are identity level controls, and so together we can create a much stronger ecosystem play.”

There is self-interest in the openness, of course. Snowflake sits atop an enormous concentration of sensitive enterprise data — more than 13,900 customers, by the company’s count — and every third-party agent that touches that data through a governed Snowflake gateway deepens the platform’s gravitational pull.

As Constellation Research analyst Michael Ni put it when the Natoma deal was announced, in comments reported by CIO.com: data platforms won the analytics era, and whoever governs agents, context, and autonomous actions wins the agentic one. A Forbes analysis of the same acquisition flagged the tension directly, noting that a governance layer living inside Snowflake risks pulling MCP’s openness back toward a single vendor’s control plane — attractive for Snowflake-standardized shops, more awkward for genuinely multi-vendor agent stacks.

Analyst forecasts show agent governance is now a trillion-dollar race against the clock

The urgency behind today’s announcement is not manufactured. Gartner predicts that by 2027, governance gaps discovered only after production incidents will force 40% of enterprises to demote or decommission autonomous AI agents — with analysts there warning that the greatest risk an agent poses often lies not in its output but in the actions it is empowered to take. IDC, meanwhile, expects more than 1 billion actively deployed AI agents by 2029, executing roughly 217 billion actions per day, and forecasts agentic AI will exceed $1.3 trillion in worldwide IT spending that year. The research firm’s analysts now argue agentic platforms should be treated as decision infrastructure, not productivity software.

Against that backdrop, the identity layer is becoming the contested ground, and every major vendor — Salesforce, ServiceNow, Microsoft, Google, Okta — is racing toward the same runtime-governance chokepoint. Snowflake’s differentiator is proximity to the data itself. As Upadhyay put it, security “can’t just be an API proxy sitting in front of an LLM. It has to anchor all the way down into the underlying data layer, enforcing zero-copy boundaries, dynamic data masking, and real-time exfiltration safeguards before an agent ever touches a row of data.”

The rollout now moves to proving ground. Cortex AI Gateway enters public preview soon, and the five partner integrations enter private preview, a phase Wang described as a deliberate feedback loop — customers on day one get an agent-access broker plus “a full audit log that will show you, for example, what that agent is actually doing,” even when an agent deviates from its intent. Gnanasambandam, characteristically, wants enterprises to skip the easy demos entirely, urging customers to bring loan-origination workflows spanning three clouds and ten applications, half of them mainframes: “Give us that complex use case and bring anyone on and do it in your context, and we will take the challenge with anyone in the world.”

That confidence — from a coalition of rivals, no less — captures what makes this moment unusual. The companies that spent the last decade fighting over who verifies human identity have concluded, more or less simultaneously, that the next decade belongs to whoever can verify the machines acting on our behalf. Upadhyay distilled the wager into a single line: “The future of AI won’t be won by the organizations with the most agents, but by the organizations that can govern those agents with the most trust, visibility, and control.” In the agentic enterprise, it turns out, trust isn’t the guardrail. It’s the product.

Presented by Vijil

In dynamic environments where users, data, workflows and attack techniques change continuously after deployment, AI agent trust has become a runtime problem. Most organizations still treat trust as a pre-deployment exercise, declaring an agent production-ready and launching it after it passes sandbox evaluations and performs successfully in security tests. Unfortunately, that trustworthiness breaks down the moment an agent begins interacting with the real world.

“The core of the problem is that CIOs and business owners think about AI systems the way they think about SaaS or mobile applications, which do not respond dynamically to the world around them,” says Vin Sharma, Founder and CEO of Vijil. “Agents, by the textbook definition, are meant to perceive their environment, reason, act, observe the consequences, and learn from the gap between expectation and reality. The problem is that the models underneath them are built from static training data, and that picture of the world is already outdated by the time they reach production.”

Why benchmark scores fall short for agentic system trustworthiness

Traditional AI evaluations offer a point-in-time assessment of agent capability, rather than trustworthiness. There are three reasons why that assessment fails to predict real enterprise behavior:

First, benchmarks are static, built around a particular notion of what good performance means when they were developed, while the world keeps moving ahead.

Secondly, they model reality imperfectly, so that the gap between the benchmark and the real world is exactly where many failures occur.

And third, benchmarks are public, so they leak into future models’ training data, letting models effectively memorize the test rather than prove real capability..

“The agent or the application could score exceptionally well on a benchmark, but there’s that gap between that benchmark and the real world,” Sharma says.” Doing well only proves it can pass the test, not that it’ll perform reliably in production.”

But overall, benchmarks fall short precisely because they measure capability, not trustworthiness.

“We tend to think of agents as factotums, generally utilitarian agents to whom you can delegate certain types of tasks,” Sharma says. “But what we need to do is actually assign an objective that demands they always perform with the duty of competence, duty of care, and duty of loyalty to the enterprise.”

Of course, agents are not conscious and cannot be expected to feel actual human loyalty, but under the law, fiduciary duty doesn’t actually require consciousness. It just means that the agent should be bound to place the interests of the principal above its own or anyone else’s, as a functional requirement, and testable regardless of intention.

Capability and trustworthiness are different questions

Prioritizing trustworthiness over capability requires rethinking what enterprises expect from AI agents. Sharma calls that model the fiduciary agent, a term borrowed from professions that are bound by a formal duty of care, such as financial institutions or healthcare providers who owe their clients duties of competence, care, and loyalty. It addresses a critical issue in today’s industry: the focus almost entirely on competence, with little attention paid to whether an agent is beholden to the interests of the principal delegating work to it.

Testing starts from a working definition: an agent is trustworthy if the benefit of delegating a task to it exceeds the risk of that task’s failure. It’s an equation spelled out in economic terms that executives can act on directly, and risk breaks down to three components:

• reliability, or whether the agent performs as expected under varying conditions

• security, or its resistance to attacks from malicious actors

• and safety, or how contained the damage stays when failure eventually happens.

“The resulting score can be compared to a consumer credit rating, but built from behavioral data,” Sharma explains. “Meanwhile, testing methodology should be centered around three Ps: purpose, personas, and policies.”

At Vijil, purpose-based testing adapts to the specific workflow an agent handles, growing harder or easier depending on performance, similar to a computer-administered exam. Persona-based testing draws on more than a thousand demographically varied user profiles alongside adversary profiles, from ethical hackers to state-sponsored attackers, to simulate the range of people and threats an agent might encounter. Policy-based testing builds a custom harness from an organization’s own rules, whether they come from regulation, an internal privacy policy, or brand guidelines, and measures how far an agent strays when it violates them.

The trust failures that only emerge in production

Many failures cannot surface during pre-production testing because they arise from change in the environment itself. Machine learning has previously described this as data drift and concept drift, and for a CIO or CSO it means the people interacting with an agent differ from those the agent was planned for, and those users behave in ways that only become visible in production. At the same time, new attacks are emerging with increasing frequency as organizations push general-purpose agents into specialized enterprise roles they weren’t designed for and cannot easily constrain once deployed.

Multi-agent systems also introduce a brand-new category of failure that can’t be detected at the individual agent level, when agent systems act against the interests of the principal. For instance, collusion can occur when agents work together — one coding agent generates code while a second tests it, and behind the scenes both agree to leave a backdoor or flaw intact rather than flag it. Or agents divvy up tasks or responsibilities between themselves rather than focusing on their assigned tasks.

“What’s no longer in question is whether this is possible. It’s proven to exist,” Sharma said. “Is it six, 12, 18 months from now that you should worry about collusion among AI agents? I think it’s sooner than that. We’ve left the era of failure prevention. Now we have to think in terms of resilience: How quickly do you recover from failures in production?”

What continuous trust management looks like in practice

Operationally, continuous trust management goes back to those longstanding principles of observability and control, applied across the lifecycle of an agent population:

The first step is discovery, bringing shadow AI and ungoverned agents into the governance fold.

The second is assigning each agent a standards-based workload identity distinct from that of its human principal, which allows organizations to grant agents narrowly restricted permissions for their delegated tasks.

The third is policy-based control enforced through a mandatory enforcement point in the agent, instead of leaving it to the developer’s discretion.

From there, two new KPIs emerge: time to trust and time to recovery. Time to trust is how long it takes an organization to move from intention to a production deployment it can stand behind. Time to recovery is the interval between when a vulnerability is detected and when it gets fixed.

New organizational responsibility for this work may fall to a chief AI officer or be shared across GRC, CIO and CSO functions, Sharma says. Meanwhile, multi-agent systems will reshape how organizations view trust, rather than fit into current narrow definitions.

“Trust is not a vibe. Trust is not a virtue,” Sharma said. “It is something that you build into the infrastructure of your systems, so that it is continuous. It’s trackable, measurable. It allows your systems and your organization to improve continuously.”

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.

Microsoft opened a new front in the AI security wars on Monday, unveiling its first custom-built cybersecurity model and a sweeping agentic defense platform — and making an argument that could reshape how enterprises buy AI: the future belongs not to the biggest model, but to the cheapest one that’s good enough, routed intelligently.

The company announced MAI-Cyber-1-Flash, a compact security model developed in-house by its Microsoft AI (MAI) division, embedded inside MDASH, Microsoft’s multi-agent harness for finding and fixing software vulnerabilities. Together, the company says, the system scores 96% on CyberGym — a benchmark measuring how well AI systems reason over large codebases to find real vulnerabilities — beating frontier models including Mythos, Gemini, and GPT, while cutting costs roughly in half compared to Microsoft’s own current production configuration.

Alongside the model, Microsoft introduced Project Perception, an agentic security system that coordinates “red team” agents that hunt for paths to compromise, “blue team” agents that investigate and triage risk, and “green team” agents that remediate and harden defenses. Project Perception enters public preview on August 3.

In an exclusive interview with VentureBeat, Microsoft AI CEO Mustafa Suleyman made clear the company sees Monday’s announcement as the opening move in a much longer campaign.

“We really do have a pretty significant data and harness and expertise moat, and that is enabling us to train models which are faster, better, cheaper, and I think this is genuinely the tip of the iceberg,” Suleyman said. “We haven’t been working on this for long. The next model is going to be pretty phenomenal.”

Inside the 90/10 architecture that still depends on OpenAI’s GPT-5.4

The most technically revealing detail in the announcement is not the model itself but how Microsoft deploys it. MAI-Cyber-1-Flash was designed to handle up to 90% of security tasks efficiently, while MDASH escalates the remaining 10% of exceptionally difficult problems to a larger frontier model — which, notably, is OpenAI’s GPT-5.4. In other words, Microsoft’s flagship security AI still leans on its longtime partner-turned-rival for the hardest work.

Asked to explain that relationship, Suleyman pointed to the harness, the orchestration layer that routes each incoming problem to the right model. “The harness is like a router,” he told VentureBeat. “It’s kind of like guardrails and a rule set of an organizing logic, which matches queries to… incoming problems to a model that suits the problem.” The system has three components, he explained: the harness, the small and fast MAI-Cyber-1-Flash handling the bulk of queries, and GPT-5.4 sitting alongside as “just a generalist coding model.”

Pressed on how a system reliant on OpenAI’s model can outperform frontier competitors, Suleyman argued the performance comes from the whole system, not any single model. “These are very complicated, long, agentic loops which require storing state, drawing on another database, consulting best practice… handing back to a small model, writing a bunch of code, validating that that was correct,” he said. “There’s like hundreds of steps to solve that, and that’s why it’s really the system together that delivers the better performance.”

And why GPT-5.4 specifically for the escalation tier? Cost, again. “GPT-5.6 is expensive. GPT-5.4 is incredibly good relative to its cost,” Suleyman said. “The whole game here is to reduce the costs. Mythos and so on are extremely expensive models… we want to be able to deliver better performance for cheaper. That’s what customers want.” The arrangement captures Microsoft’s evolving posture toward OpenAI: still a customer of the partnership that drew regulatory scrutiny in Brussels and Washington in 2024, but increasingly determined to own the layers of the stack where it believes it holds durable advantages.

Why token costs — not model quality — are becoming the real barrier to enterprise AI adoption

The economics may matter more than the benchmark. Microsoft says the new configuration delivers roughly 50% cost savings against the current MDASH setup, which runs a blend of GPT-5.4, 5.4 mini, and 5.3 codex. In security — an always-on workload processing enormous volumes of signals — token costs compound relentlessly, and Microsoft argues they have become the binding constraint for defenders.

Suleyman frames the cost issue as downstream of a harder physical limit. “The key barrier to adoption is access to chips, and cost is a function of chips,” he said. “No matter how much money you’ve got, there’s actually a limited supply of chips. Then trying to squeeze more model output on fewer chips is clearly super valuable.”

He also described a broader enterprise backlash against frontier-model pricing. Companies initially maxed out on the best available models, he said, but “then they realize they’re sort of paying… a phenomenal amount of money, and people are absolutely token maxing everywhere across their business. So there’s a massive pushback to reduce cost everywhere.”

That positions Microsoft to ride a market trend rather than fight it. Cost-efficient, near-frontier models have proliferated over the past year — from xAI’s recent Grok release to a wave of Chinese models built on the same premise — and Microsoft is betting that as a platform company it can align itself with enterprise cost pressure. “The top model providers want you to use the most expensive model continuously, whereas because we are a platform, we’re on the side of the enterprise,” Suleyman said. “There’s no point asking… Mythos what the capital of France is.”

The 100-trillion-signal data moat Microsoft says no competitor can replicate

Every AI lab claims differentiation. Microsoft’s claim in security rests on something genuinely hard to copy: telemetry. The company processes more than 100 trillion security signals daily — a figure consistent with its 2025 Digital Defense Report, which also cited 4.5 million new malware files blocked and 5 billion emails screened per day — and draws operational insight from 1.6 million customers.

“We have trillions and trillions of data points going back decades,” Suleyman said. “It is, I think, the largest longitudinal cybersecurity dataset around,” in part because Microsoft’s customer base includes governments “who have been consistently attacked for years, and we have been consistently attacked.” Asked directly whether this constitutes an advantage no competitor can match, Suleyman didn’t hedge: “That is definitely a moat for us. Both the data and the expertise, and just the experience in the institution of going through that process.”

The strategic logic is that cybersecurity functions as a live reinforcement-learning loop: defenders act, outcomes are observed, models improve. Microsoft argues that connecting actions to outcomes — what was exploited, what was contained, what was blocked — yields training signal that pure model labs simply cannot buy or manufacture.

There is real substance here, but the usual caveats apply. The CyberGym results come from Microsoft’s own evaluation, the fine print shows the headline “96%” is actually 95.95%, and vendor-run benchmarks that pit an entire tuned agentic system against competitors’ base models are not apples-to-apples comparisons. What Microsoft has measured is a full harness-plus-models configuration against what customers might otherwise assemble — arguably the commercially relevant comparison, but not a controlled model-versus-model test.

The dual-use dilemma: how Microsoft plans to keep a vulnerability-hunting AI out of the wrong hands

A model built to find challenging vulnerabilities in complex codebases is, by definition, a model that could find vulnerabilities for attackers. This is not a theoretical concern. Microsoft’s own threat intelligence team, in joint research with OpenAI published in February 2024, documented nation-state actors from Russia, North Korea, Iran, and China probing large language models for reconnaissance, scripting, and vulnerability research. Its 2025 Digital Defense Report went further, warning that AI agents could eventually automate the entire attack lifecycle.

Suleyman said Microsoft is gating access accordingly. “We’re very strict about who gets access to the model, and we’re very careful about that,” he said. “We constantly monitor the API and usage.” An approved user, he added, “has to be seen to be having good intent, but also have technical competence.” The rollout will be deliberately staged: “It’s not going to be thousands next week. There will be tens, and then hundreds, and then thousands.”

Microsoft says the model was evaluated by its AI Red Team, subjected to automated and expert-led adversarial exercises, and independently assessed by a third party, with deployment wrapped in tenant isolation, auditing, and sandboxed execution environments with no internet access.

Suleyman also offered a candid acknowledgment of Microsoft’s positioning relative to the bleeding edge — one that doubles as a pitch to risk-averse buyers. “Even though we might be a few months behind the absolute cutting edge at any given moment… it matters that we’re doing it very carefully and thoughtfully, and we have a track record of doing that,” he said. For a company that spent 2024 absorbing hard security lessons — from delaying its Recall feature over privacy concerns to convening an industry summit after the CrowdStrike outage disabled some 8.5 million Windows devices — that trust-first framing is both strategy and necessity.

What Microsoft’s superintelligence roadmap signals about the future of enterprise AI

Suleyman described a rapidly accelerating MAI roadmap, roughly nine months after Microsoft stood up its superintelligence team. “We have the compute that we need. We certainly have the data we need. We have the talent,” he said. “Our momentum is accelerating rapidly.” The top enterprise demand he’s hearing is for “agents that can produce arbitrary code to solve whatever problem they direct them at,” as vibe-coded internal tools graduate from experiments into production. The next phase, he said, pulls voice, transcription, image, and coding models “all integrated into the same harness.”

Notably, Suleyman expressed skepticism about the industry’s default assumption that everything eventually converges into one giant unified model. “It remains to be seen whether one giant model that is fully multimodal is actually able to deliver additional transfer learning benefit because of the integration,” he said, “or whether it’s just a big lumbering expensive giant.”

That skepticism is the through line of the entire announcement. Microsoft is wagering that the unit of competition in enterprise AI is no longer the model at all — it’s the system: the router, the specialized small models, the frontier fallback, and the proprietary data feeding the loop. In security, where Microsoft controls both the telemetry flowing in and the products that act on it, that wager is at its strongest. Whether it holds in domains where the company’s data advantage is thinner remains the open question hanging over the MAI roadmap.

For now, though, Microsoft has offered the industry a preview of how it intends to fight the next phase of the AI race: not by building the biggest brain, but by building the best machine around it. As Suleyman put it, this is the tip of the iceberg — and Microsoft is betting everything on what sits below the waterline.

The same attacker broke into the same internet-facing Langflow server twice, and the second time brought ransomware built to destroy trained AI models. Sysdig’s Threat Research Team documented the first campaign on July 1 and the second on July 20. The entry point never changed, but the payload changed completely.

Both ran through CVE-2025-3248, a missing-authentication flaw in Langflow’s code-validation endpoint that lets anyone reaching the server execute Python on it. In the first, the agent improvised, encrypting 1,342 Alibaba Nacos configuration items with MySQL’s own encryption function and dropping the tables. In the second, it staged ENCFORGE, a compiled Go binary sweeping roughly 180 file extensions.

ENCFORGE was built for AI assets, not adapted to them

What gives the design away is the extension list. Sysdig found PyTorch and TensorFlow checkpoints, Hugging Face SafeTensors weights, the GGUF format behind most local LLM deployment, FAISS vector indexes and training data in Parquet and NumPy.

Generic ransomware picks up model files by accident because it encrypts everything. ENCFORGE names them.

Its flag for appending formats uses LoRA adapters and legacy GGML weights as the example, and an attacker who writes that knows whose machines these are.

Michael Clark, who leads Sysdig’s threat research team, framed the objective as destroying “the one thing an organization can’t simply restore.” ENCFORGE carries no network code. Sysdig found no outbound dial in the binary, no leak site and no payment portal, and the identical Proton Mail contact in both ransom notes ties the campaigns to the crew it tracks as JADEPUFFER. The agent harvested credentials on the way in, but the locker cannot exfiltrate anything, so its only pressure is making files unusable. It encrypts regions of a file rather than the whole file, under AES-256-CTR with a per-run key wrapped in an embedded RSA-2048 key, the speed optimization established ransomware families use to ruin large files fast.

Your backup plan probably does not cover model weights

Restoring a database from Friday’s snapshot costs a weekend of transactions. Restoring a fine-tuned model costs everything learned since Friday, none of it stored as rows to replay.

Rebuilding one is not a restore job. Sysdig puts direct recovery for a production-ready fine-tuned model between $75,000 and $500,000, reflecting cloud GPU rates across the training runs a usable result requires plus the engineering hours behind them. That is per model, and teams keep several variants on shared storage. If the training data sits on the same host as the weights, recovery is blocked until the dataset is rebuilt. Paying is no way out either. In the first campaign, the encryption key was generated at random, printed to the console once and never saved, which made that payload a wiper wearing a ransom note.

That figure makes the argument fundable. Kayne McGladrey, an IEEE Senior Member who has spent his career in identity security, told VentureBeat that security teams lose these fights by filing the exposure under the wrong heading. Companies “should be focused on business risks rather than some, you know, cybersecurity risk, because if it doesn’t affect the business, like a loss or financial loss, in this case, predominantly, then nobody’s going to pay any action to it, and they will not budget it appropriately, nor will they adequately put in controls to prevent it,” he said. A destroyed model carries a known replacement cost, which is the version of this story a CFO acts on.

Official guidance has not caught up. In May 2025 the NSA’s Artificial Intelligence Security Center, CISA and the FBI published “AI Data Security,” the most authoritative document on the subject, co-sealed with the U.K., Australia and New Zealand. The three risks it names are the data supply chain, maliciously modified data and data drift. All three ask whether the data can be trusted. ENCFORGE asks whether it still exists.

It built its own escape hatch in five minutes

The delivery failure is where this campaign shows its hand.

After confirming execution, the agent swept the host for cloud keys, connection strings and API tokens, replayed them against internal database and cache services, and found the Docker socket at /var/run/docker.sock, which is functionally root. It then tried to pull the ransomware binary from its command and control server, and the fetch did not land.

Rather than retry, it changed strategy, building six Python scripts through the Langflow channel and converging on a working host escape in five minutes and 24 seconds, each correcting a failure in the one before it. The final script finds the host process ID through the Docker API, copies the binary across the namespace boundary, runs the encryption, then counts the files to confirm it worked. In the first campaign, that same behavior was a failed login diagnosed and fixed in 31 seconds.

The problem got harder and the method held. Sam Evans, then CISO at Clearwater Analytics, put it in budget terms. “In security, it’s all about dwell time,” he told VentureBeat in an exclusive interview. “If there’s a bad actor in your environment and they’ve been there for a while, your dwell time is increased, therefore the blast radius has increased. Probability of it becoming a material incident is exponentially high.”

Mike Riemer, Ivanti’s field CISO, has watched that pivot become standard. Vendors hardened the front door, he told VentureBeat, so attackers quit knocking. “I can’t get through the front door, so let me get somebody his house key, and I can make it through the back door with a house key,” he said. Behind it sits whatever teams assume is covered, because “they don’t sit out directly on the internet, and they’re behind a protection barrier, but they’re not.”

No one claimed a machine did this unsupervised. TechCrunch reported on July 6 that the first operation still needed a person to pick the target and stand up infrastructure, and Sysdig could not trace the root credentials. A human aimed this one, and everything after ran with nobody at the keyboard.

Heath Renfrow, co-founder and CISO at breach-recovery firm Fenix24, told Infosecurity Magazine that when an agent compresses hours of operator work into minutes, “defenders lose valuable time.” Whether the attacker was AI-driven does not change the response.

The door had been open for 14 months

CVE-2025-3248 carries a CVSS score of 9.8. CISA added it to the Known Exploited Vulnerabilities catalog on May 5, 2025, with a federal deadline of May 26, and Langflow fixed it in 1.3.0. When JADEPUFFER came back in July 2026, the server was more than fourteen months past that listing and already documented publicly as a breach victim.

Riemer put a number on how little time that leaves. “If I release a patch and a customer doesn’t patch within 72 hours of that release, they’re open to exploit, because that’s how fast they can now do it,” he said, adding most customers need a week to patch by hand. Set 72 hours against fourteen months, and the gap stops reading as one lapse.

Nothing in either campaign was new. The first forged a Nacos admin token with a default signing key public since 2020, walked through CVE-2021-29441, an authentication bypass Alibaba patched in 2021, and found a MinIO store on minioadmin:minioadmin. Sysdig counted more than 600 payloads, every one leaning on a known misconfiguration or a patched bug left exposed. The second added an exposed Docker socket. Every weakness was routine. Assembling them at machine speed was not.

Langflow draws this attention because of what it holds. VentureBeat reported in June that roughly 7,000 instances sit exposed, most in North America, holding provider API keys, cloud credentials and live connections to the vector stores ENCFORGE was built to encrypt. Riemer puts it bluntly. “When you put your security at the edge of your network, you’re inviting the entire world in to the edge of your network,” he said.

CISA has added five Langflow flaws to its Known Exploited Vulnerabilities catalog, two of them this month. Five Langflow flaws now sit on the KEV catalog, two of them this month. CISA added CVE-2026-55255 on July 7, a cross-tenant bypass letting any authenticated user on a shared instance run another tenant’s flows with that tenant’s credentials, which the maintainers’ advisory rates 9.9 and fixed in 1.9.1.

On July 21, CISA added CVE-2026-0770, and that one is worse. Trend Micro found an unauthenticated path to root code execution through the exec_globals parameter, on the same validate endpoint JADEPUFFER came through, rated 9.8. KEVIntel logged exploitation from June 27, more than 220 attempts across 64 addresses. According to founder Ryan Dewhurst, speaking to BleepingComputer, the payloads reached past reconnaissance for AWS credentials and container metadata. Federal agencies had until July 24.

None of this is an exotic environment. A Cloud Security Alliance survey of 418 professionals, commissioned by Token Security, found 82% of organizations had discovered AI agents nobody knew about, and 65% had handled an agent-related incident in the past year.

McGladrey traces the permission half back four decades. Companies always cloned one employee’s access profile onto the next hire, and now do it with agents. An agent “does whatever it needs to do to get its job done,” he said, and it “uses far more permissions that it shouldn’t have… than a human would do, because of the speed of scale and also intent.”

What to do before the board asks

“Every time some new ransomware attack is published in the news, we get the inquiry from the board. What are we doing about this?” Evans said. “And if it involves AI, it sparks their fear even more.”

Five things are worth answering this week. None requires buying anything.

1. Get every internet-reachable Langflow instance onto the current supported release. Anything off it is exposed to at least one of the five flaws CISA has now listed, including the July 21 addition. Then review historical requests to /api/v1/validate/code for the exec_globals pattern.

2. Get the Docker socket out of application containers. Langflow has no reason to create them. If the mount is required, front it with a socket proxy allowing only needed calls.

3. Name model artifact paths in the backup plan. Immutable snapshots of checkpoints, vector indexes and training data, restore tested, data off the host holding the weights.

4. Rotate every credential the host could reach, then pull provider keys out of its runtime. Patching does not revoke what already left. The first campaign harvested OpenAI, Anthropic and cloud credentials within seconds. Scope replacements to a secrets manager.

5. Detect mass .locked file creation in directories holding .gguf, .safetensors, .ckpt or .faiss files. Sysdig published a YARA rule and both hashes, neither with antivirus coverage at analysis time. It published no file count, so what is documented is a live encryption pass, not a measured loss.

An attacker coming through an exposed AI framework now arrives carrying something built for what it connects to, and those assets are the ones a restore cannot reproduce. Model artifacts belong in the recovery plan next to the databases. Under three weeks passed between Sysdig’s two reports, all this attacker needed to go from improvised Python to a compiled locker.