That is not a hypothetical. In a few months, three of the most widely deployed AI agent frameworks each turned a known, ordinary bug class into a way through. Check Point Research chained a SQL injection in LangGraph’s SQLite checkpointer to full remote code execution. Tenable and VulnCheck tracked a path traversal in Langflow’s file upload endpoint to active, in-the-wild RCE. Cyera documented a path traversal in LangChain-core’s prompt loader that reads your secrets off disk. Two paths to a shell, one to your keys. They are the same bug, wearing three frameworks.

These frameworks became production infrastructure faster than anyone secured them. They store agent state, take file uploads, load prompt configs, and hold the credentials to databases, CRMs, and internal APIs. The edge tools watch traffic. The endpoint tools watch processes. Neither was built to treat an imported framework as a boundary worth guarding, and that blind spot is exactly where all three chains live, widening every week as these frameworks ship to production.

The LangGraph chain, SQL injection to a Python shell

Start with the one most teams pulled into production this quarter. LangGraph gives AI agents memory through checkpointers, the persistence layer that stores execution state. It has cleared over 50 million downloads a month. Yarden Porat of Check Point Research took that layer apart and found three vulnerabilities. Two of them chain to RCE.

CVE-2025-67644, rated CVSS 7.3, is a SQL injection in the SQLite checkpointer. The function that builds the WHERE clause for checkpoint lookups drops user-controlled filter keys straight into the query with no parameterization and no escaping. This does not hit everyone, but where it hits, it is serious. A deployment is exposed when it self-hosts LangGraph on the SQLite or Redis checkpointer and lets untrusted input reach get_state_history() or a similar history endpoint. Meet those conditions, and an attacker who controls the filter writes a fabricated row straight into the checkpoint table. Run LangChain’s managed LangSmith platform on PostgreSQL, and the exposure is gone.

Then CVE-2026-28277, CVSS 6.8, finishes the job. LangGraph’s msgpack checkpoint decoder rebuilds Python objects from the stored data, which lets it import a module and call a named function with attacker-supplied arguments. That step needs write access to the checkpoint store; the SQL injection is what grants it remotely. LangGraph loads the forged row as a legitimate checkpoint, the decoder runs the specified function, including os.system, and code executes under the identity of the agent server. A third issue, CVE-2026-27022, CVSS 6.5, reaches the same place through the Redis checkpointer.

There has been no confirmed exploitation in the wild yet. A working proof-of-concept is public in Check Point’s disclosure. The fixes are version bumps: langgraph-checkpoint-sqlite to 3.0.1, langgraph to 1.0.10, and langgraph-checkpoint-redis to 1.0.2.

The Langflow chain, one unauthenticated request to RCE

Langflow is the one already under attack. CVE-2026-5027, CVSS 8.8, is a path traversal in the POST /api/v2/files endpoint, which takes the filename straight from the form data and writes it to disk unsanitized. An attacker packs that filename with traversal sequences and drops a file anywhere, such as a cron job in /etc/cron.d/. Because Langflow ships with auto-login enabled in its default configuration, an exposed instance needs no credentials at all. A single unauthenticated request reaches the endpoint, and the next cron run hands over a shell.

VulnCheck’s Caitlin Condon confirmed exploitation on June 9: “Our Canaries observed exploitation of CVE-2026-5027 that successfully leveraged the path traversal to write what appear to be test files on victim systems.” Censys put roughly 7,000 exposed instances on the internet, most in North America. This is the third Langflow flaw to draw active exploitation this year, after CVE-2025-34291, which the Iranian state-sponsored group MuddyWater weaponized and which CISA added to its Known Exploited Vulnerabilities catalog in May. CVE-2026-5027 itself was patched in version 1.9.0, released April 15.

The timeline is what sets the clock. The patch shipped April 15. Attacks started in June, and VulnCheck added CVE-2026-5027 to its exploited-vulnerabilities list June 8 once its sensors caught the first in-the-wild hits. Every instance left unpatched between those two dates has been sitting in the open for almost two months. The lesson for security teams is to start the patch clock at disclosure, not at a federal catalog entry.

The LangChain-core gap, arbitrary file reads through the prompt loader

LangChain-core, the foundation under both, disclosed CVE-2026-34070, CVSS 7.5, a path traversal in its legacy prompt-loading API. The load_prompt() functions read a file path out of a config dict with no check against traversal sequences or absolute paths, so an attacker who influences that path reads arbitrary files the process can reach, including the .env file holding OPENAI_API_KEY and ANTHROPIC_API_KEY. Cyera paired it with CVE-2025-68664, CVSS 9.3, a deserialization flaw that resolves environment secrets through a crafted object. The fix versions differ, which matters when you patch: CVE-2026-34070 lands in langchain-core 1.2.22 and 0.3.86; CVE-2025-68664 lands earlier in 1.2.5 and 0.3.81. Clear both, or the higher-severity flaw stays live behind a patched one.

