





![A battery being taken out of an iPhone [Apple]](https://photos5.appleinsider.com/gallery/59757-122185-58508-119228-000-lead-battery-xl-xl.jpg)



ChatGPT Work








Apple TV 4K
Mario Kart Tour

Macs continue to gain market share



iPhone Fold render
Slopsquatting represents an emerging supply chain threat made possible by AI hallucinations. As developers increasingly rely on AI coding assistants, they unknowingly grant cybercriminals access to their software from day one.
Slopsquatting is a new type of supply chain attack that uses large language model (LLM) hallucinations to inject malicious code into development workflows. The term combines "AI slop" and "typosquatting," a deceptive practice where attackers register misspelled or lookalike versions of popular domains to prey on users who enter URLs incorrectly.
This novel attack vector exploits LLMs' tendency to generate fictitious software package names, which threat actors can then register and populate with malicious code.
During AI-assisted coding, the model may generate fake open-source packages — bundled collections of files, programs and installation tools. This alone is not necessarily harmful. However, if an attacker registers that fake package name, they can inject malware that gets incorporated directly into a developer's codebase.
Traditionally, AI safety risks stem from hallucinations, which can adversely affect users who treat misinformation as valid. However, those same hallucinations have evolved into exploitable security vulnerabilities.
Typosquatting is a deceptive practice where a cybercriminal registers a mispelled version of a popular package to trick developers. It has existed for decades, so registries have built protections against it.
However, AI has changed the threat model. It recommends fictitious packages that sound plausible rather than making simple misspellings. Once attackers learn which hallucinated packages models tend to invent, they can register malware-filled packages under those names.
Since the hallucinated packages are not simply typoed versions of popular libraries, there are no protections against this practice at scale. For example, the registry protects against an attacker publishing "crossenv," a squat of the popular "cross-env" package. However, it would not identify "mpn install cross-env file" or "cross-env-extended" as threats.
Even if many LLMs recommend the same hallucinated package, widespread compromise is still possible. Malicious packages could remain undetected in production for months or even years, allowing threat actors to passively inject malware across countless environments.
One research team analyzed 31,267 vulnerabilities belonging to 14,675 packages across 10 programming languages. They discovered that reported vulnerabilities are increasing at an annual rate of 98%, faster growth than the 25% annual increase in the number of open-source software packages. The team also observed an 85% increase in the average lifespan of vulnerabilities, indicating a decline in security.
Malicious actors can create open-access packages under the same name as commonly hallucinated libraries. Instead of standard code, they are filled with malware. The models believe they are referring to existing packages, so they often repeat the same hallucinated names. Since the hallucinations are not random, attackers could theoretically register packages that trick tens of thousands of developers.
These packages appear legitimate. String similarity to real libraries makes them recognizable. One-character typos suggest simple mistakes rather than malicious intent. Even fully fabricated names remain believable when the AI presents them in proper context. Detection is challenging, as developers trust their coding assistants to recommend valid dependencies.
LLMs generate the statistically most likely answer rather than prioritizing accuracy. Hallucinations are relatively common as a result. One study found hallucination rates range from 50% to 82%, depending on the model and prompting method. Even GPT-4o, the best-performing model, goes no lower than 23%, even with prompt-based mitigation.
Adversarial hallucination attacks could worsen this problem. Threat actors can leverage token-level manipulation or retrieval poisoning to force models to hallucinate in ways they want, increasing the likelihood that models recommend their malicious packages.
While all LLMs are prone to slopsquatting, some are more vulnerable than others. The likelihood of producing hallucinated packages during code generation depends on the model. Proprietary models are four times less likely to generate hallucinated packages than open-source models.
One research group proved this by conducting 30 tests across 30 different systems. Out of the 576,000 code samples and 2.23 million packages it produced, 19.7% were hallucinations. GPT-4.0 Turbo had a hallucination rate of 3.59%, while DeepSeek 1B, the best-performing open-source model, reached 13.63%.
This research suggests that organizations relying on open-source AI tools for code generation are roughly four times more exposed to slopsquatting attacks. That doesn’t necessarily mean proprietary tools will always remain safer, though. Once attackers realize this disparity, they may manipulate proprietary LLMs to take advantage of perceived safety.
Software developers who use AI tools estimate that over 40 percent of the code they commit includes AI assistance. They expect that percentage will increase considerably within the next few years. Already, 72% of those who have tried AI use it daily.
The uptick in vibe coding and AI-assisted coding amplifies the threat surface. As more developers integrate AI tools into their workflows without implementing proper verification processes, the attack surface for slopsquatting continues to expand.
For those using AI to assist with coding, double-checking output is essential. Verifying that recommended packages actually exist in official repositories before incorporating them into projects reduces risk.
Implementing automated checks that validate package names against known registries can help catch hallucinated packages before they enter production code. Security teams should also monitor for unusual package installations and maintain up-to-date threat intelligence on known slopsquatting campaigns.
Zac Amos is the Features Editor at ReHack.
An enterprise AI agent answers with total confidence, but the number is wrong. Nobody catches it until someone traces it back to a stale metric definition or a document the retrieval system never pulled. The model did not fail. The context it was given did.
In the past six months, 57% of enterprises traced a confident but wrong AI agent answer to missing or inconsistent business context, and 31% said it happened more than once, according to a VB Pulse June 2026 survey of 101 qualified enterprises with more than 100 employees.
The reason is not hard to find. Retrieval over documents is the default way agents get business context for 38% of enterprises, nearly double the next closest approach. The way most enterprises choose a retrieval system compounds the problem. Ease of ingestion and operational simplicity lead the selection criteria, with retrieval accuracy running behind both. The accuracy problem only shows up after the system is already live.
There is a known fix for this, a governed context layer every agent reads from instead of guessing. Vendors are racing to roll out context platforms while most enterprises are still figuring out what it is.
The context layer is meant to be a shared model of what business data actually means, built once and referenced consistently instead of re-derived by every agent that touches it.
The VentureBeat research shows the enterprise response to that idea is broad but unfinished. Twenty-five percent of respondents run one in production. Thirty-four percent are building one right now. The remaining 41% have not started.
Among companies already building or running a governed context layer, 78% report a confident-wrong failure — an AI agent that answered with total certainty and was still wrong. Among companies with no plans to build a layer, only 20% report the same thing. Companies that already got burned are far more likely to be building the fix. Companies that haven't been burned yet see no urgency.
Every major data and AI platform vendor is now building some version of this layer, and they are not converging on the same architecture.
DataHub is treating catalog metadata and years of analyst query behavior as a knowledge source, then keeping it current as a living system rather than a static wiki.
Microsoft's Fabric IQ is building a business ontology that any agent, not just Microsoft's own, can query over MCP.
Couchbase is pushing agent memory and context retrieval down to the edge, arguing the operational database is a more natural home for it than a search or analytics layer bolted on after the fact.
Pinecone's Nexus is compiling structural logic into the metadata layer ahead of runtime, betting that agents need pre-built structure more than they need faster search.
Snowflake runs a two-layer system, Horizon Context for customer-managed definitions and Cortex Sense for context the platform infers on its own.
Oracle's Unified Memory Core takes the opposite approach, folding vector, graph and relational data into one transactional engine so there is no sync layer left to go stale.
Google's Knowledge Catalog mines query logs and usage patterns to curate semantic context automatically.
AWS's Context service makes the same bet, a knowledge graph that gets smarter from how agents actually use it rather than from manual re-curation.
The vendor approaches differ. What analysts and practitioners have told VentureBeat about the underlying problem, across a run of interviews this year, does not.
When DataHub's context layer push landed this spring, Constellation Research VP and principal analyst Michael Ni framed the stakes in blunt terms. "Whoever controls runtime context controls the AI decision layer for enterprise data," Ni said. He was equally direct about how far any single product actually gets a buyer. "Vector memory isn't business meaning, business meaning isn't governance and governance isn't execution," Ni said.
In the same interview, BARC analyst Kevin Petrie pointed to a narrower but concrete gap. Most context platforms concentrate on structured tables, he said, which give agents trusted facts but miss the harder, messier context locked in documents and unstructured content, exactly the material a business actually runs on day to day.
Stephanie Walter, practice leader for AI Stack at HyperFRAME Research, made a related point earlier this year when VentureBeat asked her about enterprise context fragmentation.
"The market is converging on the same conclusion," Walter said. "Agents don't just need more tokens or better models. They need governed, current, low-latency context." She made a similar case in an earlier review of Pinecone's Nexus launch, careful not to overstate how new any of this is. Nexus, she said, "shifts knowledge work from runtime chaos to pre-compiled structure. But it's an evolution of RAG architecture, not a complete reinvention."
Gartner's Arun Chandrasekaran, reviewing the same launch, offered the more forward-looking read. Agentic AI, he said, is moving from pure information retrieval toward a reasoning architecture, one where long context works as short-term memory and a vector database functions as deep storage underneath it.
The fragmentation problem shows up hardest at the practitioner level, where separate tools for retrieval, memory and access control were never built to agree with each other. Steven Dickens, CEO and principal analyst at HyperFRAME Research, put it bluntly after Oracle's AI database push landed this spring. "Data teams are exhausted by fragmentation fatigue," Dickens said. "Managing a separate vector store, graph database and relational system just to power one agent is a DevOps nightmare."
Matt Kimball at Moor Insights and Strategy, in that same story, put the production reality more simply. Getting an agent working is not the hard part, he said. The struggle is running it in production, where the goal becomes removing the distance between data and execution rather than adding another layer on top of it.
Here's what this adds up to for enterprises building on this layer.
Retrieval alone will not close the context gap. RAG is the default source for context in most enterprises today, and it is also the layer most closely associated with the confident-wrong-answer failure. Adding more documents or a bigger index does not fix a definition that is inconsistent across systems.
The semantic context layer is where the budget is actually moving, even where it hasn't shipped. Fifty-eight percent of enterprises are already engaged — building or in production — but only 25% have actually gotten a layer live. That gap shows where enterprises have decided to spend, not where they've arrived.
No single vendor owns the architecture yet, and that is likely to stay true for a while. Enterprises evaluating this layer should expect to integrate rather than pick a single winner, at least for the next several quarters.
The buying decision is happening this year, and it is concentrated among the companies already burned by it. Fifty-seven percent of enterprises plan to switch or add a retrieval or context platform within the next twelve months. That intent is not spread evenly. Enterprises that reported a repeat confident-wrong failure plan to switch or add a provider at roughly 81%, against 32% among enterprises that never hit the problem. The companies shopping for new context tooling right now are largely the ones whose agents already got it wrong.
The agents are already running. The context underneath most of them is still being built, and the vendor selling the fix is being chosen this year.
This data will be part of a broader conversation at VB Transform 2026 on July 14 and 15 in Menlo Park: the context gap enterprises are racing to close, and which of the emerging approaches — governed semantic layers, hybrid retrieval, provider-native bundles — actually holds up in production.
OpenAI on Thursday launched ChatGPT Work, a new AI agent embedded inside its flagship chatbot that aims to transform ChatGPT from a question-and-answer tool into an autonomous work platform capable of executing complex, multi-step tasks across users' email, calendars, code repositories, and messaging apps.
The product is powered by OpenAI's latest flagship model, GPT-5.6, and is designed to go far beyond generating text. ChatGPT Work can gather context from connected apps, files, and workflows to produce finished documents, spreadsheets, presentations, reports, and websites. The agent takes a stated outcome, breaks it into smaller steps, and stays with complex projects for hours, completing them independently.
The launch marks OpenAI's clearest attempt yet to reposition ChatGPT as a workplace platform rather than a chatbot — and it arrives at a moment of extraordinary financial significance for the company. Last month, OpenAI confidentially submitted a draft S-1 registration statement to the SEC, initiating what could become one of the largest technology IPOs in history, with reported valuations clustering between $730 billion and $852 billion and annualized revenue that has blown past $25 billion.
In a short demonstration and conversation with VentureBeat on Friday, Ty Geri, a product manager at OpenAI who helped build ChatGPT Work, said the product's mission is to democratize the kind of agentic AI capabilities that OpenAI's internal engineering tool, Codex, has already demonstrated. "What's really exciting is we've seen how much Codex has been able to push the frontier of what we can get done with these AI tools, as opposed to just getting information or answers or guidance," Geri said. "Our internal adoption of Codex is literally an exponential curve across every single product function and every single use case."
The core architectural bet behind ChatGPT Work is a persistent cloud-based virtual machine that runs on OpenAI's servers, always available to the user regardless of which device they happen to be on. That marks a deliberate departure from competitors whose agents require a local machine to remain powered on and connected.
"What's really exciting about ChatGPT Work is that it's a virtual machine in the cloud that's always on for you, and this is available across all of our paid tiers," Geri said. "All Plus users are getting this. I think that's a very unique aspect of this."
The mobile-first aspect of the launch is something Geri described as "missing from the market." He pointed to the ability to create a website on a phone and share it with collaborators as a particularly novel capability. "Sites are new in general to Codex. They launched in Codex about a week and a half ago, but now we're launching also in web and mobile. You can create a site on your phone at the beach and share it with your friends," he said.
ChatGPT Work will roll out beginning with Pro, Enterprise, and Edu users, and will expand to Plus and Business users over the next few days. In the interview, Geri emphasized that the availability of the product to Plus subscribers — not just premium tiers — is central to OpenAI's strategy. "It's accessible to all paid plans, including Plus users, which in my opinion is a really big feat, and really part of that OpenAI mission, which is about bringing all this power to as many people," he said.
The product relies on MCP-based plugins to connect to external services like Gmail, Google Calendar, Slack, and GitHub. When asked whether the plugin architecture is based on the Model Context Protocol standard, Geri confirmed: "These are all based on MCP." He added that connecting multiple Gmail accounts — a frequent user request — "is definitely on the roadmap."
The experience is designed to be action-oriented from the first interaction. ChatGPT Work offers a personalized onboarding flow that surfaces different suggested use cases depending on the user's role. Geri demonstrated how the system, detecting his role as a product manager, immediately suggested tasks like evaluating AI systems, building research artifacts, and managing his calendar. "You can start with a simple task like catch me up on Slack or Teams or read today's calendar," Geri said. He described a scenario where the system reviewed his calendar, identified scheduling conflicts, flagged meetings requiring preparation, and then — on his instruction — declined, accepted, or rescheduled events directly.
Users can also customize the agent by teaching it their writing style, organizing outputs into projects, and — in a lighter touch — choosing a virtual pet that accompanies them in the interface. The interface also introduces a hosted website feature that allows users to build and share interactive sites directly through ChatGPT Work, turning what would typically be a static slide deck into a dynamic, collaborative artifact. "Now we suddenly have a collaborative interface that's actually more exciting and more accessible than a slide deck, which has all these formatting restrictions," Geri said.
Geri's own usage of ChatGPT Work illustrates the breadth of tasks the system can handle. In the run-up to the product's launch, he needed to organize pre-release testing sessions — known internally as "bug bashes" — across dozens of features and team members.
"I just come to ChatGPT Work and say, 'Set up a bug bash for all the distinct features in ChatGPT Work. Add all the people that worked on that feature,' and it can check Slack, it can check GitHub, it can check Docs, and find a time that works for the four highest contributors to that feature," Geri said. "It went and scheduled 10 bug bashes, all coordinated across all those different people. That would have taken me 30 minutes at least."
But Geri pushed back against the characterization that ChatGPT Work is limited to rote administrative work. He described using it for analytically complex tasks like identifying the biggest causes of user churn for specific product features and generating product solutions — work he said would previously have taken months. "Things that we would have spent three months doing, we can now spend a week doing — and do much more, and make a much better product," Geri said. "Bugs that we would have found three or four weeks from now, we can now find within two days and fix for our users."
He also described handing off the tedium of product testing itself. "It used to be that even though like the most interesting part of my job is like what to test, I would actually end up having to spend most of my job doing the testing, which is like me taking a mouse and like clicking on the same thing over and over again, like five times," Geri said. "Instead, now I can define what do we want to test, and ChatGPT Work or Codex can actually go test it for me, deliver me that bug report, and then we can work on fixing that bug."
When pressed on data privacy concerns — given that ChatGPT Work pulls sensitive information from workplace tools like Slack, Google Drive, and email — Geri said privacy "is incredibly important, and the most important part of this is it's always in the user's control."
He pointed to OpenAI's existing enterprise security infrastructure, noting that "enterprise accounts have ZDR, and users can always opt out of letting their conversations help improve future models, which many users do." The comment aligns with assurances OpenAI made when it first launched ChatGPT Enterprise in August 2023, when the company wrote in a blog post that it does "not train on your business data or conversations."
The privacy question carries additional weight now because of the sheer volume of sensitive workplace data ChatGPT Work is designed to access. Unlike a chatbot session where a user voluntarily pastes text into a prompt, ChatGPT Work actively reaches into connected systems — reading Slack messages, scanning calendar invitations, pulling GitHub commit histories — to assemble context for its tasks. That represents a fundamentally different data surface area than anything OpenAI has offered before, and one that enterprise security teams will scrutinize carefully before granting access.
ChatGPT Work lands squarely in the middle of what has become the defining competitive battlefield in enterprise AI: the race to build autonomous workplace agents that can go beyond generating text and actually execute tasks.
The product arrives months after Anthropic took Claude Cowork out of preview and into general availability in April, bringing its AI agent to web and mobile platforms aimed at helping enterprise users monitor and manage long-running AI-driven tasks from anywhere. Meanwhile, Microsoft made Copilot Cowork generally available worldwide on June 16, built in partnership with Anthropic to move beyond chat and into execution. The three products — ChatGPT Work, Claude Cowork, and Microsoft Copilot Cowork — now compete directly for the attention of enterprise IT departments and individual knowledge workers alike.
The convergence is striking. All three products share a remarkably similar vision: a persistent AI agent running in the cloud that can break complex tasks into steps, connect to workplace tools via plugins, and produce finished outputs rather than just conversational replies. All three work across desktop, web, and mobile.
What distinguishes OpenAI's approach is its raw consumer distribution advantage. ChatGPT has reached 900 million weekly active users, and OpenAI now has 50 million paying subscribers. More than 9 million paying business users rely on ChatGPT for work, and 92% of Fortune 500 companies now use ChatGPT. By making ChatGPT Work available to Plus subscribers at $20 a month — not just Enterprise or Pro customers — OpenAI is betting that broad accessibility will drive adoption faster than any competitor can match.
When asked about the potential impact on the labor market, Geri was careful with his framing. He declined to speak broadly about workforce disruption but offered his personal experience as a product manager whose day-to-day work has been substantially reshaped by the tool.
"My job is not to schedule bug bashes and find out who contributed to a specific feature. That's a task I do in my job, but that's not my job," Geri said. "My job is to make an amazing product." He described ChatGPT Work as "a partner" and "an extension of me, certainly not a replacement," adding: "Everybody feels far more productive than before, but is also almost working harder than before, because you get to work on all the things you want to work on as opposed to the drudgery around it."
But Geri was also careful not to minimize the sophistication of the work the agent can handle. "I also don't want to say that it's only doing mundane tasks because, like something like hill climbing retention curves on a given feature is not mundane. It's actually really hard to do," he said. The distinction matters. If ChatGPT Work were merely automating calendar invitations and expense reports, it would be a convenience tool. The fact that Geri describes it compressing three months of analytical product work into a single week suggests something with far greater implications for how teams are structured and staffed.
The timing of ChatGPT Work's launch is impossible to separate from OpenAI's IPO trajectory. The company needs to demonstrate that it can convert its massive consumer user base into durable enterprise revenue — a narrative that becomes significantly more compelling with a product explicitly designed around professional workflows.
OpenAI said it is generating $2 billion in revenue per month, growing four times faster than Alphabet and Meta did at comparable stages, with enterprise now making up more than 40% of revenue and on track to reach parity with consumer by the end of 2026. But OpenAI remains heavily loss-making, and the company does not expect to reach profitability until around 2030, with internal projections suggesting losses of $14 billion in 2026 alone.
The competitive dynamics are unprecedented. Anthropic filed for its own IPO on June 1 at a $965 billion valuation, setting up simultaneous public listings from the two most prominent AI startups in history. Whether both can sustain their lofty valuations under the scrutiny of public market investors will depend in large part on whether products like ChatGPT Work and Claude Cowork deliver measurable productivity gains to paying enterprise customers.
The launch also caps a product trajectory that began with ChatGPT Enterprise in August 2023, accelerated through the release of OpenAI's Operator agent in January 2025, and continued through Operator's deprecation and shutdown on August 31, 2025, when its capabilities were folded into the ChatGPT agent framework. ChatGPT Work is the consolidation of those efforts into a single, unified product — one that pairs GPT-5.6's three model variants (Sol for power, Luna for speed, and Terra for balanced everyday use) with a persistent cloud environment and an expanding library of MCP plugins.
When asked whether ChatGPT Work signals a shift toward a new kind of operating system — one where users interact with their computers primarily through an AI agent rather than through traditional mouse-and-keyboard interfaces — Geri stopped short of making sweeping predictions. But he hinted at the direction OpenAI sees ahead.
"Anybody who has worked with Codex or now ChatGPT Work will realize how exciting it is to interact with your environment and your computer via the agent," he said. "Especially in the desktop app, where the model has access to your entire machine and can interact with websites on your behalf — it's really able to be an extension of you and a real partner, and that certainly feels like the future."
At the end of the interview, Geri circled back to something personal. "I've never enjoyed work as much as I have in the last month using ChatGPT Work and Codex," he said — a striking admission from a product manager who, until recently, spent a meaningful share of his days clicking through the same interface five times in a row just to see if it would break. OpenAI is now asking 900 million users to believe that feeling scales. For a company weeks away from one of the largest public offerings in history, the answer to that question is worth roughly $850 billion.
Enterprise companies are running AI agents ahead of the controls needed to manage them — and they deployed that way knowingly. That is the central finding from VentureBeat Research's June survey of 573 technical leaders at companies with 100 or more employees, fielded across five parallel surveys of the agentic stack.
Enterprises are now retrofitting to catch up with their own standards, and they are budgeting for it: Roughly six in 10 enterprises plan to switch or add vendors in each of five control layers within the next 12 months, and roughly a third — depending on the layer — plan to move within the quarter, the research finds.
There are five main layers where enterprises are building: identity for agents (which agent is allowed to do what, under whose credentials); evaluation of agent output (whether the work is any good); cost telemetry (what each agent costs to run); the context layer (the business data and definitions agents draw on to answer); and the orchestration control plane (the software that coordinates multi-step agent work).
Enterprises are already paying the price for deploying agents ahead of adequate control functions. Fifty-four percent of companies had an agent security incident or near-miss caught before harm in the past 12 months. Twenty-seven percent exercise only reactive control of agent spend — they learn what an agent costs when the invoice arrives, with no per-agent budget or ceiling in place.
Here are the five findings that anchor the set — one finding per layer of the tech stack — and what the data suggests doing first in each.
Eighty-six percent of enterprises that run their own GPUs report utilization of 50% or less. Wall Street has spent the quarter debating whether the AI buildout is overbuilt. This is buy-side measurement, from the enterprises doing the buying, and the research says the most expensive hardware in buildings of these enterprises runs at no more than half its capacity.
The measurement gap compounds it: A minority 44% rigorously track what their AI compute actually costs and returns. Everyone else is only estimating. And the enterprise shopping process continues regardless: 45% of these enterprises say the emerging compute option they are most likely to evaluate in the next 12 months is an AI-specialized cloud (CoreWeave, Lambda, Crusoe, Nebius). However, under 2% of these enterprises report using one of these neoclouds today.
Moreover, roughly one in three companies appears to be considering a hedge against Nvidia: Asked which emerging compute option they are most likely to evaluate in the next 12 months, 32% of enterprises named non-Nvidia accelerators (AWS Trainium, Google TPUs, AMD), while 28% named next-generation Nvidia GPUs. The data suggests that enterprises should measure the utilization and per-workload cost of the GPUs they already own before committing budget to new compute — whether that's an AI-specialized cloud contract, new accelerators, or more GPUs.
Seventy-one percent of enterprises say a quarter or fewer of their deployed "agents" can complete multi-step work on their own; the rest are single-prompt chatbots. Only 10% say true agents are the majority of what they run. To be sure, the respondents reported that they are in a position to know these things: 81% said they recommend or decide AI purchases at their companies.
That finding — that most agents are actually just chatbots in trenchcoats — lands amid adoption claims across the industry running well ahead of what enterprises are actually running. Gartner predicted 40% of enterprise applications will be integrated with task-specific AI agents by the end of 2026, up from less than 5% in 2025. It also warned that the most common misconception is referring to these AI assistants as agents, a misunderstanding known as "agentwashing."
Meanwhile, Zapier's enterprise survey said 72% reported deploying or testing autonomous agents; and Writer's 2026 survey has 97% of executives saying their company deployed AI agents in the past year.
Those surveys asked whether companies have deployed something called an AI agent, and companies said yes. Our survey asked the people running those deployments a harder question: Of the agents you have in production, how many can complete a multi-step task without a person driving each step? The gap matters for two practical reasons. First, the inflated adoption figures are the benchmark boards and vendors use to pressure technical leaders into moving faster — and this data says the real bar is far lower than the headlines suggest. Second, the label determines the bill: A single-prompt chatbot with a human reading every answer needs none of the identity, evaluation, and cost controls this report covers, while a true multi-step agent needs all of them.
Two-thirds of enterprises fall into one of two camps: 34% already allow an AI agent to push a code or system change to production based on automated evaluation results alone, with no human reviewing it, and another 33% are actively engineering their pipelines to allow that within the next 12 months. Only five percent fully trust the automated evaluations that would make that decision.
The distrust is earned. Half of enterprises shipped an agent that passed internal evaluations and then caused a customer-facing failure in the past year; a quarter watched it happen more than once. Asked to name the biggest weakness in their current evaluations, more enterprises chose “poor alignment with real-world outcomes” than any other answer — 29% of respondents.
And most of the checking happens before an agent ships, then stops. Once agents are live with real users, only 23% of enterprises run real-time quality checks on the answers those agents produce. Another 51% monitor system health only — uptime, request traces, and gateway logs — which tells them the agent is running, and nothing about whether its answers are right. The first move: Before removing human review from any workflow, test your evaluations against production outcomes rather than internal benchmarks, and instrument answer quality, not just uptime.
This finding is explored in more depth in VentureBeat's related coverage of the evaluation gap, which found that larger enterprises are moving faster toward zero-human deployment while also failing more often — and outlines a regression-testing framework built on production outcomes rather than internal benchmarks.
Sixty-nine percent of companies allow agent credential sharing somewhere in their agent fleet during runtime – meaning multiple agents operating under one API key or service account. Those companies were far more likely to get hit: Organizations with credential sharing anywhere in the fleet experienced a security incident or near-miss at a 63.5% rate (47 of 74), against 40.9% (9 of 22) where every agent has its own scoped identity.
The takeaway for enterprises is this: Give every agent its own scoped identity, starting with the agents that touch production systems.
Fifty-seven percent of enterprises traced at least one confident, wrong agent answer in the past six months to missing or inconsistent business context: wrong metrics, stale definitions, absent documents. Most of them watched it happen more than once.
Most enterprise companies are fixing this, even though they’ve moved forward with agent deployment already: 25% already run a governed semantic layer, or one governed definition of the business that every AI reads from, in production. However, 34% are still building one, and 41% haven't started. The takeaway: Govern the definitions your agents answer from, metrics and entities first, before scaling the agents that depend on them.
One more shift is worth reporting with its limits stated plainly. In our spring orchestration survey wave, the top concern about provider-controlled orchestration was security and permissioning limits (32%). By June, vendor lock-in led at roughly a third, with security limits at 28%.
Those are two snapshots one quarter apart, and here’s one possible explanation for why portability became a top issue for enterprises. Our June survey went into market after a June 12 U.S. Commerce Department export order took Anthropic's Claude Fable 5 offline for enterprises for roughly three weeks. Meanwhile, Chinese company Z.ai released GLM-5.2's open weights under an MIT license on June 16 at roughly one-sixth of GPT-5.5's price; and Tencent's Hy3 arrived July 6 under Apache 2.0; and OpenAI previewed GPT-5.6 on June 26 to a small group of government-vetted partners, opening it broadly on July 9 after the government's review cleared. The open-weight releases in particular promise enterprises more control over their agents, and while we haven't established a causal link here, the timing is worth noting.
The posture data matches the mood: 51% now expect their primary control plane for enterprise agents to be hybrid — provider-native plus external orchestration — by the end of 2026, up from 34% in the spring survey wave. Enterprises reporting that they rely purely on provider-managed agent services fell from 12% to 7%.
The synthesis across all five surveys reveals a huge “buying” window. In each of the five control layers, 57% to 64% of enterprises plan to switch or add vendors within 12 months — 64% in infrastructure and in evaluations, 59% in agent security, 57% in retrieval and context — and 26% to 38%, depending on the layer, plan to move within a quarter. No layer has an established incumbent: The most common evaluation tooling is the model provider's built-in evals, tied with no dedicated tooling at all (17% each); 82% of respondents name provider-native or hyperscaler controls as their primary agent security layer; and provider-native retrieval leads the context technology layer (RAG, etc) as well.
Most enterprises are defaulting today to the built-in tools that ship with the big AI platforms they already use: Anthropic, OpenAI, Google, Microsoft, and AWS. That holds true across every one of these agentic technology layers: enterprises are looking to their primary cloud and model providers to supply the guardrails, evaluations, and retrieval solutions already bundled into those providers' offerings.
Those defaults are winning on convenience, and they're also what the coming spending decisions will test. The survey didn't ask which direction that money moves — toward the platforms' built-in tools or toward the specialists challenging them — which is exactly why every contract in these five layers is worth watching over the next four quarters.
The Q3 survey wave will measure whether the enterprises made good on these budget plans: whether their agents gained scoped identities, whether evaluations got tested against production outcomes, whether GPU utilization rose, and whether the semantic layers under construction shipped.
VentureBeat will release the full Q2 reports across all five VB Pulse trackers at VB Transform, July 14–15 at Hotel Nia in Menlo Park, where we convene enterprise technical leaders building autonomous agents in production.
Disclosure: VentureBeat produces both this research and VB Transform
Enterprise AI teams are giving agents more freedom at the same moment their confidence in automated testing is collapsing.
Half of enterprises have deployed an AI agent or LLM feature that passed internal evaluations and yet still caused a customer-facing failure — one in four more than once — according to the June 2026 VB Pulse survey of 157 qualified enterprise respondents at companies with 100 or more employees.
The sample is self-selected rather than a probability sample, so the findings should be read as directional, not precise.
But enterprises are not responding by slowing automation: 66% of respondents already permit some production deployment without human review or are building systems intended to do so within the next 12 months. Only 5% say they fully trust the automated evaluations that would make those release decisions.
That mismatch is the evaluation gap: the autonomy ceiling is rising faster than the assurance beneath it.
It also fits a broader thesis that will be explored at VB Transform 2026: enterprises ship agents first, while the control layers around identity, evaluation, cost, context and orchestration are arriving later. The next year will be a retrofit cycle, with buyers shifting budget toward the systems that make agentic deployments governable and dependable.
Traditional software testing usually asks whether a defined input produces an expected output. Agent testing is harder because the system may choose its own sequence of steps, call tools, retrieve data, alter state and respond differently from one run to the next.
An agent can make several individually plausible decisions and still reach the wrong result. It may retrieve the correct account but update the wrong field. It may draft a valid refund request but send it without approval. It may call five tools successfully before a sixth step leaks sensitive information or leaves a workflow incomplete.
The survey shows enterprises already recognize this limitation. The most common reason for distrusting automated evaluation is poor alignment with real-world outcomes, cited by 29% of respondents. Bias or inconsistency follows at 21%, lack of explainability at 18%, and data leakage or privacy concerns at 17%.
That hierarchy matters. Enterprises are saying the score often does not predict what happens when a customer, employee or business process encounters the agent in production — not that automated scoring is too slow or expensive.
NIST makes a similar point in its Generative AI Profile: measurements gathered in controlled environments may not transfer cleanly to deployment because behavior changes with prompts, users, context and operating conditions. Its guidance calls for field testing, post-deployment monitoring and clear processes for escalating failures.
A single successful run proves that an agent can complete a task. It does not prove that it will complete the task reliably.
Anthropic’s guidance on agent evaluation distinguishes between measuring whether a system succeeds at least once across repeated attempts and whether it succeeds every time. That distinction is essential for customer-facing or operational workflows. A model that occasionally produces an excellent answer may still be unacceptable if the same task fails unpredictably on the next attempt.
Enterprise teams should therefore treat repeatability as a first-class metric. That means running the same scenario multiple times, varying phrasing and context, testing tool failures, and measuring whether the final business outcome remains correct even when the route changes.
The evaluation set also has to evolve. Every production incident should become a permanent regression test. Customer escalations, failed tool calls, incorrect approvals and data-handling mistakes should feed back into the pre-deployment suite rather than remaining isolated support cases.
The survey does not imply that every agent action should require a person. Human review cannot scale across millions of low-consequence decisions.
But zero-human operation should be earned by demonstrated reliability and bounded by the consequences of failure.
Low-risk actions such as drafting internal summaries or categorizing documents can tolerate broader autonomy. Financial transactions, customer communications, code deployment, access-control changes and data deletion need stricter thresholds, repeated consistency tests, policy checks, rollback mechanisms and clear human escalation paths.
The risk isn't evenly distributed by company size, either. Larger enterprises — those with 2,500 or more employees — are moving toward zero-human deployment fastest, at 70% versus 64% for smaller companies, and they're also shipping more agents that go on to fail a customer, at 54% versus 48%.
That is the warning for enterprise leaders. Removing the human from the loop does not remove uncertainty. Without stronger assurance, it converts uncertainty into an automated production decision.
The market will keep pushing toward greater autonomy because the economic incentive is real. The organizations best positioned won't be those that remove people fastest — they'll be the ones that treat repeatability and regression testing as seriously as deployment speed.
The vast majority of business data is tabular — living in data warehouses, CRMs, and financial ledgers — yet building a reliable model from it still means training a new one from scratch for every dataset, then maintaining hyperparameter tuning loops, feature engineering, and retraining pipelines to fight data drift. Google Research is proposing a way around that: a new foundation model called TabFM that treats tabular prediction as an in-context learning problem instead.
It can generate predictions for a new, unseen table in a single forward pass. For enterprise developers and AI engineers, this reduces the time-to-production from weeks of pipeline engineering to a single API call.
To extract reliable predictions from a gradient-boosted tree, data scientists must build and maintain complex data pipelines. They have to clean messy inputs, impute missing values, encode categorical variables into numerical formats, and engineer custom feature crosses.
Once the data is ready, they must run repetitive hyperparameter optimization loops, searching across learning rates, tree depths, subsampling ratios, and regularization grids to find the best configuration.
Once deployed, these traditional models "incur ongoing operational debt through data drift monitoring and retraining pipelines to stay accurate," Weihao Kong, Research Scientist at Google Research, told VentureBeat.
Meanwhile, the rest of the AI industry has moved on. Generative AI models for text and computer vision have seamlessly shifted to zero-shot inference, where a model can perform a completely new task simply by being prompted with context.
Large language models (LLMs) already excel at in-context learning, so why can't we just feed tables into an off-the-shelf LLM?
Because LLMs are trained on natural language rather than structured data, they struggle to process tables directly. First, their context limits are exhausted quickly by medium-sized tables containing just a few thousand rows and hundreds of columns. Second, LLMs suffer from tokenization inefficiency, awkwardly splitting numerical values and destroying mathematical precision. Finally, they suffer from structural blindness. When a 2D table is serialized as a 1D text string, LLMs lose track of which value belongs to which row and column as the table grows.
"That's why, today, it is far more effective to use an LLM to write the code that handles feature engineering and calls XGBoost than to ask the LLM to read the table itself," Kong said.
To run inference with TabFM, you do not update any model weights. Instead, you take your historical examples (the training rows with their known labels) and your target rows (the new data you want to predict) and pass them to the model as a single, unified prompt. The model learns to interpret the relationships between columns and rows directly from this context at runtime.
For example, consider an enterprise analyst trying to predict customer churn. Instead of building a bespoke data pipeline and training an XGBoost model, they can simply pass a sample of historical user session data alongside a new, active session into TabFM. In one forward pass, the model returns an instant churn probability.
TabFM overcomes the limitations of LLMs by treating the data as a grid, preserving its structural integrity without forcing it into a single-dimensional text string.
To effectively process diverse tabular structures while enabling scalable zero-shot prediction, TabFM synthesizes the strengths of earlier experimental architectures, TabPFN and TabICL. TabPFN, developed by Prior Labs, first proved that a transformer architecture could perform zero-shot classification on small tables, though it struggled to scale computationally to larger datasets.
Later, TabICL, developed by France's National Research Institute for Digital Science and Technology, addressed this bottleneck by introducing row compression, allowing in-context learning to efficiently process much larger tables.
TabFM combines TabPFN's deep feature contextualization with TabICL's efficient compression into a novel hybrid design built on three key mechanisms:
1. Alternating row and column attention: The raw table is first processed through a multilayer attention module that alternates across both columns (features) and rows (examples). By continuously attending across these two dimensions, the model natively captures complex feature interactions. This deep contextualization does the heavy lifting that would usually require tedious manual feature crafting by data scientists.
2. Row compression: Following this contextualization, the cross-attended information for each row is compressed into a single, dense vector representation. TabICL pioneered this by using CLS tokens to compress a row's rich information into one vector, "in contrast to TabPFN v2, v2.5, and v2.6, which attend over the full cell grid throughout the network," Kong explained. This drastically shrinks the computational footprint.
3. In-context learning (ICL): A causal Transformer then operates on this sequence of compressed embeddings. This Transformer model uses the attention mechanism of TabICL to attend over these dense row vectors, drastically reducing the computation cost and allowing the model to process large datasets efficiently.
A major selling point of TabFM is its pretraining recipe. The model was trained entirely on hundreds of millions of synthetic datasets. These datasets were dynamically generated using structural causal models (SCMs) that incorporate a wide variety of random functions. By training exclusively on synthetic SCMs, TabFM learned the fundamental mathematical priors of how tabular features interact without ingesting real-world, confidential CSV files.
To test the model's capabilities, Google researchers benchmarked TabFM on TabArena, a comprehensive evaluation suite spanning 51 diverse tabular datasets across 38 classification and 13 regression tasks.
On these public benchmarks, TabFM's zero-shot predictions already match or beat heavily tuned supervised baselines. However, Google is careful to note that this does not automatically mean TabFM will universally dethrone bespoke, hyper-optimized production models on every enterprise workload.
"Instead of replacing hyper-optimized production models, the true practical business value it unlocks for lean engineering teams is velocity," Kong said. "It allows data analysts and backend engineers to instantly spin up high-quality baseline models without a dedicated data science team managing a complex lifecycle."
For advanced practitioners looking to squeeze out maximum accuracy, the research team also introduced a "TabFM-Ensemble" configuration. By running the model through 32 distinct variations and blending the results, TabFM pushes the performance even further.
The shift to in-context learning for tables introduces a new economic trade-off that engineering teams must consider.
With traditional algorithms, training is slow and expensive, but inference is lightning-fast and cheap. TabFM flips this dynamic. While training time drops to zero, inference becomes significantly heavier. Because the model must process the entire historical dataset as context during every single prediction, it requires more compute and memory at runtime.
In this new paradigm, "traditional machine learning training becomes the 'prefill' phase (KV caching) in the context window," Kong said. While this prefill cost is steep, it is paid only once per table, and the cache is reused across subsequent queries. "The catch is prediction latency, which no amount of caching removes," Kong added. Every new prediction requires a pass through a large transformer. "Any production API requiring single-digit-millisecond response times cannot tolerate TabFM's forward-pass overhead."
For developers looking to evaluate the model today, the barrier to entry is low. Google designed TabFM as a drop-in replacement for traditional ML workflows, offering a scikit-learn compatible API (TabFMClassifier and TabFMRegressor). It natively handles mixed numerical and categorical columns, works directly with pandas DataFrames, and requires no manual ordinal encoders or numerical scalers. The library supports both JAX and PyTorch backends.
However, enterprise teams need to be aware of current limitations and licensing restrictions. The model architecture has a hard limit of 10 output classes for classification tasks, and it is optimized for tables with up to 500 features. More importantly, while Google released the underlying codebase under the permissive Apache 2.0 license, the pre-trained model weights are published on Hugging Face under a strict tabfm-non-commercial-v1.0 license. Developers can evaluate the model internally, but it cannot be deployed in commercial products yet.
Looking ahead, Google is addressing the commercial deployment friction through its cloud ecosystem. TabFM is being integrated directly into Google BigQuery, allowing analysts to run zero-shot predictions natively via an “AI.PREDICT” command. By putting foundation model inference right next to the data warehouse, TabFM could soon make complex tabular machine learning as accessible as a basic database query.
In practice, TabFM shines in rapid prototyping, high data drift environments, and small to medium-sized datasets under 100,000 rows. Conversely, teams should stick to traditional models for strict, ultra-low latency APIs, or massive tables exceeding one million rows, which currently require aggressive row sampling that degrades the foundation model's competitive advantage.
Share one API key across five AI agents, and a single compromised agent inherits the reach of all five. The attacker immediately benefits from the accumulated permissions of every workflow that the key touches. The forensic trail goes cold at the credential level because five agents on one account leave no record of which agent did what.
Sixty-nine percent of enterprises run agents with credential sharing somewhere in their deployments, according to VentureBeat’s June 2026 Pulse Research wave of 107 enterprises.
That one number explains the buying spree reshaping enterprise security this year. Palo Alto Networks, CrowdStrike, and Cisco have collectively bet more than $22 billion on it in the past year, targeting exactly the layer most enterprises in this survey haven't finished building.
Palo Alto Networks completed its acquisition of CyberArk on February 11 for $21.1 billion in total consideration at close — a deal it announced last July at roughly $25 billion and the largest in the company's history.
CrowdStrike closed its $740 million acquisition of runtime authorization platform SGNL and, by June 15, shipped the first product from the deal, Continuous Identity for AI Agents. CrowdStrike integrated SGNL in less than a year, delivering a product that validates every agent action in real time based on who owns it, who is calling it, and the device's risk posture.
Cisco announced its intent to acquire non-human identity specialist Astrix Security on May 4 for a reported $400 million.
For a security director, this survey reads as a board-level question, not a trend line. It also surfaces a finding no competitor’s data shows, one that exposes which companies are the most at risk.
The data below is the first look at VentureBeat’s Q2 Agentic Security report, drawn from 107 qualified respondents at organizations with more than 100 employees. The full report will be released to attendees at VB Transform, the event in Menlo Park next week (July 14-15) focusing on enterprise autonomous agents.
Forty-five percent are final decision-makers for AI purchases. The sample skews mid-market, so read the numbers as the view from organizations adopting agent security right now rather than from the largest enterprises.
More than half of respondents, 54%, have already had an agent security incident or near-incident. Eighteen percent confirmed an incident, and thirty-six percent caught a near-miss before a breach. Security teams are stopping most of these events at the last control point in the chain, but the rest of the data shows how thin that margin is.
Only 32% of enterprises give every AI agent its own scoped, managed identity. Nearly half (48%) report that some agents have scoped identities, while many still share credentials. Another 32% say agents mostly run on shared API keys or borrowed human and service-account credentials. The survey question allowed more than one selection, and 24 of the 107 respondents chose multiple options — which is why the three categories sum to 112%. Deduplicated by respondent, 74 organizations, or 69%, flagged credential sharing in at least one answer.
One number explains why the acquisitions target this layer. A shared credential converts a single compromised agent into many, and CyberArk's research puts machine identities at 82 for every human in organizations worldwide, with agents as the fastest-growing category of the ratio. Cisco made the same diagnosis when it bought Astrix, whose founders built the company around API keys, service accounts, and OAuth tokens. Cisco’s announcement calls those the credentials AI agents are now “using (and abusing)” to execute work at scale.
Adam Meyers, senior vice president of counter adversary operations at CrowdStrike, described the mechanism directly in an interview with VentureBeat. Some AI systems have their own identities, he said, and in other cases “people give their identity to the AI to take action on their behalf, and that also further kind of murkies the water and makes it very complex.” The murk is the point, because when the identity is shared, attribution dies with it.
Forty-nine percent of enterprises enforce scoped permissions at runtime, and 47% monitor and log agent activity, which can help reduce security incidents. Only 30% sandbox their highest-risk agents, the one control that limits blast radius when the first two fail. Isolation is what keeps a single compromised agent from becoming a deployment-wide event. Enterprises have funded detection and resistance, but the containment layer barely exists.
The sharpest finding in the survey, and the one no vendor report captures, shows up when you split results by company size. The incident rate is 49% for companies with 101 to 1,000 employees, but it shoots up to 63% for companies with more than 1,000. Sandbox isolation moves the other way, falling from 35% to 20% at the larger companies.
The chart above shows the same finding at finer granularity: the 49%/63% split above is a binary cut at 1,000 employees, while the bars here break incident rate and isolation rate into four size bands. The red line measures incidents and near-misses, and the navy tracks the one control that contains damage after everything else fails. At organizations with 101 to 250 employees, the two sit 7 points apart, but above 5,000, the gap blows out to 60 points. That top band pools the survey's two largest size groups and holds only 15 respondents, so treat the number as directional. Larger enterprises run more agents across more systems, which drives incidents up while sandboxing, the engineering project that would contain them, goes unfunded. The enterprises with the most agents have the least isolation around them.
The deals target exactly those accounts. Palo Alto Networks, Cisco, and CrowdStrike sell to large enterprises first, where incident rates are highest and containment is the thinnest.
The model providers are the security layer. OpenAI's built-in guardrails lead at 51%. Google Cloud reaches 36%, Microsoft Azure's Purview and Copilot Studio DLP 35%, and Anthropic's managed-agent controls 29%. Eighty-two percent of respondents name a provider-native or hyperscaler control as their single primary agent security layer.
The purpose-built specialists are in single digits, with Palo Alto Networks' Prisma AIRS at 7%, CrowdStrike at 6%, and Okta for AI Agents at 4%. Zenity and the dedicated non-human identity platforms are at 3% each. Microsoft Entra Agent ID is the highest-penetration identity-specific control in the dataset at 13%, the only one from a hyperscaler, and it still falls outside the top four. Only 5% of enterprises run no dedicated agent tooling at all, and the rest have tooling that came pre-installed.
Bundled controls lead because they ship free and are enabled by default. Most filter prompts and outputs, but they do not give an agent its own identity or sandbox it. Hyperscalers sell identity-layer products, and Entra Agent ID is in the dataset at 13%, but adoption stays low. The two controls that reward incident data the most, scoped identity and isolation, are the two that the default stack does not include.
Prompt-and-output filters evaluate whether a call looks malicious. That is an intent problem, and intent cannot be solved at the language layer. CrowdStrike CTO Elia Zaitsev drew the line in an interview at RSAC 2026. "Observing actual kinetic actions is a structured, solvable problem," Zaitsev said. "Intent is not." CrowdStrike's Falcon sensor walks the process tree on an endpoint and tracks what agents did, not what agents appeared to intend. A scoped identity and an isolation boundary give that sensor something to track, while a shared credential on a bundled guardrail does not.
Cloud security went through the same cycle a decade ago, and Palo Alto Networks, CrowdStrike, and Wiz built multi-billion-dollar businesses on the gaps native cloud controls left open. Agent security is tracking the same path faster. A misconfigured storage bucket sat open until a human noticed. A misconfigured agent exploits its own over-permissioning on every run, and no human is watching when it does. Merritt Baer, chief security officer at Enkrypt AI and a former deputy CISO at AWS, told VentureBeat that the default layer is thinner than enterprises assume. "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."
Here is the contradiction worth a keynote slide. Enterprises rate their agent security tooling 4.2 out of 5, with value for money at 4.1 and ease of implementation at 3.9. Those scores would make most SaaS vendors envious.
Only 35% believe their AI-enabled defenses are ahead of AI-enabled attackers, while thirty-two percent call it roughly even. Twenty-one percent say attackers lead, and another 21% say it is too early to tell, showing how enterprises trust their tooling more than they trust its outcomes.
Budgets confirm it. Forty-six percent allocate 6 to 10% of the security budget to agent security, and a full third spend 5% or less. Half the sample has already had an incident or near-miss, but the funding does not match the exposure.
Fifty-nine percent plan to adopt, add, or replace agent security tooling within 12 months, and twenty-nine percent plan to move this quarter. OpenAI leads forward interest at 34%, followed by Google at 30%, Anthropic at 29%, and Azure at 25%. The dedicated vendors draw more interest looking forward than their current single-digit footprint suggests. Satisfied customers do not reshuffle this fast unless they know the stack they're currently using is provisional.
1. Inventory every agent’s credentials this quarter. Map which agents share credentials with other agents and which run on borrowed human or service-account identities. The goal is not one credential per agent. Agents that touch multiple systems need multiple scoped identities. The goal is zero shared credentials between agents and zero borrowed human identities. Thirteen percent of surveyed enterprises already run Microsoft Entra Agent ID. Okta for AI Agents and the non-human identity specialists sell equivalents. Shared and borrowed credentials are the first thing to eliminate.
2. Sandbox the riskiest agents first. Isolation is the least-adopted control at 30% and the only one that contains blast radius after prevention fails. Rank agents by the sensitivity of what they touch and isolate the top of the list. Above 1,000 employees, where isolation falls to 20%, this is the single highest-return move in the dataset. Sandboxing does not require replacing the agent or the platform. It requires a policy decision and an isolation layer.
3. Match the budget to the incident rate. A third of enterprises fund agent security at 5% or less of the security budget, even though more than half have already had an incident or near-miss. Nine percent allocate more than 25% today. The full report breaks out exposure and containment by company size, showing which bands carry the most risk and the least protection.
The board's question is simpler. If one of our AI agents was compromised this afternoon, which systems did it touch, and whose credentials was it holding? For the 69% of enterprises running agents on shared credentials, the answer is a shrug. The trail goes cold at the key.
The full Q2 Agentic Security report, with the complete vendor matrix, industry cuts, and the full dataset behind these charts, debuts July 14 and 15 at VB Transform, held at Hotel Nia in Menlo Park. The open question it leaves is whether enterprises close the agent security gap on their own terms, or whether a confirmed breach closes it for them.





