Three frameworks, three classic AppSec bugs. Path traversal. SQL injection. Unsafe deserialization. Nothing exotic, nothing AI-specific, just old vulnerabilities living inside new infrastructure. None of this is a frontier-model problem. It is plumbing, sitting in the layer where AI meets the enterprise.

Why the scanner cannot see it

Merritt Baer, CSO at Enkrypt AI and former deputy CISO at AWS, has named what makes this kind of failure hard to see coming. It does not announce itself as an AI problem. "CISOs will experience MCP insecurity not in the abstract, but when an employee pastes sensitive data into a tool, or when an attacker finds an unauthenticated MCP server in your cloud," Baer told VentureBeat. "It won't feel like 'AI risk.' It will feel like your traditional security program failing." The framework chains here are the same shape. An exposed Langflow instance is an unauthenticated server in your cloud, and the alert, if one fires, reads like an ordinary incident.

That is the gap in one sentence. The exploit lives in the framework your code imports. The WAF never sees a msgpack decoder running three layers down. The EDR watches the agent server make the same process calls it makes a thousand times a day and waves it through. Both tools are doing their job. Nobody scoped the framework itself as the thing that could turn on you.

The root cause is older than AI, and Baer names it. “MCP is shipping with the same mistake we’ve seen in every major protocol rollout: insecure defaults,” she told VentureBeat. “If we don’t build authentication and least privilege in from day one, we’ll be cleaning up breaches for the next decade.” Langflow’s auto-login is that mistake shipped. LangChain-core’s unguarded prompt loader is that mistake shipped. The convenient default is the vulnerability. And the moment an agent connects to anything, that risk compounds. “You’re not just trusting your own security, you’re inheriting the hygiene of every tool, every credential, every developer in that chain,” Baer said. “That’s a supply chain risk in real time.”

There is a governance failure layered on top of the technical one, and it is the same miscategorization Assaf Keren, chief security officer at Qualtrics and former CISO at PayPal, has flagged in adjacent tooling. “Most security teams still classify experience management platforms as ‘survey tools,’ which sit in the same risk tier as a project management app,” Keren told VentureBeat. “This is a massive miscategorization.” Swap in AI agent frameworks, and it still holds. Teams file LangGraph, Langflow, and LangChain under developer convenience, then wire them into databases, CRMs, and provider keys. “Security has to be an enabler,” Keren said, “or teams route around it.” These frameworks are what routing around it looks like.

Follow the money and it points at the same layer. On its Q1 fiscal 2027 earnings call, CrowdStrike reported its AI detection and response line up more than 250% sequentially, and on June 17 it extended that runtime coverage to agent, LLM, and MCP traffic on AWS. George Kurtz, the company’s co-founder and CEO, named the reason in plain terms: “Agents run on the endpoint. They make tool calls, access files, invoke APIs, and move data at the process level.” That is the exact plumbing these chains abuse, and real money is now moving to the layer your AppSec scan skips.

What to put in front of the board

The board does not need the CVE numbers. It needs the consequence, and Keren draws the line the board cares about. Most teams have mapped the technical blast radius. “But not the business blast radius,” Keren told VentureBeat. “When an AI engine triggers a compensation adjustment based on poisoned data, the damage is not a security incident. It is a wrong business decision executed at machine speed.” A framework RCE is the same problem one layer earlier. The agent does not just leak a credential; it acts on production systems with it, and the business sees an outcome no one can explain.

So frame it the way a board frames it: we run AI agent frameworks in production that can be turned into remote shells through bugs our scanners are not built to find, all three are patched, one is under active attack, and here is the date every instance is verified and closed. None of this required custom malware or a zero-day.

The six-question checklist

Six trust boundaries, one per row, each with the question, the proof point, the command, the fix, and the board line. Run it tonight.

How to read this table: each row is one trust boundary, left to right, from the question to ask to the line to read your board.

Give the board the deadline, not the technology

The fixes are not a re-architecture. They are version bumps and config changes you can land this week. The exposure is the gap between the day the patch shipped and the day your team runs the checks, and right now that gap is measured in months. The frameworks did exactly what they were built to do.

On June 15, Varonis disclosed SearchLeak (CVE-2026-42824), a proof-of-concept exfiltration chain in Microsoft 365 Copilot Enterprise Search. A victim clicks a crafted microsoft.com URL, Copilot searches their mailbox, and the data leaves through a Bing SSRF. No plugins, no second click, no visible indicator. Four days earlier, Obsidian Security published a three-CVE chain against LiteLLM that carried a default low-privilege user all the way to admin and remote code execution. Two tools. Two teams. One broken boundary.

The five-check audit at the end of this article maps each gap to a CVE or a market signal from June, a command you can run before lunch, and a sentence a CISO can read to the board.

Copilot turned a trusted URL into an exfiltration engine

SearchLeak chained three weaknesses into a silent data-theft chain. The URL q parameter fed attacker instructions straight to Copilot’s LLM. A rendering race condition fired an image tag before the output sanitizer ran. Bing’s image-search endpoint, allowlisted in the Content Security Policy, routed the stolen data out. Microsoft rated the flaw critical and patched it on the back end, according to Varonis. NVD has not yet scored it; a third-party tracker lists it at 6.5 medium. The severity is contested, but the mechanism is not.

The escalation is the real story. This is the third Varonis Copilot exfiltration chain in twelve months, after Reprompt in January and EchoLeak in 2025. Reprompt hit Copilot Personal. SearchLeak hit Enterprise Search. Enterprise inherits the user’s full organizational permissions, so the blast radius is everything that a user can reach.

LiteLLM handed a default account to every provider key

The LiteLLM gateway holds the keys for OpenAI, Anthropic, Azure, and Bedrock behind a single proxy. The Obsidian chain runs in three moves. CVE-2026-47101, an authorization bypass, lets a non-admin mint a wildcard API key. CVE-2026-47102 promotes that caller to proxy admin through an unguarded /user/update endpoint. CVE-2026-40217 escapes the code sandbox through exec() with full builtins. Obsidian then demonstrated a reverse shell by injecting a forged tool-call response through LiteLLM’s callback mechanism. Obsidian assessed the combined chain at CVSS 9.9. The developer typed one word. The attacker popped a shell.

A separate LiteLLM flaw made the urgency immediate. CVE-2026-42271, a command-injection bug in the MCP test endpoints, landed on the CISA KEV list on June 8 with a June 22 remediation deadline. That KEV entry is not the Obsidian chain. The two are distinct disclosures four days apart, fixed in different releases, pointed at the same gateway. LiteLLM carries more than 40,000 GitHub stars and sits in thousands of enterprise deployments. This is not the first scare, either. A supply-chain compromise backdoored LiteLLM versions 1.82.7 and 1.82.8 on PyPI in March. A compromised gateway exposes every provider credential the organization holds.

Langflow and Mini Shai-Hulud proved the pattern scales

The same boundary broke in two more tools in the same fortnight. Langflow CVE-2026-5027 became the third Langflow remote-code-execution flaw to hit active exploitation this year. A path traversal in file upload lets an attacker write files anywhere on disk, and because Langflow ships with auto-login enabled by default, a single unauthenticated request reaches RCE. VulnCheck confirmed exploitation on June 9. Censys counted roughly 7,000 exposed instances, the heaviest concentration in North America, with MuddyWater attribution.

The Mini Shai-Hulud campaign hit a different pressure point. After the worm’s source code went public on May 12, copycat variants compromised 32 Red Hat Cloud Services npm packages on June 1, packages pulled 80,000 times a week. The worm harvests more than 20 credential types and self-propagates under the compromised maintainer’s identity.

Four teams, four tools, one operating failure. The bug classes differ. SearchLeak is a prompt injection. LiteLLM is privilege escalation. Langflow is path traversal. Mini Shai-Hulud is supply-chain poisoning. The boundary that broke is the same in all four.

The market already repriced the risk

CrowdStrike’s Q1 FY27 earnings call put a number on the gap. AIDR, the company’s AI detection and response line, grew ending ARR more than 250% sequentially, with a Q2 pipeline above $50 million (SEC-filed 8-K). Total company ARR reached $5.51 billion, and CrowdStrike’s fleet telemetry shows more than 1,800 agentic applications running across enterprise endpoints.

On June 17, the company extended AIDR to AWS, adding real-time evaluation of agent, LLM, and MCP communications across Amazon Bedrock, Kiro, and Strands Agents, building on its work with Anthropic’s Project Glasswing. Daniel Bernard, CrowdStrike’s chief business officer, said the AI attack surface now spans development, runtime, identities, and cloud infrastructure, and that teams treating those as separate domains leave the gaps between them open.

Practitioners name the same gap in plainer terms

David Levin, CISO at American Express Global Business Travel, told VentureBeat the pattern does not surprise him. “We kind of have this shadow AI, which is just the new version of shadow IT,” Levin said.

Both Langflow and LiteLLM fit the description. Teams stood them up for convenience, gave them credentials, and never brought them under governance. Levin puts the fix before deployment. “We didn’t go into this with just saying we’re going to go do this without the right fundamentals,” he said. “We leverage NIST controls. NIST has released their CSF along with their AI framework. OWASP released their top 10. You need the right fundamentals before you deploy.”

Merritt Baer, CSO at Enkrypt AI and former AWS Deputy CISO, named the structural version of the failure in a separate VentureBeat interview. “Enterprises believe they’ve ‘approved’ AI vendors, but what they’ve actually approved is an interface, not the underlying system,” Baer said. “The real dependencies are one or two layers deeper, and those are the ones that fail under stress.” She has tied that directly to how systems fall. “Raw zero-days aren’t how most systems get compromised. Composability is,” Baer told VentureBeat. “It’s the glue between the model and your data where the risk lives. If you give an agent bash and a root token, you’ve already done most of the attacker’s work for them.” That is what rows 2 and 4 of the audit test: the gateway that holds every key, and the agent identity no one governs.

Levin had a sharper frame for the boardroom. “You need to talk more in terms of risk versus compliance to your boards and your executives,” he said. “It’s not about the size of the engineering team anymore. It’s the size of your imagination. It’s all written in plain English. It’s not hard for anyone.” Neither SearchLeak nor LiteLLM needed custom malware or a zero-day to work.

Adam Meyers, CrowdStrike’s SVP of Intelligence, put the operational squeeze in numbers in an exclusive VentureBeat interview. “The problem is not zero-day. The problem is patching. If you 10x that problem, they’re gonna be completely underwater,” Meyers said. He pointed to identity as the second front. “Some of these AI have their own identities, or people give their identity to the AI to take action on their behalf, and that makes it a very complex problem.”

The five-check trust-boundary audit

Each row maps a gap to its proof point, a verification command for Monday morning, the fix, and the sentence to read to the board.

The fix is plumbing, not policy

The June 2 executive order creates an AI Cybersecurity Clearinghouse with a July 2 deadline. The five gaps above are not frontier-model problems. They are plumbing problems in the gateways, orchestration platforms, identity layers, and runtime environments where AI meets the enterprise.

The audit is five rows. Every row maps to a June disclosure or market signal, a command a team can run before lunch, and a sentence a CISO can read to the board. The question is not whether your vendor will patch. It's whether you find the gap first — or whether an attacker finds it the way they found Copilot and LiteLLM.

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.

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.

"These agents are doing things that you cannot necessarily control, and you cannot necessarily train," said Gal Marder, Chief Strategy Officer at JFrog, in an exclusive interview with VentureBeat.

Available immediately, the partnership hardwires NanoClaw agents directly to JFrog’s vetted software registries, ensuring that AI assistants can only pull scanned, safe dependencies.

The release addresses a rapidly growing blind spot in tech: autonomous agents frequently install packages in the background to extend their capabilities, often without their human operators' knowledge or oversight.

"The people who are operating the agents are not necessarily developers, and they are not even aware of the implications," explained Gavriel Cohen, creator of NanoClaw and CEO and co-founder of its new commercial services startup, NanoCo AI.

To secure the broader ecosystem, the partners are working to make it available completely free of charge for the open-source community, while enterprise organizations can seamlessly route their agents through their existing, commercially licensed JFrog environments.

The new technical capability enabled by this partnership follows NanoCo's moves to add permissions dialogs across the apps in which it's available via a partnership with Vercel, and a new partnership with Docker to allow NanoClaw agents to run more securely, isolated from other software environments directly inside Docker virtual containers.

The risk of current, personal autonomous AI agents

When an operator interacts with an autonomous system like NanoCo's NanoClaw, they communicate at a high level of abstraction.

A user might simply send an audio file or a voice note, prompting the agent to independently figure out how to process it.

As Cohen explained, the agent thinks, "oh, I can't understand voice notes, so let me go and grab a package and download something and install it and set it up and run it".

This dynamic self-improvement makes AI agents incredibly powerful, but it also renders them highly susceptible to software supply chain attacks.

Bad actors are increasingly poisoning open-source registries with malicious packages. Because agents act autonomously to fetch what they need, they bypass human scrutiny.

The operators, who may not even be developers, are largely unaware of the security implications unfolding behind the scenes.

How NanoCo and JFrog are working to stop agents from running malicious code

The integration between NanoCo and JFrog acts as an automated immune system for these AI environments.

Under the hood, NanoClaw agents are now configured to route their requests for software packages, CLI tools, and Model Context Protocol (MCP) servers exclusively through JFrog’s registries.

If an agent attempts to download a compromised library—such as a vulnerable version of the popular Axios package—the JFrog registry intercepts the request.

It blocks the installation, returning a security policy error to the agent, noting that the request was "rejected by JFrog's registry with a 403 security policy".

Crucially, the system does not just stop at blocking the threat; it creates a dynamic correction loop. The agent is notified of the vulnerability and guided to automatically seek out and install an approved, non-malicious version of the requested package instead.

For large organizations, this integration solves a massive compliance headache. Marder notes that as enterprises adopt autonomous agents, they require absolute visibility.

Organizations need "a system of record, we need somewhere to track what agents that's running by whom and consuming what packages and using what skills and using what MCPs," he told VentureBeat.

Beyond visibility, the JFrog integration provides a foundational "trust layer" and strict governance over what these automated systems are permitted to access.

Licensing and accessibility

In the realm of software distribution, licensing and access parameters dictate adoption. The NanoCo and JFrog partnership utilizes a dual-track approach to serve both individual open-source developers and highly regulated enterprises.

For the open-source community, the integration is completely free. JFrog is providing open-source NanoClaw users with complimentary access to safe, vetted sources of artifacts, tools, and skills.

This allows individual developers to run autonomous agents locally without drowning in manual approval requests for every single dependency. Furthermore, as community members build and share new "skills" for the agents, these contributions are uploaded to the registry, scanned for malicious code, and cleared before anyone else can use them.

This infrastructure directly neutralizes the threat of poisoned community repositories.

For enterprise deployments, the architecture plugs seamlessly into an organization's existing commercial environment. Rather than using the public open-source registry, corporate users point their NanoClaw agents to their own internal JFrog registries.

This ensures that all agent activity adheres to the company’s specific commercial licenses, internal security policies, visibility needs, and governance standards.

As AI continues to blur the line between human intent and machine execution, the infrastructure securing that execution must evolve. This partnership acknowledges a core reality: you cannot train an AI to perfectly recognize every zero-day vulnerability; instead, you must build an environment where the agent simply cannot reach the vulnerability in the first place.

No malware, no stolen credentials, and no prompt injection in the sense most security teams drill for. The agent did exactly what Meta built it to do. That is what should keep a security operations leader up at night: The takeover did not break a control; it rode one that was already trusted.

What a SOC needs is a way to walk each recovery path through an audit grid with its AI build team before the next renewal closes. The AI Authority Audit Grid at the end of this article maps every authentication write a support agent can make on the recovery path, what Meta's incident proved about each one, why it stays dark to the SOC, and the control that closes it.

The agent is an authorized actor, so the SOC reads the takeover as routine traffic

From inside the detection stack, the attack produced no signal the stack could read. The agent binds a new email, then resets the password, and identity and access management logs both writes as an authorized actor, so each lands in the authentication state as a legitimate transaction. No anomalous login, no failed-auth spike, nothing for EDR or DLP, no SIEM rule to match, because nothing in the sequence looks like an attack. The takeover lived inside the trust boundary the stack assumes is safe. There is no foothold to find, because the agent was the foothold, and it was supposed to be there.

The chain was almost insulting in its simplicity. Brian Krebs documented the version pro-Iran hackers posted to Telegram on May 31. The attacker switched on a VPN to appear in the victim's region, sidestepping Instagram's location alarms, then asked the support assistant to add a new email and send a verification code, as the BBC confirmed from the same recordings. The bot complied, sending the one-time code straight to the attacker, Gizmodo reported. The reset finished and the owner was locked out, in minutes. The exploit failed against any account with MFA enabled, according to Krebs.

The hijacked accounts were not soft targets. They included Sephora, U.S. Space Force senior enlisted leader Chief Master Sergeant John Bentivegna, researcher Jane Manchun Wong, and a dormant Obama White House handle that briefly posted a defaced image, according to 404 Media. Meta disputes the Obama account, according to TechCrunch, and called claims that leaders' accounts were breached "completely false," according to the BBC. The rest stand.

MFA held. The recovery path beside it did not.

The detail that decided who survived was narrow. Krebs reported the attack failed against any account with multifactor authentication, even SMS. The recovery path beside it was the gap. When that path asked for a selfie video, attackers ran the target's public photos through an AI video generator and submitted the clip, which Meta accepted as valid identity verification, gHacks reported. Either way the failure was the recovery door, not the login door MFA guards.

That makes this an architecture problem, not a Meta problem. MFA gates the login path for owner and attacker alike, but the recovery path runs beside it, built to relax the usual checks because it exists for the moment a user has lost the normal way in. Meta put an agent on that path with write access to authentication state and no deterministic check between a convincing request and a committed change. Authorization cannot live inside the model, because a conversational system can be talked into skipping a check. It has to live outside the model, in a gate the agent cannot reason its way past. Security researchers have a name for this pattern, the confused deputy, a trusted system tricked into spending its privileges on an attacker's behalf.

This is not the last support agent that will hand over an account. Ian Goldin, a threat researcher at Lumen's Black Lotus Labs, told Krebs on Security that AI bots are as easy to social engineer as the human agents they replace, and just as eager to help. "AI chatbots create interesting new attack surface, and we're likely going to see a lot more of these kinds of attacks," Goldin said. Every enterprise wiring an agent into a recovery, provisioning, or password flow is shipping the same write access Meta did.

Simon Willison, who coined the term prompt injection, put it plainly on his blog. "Meta really did wire their support system into an AI chatbot that had the ability to fast-forward through the entire account recovery process," he wrote. "This one hardly even qualifies as a prompt infection. Don't wire your support bot up to allow one-shot account takeovers." The attacker never tricked the agent. The attacker asked, and the agent had untrusted input, write access, and a way to execute, all at once.

OWASP named this class before Meta shipped it, as Excessive Agency at LLM06 and Identity and Privilege Abuse at ASI03 in the Agentic AI Top 10. The warning label was on the box: Meta pushed the assistant to every Facebook and Instagram account in March, according to 404 Media, with the power to reset passwords and handle recovery, the product page promising "solutions, not just suggestions" under the line "account security and recovery." Meta gave the agent the power and never built the gate to govern it.

The AI Authority Audit Grid

Security operations leaders need to run this against their own support agent before the next renewal closes. Each row is an authentication write the agent makes on the recovery path, with what Meta proved, why your stack misses it, and the control that closes it.

The fix is not bolting yet another MFA prompt onto the login screen. The people who survived Meta’s incident were the ones who already had that control in place.

The fix is pulling authorization out of the recovery path’s honor system and putting it behind a gate that does not move just because a prompt sounds convincing. Build the agent so the SOC sees every write it makes, and so any write that changes who owns an account cannot commit without a check that the model does not control.

Meta just showed what happens when the most trusting employee on the team is also the one holding the keys. The next agent like that is already reading your intellectual property and financials.

On Tuesday at its annual Build developer conference, Microsoft offered what may become the definitive answer. The company introduced Microsoft Execution Containers, or MXC — a policy-driven execution layer, built into the Windows operating system itself, that lets developers and IT administrators declare exactly what an AI agent can and cannot access, with those boundaries enforced at runtime by the OS kernel.

The announcement, buried within a sweeping set of developer-focused updates, is arguably the most consequential platform move Microsoft made at Build this year, and it has the potential to reshape how every enterprise on Earth thinks about deploying autonomous AI software.

MXC is not a product you buy. It is an SDK and a policy model — a foundational primitive embedded in Windows and the Windows Subsystem for Linux — that provides what Microsoft calls a "composable sandbox spectrum." That spectrum ranges from lightweight process isolation, already adopted by GitHub Copilot's command-line interface, all the way up to micro-virtual machines, Linux containers, and full cloud instances running on Windows 365.

The system separates an agent's execution from the user's desktop, clipboard, user interface, and input devices. Critically, it binds every agent to a strong identity — either a local ID or a cloud-provisioned identity backed by Microsoft Entra — so that every action the agent takes can be attributed, audited, and governed.

The implications are enormous. Until now, the enterprise deployment of AI agents has been stuck in a paradox: the more autonomous and useful an agent becomes, the more dangerous it is to let it operate on a corporate network without guardrails. MXC is Microsoft's attempt to break that paradox — not by making agents less capable, but by making the environment they operate in fundamentally more controlled.

Why every autonomous AI agent is a security incident waiting to happen

To understand why MXC matters, consider what an AI agent actually does when it runs on your computer. Unlike a traditional application, which operates within well-understood boundaries — a word processor reads and writes documents, a browser fetches web pages — an AI agent is, by design, unpredictable. It receives a goal in natural language, reasons about how to achieve it, and then takes actions: opening files, executing code, calling APIs, browsing the web, interacting with other software. Each of those interactions creates what security professionals call "attack surface."

Microsoft's own blog post framed the challenge in stark terms. The company wrote that "as agents become more capable and autonomous, they're delivering material productivity gains. But they're also introducing new risk, and the issue isn't just the agent. It's the entire system the agent operates across." Every interaction between agents and humans, tools, applications, models, and other agents "exposes new attack surface and introduces different failure modes." Microsoft characterized this as "a multi-layer systems problem."

This is not a theoretical concern. In the months leading up to Build, security researchers demonstrated numerous ways that AI agents could be manipulated — through prompt injection, through malicious tool calls, through data exfiltration disguised as normal workflow. For enterprises that handle sensitive data, proprietary models, and regulated information, the absence of a trusted execution environment has been the single biggest barrier to moving agents from demo to deployment.

Microsoft's answer is a sandbox that scales from a single process to a full virtual machine

MXC operates on a deceptively simple principle: declare what the agent can do before it runs, and let the operating system enforce those declarations at runtime. A developer or an IT administrator writes a policy that specifies which files, directories, and network resources an agent is allowed to access. MXC then creates a contained execution environment — a sandbox — that enforces those boundaries regardless of what the agent attempts to do.

What makes MXC unusual, and potentially very powerful, is the breadth of its isolation options. Microsoft designed the system so that a single SDK and policy model can map to the appropriate isolation construct for any given workload. For a lightweight coding assistant that just needs to read the current project directory, fast process isolation may be sufficient. For an autonomous agent that executes arbitrary code downloaded from the internet, a full micro-VM may be required. The system is designed to be "dynamically composable based on intent and risk," meaning that the level of isolation can be adjusted based on what the agent is actually doing, not just what category it falls into.

Session isolation is a particularly important feature. MXC separates the agent's execution from the user's desktop, clipboard, UI, and input devices. This directly mitigates several classes of attacks that security researchers have identified as particularly dangerous for AI agents: UI spoofing, where an agent manipulates what the user sees to trick them into approving a malicious action; input injection, where an agent sends keystrokes or mouse clicks to other applications; and cross-session data leakage, where information from one user's session bleeds into another.

A live demo showed an AI agent trying to delete files — and failing, because the OS wouldn't let it

During a pre-briefing with VentureBeat the night before the announcement, a Microsoft developer offered a vivid demonstration of the technology in action. He had set up the open-source agent framework OpenClaw running inside MXC's sandbox on his personal development machine. He then instructed the agent to delete all the files on his desktop. The agent attempted to comply — but the sandbox prevented it. "If you look at my desktop here, you see how clean my desktop is," the developer said during the demo. "That's a lie." The files, he explained, were completely safe because "the container won't allow it."

The demonstration went further, showcasing the granularity of MXC's controls. Users can mark specific files as read-only for the agent, restrict access to the browser and screen capture, control whether the agent can see location data, and have all of those permissions managed centrally by an enterprise IT department through Intune policies. The agent operates inside what is effectively a one-way mirror: it can do the work it has been asked to do, but it cannot see or touch anything outside the boundaries that its policy defines.

Pavan Davuluri, Microsoft's Executive Vice President for Windows and Devices, underscored during the pre-briefing that the primitives MXC introduces — security, containment, isolation, and user control — are essential to making AI agents commercially viable.

He emphasized that these capabilities are "not unique to OpenClaw" and that "this pattern repeats itself over and over" for any agent running on a Windows device. The primitives that exist in the operating system now "for the file around security, containment, isolating them, having users in control," he said, are what will make agents safe enough for ordinary consumers and corporate deployments alike.

Defender, Entra, Intune, and Purview integration arriving in July turns MXC into an enterprise control plane

For corporate IT departments, the most significant element of the MXC announcement is not the SDK itself but its integration with Microsoft's existing enterprise security stack through what the company calls Agent 365. Arriving in preview in July, Agent 365 layers Microsoft's Entra identity service and Intune device management platform on top of MXC, so that IT administrators can govern agent containment centrally while developers choose the level of isolation their workload demands.

The integration goes further: Microsoft Defender will provide runtime threat protection, Entra will handle identity and access management, Intune will enforce device-level policies, and Microsoft Purview will extend its data governance and compliance capabilities to agent activity. This means that an enterprise could, in theory, allow employees to run AI agents on their corporate machines — even powerful, autonomous agents that execute code and manage files — while maintaining the same kind of centralized visibility and control that IT departments currently have over traditional applications.

Microsoft described the identity layer in its official blog: "Windows assigns agents a local ID or a cloud provisioned identity backed by Entra and attributes all activity from the container to that identity, so you can clearly differentiate human from agent." For regulated industries — financial services, healthcare, government — the ability to produce an audit trail that distinguishes between human actions and agent actions on the same machine could prove to be a regulatory requirement, not merely a nice-to-have feature. Every agent action attributable to a specific identity, every containment boundary enforceable through the same policy infrastructure that already governs hundreds of millions of Windows devices — this is the architecture that could finally move AI agents from pilot programs to production.

OpenAI, Nvidia, Manus, and Nous Research are already building on MXC — and that changes the calculus

Platform announcements at developer conferences are often aspirational. What distinguishes the MXC launch is the breadth and specificity of the partners already building on it. Microsoft named five: OpenAI, Nvidia, Manus, Nous Research (maker of the Hermes agent), and the OpenClaw open-source project. Each is integrating MXC in a distinct way that illuminates a different use case for the technology.

OpenAI's involvement is particularly striking. David Wiesen, a member of OpenAI's technical staff, said that "working with Microsoft on the Microsoft Execution Containers (MXC) allows us to explore new patterns for AI agents to safely and efficiently generate and execute code." He added that by combining Codex's capabilities with MXC's execution environment, the goal is "to help developers move from intent to reliable execution faster, while maintaining the security and control enterprises need." The reference to Codex — OpenAI's code-generation agent — suggests that MXC could become the default execution environment for one of the most widely anticipated agent products in the industry.

Nvidia is bringing its OpenShell framework to Windows built on MXC, providing what Microsoft described as "an easy-to-deploy package for autonomous, always-on agents safely." Manus, the Chinese-born AI agent startup that gained viral attention earlier this year, is also integrating. Tao Zhang, Manus's Chief Product Officer, said that MXC "gives developers a policy-driven way to define what an agent can access and enforce those boundaries at runtime, so more autonomous agents can operate safely in enterprise environments." And Dillon Rolnick, the CEO of Nous Research, offered what may be the most concise articulation of why MXC matters: "Continuously-running local agents, like Hermes Agent, require intentional isolation. Developers need control over what an agent can access and trust that those controls will hold."

How an open-source agent framework became Microsoft's proving ground for AI safety on Windows

One of the more revealing stories behind the MXC announcement involves OpenClaw. During the press pre-briefing, a Microsoft developer described how the partnership came together organically — Peter Steinberger, OpenClaw's creator, sent him a direct message in January expressing interest in collaborating. What began as a casual conversation evolved into a full-fledged platform partnership, with Microsoft developers contributing to the OpenClaw Windows companion app, built as a native WinUI application rather than a wrapped web app.

The OpenClaw integration serves as what Scott called "the ultimate test app for all the stuff that [the Windows platform team] is making." If OpenClaw — which by its nature gives agents broad autonomy to execute tasks on a user's machine — can run securely within MXC's containment boundaries, then the containment system is robust enough for any agent. Scott explained the philosophy driving the work: "Think of OpenClaw Windows as the ultimate test app... If OpenClaw can succeed on Windows, that means that the Linux support is there, the container support is there, the containment is there."

The companion app demonstrates the full spectrum of MXC's enterprise controls — file permissions, network access, screen capture restrictions, location data — all manageable centrally through Intune policies. Microsoft donated the project to OpenClaw and plans to continue contributing to it as open source. As one member of the Windows leadership team put it during the briefing: "All agents, all comers, everyone is welcome on Windows... It's going to run great on Windows, because the primitives are there. The base of the pyramid is solid."

Building containment into the OS gives Microsoft a strategic edge over Apple's walled garden and Google's cloud-first model

MXC arrives at a moment when the technology industry is grappling with a fundamental tension. AI agents represent what may be the most significant new category of software since mobile applications, and every major technology company is racing to build them. But the security and governance infrastructure required to deploy these agents responsibly in enterprise environments barely exists. Microsoft's approach is distinctive because it locates the trust layer at the operating system level rather than in the agent framework, the model provider, or a third-party security product.

This is a deliberate architectural choice. By building containment into Windows itself, Microsoft ensures that the security guarantees hold regardless of which agent, which model, or which framework a developer chooses.

It also means that the hundreds of millions of Windows devices already managed through Intune and secured through Defender can, in principle, become agent-ready through a software update rather than a rip-and-replace deployment.

Apple's approach to AI agents leans heavily on its walled-garden ecosystem, offering security through restriction — limiting which agents can run and what they can do. Google's approach, centered on its cloud infrastructure, offers security through centralization. Microsoft's approach offers security through declaration and enforcement — allowing any agent to run, but containing its impact through OS-level policy.

For enterprises that operate in heterogeneous environments with diverse toolchains and multiple AI providers, the Microsoft model may prove the most practical. The competitive dynamics are already shifting: with OpenAI's Codex, Nvidia’s OpenShell, and independent agent frameworks like Manus and Hermes all building on MXC, Microsoft is positioning Windows not just as the platform where agents run, but as the platform where agents can be trusted to run.

The hardest part isn't building the sandbox — it's writing the policies that go inside it

MXC is available now in early preview, meaning developers can begin building against the SDK and testing containment policies. The Agent 365 integration with Defender, Entra, Intune, and Purview is scheduled for preview in July — a timeline aggressive enough to suggest that much of the engineering work is already done, but far enough out to allow for refinement based on developer feedback.

The real test, however, will come when enterprises begin deploying agents at scale on production networks. Containment is only as good as the policies that govern it, and writing effective agent policies for complex enterprise environments will be an entirely new discipline — one that IT departments have not yet developed and that no vendor has yet figured out how to teach. The technology is promising, but an empty sandbox is just an empty box. Filling it with the right rules, for the right agents, in the right contexts, will require a level of organizational sophistication that most companies are only beginning to contemplate.

Still, the significance of what Microsoft announced on Tuesday is difficult to overstate. For the first time, a major operating system vendor has proposed a comprehensive, kernel-level answer to the question of how autonomous AI software should be contained, identified, and governed on the devices where most of the world's work actually gets done. The industry spent two years teaching agents to act. Microsoft is now betting that the bigger business — and the harder engineering problem — is teaching the operating system to watch.