Home

An AWS software bug showed some customers billing estimates in the billions and trillions. Here is what failed, why invoices were unaffected, and what IT teams should know. The post AWS Billion-Dollar Software Bug Explained appeared first on TechRepublic.

A host platform for AI models and datasets confirmed it had experienced a data breach.

Hugging Face’s incident response team first turned to frontier AI models to analyze a breach of the company’s production infrastructure, and the models refused to help. Commercial safety guardrails built to stop attackers blocked every forensic query because they treated the IR team’s real exploit data the same way they would treat a live attack.The attacker, an autonomous AI agent running the campaign end to end, moved laterally across the Hugging Face infrastructure for a weekend, undetected and unstopped.Security leaders are quick to recognize the pattern and diagnose what went wrong. “I’ve seen versions of this during red-team exercises and internal security testing, but this is one of the first high-profile examples where it materially affected real incident response,” said Merritt Baer, senior adviser to Andesite, G2I, and AppOmni and former Deputy CISO at AWS.None of this is unique to Hugging Face, Baer said. “Commercial frontier models optimize for preventing misuse. They generally have no cryptographic or organizational way to determine whether the person asking ‘analyze this malware’ is an incident responder or the malware author.”A malicious dataset opened two code-execution pathsOn July 16, Hugging Face disclosed that an autonomous AI agent system had compromised its production infrastructure, gaining unauthorized access to a limited set of internal datasets and several service credentials. The company verified that its software supply chain was clean and found no evidence of tampering with public models, datasets, or Spaces. Hugging Face is still assessing whether the intrusion touched any partner or customer data and says it will contact affected parties directly as required. But few enterprise threat models had accounted for the attacker Hugging Face faced. An autonomous agent ran the entire campaign from initial access through credential harvesting. No human guided it.The entry point was a malicious dataset. When the data-processing pipeline ingested it, the dataset triggered code execution in two ways, through a remote-code loader and through a template-injection flaw in dataset configuration files. No admission gate screened the file before it reached a processing worker, the compute job assigned to each dataset. Initial access came through the data pipeline itself, a route that worked because most enterprise security teams treat the data feeding their pipelines as trusted input rather than an attack surface.Worker isolation did not hold. From that first foothold, the agent broke out onto the node running the workload, then harvested cloud and cluster credentials scoped broadly enough to reach multiple internal clusters, all of it inside a single weekend. Hugging Face described the agent framework as executing thousands of individual actions through a swarm of short-lived sandboxes, with self-migrating command-and-control staged on public services. The disclosure adds that the framework appeared to be built on an agentic security-research harness, which would put tooling designed for red-team work behind a live intrusion. Why the defenders’ queries looked like attacksInvestigators reconstructed more than 17,000 recorded events using AI-driven analysis agents of their own.First attempts at the log analysis ran on frontier models behind commercial APIs. Defenders’ steps included submitting real attack commands, exploit payloads, and command-and-control artifacts for classification, but safety guardrails blocked the requests outright.Baer traced the block to the prompts themselves. “The same prompts that are most valuable during an active intrusion, shell commands, exploit chains, credential dumps, persistence mechanisms, lateral movement, are exactly the prompts most likely to trigger safety systems,” she told VentureBeat. “As AI becomes embedded in security operations, this becomes an operational resilience issue rather than merely a model policy issue.”The forensic analysis finished on GLM 5.2GLM 5.2, an open-weight model deployed on Hugging Face’s own infrastructure, took the job the commercial APIs refused. No attacker data left the company’s environment. “This experience points to a gap worth planning for,” the company wrote in its disclosure. Hugging Face does not know which model powered the agents. It could have been a jailbroken hosted model or an open-weight model running without restrictions. Either way, the disclosure continued, “the attacker was bound by no usage policy, while our own forensic work was blocked by the guardrails of the hosted models we first tried.” Hugging Face drew that line itself, writing that the experience is not an argument against safety measures on hosted models and that it is sharing the feedback with the providers concerned.What authenticated trust changesThe industry, Baer argued, needs to move past treating AI safety as a content moderation problem. “Security operations require something different. Authenticated trust.” Instead of asking whether anyone should receive an answer, the question becomes whether an authenticated security team, operating under enterprise controls, should receive it. “The model shouldn’t only understand what is being asked. It should understand who is asking, why, and under what governance.”“Organizations already build contingency plans for cloud outages, identity provider failures, or EDR failures,” Baer wrote. “AI assistants are becoming another dependency.”Her advice on IR playbooks was blunt. “A mature incident response plan should assume that during a severe incident, commercial AI APIs may refuse requests, API rate limits may become unavailable, internet connectivity may be impaired, and data governance rules may prohibit uploading forensic evidence externally.” The lesson, she wrote in her emailed answers, “isn’t ‘don’t use commercial models.’ It’s ‘don’t make them a single point of failure.’”AI-enabled attacks rose 89% year-over-yearAutonomous AI-driven attacks are not limited to AI platforms. CrowdStrike’s 2026 Global Threat Report documented AI-enabled adversary operations increasing by 89% year over year, with average breakout times falling to 29 minutes. Enterprises running AI workloads in production with agentic access to their pipelines face similar exposure.Six control domains determined the blast radius and recovery speed at Hugging Face. Each one maps to a concrete action security leaders can take before the next autonomous-agent breach arrives.AI Pipeline Breach Response PlaybookControl DomainWhat BrokeMonday ActionDataset admission controlsTwo code-execution paths were exploited. No admission gate validated the dataset before it reached a processing worker. The data pipeline became the initial access infrastructure.Require sandbox execution and static analysis of all datasets before they reach workers. Block remote-code loaders and template-injection paths by default. Audit for any path granting code execution to untrusted content. Report to the board as a supply-chain risk.Worker-to-node privilege boundariesWorker isolation failed to prevent escalation to the node. The agent gained cluster credentials because the workload-infrastructure boundary was never enforced at container runtime.Enforce hard privilege boundaries between workers and nodes. Deploy container runtime security to prevent workload escape. Audit whether workers can reach node-level APIs or credential stores. Include in the next penetration test scope.Credential exposureCloud and cluster credentials harvested after node access. The scope was broad enough for lateral movement across multiple clusters over a weekend.Rotate credentials on a scheduled cadence and after any anomaly alert. Scope to the minimum cluster and service. Deploy monitoring that flags access from unexpected nodes at machine speed. Map blast radius for board reporting.Machine-speed detectionThousands of actions through short-lived sandboxes with self-migrating C2. AI-assisted anomaly detection surfaced the campaign after a weekend of lateral movement, per the disclosure.Calibrate detection for machine-speed patterns. Ensure high-severity alerts page responders in minutes, regardless of time. Audit SIEM rules for detecting thousands of short-lived executions within a single hour.Private AI forensic capacityCommercial APIs blocked forensic analysis. Guardrails screened query content, never analyst identity. Investigation ran on GLM 5.2 privately.Deploy a capable open-weight model on private infrastructure before an incident. Test against real forensic workflows. Ensure IR playbook includes fallback for when commercial APIs refuse. Document gap for cyber insurance.Autonomous-agent threat modelingThe campaign matched the forecast agentic-attacker scenario, but no threat model had operationalized it. LLM powering the agent is still unknown.Add autonomous AI agents as a distinct adversary class with machine-speed decision cycles. Run tabletop at agent speed. Present results to the board as evidence that timelines need recalibration. Include in the cyber insurance application.The board question is operational resilience“The question for directors is simple. What happens if one of our critical security tools becomes unavailable during the exact moment we need it most?” Baer framed that as operational resilience, not AI policy. She would have boards take that framing straight to management and press for specifics. “Have we actually exercised that fallback during tabletop exercises? How quickly can we switch during an incident?” Procurement needs to change alongside governance, starting with the questions buyers ask. Security teams evaluating AI vendors should ask about their process for authenticated incident responders, whether enterprise customers receive different handling during verified incidents, and whether models can be deployed privately. “Those questions belong alongside uptime, privacy, and compliance,” Baer said.“The biggest takeaway isn’t that safety guardrails are ‘bad.’ They’re doing what they were designed to do,” she argued. Her larger point is that the threat model itself has changed. “For decades, defenders had better tools than attackers because they operated inside trusted enterprise environments. With foundation models, both sides increasingly use the same capabilities, but one side is constrained by enterprise governance, policy, compliance, and safety controls, while the adversary simply downloads an uncensored open-weight model and keeps going. That’s a new kind of asymmetry,” she added. “The organizations that handle it best won’t necessarily be the ones with the most powerful AI. They’ll be the ones that architect AI as a resilient security capability rather than a single cloud service.”Hugging Face has contained the intrusion, rebuilt compromised nodes, rotated credentials, and reported the incident to law enforcement. The company recommends that all users rotate access tokens and review recent account activity. Mid-incident, Hugging Face found out whether its own AI tooling would be available, and the first answer was no. Security leaders running AI in production should find out in incident response planning instead, before an autonomous agent forces the test.

Presented by JumpCloudThe organizations losing confidence in AI are the ones most likely to get it right.Six months ago, 40% of IT leaders described their organizations as mature in AI deployment. Today that number is 23%. Before you read that as a setback, consider what it actually reflects.We recently surveyed 800 IT leaders across the U.S. and U.K. for our Q3 2026 trends report, and the data tells a consistent story: the organizations revising their self-assessment downward are overwhelmingly the ones that have moved AI agents from pilots into production. They’re not losing faith in AI. They’re running into the problems that only show up when agents are doing real work in real systems, and they’re being honest about what they found.That kind of honesty is harder to come by than it sounds, and it matters more than the confidence number itself.Deployment was the easy part84% of organizations plan to expand AI use in IT operations over the next 6 to 24 months, so the drop in confidence isn’t a retreat. What it reflects is a more accurate picture of what production actually requires.In a pilot, an AI agent does one thing in a controlled setting. In production, it accesses real systems, makes decisions that affect real workflows, and operates continuously, often without a human in the loop. The governance infrastructure that entails is materially different from what it took to get the pilot working. Most organizations built enough to ship. Fewer built enough to scale.The IT leaders revising their self-assessment are confronting questions they didn’t have to ask at the pilot stage: Can we see every agent running in our environment? Do we know what each one can access? If an agent behaved unexpectedly last week, how long would it take to find out? For most organizations, at least one of those answers is uncomfortable.The gap between perception and reality is where risk accumulatesThe graphic above captures the structural problem. Across confidence, governance, and autonomy, the same pattern holds: deployment is moving faster than the controls built around it.The organizations that have closed this gap share specific characteristics. They’ve consolidated their IT environments rather than adding tools to solve each new problem, because every additional platform creates another place where agent identity, access, and accountability can go unmanaged. They treat AI agents as governed identities rather than tolerated shadow processes. And they measure what AI actually produces, not just what it deploys.The payoff is tangible. Organizations in the top tier of our maturity model are five times more likely to report no barriers to expanding their AI agents than the average organization. They are not more cautious about AI. They are more confident in it, because they built the foundation that makes confidence earned rather than assumed.The governance gap has a specific shapeThe hardest problem in enterprise AI right now is not capability. It is accountability, and the data makes the specific failure point clear: non-human identity governance is the least adopted AI security practice we measured, in place at just 21% of organizations.Non-human identities now outnumber human users in 83% of organizations, and that population is growing fast. Yet most of those identities exist without the governance structures that every human employee has as a matter of course: no formal record, no named owner, no defined scope of access, no offboarding process when their purpose expires. They keep running. They keep accessing systems. They keep accumulating permissions. We call these Zombie Agents, and they are the service account problem of the AI era, operating at machine speed and in every department.The accountability gap is where real risk lives. When a human employee takes an action, there is an implicit accountability chain. When an autonomous agent takes an action, that chain breaks unless it has been deliberately engineered. Most organizations have not yet engineered it, and the gap between the autonomy agents are being granted and the oversight structures in place to manage them is widening every month.What the confidence drop is actually telling usWhen AI maturity confidence was uniformly high across the market, that was worth worrying about. It meant most organizations hadn’t yet run into the hard parts. A selective drop, concentrated among organizations actively running agents in production, means the market is developing a more accurate picture of what AI operations genuinely require.The organizations recalibrating are doing the work that makes long-term AI adoption possible: building identity infrastructure that covers agents alongside humans and devices, unifying the environments where governance needs to apply, and measuring outcomes rather than just counting deployments. They haven’t lowered their ambitions for AI. They have raised their standards for what it means to run it responsibly.84% of organizations plan to expand AI use over the next two years. The ones that will do it well are honest enough, right now, to admit what they haven’t yet built.JumpCloud’s Q3 2026 AI Readiness Research report (n=800 IT leaders, U.S. + U.K.) is available here. The report covers AI agent deployment stages, identity governance gaps, IT unification benchmarks, and budget realism across mid-market and enterprise organizations.Rajat Bhargava is CEO and Co-founder at JumpCloud.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.

This is a comprehensive list of the top Disaster Recovery as a Service providers. Use this guide to compare and choose the best solution for you. The post Top 5 Disaster Recovery Companies in 2026 appeared first on TechRepublic.

23andMe will pay $18 million to settle claims from 43 states over its 2023 data breach, which exposed genetic information tied to nearly 7 million people. The post 23andMe Agrees to $18M Settlement With 43 States Over 2023 Data Breach appeared first on TechRepublic.

Capital One on Thursday released VulnHunter, an open-source, agentic AI security tool that scans source code for exploitable vulnerabilities, maps out how an attacker would reach them, and proposes targeted fixes — all before a single line ships to production. The tool, built internally and now available on GitHub under an Apache 2.0 license, is one of the most ambitious attempts by a major financial institution to turn offensive AI capabilities into a public defensive resource.At a time when security teams are facing a rising tide of new AI threats, Capital One's decision to open-source the tool reflects an effort, according to CISO Chris Nims, to address "an increasingly brief window before sophisticated, next-generation AI attack capabilities become affordable and accessible to virtually every adversary."Capital One is not simply releasing another vulnerability scanner. VulnHunter introduces what the company calls an "attacker-first forward analysis" — a workflow in which the tool begins at the points where a real adversary would enter a system, such as APIs, network messages, or file uploads, and reasons forward through the application's logic to determine whether an exploit path actually survives the code's existing defenses. Conventional scanners typically work in reverse, flagging a dangerous-looking code pattern and then searching backward for a hypothetical attacker. That approach, security practitioners widely acknowledge, buries engineering teams under avalanches of false positives.VulnHunter attacks that problem head-on with a second innovation: a built-in "falsification engine" that tries to disprove its own findings before a developer ever sees them. After the tool surfaces a potential vulnerability, a structured reasoning workflow hunts for logical gaps, unsupported assumptions, and conditions that would prevent the attack from succeeding. Only findings the engine fails to rule out reach a human reviewer — and when they do, VulnHunter delivers not just an alert but a full explanation of the exploit path and a proposed code fix ready for engineering review.The tool currently runs on Anthropic's Claude Opus 4.8 model inside a Claude Code environment, though Capital One says the framework has the potential to work across other foundation models and coding harnesses.Why Capital One is giving the tool awayAsked why Capital One decided to open-source a tool this consequential, Nims pointed to the communal nature of the problem. "We felt an imperative to open-source VulnHunter because modern software supply chains are very connected, and the scale of the AI threat is larger than any single organization," Nims told VentureBeat. "Securing software and our digital environments is a shared foundation that benefits developers, enterprises, and the people who depend on the systems we all build. The defensive tools to address this reality need to be just as widely distributed, tested, and improved as the codebases they protect.""Rather than wait," he added, "we decided that the right response was to build a product that is purpose-fit for today's complex security landscape, and put it into the hands of defenders everywhere."Why Capital One believes open-sourcing VulnHunter strengthens everyone's defensesThe release nonetheless arrives against a backdrop the company knows well. On July 19, 2019, Capital One disclosed that an outside individual — later identified as a former Amazon Web Services employee named Paige Thompson — had gained unauthorized access to names, addresses, self-reported income, Social Security numbers, and linked bank account numbers belonging to credit card customers and applicants. The breach, which Capital One says occurred on March 22 and 23, 2019, was discovered only after an external security researcher flagged a configuration vulnerability through the company's Responsible Disclosure Program on July 17 of that year.The damage was sweeping. Approximately 100 million people in the United States and 6 million in Canada were affected. Roughly 140,000 Social Security numbers, about 80,000 linked bank account numbers, and approximately 1 million Canadian Social Insurance Numbers were compromised. The FBI arrested Thompson, and the government stated it believed the data had been recovered with no evidence of fraud. But the reputational and regulatory toll was enormous.In August 2020, the Office of the Comptroller of the Currency fined Capital One $80 million, finding that the bank had failed to adequately identify and manage risks as it migrated significant technology operations to the cloud. As Reuters reported at the time, the OCC's consent order cited insufficient network security controls, inadequate data loss prevention measures, and a board that failed to hold management accountable when internal auditing surfaced problems. The OCC also ordered Capital One to overhaul its operations and submit new cybersecurity plans for regulatory review.CyberScoop at the time called the incident "a cautionary tale for companies rushing to embrace new tech." Capital One's own CEO, Richard D. Fairbank, acknowledged the gravity of the moment. "While I am grateful that the perpetrator has been caught, I am deeply sorry for what has happened," Fairbank said at the time. "I sincerely apologize for the understandable worry this incident must be causing those affected and I am committed to making it right."Inside Capital One's decade-long open-source strategy — and what VulnHunter adds to it.What followed was not a retreat from technology but a doubling down — with security explicitly at the center.Capital One began releasing open-source projects in 2014 and declared itself an "open-source first" company in 2015 as part of a broader technology transformation that began over a decade ago. The company has continued to invest in software supply chain security, open-source governance, and AI-driven defense. In August 2022, Capital One joined the Open Source Security Foundation as a premier member, earning a seat on the organization's Governing Board. Chris Nims, then EVP of Cloud & Productivity Engineering, framed the move as a natural extension of the company's operating philosophy. "As a highly-regulated company, we are seasoned in managing compliance and governance and advocate for standardization, automation and collaboration," Nims said in the OpenSSF announcement.Behind that public commitment lay a substantial operational apparatus. Capital One's Open Source Program Office, now in its third iteration, manages open-source usage, contributions, and community building across the enterprise. The company has released more than 40 open-source projects and has made thousands of contributions to external open-source projects it depends on, according to the company. Those efforts address not just code dependencies but the entire software development lifecycle — DevSecOps tools, infrastructure, and the collaborative environments, both internal and external, that shape how software gets built and shipped.VulnHunter is the most consequential product of that multi-year effort — and the release positions open-source collaboration not as charity but as a competitive security strategy. "At the end of the day our goal is to make this product as broadly accessible as possible," Nims said. The company argues that modern software supply chains are so deeply interconnected that a single vulnerability in a widely used open-source component can cascade across thousands of enterprises simultaneously. Proprietary defenses, no matter how sophisticated, cannot address a problem that is fundamentally communal. By releasing VulnHunter under a permissive license, Capital One invites the global security research community to stress-test, extend, and improve the tool — effectively crowdsourcing its own defense infrastructure while strengthening the broader ecosystem.Inside VulnHunter's three-stage AI engine for finding exploitable codeFor engineering leaders evaluating VulnHunter, the technical architecture is where the tool's ambitions become concrete. The workflow unfolds in three distinct stages.In the first stage — attacker-first forward analysis — VulnHunter begins at the points where an external adversary would interact with a system: API endpoints, network message handlers, file upload interfaces. From each entry point, the tool reasons forward through application logic, tracing data flows, transformations, and internal security checkpoints to determine whether an attacker can actually reach a dangerous code path. This approach mirrors how a skilled penetration tester would probe a system, but automates the process at a scale no human team could match.The second stage is where VulnHunter departs most sharply from conventional scanners. After identifying a potential vulnerability, the falsification engine runs a structured reasoning workflow designed to disprove its own conclusion. It searches for assumptions that do not hold, logical gaps in the exploit path, and environmental conditions that would prevent an attack from succeeding. Findings that fail this internal challenge are discarded before any developer sees them. Capital One's explicit goal is to shift the developer's burden away from triaging false alarms — a perennial pain point that erodes trust in security tooling and slows development velocity.In the third stage, vulnerabilities that survive the falsification engine trigger an evidence-backed remediation workflow. VulnHunter gathers supporting evidence across the codebase, maps the complete surviving exploit path, explains the defect and the specific capabilities an attacker would gain, and generates targeted code changes for engineering review. The output is not a generic advisory but a concrete, context-aware patch proposal.Capital One says it validated VulnHunter internally before release, running it across thousands of repositories spanning tens of business areas. The company reports that the tool identified and remediated vulnerabilities with speed and efficiency that far exceeded what its teams previously achieved through manual triage.Why AI-powered attacks are forcing banks to rethink traditional cyber defensesVulnHunter arrives at a moment when the cybersecurity landscape is shifting beneath the feet of every enterprise. Capital One's announcement frames the urgency in stark terms: advanced AI models have "dramatically lowered the barrier for bad actors to discover and exploit vulnerabilities in software," and the window before sophisticated AI attack capabilities become affordable and accessible to virtually every adversary is shrinking rapidly."Safeguarding information is essential to our mission and our role as a financial institution," Nims told VentureBeat. "We have invested heavily in cybersecurity and will continue to do so to stay ahead of today's evolving threat landscape."The company's own AI security researchers have been tracking these trends closely. At NeurIPS 2024 in Vancouver, Capital One's team presented research and curated a list of nearly 100 papers spanning LLM safety, adversarial resilience, jailbreak attacks, and synthetic data generation. The papers they highlighted — including work on multi-agent defense frameworks, automated red-teaming, and guardrail classifiers — paint a picture of an arms race in which offensive and defensive AI capabilities are co-evolving at breakneck speed.Several of those research themes map directly onto VulnHunter's architecture. The falsification engine echoes the adversarial defense strategies explored in papers like "BackdoorAlign," which demonstrated that embedding a structured safety mechanism into a small number of training examples could recover a model's safety alignment without degrading performance. The attacker-first forward analysis reflects the philosophy of "WildTeaming," a framework that collects and analyzes real-world jailbreak attempts to build more resilient models. And VulnHunter's emphasis on minimizing false positives parallels the goals of "GuardFormer," a guardrail classifier that outperformed GPT-4 on safety benchmarks while running 14 times faster.The thread connecting all of this work is a conviction that traditional, reactive security — monitoring networks, patching known vulnerabilities, responding to incidents after they occur — is no longer sufficient when adversaries can use AI to discover and exploit zero-day vulnerabilities at machine speed. The only durable defense, Capital One argues, is to find and fix the vulnerabilities in your own code before attackers find them first.What Capital One's cloud security journey reveals about the entire banking industryCapital One's cloud journey also illuminates a broader reckoning across financial services. When Capital One moved aggressively to Amazon Web Services in the mid-2010s, it was a rarity among major banks. Most financial institutions simply did not trust third parties to store their most sensitive data. Capital One's CIO at the time, Rob Alexander, publicly championed the cloud as more secure than the bank's own data centers — a claim that the 2019 breach complicated considerably.The CyberScoop report from that period captured the tension within the industry. W. Patrick Opet, managing director of cybersecurity at JP Morgan Chase, described a cultural shift in banking from prioritizing traders to prioritizing developers: "Now, it's 'Focus on the developer, turn everything into code, and automate everything.'" Mark Nicholson, Deloitte's cyber leader for the financial industry, noted that the pressure to move quickly was exposing "weaknesses in the development methodology." And the breach itself was a reminder that even as Chase spent $600 million annually on cybersecurity, relatively simple vulnerabilities — like the Apache Struts bug that enabled the Equifax breach — could undercut massive investments in data protection.Seven years later, the industry has largely followed Capital One into the cloud, and the security challenges have only intensified. The question is no longer whether to use cloud infrastructure but how to secure the software that runs on it. VulnHunter represents part of Capital One's answer to that question: rather than relying solely on network-level controls and perimeter defenses, push security directly into the code itself, at the moment it is written. The open-source release also carries implicit competitive pressure. If VulnHunter gains traction among developers and security teams, it could set a new baseline for what enterprise security tooling is expected to do — and force rival banks, fintechs, and cloud providers to match or exceed its capabilities.Whether VulnHunter lives up to that ambition will depend on adoption, community engagement, and the tool's real-world performance against the increasingly sophisticated AI-powered attacks it was designed to counter. But the release itself tells a story that extends well beyond any single tool or any single company. In 2019, a misconfigured web application firewall — exploited alongside an overly permissive cloud access role — exposed the records of roughly 100 million Americans and made Capital One a byword for cloud misconfiguration risk. In 2026, the same institution is open-sourcing an AI-driven defense built for a new generation of threats — and betting that the best way to protect its own code is to help the entire industry protect theirs.

Microsoft is reportedly developing Project Perception, a lower-cost AI security tool that would use multiple models to identify enterprise vulnerabilities. The post Microsoft’s ‘Project Perception’ Could Challenge Anthropic’s Mythos in AI Security appeared first on TechRepublic.

Zoom patched a critical Windows flaw that could enable remote account takeover, along with three high-severity privilege-escalation vulnerabilities. The post Critical Zoom Flaw Could Let Attackers Take Over Windows Accounts appeared first on TechRepublic.

The FCC has proposed requiring identity verification for phone activation, a move supporters say will fight fraud while critics warn it threatens privacy. The post New FCC Proposal Pits Phone Privacy Against Fraud Prevention appeared first on TechRepublic.

Apple faces a proposed class action alleging a Hide My Email flaw could expose users’ real addresses despite the company’s privacy claims. The post Apple Sued Over Hide My Email Privacy Claims appeared first on TechRepublic.

Catch up on the week's biggest tech news, including Google's app store shakeup, Apple's AI expansion, OpenAI's hardware plans, and critical security threats. The post AI Hardware, App Store Shifts, and Security Scares Define This Week in Tech appeared first on TechRepublic.

1Password's new Claude integration lets AI agents sign in to websites without exposing passwords, adding user approval and credential protection. The post 1Password Lets Claude Sign In Without Revealing Passwords appeared first on TechRepublic.

Hugging Face says an autonomous AI agent carried out a cyberattack against its production systems, highlighting the growing role of AI in offensive and defensive cybersecurity. The post Hugging Face Says Autonomous AI System Executed Multi-Stage Cyberattack appeared first on TechRepublic.

ClickLock can shut down Mac apps for more than three days while pressuring users to enter a password and stealing sensitive account data in the background. The post ClickLock Mac Malware Traps Users in a Three-Day Password Loop appeared first on TechRepublic.

EU rules will make Google share anonymized search data and give rival AI assistants broader access to Android features across Europe. The post EU Orders Google to Open Android AI Features, Share Search Data With Rivals appeared first on TechRepublic.

A report by Drata recently analyzed survey responses from security and IT professionals on AI adoption trends.

Across 107 enterprises, AI infrastructure spending is accelerating well ahead of the ability to see or steer its economics. Most organizations run their AI on a familiar base of hyperscalers and model-provider APIs, yet the next dollar is aimed at specialized compute almost none of them use today; a majority intend to switch or add providers within the year, many within a quarter. Buying decisions turn on integration and total cost of ownership rather than headline token price — which is fortunate, because most enterprises cannot yet see their unit economics clearly: GPUs sit at half utilization or less, and fewer than half rigorously track what their compute actually costs. The result is a compute gap — heavy, fast-moving investment running ahead of the visibility needed to control it.This wave of VentureBeat Pulse Research examines enterprise AI infrastructure and compute: where organizations are in their deployment journey, what they run AI on today, how satisfied they are, what would make them switch, where they plan to evaluate their investments, and — most revealingly — how well they can measure and control the economics of the compute underneath it all.The central finding is a compute gap — the distance between how aggressively enterprises are investing in AI infrastructure and how little of its economics they can see. Only about one in five (21%) run AI in production at scale, yet spending intentions are outrunning that maturity: the single largest planned area enterprises plan to evaluate over the next year is AI-specialized clouds (45%), a layer almost none of these enterprises use today. Meanwhile the compute already in place runs cold — 83% report GPU utilization of 50% or less — and fewer than half (44%) can rigorously track what their AI compute costs. Enterprises are buying more infrastructure faster than they can account for what they already own.Enterprises are not settled on their infrastructure vendors, either: A clear majority (64%) plan to switch or add an infrastructure provider within twelve months, and 38% within the next quarter — unusually high churn intent for a category this foundational. When they choose, they choose on integration with the existing stack (41%) and total cost of ownership (35%), not on headline price: cost per million tokens is the deciding factor for just 8%. And the frontier constraint that will shape the next round of decisions — the shift from GPU compute to memory bandwidth as inference scales — is barely on the radar, with roughly one in five enterprises either unaware of it or yet to address it.MethodologyVentureBeat fielded this survey as part of its ongoing Pulse Research series, this survey focused on enterprise AI infrastructure, compute, and inference economics. Responses are filtered to organizations with more than 100 employees (n=107; the survey’s smallest size band, 1–100 employees, is excluded), drawn from a single Q2 2026 (June) wave. Because this is one wave rather than a pooled multi-month sample, the report reads cross-sectionally and does not infer month-over-month trends. Several questions were multiple-select, so those shares can sum to more than 100%.By organization size the sample concentrates in the mid-market: 101–250 employees (36%) and 251–1,000 (27%) lead, with 1,001–5,000 (22%), 5,001–10,000 (8%), and 10,001+ (7%) above them. By role it spans managers (38%), individual contributors (28%), VPs and directors (19%), and the C-suite (13%); on purchasing authority it is buyer-credible, with 45% final decision-makers and another 30% recommenders or influencers for AI solutions. Technology/Software is the largest industry at 26%, followed by Healthcare/Life Sciences (15%), Financial Services (13%), and Retail/E-commerce (12%).At 107 respondents the sample is large enough to read directionally but should be treated as a directional signal rather than a precise measurement; it is self-selected and is not a probability sample. It also skews toward the mid-market and toward earlier-stage adopters, so it is best read as the view from organizations actively building out AI infrastructure rather than from the largest hyperscale operators.Finding 1: Ambition outpaces productionOnly one in five run AI in production at scaleWe asked where organizations sit in their AI deployment journey. Most are still building toward production rather than operating at scale.The maturity curve is front-loaded. Three-quarters of enterprises (76%) are either experimenting or running only some workloads in production, and just 21% describe AI in production at scale. This matters for everything that follows: the infrastructure decisions in this report are being made largely by organizations still early in deployment, whose compute footprint — and whose costs — are about to grow. The evaluation and switching intentions in Findings 3 and 4 are the leading edge of that build-out, not the settled preferences of operators who have already found what works.Finding 2: Enterprises run on hyperscalers and model APIsThe specialized GPU clouds barely register — todayWe asked which providers and platforms enterprises currently use to run their AI. The answer is a familiar one: the incumbents.The current stack is hyperscaler-and-API. Google Cloud leads at 48%, and the general-purpose clouds (Google, Microsoft, AWS, Oracle) together with the major model APIs (Gemini, OpenAI, Anthropic) account for essentially all current deployment. The specialized “neocloud” GPU providers that dominate AI-infrastructure headlines — CoreWeave, Lambda, Crusoe, Nebius and peers — register at or near zero among these enterprises today. Only 6% run their own on-prem GPU clusters and 4% a custom open-source stack. Enterprises are, for now, running AI on the providers they already buy from — which makes the evaluation intentions in Finding 3 all the more striking.(A note on reading these shares. As described in the methodology section, this sample is self-selected and skews mid-market, and this question counted every provider a respondent uses — an average of 2.1 selections each — so the figures measure presence in the stack rather than spending or primary status. A sample built this way will show a different provider mix than a spend-weighted census of the broader market; Google's strength here, for example, is consistent with its long-standing position among smaller enterprises building on AI. Read these shares as a portrait of what this AI-active cohort runs today, and treat gaps between these figures and industry-wide market share estimates as a property of the sample rather than a contradiction of either.)Finding 3: The next dollar goes to infrastructure they don’t yet runAI-specialized clouds top the evaluations listWe asked where enterprises planned to evaluate AI infrastructure over the next 12 months. Their answers point away from the stack they run today.Here is the report’s sharpest tension. The single most-cited planned evaluation area — AI-specialized clouds, at 45% — is the very category almost none of these enterprises use today (Finding 2). Nearly a third (32%) intend to evaluate non-Nvidia accelerators, and 28% in next-generation Nvidia silicon; even decentralized compute networks (16%) and sovereign compute (11%) draw meaningful interest. Read against current usage, this is not incremental — it is the leading edge of a re-platforming. The direction-of-travel question tells the same story: every infrastructure approach is net-expanding, but specialized AI clouds carry the highest net momentum (+24), edging out even the hyperscalers (+22). Enterprises are preparing to move a meaningful share of AI compute off the general-purpose cloud.This continues a trend we saw in our April-May survey wave. Back then, usage of the AI-specialized clouds was equally marginal — CoreWeave at 3%, Lambda at 4%, Crusoe at 2% of enterprises. When we asked enterprises what change they planned in their AI infrastructure strategy over the next twelve months, the most-cited answer was moving workloads to specialized AI clouds, at 33%. Asked in April-May which emerging compute option they were most likely to evaluate AI-specialized clouds again drew the most responses. Two waves, two differently worded questions, one consistent picture: the type of cloud enterprises are most eager to assess is the type they have barely begun to use.Finding 4: A switching wave is buildingSix in 10 plan to change providers within a year — many within a quarterWe asked whether and when enterprises plan to switch or add an infrastructure provider. Very few intend to stand still.For a category as foundational as compute, this is a remarkable amount of intended movement. Only 36% have no plans to change, meaning a clear majority (64%) intend to switch or add a provider within twelve months — and 38% within the next quarter alone. Where that interest points is telling: the providers drawing the most switching consideration are again the incumbents — Microsoft Azure and Google Cloud (33% each), OpenAI (30%), and Gemini (22%) — which suggests much of the near-term movement is reshuffling among the majors and consolidating spend rather than defecting to new entrants. The neocloud interest in Finding 3 is a 12-month evaluation thesis; the switching in the next quarter is mostly incumbents trading share.(Method note: Respondents who selected both "no plans to change" and a specific switching window are counted as switchers, on the logic that naming a timeframe is the more specific answer; three respondents were reclassified under this rule.)Finding 5: Nobody buys on token priceIntegration and total cost of ownership decide — not sticker priceWe asked what matters most when enterprises select an AI infrastructure provider. Headline price finished last.Enterprises do not buy AI infrastructure on pricing, which is the place vendors compete on hardest. Integration with the existing stack (41%) and total cost of ownership (35%) dominate, while the headline metric — cost per million tokens — is the deciding factor for just 8%, dead last. The pattern is coherent: buyers are optimizing for how a provider fits and what it truly costs to operate, not for the advertised unit rate. It also foreshadows Finding 7 — enterprises say TCO matters most, yet most cannot yet measure it rigorously. The stated priority and the measured capability are out of step.Finding 6: Expensive GPUs, idle most of the time83% report GPU utilization of 50% or lessWe asked what share of their GPU capacity enterprises actually utilize. The answer is a well-known but rarely quantified inefficiency.Disclosure: Band percentages count every selection against all 107 qualified respondents; 14 respondents selected more than one band, so bands overlap. At the respondent level, 83 of the 100 GPU-operating enterprises reported utilization at or below 50%The compute already in place runs cold. Adding the bands at or below half capacity, 83% of enterprises that operate GPUs report utilization of 50% or less, and nearly half (49%) run at 25% or below. Only 12% clear the 50% mark, and a further 8% do not measure utilization at all. Idle accelerators are expensive accelerators, and this is the clearest single measure of the compute gap: enterprises are planning to buy more GPUs and specialized compute (Finding 3) while the capacity they already own sits substantially unused. The efficiency headroom in the current fleet is large — and largely unmeasured.Finding 7: Spending fast, measuring slowlyFewer than half rigorously track what their compute costsWe asked whether enterprises can quantify the cost and return of their AI infrastructure spend, and how satisfied they are with what they run. Confidence in the ledger lags the spending.Measurement trails money. Fewer than half of enterprises (44%) rigorously track the cost and return of their AI compute; the majority track only partially (39%), cannot quantify it yet (20%), or have not prioritized it (6%). That gap is consequential given Finding 5, where total cost of ownership was the second-ranked buying criterion — enterprises are choosing providers on an economic basis they mostly cannot yet measure. Satisfaction with current infrastructure is moderately positive but not enthusiastic: on a five-point scale, overall satisfaction averages 4.0, with ease of implementation (3.8) and value for money (3.9) trailing slightly — the softness landing, tellingly, on cost. Enterprises are spending quickly and accounting slowly.Finding 8: The next bottleneck few are watchingAs inference shifts from compute to memory, the field scattersFinally, we asked how enterprises would address the emerging constraint in large-scale inference — the shift from GPU compute to memory, specifically KV-cache capacity. The responses reveal a frontier that is not yet a priority.The memory frontier is real but barely governed. Asked which approach they would rely on as the binding constraint in inference shifts from compute to memory bandwidth, enterprises scatter: Dell leads at 31%, Nvidia follows at 16%, and the rest fragments across storage vendors, open-source tooling, and model-level efficiency techniques. Most telling is that roughly one in five (18%) either do not recognize the constraint or have not begun to address it. For a shift that will reshape inference cost and architecture, this is an early and unsettled market — and, consistent with the measurement gap in Finding 7, one where many enterprises simply do not yet have a view. It is the next chapter of the compute gap, arriving before most have closed the current one.The bottom line: A compute gap that faster spending will widen, not closeOrganizations with more than 100 employees are investing in AI infrastructure faster than they can measure it. Most are still early in deployment, yet their spending intentions point past their current stack — toward specialized clouds and alternative accelerators almost none of them run today — and a clear majority intend to change providers within the year. They buy on integration and total cost of ownership rather than headline price, which is rational; the difficulty is that most cannot yet see those economics clearly.The visibility gap is concrete. The GPUs enterprises already own run at half utilization or less for the overwhelming majority, and fewer than half can rigorously track what their compute costs or returns. Satisfaction is decent but unenthusiastic, softest on value for money — the dimension hardest to judge without measurement. And the next constraint, the shift from compute to memory in large-scale inference, is arriving while most enterprises are still unaware of it. At 107 respondents in a single Q2 wave this is a directional read, skewed toward the mid-market and earlier-stage adopters — but the direction is consistent: the appetite to spend is running well ahead of the instrumentation to spend well. The compute gap is not a capacity problem that more hardware will solve on its own; it is, first, a problem of seeing what the hardware already costs. The open question for later waves is whether enterprises build that visibility before the re-platforming arrives — or buy the next layer of infrastructure as blind to its economics as the last.Based on survey responses from 107 qualified enterprise respondents (100+ employees), drawn from a single Q2 2026 (June) wave. Because this is one wave rather than a pooled multi-month sample, the results read cross-sectionally rather than as a month-over-month trend, and at 107 respondents this is a directional signal rather than a precise measurement — the sample is self-selected, skews mid-market, and leans toward earlier-stage adopters rather than the largest hyperscale operators. Respondents include managers, individual contributors, VPs/directors, and the C-suite, with buyer-credible purchasing authority, across Technology/Software, Healthcare/Life Sciences, Financial Services, Retail/E-commerce, and other industries.

Across 107 enterprises, AI agents are being given real access to systems and data while the controls meant to contain them lag behind. More than half have already had a confirmed agent security incident or a near-miss; only about a third give every agent its own scoped identity, and most agents still share credentials; and only three in ten isolate their highest-risk agents. The security stack is overwhelmingly borrowed from the model providers and hyperscalers rather than purpose-built for agents, spending remains a thin slice of the security budget, and enterprises are evenly split on whether their defenses are keeping pace with AI-enabled attackers. The result is an agent security gap — autonomous agents proliferating faster than the identity, isolation, and enforcement controls needed to hold them.This wave of VentureBeat Pulse Research examines how enterprises secure their AI agents: what tooling they run, how they manage agent identity and isolation, what has already gone wrong, how much they spend, and whether they believe their defenses are keeping pace with AI-enabled attackers.The central finding is an agent security gap — the distance between the autonomy enterprises are granting their agents and the controls in place to contain them. More than half of organizations (54%) have already experienced a confirmed agent security incident (18%) or a near-miss caught before harm (36%). The structural weakness beneath those numbers is identity: only about a third (32%) give every agent its own scoped, managed identity, while the rest report that some agents share credentials or that agents mostly run on shared API keys and human or service-account credentials. When agents share credentials, a single compromised or over-permissioned agent carries a wide blast radius — and only three in ten enterprises (30%) isolate their highest-risk agents in sandboxes to bound that radius.What makes the gap notable is how comfortable enterprises are inside it. The security stack is overwhelmingly provider-native — OpenAI’s guardrails (51%), Google’s and Microsoft’s cloud controls, and Anthropic’s managed-agent controls dominate, while the dedicated agent-security specialists barely register — and satisfaction with that borrowed stack is high, averaging 4.2 out of 5. Yet spending remains a thin slice of the security budget, only a third of enterprises believe their AI defenses are ahead of AI-enabled attackers, and a clear majority plan to change tooling within the year. Enterprises are satisfied with controls they are simultaneously preparing to replace.MethodologyVentureBeat fielded this survey as part of its ongoing Pulse Research series, this instrument focused on enterprise agent security — the tooling, identity, isolation, and enforcement controls organizations use to secure autonomous AI agents. Responses are filtered to organizations with more than 100 employees (n=107; the survey’s smallest size band, 1–100 employees, is excluded), drawn from a single June 2026 wave. Because this is one wave rather than a pooled multi-month sample, the report reads cross-sectionally and does not infer month-over-month trends. Several questions were multiple-select, so those shares can sum to more than 100%.By role the sample is senior and buyer-credible: 45% are final decision-makers for AI purchases and another 30% recommenders or influencers. Managers (43%), individual contributors (24%), VPs and directors (15%), and the C-suite (11%) make up the seniority mix. By organization size the sample is mid-market-weighted: 251–1,000 (42%) and 101–250 (25%) employees lead, with 1,001–5,000 (19%), 5,001–10,000 (8%), and 10,001+ (7%) above them. Technology/Software is the largest industry at 23%, followed by Manufacturing (15%), Retail/E-commerce (14%), and Healthcare/Life Sciences (13%).At 107 respondents the sample is large enough to read directionally but should be treated as a directional signal rather than a precise measurement; it is self-selected and is not a probability sample. It skews toward the mid-market, so it is best read as the view from organizations actively standing up agent security rather than from the largest operators.Satisfaction ratings are computed on the respondents who answered each rating question; the overall satisfaction score reflects 82 of the 107 qualified respondents.Finding 1: The incidents are already hereMore than half have had an agent security incident or near-missWe asked whether organizations had experienced an agent security incident — a confirmed breach, or a near-miss caught before harm. Most that run agents in production had.This is the report’s defining number. More than half of organizations (54%) have already had an agent security event — 18% a confirmed incident and 36% a near-miss caught before it caused harm. Only 42% report nothing, and a small remainder either run no agents in production or don’t track such events. That so many report near-misses rather than only confirmed incidents is telling: enterprises are catching problems, but they are catching them close to the edge. The controls examined in the rest of this report — identity, isolation, enforcement — are what determine whether the next near-miss stays a near-miss.Exposure scales with company size, but containment does not. The incident-or-near-miss rate rises from 49% in the mid-market (companies with 101-1,000 employees) to 63% at larger enterprises (above 1,000 employees), while sandbox isolation of high-risk agents falls from 35% to 20%, and satisfaction with security tooling drops from 4.36 to 3.97. The organizations running the most agents across the most systems carry the most incidents and the least of the one control that bounds an incident's blast radius.Finding 2: The identity gapOnly a third give every agent its own scoped identityWe asked how enterprises manage the identity of their AI agents — whether each agent has its own credentials, or agents share them. Full per-agent identity is the exception.Rolled together, the overlapping answers show 69% of enterprises (74 of 107) with credential sharing somewhere in the agent fleet. Identity is the structural weakness beneath the incidents. Only about a third of enterprises (32%) give every agent its own scoped, managed identity — the precondition for least-privilege access and clean attribution. Nearly half (48%) say some agents have scoped identities but many still share credentials, and another 32% say agents mostly run on shared API keys or borrowed human and service-account credentials. (Respondents could describe more than one pattern across their agent fleet, so these overlap.) The consequence is direct: when agents share credentials, an over-permissioned or compromised agent can act with far more reach than intended, and forensics after an incident cannot cleanly tell which agent did what. The non-human identity problem — giving every agent its own governed identity — is the single largest unfinished piece of enterprise agent security.Moreover, a company’s agent credential posture is correlated with incidents. Organizations with credential sharing anywhere in the fleet were hit — with an incident or a near-miss in the past twelve months — at 63.5% (47 of 74). Organizations where every agent carries its own scoped identity were hit at 40.9% (9 of 22). The fully-scoped group is small, so for now the relationship is an association rather than proven causation, and the gap is concentrated in the mid-market — but within a single survey, a twenty-three point difference in incident rate suggests significance.Finding 3: Observe and enforce, but rarely isolateOnly three in 10 sandbox their highest-risk agentsWe asked what an organization’s agent security posture looks like in practice — whether they observe, enforce, isolate, or some combination. The control that bounds damage is the least common.Monitoring and enforcement are reasonably common; containment is not. Roughly half of enterprises observe agent activity (47%) or enforce scoped permissions at runtime (49%), but only 30% isolate their highest-risk agents in sandboxes that bound the blast radius when the other controls fail. That ordering is backwards from a defense-in-depth standpoint: observation tells you what happened, enforcement tries to prevent it, but isolation is what limits the damage when prevention fails — and it is the control enterprises have adopted least. Combined with the identity gap in Finding 2, the picture is of agents that are watched and permissioned but rarely boxed in, which is precisely the configuration in which a single failure propagates.Finding 4: Security runs on borrowed, provider-native controlsGuardrails from OpenAI, Google and Microsoft dominate; specialists barely registerWe asked which agent security tooling enterprises use, and which is their primary layer. The answer favors the model providers and hyperscalers over the dedicated security vendors.Enterprises are securing agents with tools that came bundled with their models and clouds. OpenAI’s guardrails lead at 51%, followed by Google’s and Microsoft’s cloud-native controls and Anthropic’s managed-agent controls — and when asked to name their single primary security layer, 82% name one of these provider-native offerings. The purpose-built agent-security category — Palo Alto’s Prisma AIRS, CrowdStrike, Cisco AI Defense, Zenity, HiddenLayer, Check Point’s Lakera, Okta for AI Agents, non-human identity platforms — barely registers, each in the low single digits, and only 5% run no dedicated tooling at all. As with retrieval and evaluation elsewhere in this series, the provider bundle is winning the default: enterprises reach first for the guardrails their platform ships, and the independent security layer that would address the identity and isolation gaps has not yet been adopted at scale.The provider-default pattern is consistent across both Q2 survey waves. In April–May (n=110), usage was led by the same names — OpenAI's controls at 26%, Azure at 15%, AWS at 14%, Google at 12% — with every dedicated agent-security specialist at 3% or below and one in ten using no dedicated tooling at all. The common finding from the two surveys: Enterprises are defaulting to the solutions provided by the platform they’re using, and the specialist category vendors have yet to become big players here.(A note on reading these shares. As described in the methodology section, the respondent sample is self-selected and skews mid-market, and the usage question counted every vendor or approach a respondent has in place — so the figures measure presence in the security stack rather than spending or exclusivity. Individual vendor percentages therefore carry all the usual sample caveats. The structural pattern, however, held across both Q2 waves on two differently worded questions: provider-native and hyperscaler controls lead, and dedicated agent-security specialists remain in low single digits. Read the individual shares loosely and the pattern with confidence.)Finding 5: And enterprises are comfortable with itSatisfaction is high, even as incidents mount and identity lagsWe asked how satisfied enterprises are with their current agent security tooling. The comfort is notably out of step with the exposure documented above.Satisfaction with agent security tooling is high — 4.2 out of 5 overall, and 4.1 for value for money — among the most positive readings in this series. That is the striking part: enterprises are highly satisfied with a stack that is mostly borrowed provider guardrails, even though more than half have already had an incident or near-miss and only a third give their agents scoped identities. The comfort appears to rest on the convenience and low friction of provider-native controls rather than on demonstrated containment. It is a false comfort in the making — the same enterprises expressing satisfaction are, as Finding 8 shows, a clear majority planning to change tooling within the year, which suggests the confidence is thinner than the score implies.Finding 6: Budgets haven’t caught upMost spend under a tenth of the security budget on agentsWe asked what share of the security budget enterprises allocate to securing AI agents. For a fast-emerging risk, the allocation is modest.Spending on agent security is still a thin slice. The most common allocation is 6–10% of the security budget (46%), and a third of enterprises (34%) spend 5% or less; only a quarter (24%) devote more than a tenth. Given the incident rate in Finding 1 and the identity and isolation gaps in Findings 2 and 3, the budget looks like a lagging indicator — the risk has arrived faster than the funding to address it. The enterprises spending more than a tenth of their security budget on agents are a distinct minority, and they are likely the ones building the scoped-identity and isolation controls the rest have not.Finding 7: The arms race is even, at bestOnly a third think their AI defenses are ahead of AI-enabled attackersWe asked how enterprises assess the balance between their AI-enabled defenses and AI-enabled attackers. Confidence is far from settled.Enterprises are split on whether they are winning. Only about a third (35%) believe their AI-enabled defenses are ahead of AI-enabled attackers; the rest are less sure — 32% call it roughly even, 21% think attackers are ahead, and another 21% say it is too early to tell. Taken together, a clear majority (53%) rate the balance as even or tilted toward the attacker. That uncertainty sits uneasily beside the high satisfaction of Finding 5: enterprises are content with their tooling yet unconvinced it is winning the contest it exists to win. In a domain where the offense is also compounding with AI, an even race is not a comfortable place to be.Finding 8: A security reshuffle is comingNearly six in 10 plan to adopt or switch tooling within a yearWe asked whether enterprises plan to adopt a new, additional, or replacement agent security solution, and which they are considering. Few intend to stand pat.The security stack is not settled. While 41% have no plans to change, a clear majority (59%) intend to adopt a new, additional, or replacement agent security solution within twelve months, and 29% within the next quarter — a strong signal that, high satisfaction notwithstanding, enterprises know the current stack is provisional. Incidents are what start the buying cycle. Among organizations that have been hit, 42.1% plan to adopt, add, or replace agent security tooling within the next ninety days, against 14.0% of organizations with no incident — and after a confirmed incident it becomes majority behavior, at 52.6%. Getting hit also changes the threat assessment: 33.3% of hit organizations say AI-armed attackers are ahead of their defenses, against 8.0% of the unhit. Experience, in this data, is the strongest predictor of both urgency and pessimism.The consideration set still leans provider-native (OpenAI 34%, Google 30%, Anthropic 29%, Azure 25%), but the dedicated security vendors — Cloudflare, Cisco, Palo Alto, Okta, Check Point’s Lakera — draw early interest in the mid-to-high single digits, more than their current footprint. What the shopping does not yet include is the identity layer specifically. Twelve percent of the respondents include an agent-identity product — Okta for AI Agents, Microsoft Entra Agent ID, or a non-human identity platform — anywhere in their consideration set, and among the credential-sharing organizations that have already had an incident, identity consideration is essentially unchanged, at roughly one in ten. The control most directly implicated by the incident data is the one largely missing from the purchase plans. Whether this wave hardens the provider-native default or finally opens the door to purpose-built agent security — the identity and isolation controls the incidents call for — is the question this series will keep tracking.The bottom line: A security gap that autonomy will test firstOrganizations with more than 100 employees are giving AI agents real reach into systems and data while securing them with controls built for something else. More than half have already had an incident or near-miss; only a third give every agent its own scoped identity, and most still share credentials; only three in ten isolate their highest-risk agents; and the stack doing this work is overwhelmingly borrowed from the model providers and hyperscalers rather than purpose-built for agents.The uncomfortable pairing is confidence with exposure: satisfaction with the current tooling is among the highest in this series, yet spending is a thin slice of the security budget, only a third believe their defenses are ahead of AI-enabled attackers, and a clear majority are already planning to replace what they have. At 107 respondents in a single wave this is a directional read, skewed toward the mid-market — but the direction is clear: agent adoption is running ahead of agent security, and the controls that matter most when something fails — scoped identity and isolation — are the ones enterprises have built least. The agent security gap is not a coverage problem that a provider guardrail will close on its own; it is a problem of identity, isolation, and enforcement built for autonomous software. The open question for later waves is whether enterprises close it deliberately — or whether a confirmed incident closes it for them.Based on survey responses from 107 qualified enterprise respondents (100+ employees), drawn from a single June 2026 wave. This is a directional read, not a precise measurement — the sample is self-selected and skews mid-market, so it's best read as the view from organizations actively standing up agent security rather than from the largest operators. Respondents are senior and buyer-credible (45% final decision-makers, 30% recommenders/influencers), spanning managers through the C-suite, and drawn primarily from Technology/Software, Manufacturing, Retail/E-commerce, and Healthcare/Life Sciences.

The biggest data breaches of 2026 so far, ranked by impact, with details on exposed data, affected users, and what readers should do next. The post The Biggest Data Breaches of 2026 So Far, Ranked by Impact appeared first on TechRepublic.

Presented by Ping Identity Enterprises need to treat zero trust security architecture as an immediate requirement for AI agents rather than a long-term goal, says Andre Durand, CEO and founder of Ping Identity. Zero trust, the security model built on the assumption that no user, device, or system should be automatically trusted, requires continuous verification before every action rather than a single check at login. Agentic AI has profoundly compressed the risk timeline enterprises must manage, demanding that permission decisions be evaluated in real time.type: embedded-entry-inline id: 1Ieiy1KhHNWZE5KVqNdA1GThat compression shows up in how permissions accumulate. Every time an employee approves an AI agent's request for access to a company drive, a database, or a code repository, the enterprise hands over a sliver of control that looks routine in isolation. Across thousands of agents making thousands of requests, those approvals accumulate into an exposure that most existing security architectures were never built to measure."The rise in desire to use agents right now, and the speed of agentic, is highlighting the need to move faster on the principles of zero trust," Durand says. "Agents just move faster, full stop. A human compromise might be measured in minutes or hours, sometimes days. At agentic speed, a thousand actions could happen in five minutes."Why zero trust is now urgent for agentic AIThat difference in velocity changes how enterprises need to think about permissions. Two variables matter: the surface area of access an agent is granted and the duration that access remains valid. Traditional identity and access management tends to grant broad permissions and leave sessions open for extended periods because the human using them moves at human speed. Zero trust, in contrast, collapses both variables at once by narrowing access down to what is strictly necessary and revalidating it continuously, rather than once at login."Zero trust really just says, just enough, just in time," Durand says. "It's your next action that we care about. We're moving identity from an era where access was our runtime control point — meaning were you logged in, did you have a session — toward the decision that sits behind that login."Why agents must be treated as first-class identitiesThat shift to decision-based control has direct implications for how agents should be provisioned in the first place. The common practice of letting an agent operate under a cloned human login or a shared service account doesn't work, Durand says. "Each agent should have its own identity," he explains. "It should not be impersonating the human. It can act on behalf of the human, we could explicitly delegate authority to an agent, but we don't want to blur the lines between the human taking action and the agent taking action."And beyond that is another concern: the shared secrets, API keys in particular, that many service accounts still rely on. For example, the habit of embedding keys directly in source code, where they can be committed accidentally and exposed, is a convenient but weak security pattern that agentic workflows make considerably riskier. Building service account architectures that let agents authenticate without relying on those shared credentials or other long-lived standing access is now an urgent priority rather than a long-term cleanup project.Where enterprises can enforce zero trust policiesEnforcing any of this in practice requires identifying where policy can actually be applied. Several existing choke points, including API gateways and the agent gateway sitting in front of MCP servers, offer practical locations where enterprises can inspect what an agent is requesting and apply policy rules before granting it."Those policies could leverage real-time risk and fraud signals, and then enforce, deterministically, what the agent can do when it interacts with these systems," Durand explains.The goal is to move authorization from something decided once at login to something evaluated at the moment of every consequential action, such as an agent attempting to commit code to a repository. Instead of carrying a standing permission to write to GitHub, the agent's request would be checked against context and policy at that specific moment, closing the window of trust down to the scope of a single action.Stopping AI agents from rewriting their own permissionsThat model becomes especially important given how agents can behave once they are already inside a system — for example, coding agents that have acknowledged, when questioned, either ignoring a specific guardrail entirely, or attempting to rewrite the permissions they were given."Who's watching the watcher? Zero trust needs to apply here," Durand says. "If generative AI systems follow your instruction 97% of the time, and you're simply asking it for advice, that might be fine. If it's responsible for making a decision about who gets let in, 97% is not good enough."How to trust AI-generated output at agent speedThe answer to that gap is not to eliminate AI from the review process, but to structure reviews so no single agent’s judgment is taken at face value. Because human review cannot scale to the volume and speed of agentic output without erasing the advantage of using agents at all, a new framework is necessary, so that when one agent produces work, such as code, separate agents evaluate it, provided those reviewing agents are kept from communicating with one another or with the one they are checking. It's a new human-AI paradigm, Durand says."We probably will have to develop frameworks that we trust without seeing or verifying the output directly," he explains. "It's not that that construct is 100% foolproof. However, it's the best we can do to move at agent speed. We can't trust the exact output, but we can trust the framework."In practice, that means combining automated review with clear human accountability for higher-risk decisions, rather than treating agent output as self-validating. For traditional auditors, reviewing every transaction individually is never feasible, and statistically valid sampling stands in for full verification. The same applies to risk accumulation: a single agent action might carry little risk on its own, while a sequence of actions moving in a consistent direction could cross a threshold that triggers an intervention, including a kill switch capable of halting the agent before further harm occurs.What to ask when evaluating agentic identity platformsFor security leaders evaluating identity platforms for agentic AI, there's no narrow checklist. Enterprises should evaluate what their full lifecycle of agent management looks like. Most enterprises are managing agents on two fronts simultaneously: customer-facing agents acting on behalf of external users, and internal agents deployed to automate enterprise processes."Pause long enough to see the totality of what it would mean to secure multiple agents, both interacting with you from the outside as well as being deployed on the inside," Durand says. "We need discovery and visibility of all the agents operating within our estate, a place to register them, a standard way to assign custodians, and a way to construct and centralize policy so security can enforce it across the organization."And while basic security principles were already fully understood before agentic AI arrived, what has changed, Durand says, is that the cost of moving slowly has finally caught up with the cost of moving carelessly, giving enterprises a narrowing window to build the right architecture before widespread agentic adoption makes retrofitting far more expensive. 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.

Across 101 enterprises, the infrastructure that feeds AI agents their business context is being built faster than it can be trusted. Retrieval-augmented generation is already the default context source, and provider-native retrieval has quietly overtaken the dedicated vector databases that define the category — yet a majority of enterprises have already watched their agents produce confident, wrong answers traced to missing or inconsistent context. A governed semantic layer is emerging as the fix, but most are still building it; the field is converging on hybrid retrieval; and even as provider-native tools lead in practice, a plurality say they intend to keep best-of-breed. The result is a context gap — agents that sound authoritative running on a foundation their owners do not yet fully trust.This wave of VentureBeat Pulse Research examines the enterprise RAG and context layer: what feeds AI agents their business context, which retrieval systems enterprises run, how they buy and measure them, where the architecture is heading, and — most revealingly — how often that context is already failing them.The central finding is a context gap — the distance between how confidently enterprise agents answer and how reliable the context beneath them actually is. A majority of enterprises (57%) report that in the past six months their AI agents produced confident but wrong answers they traced to missing or inconsistent business context, and more than half of those said it happened more than once. This is not a fringe failure: retrieval is the primary context source for 38% of enterprises, more than any other approach, so when retrieval is thin or inconsistent, the errors it produces are wearing the agent’s authority. The infrastructure to fix it is being built — 58% already run or are building a governed semantic layer — but for most it is not yet in production.Underneath, the market is consolidating in a direction that surprises. Provider-native retrieval — OpenAI’s file search (40%) and Google’s Vertex AI Search (38%) — already leads every dedicated vector database, and enterprises expect hybrid retrieval to dominate by the end of 2026 (34%). Yet a plurality (36%) say they intend to keep best-of-breed standalone tools rather than consolidate onto a provider’s native context stack, and a majority (57%) plan to switch or add a provider within the year. Stated preference and actual usage are pulling in opposite directions — the market is buying provider-native while insisting it wants independence.MethodologyVentureBeat fielded this survey as part of its ongoing Pulse Research series. This survey focused on enterprise RAG infrastructure and the context layer — the retrieval systems, semantic layers, and context sources that feed AI agents. Responses are filtered to organizations with more than 100 employees (n=101); the survey drew no responses from organizations of 100 or fewer, so the full sample qualifies. All responses are from a single Q2 2026 (June) wave, so the report reads cross-sectionally and does not infer month-over-month trends. Several questions were multiple-select, so those shares can sum to more than 100%.By organization size the sample concentrates in the mid-market: 251–1,000 employees (31%) and 101–250 (31%) lead, with 1,001–5,000 (20%), 5,001–10,000 (12%), and 10,001+ (7%) above them. By role it spans managers (39%), individual contributors (27%), the C-suite (16%), and VPs and directors (14%); on purchasing authority it is buyer-credible, with 46% final decision-makers and another 26% recommenders or influencers. Technology/Software is the largest industry at 20%, followed by Healthcare/Life Sciences (11%) and a broad spread across retail, transportation, financial services, manufacturing, and education.At 101 respondents this is a modest sample and should be read as a directional signal rather than a precise measurement; it is self-selected and is not a probability sample. It is best read as the view from organizations actively standing up RAG and context infrastructure rather than from the largest operators.Finding 1: Confident and wrongMore than half have traced agent errors to bad contextWe asked whether, in the past six months, enterprises had traced a confident but wrong agent answer to missing or inconsistent business context. Most had.This is the report’s defining number. A majority of enterprises (57%) have already had an AI agent produce a confident, wrong answer they traced to bad context — wrong metrics, stale definitions, or missing documents — and more than half of those have seen it happen more than once. Only 28% report no such failure, and a small remainder either don’t run agents on enterprise data or don’t trace root cause closely enough to know. The failure mode is specific and dangerous: the model is not obviously hallucinating; it is confidently wrong because the context feeding it was thin or inconsistent. Everything else in this report — what enterprises retrieve, how they govern it, and what they plan to build — is downstream of this problem.Finding 2: RAG is the default context sourceRetrieval feeds more agents than any other methodWe asked what an enterprise’s AI agents primarily use to understand its data. Retrieval leads by a wide margin.Retrieval is the backbone of enterprise context. For 38% of organizations, RAG over documents or a vector index is the primary way agents understand the business — nearly twice the share of the next approach, a governed semantic layer or ontology (21%). Mixed approaches (14%), direct live-system queries (10%), and long-context loading (6%) fill out the rest, and only 2% let agents run on the model’s general knowledge alone. The concentration matters in light of Finding 1: because so much enterprise context flows through retrieval, the quality of that retrieval is the quality of the answer. When RAG is the default source, thin retrieval is not an edge case — it is the main failure surface.One approach is notable for its absence from these answers: customizing model weights, also known as fine-tuning. Every leading source of business context is injected at run time. Our most recent direct measurement of fine-tuning comes from our April–May survey wave (a separate survey, n=136), where fine-tuning capabilities ranked last of six factors in model selection at 5% — even as 26% of that sample still named fine-tuning and customization an investment they expect to grow. Fine-tuning has fallen out of the primary selection conversation; context injection is how enterprises make agents knowledgeable about their business.Finding 3: Provider-native retrieval already leads the vector databasesOpenAI file search and vertex AI search top the dedicated toolsWe asked which retrieval systems enterprises run in production today. The answer favors the model providers and hyperscalers over the specialists.The dedicated vector database is no longer the center of the RAG stack. OpenAI’s file search (40%) and Google’s Vertex AI Search (38%) lead — provider-native and hyperscaler-native retrieval — ahead of every purpose-built vector database. Among the specialists, the most-used is the one enterprises already run for other reasons (Elasticsearch/OpenSearch, 20%) and the open, embedded option (pgvector, 12%); the pure-play vector databases that define the category — Weaviate, Qdrant, Pinecone, Milvus — each sit in single digits to low double digits. Notably, 13% of enterprises say they still run no production RAG at all. As with the platforms in the parallel infrastructure wave, enterprises are gravitating to retrieval that comes bundled with tools they already buy.The shape of this finding held across both Q2 waves. In April–May (n=161), provider-built retrieval led usage there too, while every dedicated vector database remained marginal — the most-used standalone vector database peaked at 8% of that sample — and the hybrid, pluralistic future was already the consensus expectation (34% expected hybrid retrieval to dominate, with another 29% expecting multiple architectures by use case). Two waves, consistent picture: the category that coined the “vector database” term is being collected by the platforms enterprises already buy from.Finding 4: But they say they want to keep best-of-breedA plurality resist consolidating onto a provider’s native stackWe asked how enterprises will respond as model providers bundle retrieval, memory, and orchestration into their platforms. Their stated intent cuts against their current usage.Here is the tension at the heart of the stack. Even as provider-native retrieval leads in practice (Finding 3), a plurality of enterprises (36%) say they intend to keep best-of-breed standalone tools rather than consolidate onto a provider’s native context stack — well ahead of the 21% who plan to consolidate. Another 21% expect a mix, and 9% intend to build and own the layer themselves. The gap between what enterprises run and what they say they want is the strategic question of the category: they are adopting bundled retrieval for convenience while asserting they will preserve independence. Which impulse wins — the pull of the provider bundle or the stated preference for modular control — will shape the retrieval market more than any single tool.Finding 5: Hybrid retrieval is the consensus betVector-only retrieval is already seen as insufficientWe asked which retrieval architecture enterprises expect to dominate their production RAG systems by the end of 2026. The field is converging — with a large share still unsure.The architecture is settling on hybrid. A third (34%) expect hybrid retrieval — embeddings combined with reranking and access controls — to dominate their production systems by the end of 2026, three times the 11% who expect vector-only retrieval to prevail. That is a notable signal: the pure vector-search approach that launched the category is already viewed as insufficient on its own, superseded by pipelines that add reranking for accuracy and access controls for governance — the very access controls whose absence produces the failures in Finding 1. Tellingly, the second-largest answer is uncertainty: 17% simply don’t know, and another 14% expect to move beyond a dedicated vector layer entirely toward tool-first or long-context retrieval. The consensus is not a single tool but a layered pipeline — and it is not yet fully formed.Finding 6: The governed context layer is being built nowMost run or are building a semantic layer — few in productionWe asked whether enterprises use a governed semantic or context layer to give agents and BI a shared understanding of their data. Most are on the path; fewer have arrived.The fix for the context gap is under construction. Well over half of enterprises (58%) either run a governed semantic layer in production (25%) or are piloting and building one (34%), and a further 17% are actively evaluating — meaning three-quarters are engaged with the idea in some form. But the balance is telling: more are building than have shipped, so for most enterprises the shared, governed definition layer that would prevent the "confident but wrong" failures of Finding 1 is still a work in progress. The semantic layer is the industry’s answer to inconsistent context; this wave catches it mid-construction, ambition well ahead of production.Finding 7: Bought on ingestion and simplicity, watched for correctnessSelection favors operability; monitoring favors correctness and securityWe asked what matters most when enterprises choose a retrieval system, and what they track once it is running. Both answers lean practical.Enterprises choose retrieval systems on operability. Ease of data ingestion (36%), latency and performance (32%), and operational simplicity (29%) lead the selection criteria — ahead of retrieval accuracy and access control (23% each), the two factors most directly tied to the failures in Finding 1. Once systems are running, the emphasis shifts toward trust: the most-tracked metrics are response correctness (42%) and security and access control (38%), ahead of latency (28%), operational stability (27%), and answer relevance (23%). Satisfaction with current systems is moderately positive but not enthusiastic — on a five-point scale, overall satisfaction averages 4.0, with ease of implementation and value for money both near 3.9. Enterprises buy for how easily a system runs and watch it for whether it can be trusted.Finding 8: A retrieval reshuffle is comingA majority plan to change providers — and the vector specialists are gaining interestWe asked whether enterprises plan to change or add a retrieval provider, and which they are considering. The consideration set differs from today’s stack.The retrieval stack is not settled. While 43% have no plans to change, a small majority (57%) intend to switch or add a provider within twelve months, and a quarter (26%) within the next quarter. The consideration set is where it gets interesting: provider-native retrieval still leads what enterprises are evaluating (OpenAI 22%, Vertex AI Search 21%), but the open-source vector specialists punch above their current footprint — Qdrant (14%) and Milvus (13%) draw more switching interest than their present usage (10% and 6%) would suggest. Read with Finding 4, the picture is a market in flux: enterprises run provider-native today, are evaluating a broader field, and say they want to keep their options open. The reshuffle ahead will test whether best-of-breed intent survives contact with the convenience of the bundle.The bottom line: A context gap that more retrieval alone won’t closeOrganizations with more than 100 employees are wiring agents into their business faster than they can guarantee the context those agents run on. Retrieval is the default source of enterprise context, and it increasingly comes from the model providers and hyperscalers rather than the dedicated vector databases — yet a majority of enterprises have already watched agents answer confidently and wrongly because that context was thin or inconsistent. The failure is not exotic; it is the predictable result of pointing authoritative-sounding agents at an unreliable foundation.The industry’s answer — a governed semantic layer, hybrid retrieval with reranking and access controls — is being built but is mostly not yet in production, and enterprises are pulled between the convenience of provider-native bundles and a stated preference for best-of-breed independence. At 101 respondents in a single Q2 wave this is a directional read, skewed toward the mid-market — but the direction is clear: the context layer is the next contested tier of the AI stack, and right now agents are running ahead of it. The context gap is not a retrieval-volume problem that more documents or bigger indexes will solve on their own; it is a problem of governed, consistent, access-aware context. The open question for later waves is whether enterprises finish building that layer before the confident-but-wrong failures move from the lab into decisions that matter.Based on survey responses from 101 qualified enterprise respondents (100+ employees), drawn from a single Q2 2026 (June) wave. At this sample size the results should be read as a directional signal rather than a precise measurement — it's a self-selected sample, not a probability sample, and skews toward the mid-market. Respondents include managers, individual contributors, VPs/directors, and the C-suite, with strong purchasing authority, across technology, healthcare, retail, transportation, financial services, manufacturing, and education.

SpaceXAI open-sourced Grok Build under Apache 2.0 after privacy backlash over broad directory uploads from its terminal AI coding agent. The post SpaceXAI Open-Sources Grok Build After Privacy Backlash appeared first on TechRepublic.

Across 157 enterprises, organizations are granting AI agents more autonomy while trusting the evaluations meant to gate that autonomy less. Half have already shipped an agent that passed their internal evaluations and then failed a customer in production; only one in twenty fully trusts automated evaluation today; and the most-cited weakness is that evaluations do not align with real-world outcomes. Yet two-thirds already allow, or are actively engineering toward, deploying agent changes to production on automated evaluation alone — with no human in the loop. The result is an evaluation gap — the distance between how much autonomy enterprises are handing their agents and how far they trust the tests that are supposed to catch the failures.This wave of VentureBeat Pulse Research examines how technical leaders measure agent performance: which reliability and evaluation platforms they use, how they select and trust them, what breaks in production, and how far they are willing to let agents run without a human in the loop.The central finding is an evaluation gap — the distance between the autonomy enterprises are granting their agents and the trust they place in the evaluations meant to govern it. Half of organizations (50%) have, in the past year, deployed an agent or LLM feature that passed their internal evaluations and then caused a customer-facing failure, and a quarter have seen it happen more than once. Trust in the tests themselves is thin: only 5% say they fully trust automated evaluation today, and the single most-cited limitation is that evaluations align poorly with real-world outcomes (29%). Enterprises are discovering that a passing eval is not the same as a working agent.What makes the gap consequential is the direction of travel. Two-thirds of organizations (66%) already permit fully automated, zero-human-in-the-loop deployment for low-risk agents (34%) or are actively engineering their pipelines to allow it within twelve months (33%). At the same time, the evaluation stack that would have to earn that trust is fragmented and immature: the most common primary tools are the model providers’ native evals, tied with having no dedicated tooling at all (17% each); and only about a quarter of enterprises run real-time quality checks on live production traffic. The autonomy is arriving faster than the assurance.MethodologyVentureBeat fielded this survey as part of its ongoing Pulse Research series, this survey — the Agentic Reliability & Evals tracker — focused on how technical leaders evaluate agent performance and reliability. Responses are filtered to organizations with 100 or more employees (n=157), drawn from a single survey in June 2026; because this is one wave rather than a pooled multi-month sample, the report reads cross-sectionally and does not infer month-over-month trends. Where questions were multiple-select, those shares can sum to more than 100%.By role the sample is senior and buyer-credible: 38% are final decision-makers for AI purchases and another 34% recommenders or influencers. Product and program managers (15%), consultants and advisors (10%), directors of engineering/IT (8%), and CIOs/CTOs/CISOs (8%) lead the named titles, alongside a large “Other” function (37%). By organization size the sample is mid-market-weighted: 100–499 (37%) and 500–2,499 (27%) employees lead, with 2,500–9,999 (20%), 10,000–49,999 (10%), and 50,000+ (6%) above them. Technology/Software is the largest industry at 23%, followed by Retail/Consumer (15%), Healthcare/Life Sciences (12%), and Manufacturing (10%).At 157 respondents the sample is large enough to read directionally but should be treated as a directional signal rather than a precise measurement; it is self-selected and is not a probability sample. It skews toward the mid-market, so it is best read as the view from organizations actively standing up agent evaluation practices rather than from the largest operators.Note: This survey was rebuilt for the June wave from the earlier “LLM observability and evaluations” survey; because the questions and sample differ, no comparisons are made to the April–May data.Finding 1: A passing eval is not a working agentHalf have shipped an agent that passed evals, then failed a customerWe asked whether, in the past 12 months, organizations had deployed an agent or LLM feature that passed their internal evaluations but then caused a customer-facing failure. Half of those that run evaluations had.This is the report’s defining number. Half of organizations (50%) have shipped an AI feature that cleared their internal evaluations and then failed in front of a customer — an incorrect output, a broken workflow, or a quality incident — and a quarter have seen it happen more than once. Only 36% report no such failure, and the remainder either run no pre-deployment evaluations (8%) or don’t track the root cause closely enough to know (6%). The failure is precise and expensive: the evaluation said the agent was ready, and it was not. Everything that follows — how enterprises trust their evals, what they monitor, and how much autonomy they grant — is shaped by this experience.Finding 2: Almost no one fully trusts automated evaluationThe top complaint: Evals don't match real-world outcomesWe asked which limitation most reduces trust in automated agent evaluations today. Only a sliver of enterprises had no complaint at all.Trust in automated evaluation is scarce, and specific. Only 5% of organizations say they fully trust automated evaluation as it stands — meaning 95% name a limitation that holds them back. The most common, at 29%, is the one that most directly explains Finding 1: evaluations align poorly with real-world outcomes, passing agents that later fail. Bias or inconsistency (21%) and a lack of explainability (18%) follow — enterprises cannot always tell why an evaluation reached its verdict — and 17% cite data-leakage or privacy concerns in the evaluation process itself. The tests meant to certify agents are not yet trusted to certify them, which is precisely why the autonomy trajectory in Finding 3 is so striking.Finding 3: The autonomy ceiling is rising anywayTwo-thirds already allow, or are building toward, zero-human deploymentWe asked whether organizations would let an autonomous agent deploy a code or system change to production on automated evaluation results alone, with no human-in-the-loop validation. The trajectory runs straight through the trust gap.Here is the paradox at the heart of the report. Even though almost no one fully trusts automated evaluation (Finding 2), two-thirds of organizations (66%) either already allow zero-human-in-the-loop deployment for low-risk agents (34%) or are actively engineering their pipelines to permit it within a year (33%). Only 22% rule it out for the foreseeable future. The direction is unambiguous: enterprises are moving to let evaluations gate production autonomously — removing the human check — at the same moment they say those evaluations don’t reliably match reality. The autonomy ceiling is rising faster than the assurance beneath it, which is the mechanism by which the false-confidence failures of Finding 1 will scale rather than shrink.Notably, the autonomy bet is not just a small company phenomenon. Splitting the sample by company size, larger enterprises are slightly further down the path toward zero human review than smaller companies (70% versus 64%) and slightly more likely to have shipped an evaluation-passing agent that then failed a customer (54% versus 48%). The assumption that large, regulated organizations are holding the human in the loop longest is, in this sample, backwards.  To be sure, these are directional figures, since the survey was not a huge sample — 57 respondents from companies with 2,500+ employees and 100 from companies smaller than that. Finding 4: The evaluation stack is fragmented and provider-ledProvider-native evals lead — tied with no dedicated tool at allWe asked which agent reliability or evaluation platform enterprises primarily use today. The market has no clear leader — and a large share has nothing dedicated.The evaluation layer is early and unconsolidated. Provider-native tooling leads — OpenAI’s native evals and traces (17%) and Anthropic’s Claude Console evals (13%) together outweigh any independent platform — but it is tied at the top by a striking answer: 17% of enterprises use no dedicated agent-evaluation tooling at all, a notable gap for organizations shipping agents to customers. The specialist evaluation vendors — DeepEval (12%), Braintrust (8%), LangSmith, Weave, Promptfoo, Langfuse, Arize — are scattered across single to low double digits, and 11% have built their own. No independent platform has yet become the category standard, which leaves most enterprises evaluating agents with provider-native tools, home-grown scripts, or nothing.Finding 5: Production monitoring rarely watches output qualityOnly a quarter run real-time quality checks on live trafficProduction monitoring for an AI agent can watch two very different things. It can watch whether the system is functioning — is the agent up and responding, did each request complete, how fast, at what cost, with any errors. Or it can watch whether the agent's output is correct — automated checks that evaluate the content of each answer as it goes out: did the agent give the right answer, take the right action, stay within policy. The distinction matters because a confidently wrong answer is invisible to the first kind of monitoring: the request completes, the response is fast, no error is thrown, and every functioning-metric reads healthy. We asked organizations which kind their live production monitoring is built for today.Grouped by what is actually being watched, the split is stark: 51% of organizations monitor only whether the agent is functioning, while 23% monitor whether its answers are right. Counting the ad-hoc reviewers and the don't-knows, roughly three-quarters of organizations run no automated, real-time evaluation of output correctness in production — they can see that the system is up and what it costs, and they are taking the correctness of its answers on faith. That blind spot is the runtime counterpart to the pre-deployment gap in Finding 1: the same organizations engineering the human out of the deployment decision mostly cannot see, in real time, when the deployed agent starts getting things wrong.Finding 6: Bought on cost, measured on consistencyPrice and integration drive selection; evaluation consistency is the goalWe asked what most influenced enterprises’ choice of an evaluation vendor, and what they treat as their primary measure of success. Both answers are pragmatic.Enterprises buy evaluation tooling on economics and trust it on repeatability. Cost of evaluations (28%) narrowly leads selection, just ahead of ease of integration (27%) and evaluation accuracy (24%) — breadth of observability (13%) and vendor roadmap (4%) matter far less. On what success looks like, more than a third (36%) name evaluation consistency — getting the same verdict on the same behavior every time — well ahead of speed of experimentation (19%), reduction in failures (18%), production visibility (13%), and compliance (11%). The emphasis on consistency is telling: before enterprises can trust an evaluation’s verdict, they need it to be stable — the very property whose absence (bias and inconsistency) ranked among the top trust limitations in Finding 2. Satisfaction with current tooling is only moderate, averaging 3.8 on a five-point scale across overall satisfaction, ease of implementation, and value for money.Finding 7: The next dollar goes to humans and observabilityInvestment is flowing to oversight, not just automationWe asked which reliability and evaluation investment will grow most over the next year. The money is going toward watching agents more closely — including with people.The second-largest planned investment — behind only production observability — is human review workflows, at 26%. Read against Finding 1, that is the report's quietest contradiction: at the same moment two-thirds of enterprises are engineering the human out of the deployment decision, more of them plan to grow spending on human reviewers (26%) than on the automated evaluation pipelines (16%) that would replace them. The zero-human trajectory and the human-review budget are rising in the same companies at the same time. Indeed, only 8% report that their budget is not increasing. Taken together, enterprises are hedging: building toward autonomy while spending to watch agents more closely and keep humans available for the calls that automated evaluation cannot yet be trusted to make.Finding 8: A tooling reshuffle is comingNearly two-thirds plan to adopt or switch platforms within a yearWe asked whether enterprises plan to adopt a new, additional, or replacement evaluation platform, and which they are considering. Few intend to stand pat.The evaluation market is wide open. While 36% have no plans to change, a clear majority (64%) intend to adopt a new, additional, or replacement platform within twelve months, and 31% within the next quarter. The consideration set points where current usage is thinnest: Confident AI’s DeepEval leads what enterprises are evaluating (20%), ahead of OpenAI’s native evals (13%) and Braintrust (9%) — the open-source specialists drawing more interest than their present footprint. Given that so many enterprises today rely on provider-native tools or nothing at all (Finding 4), this is less a defection than a first real wave of tooling adoption — the moment the evaluation layer starts to consolidate. Which platforms earn that trust, in a market where almost no one trusts automated evaluation yet, is the open question this series will keep tracking.The bottom line: An evaluation gap that autonomy will widen, not closeOrganizations with 100 or more employees are granting AI agents more independence than they trust their evaluations to support. Half have already shipped an agent that passed its evals and then failed a customer; almost none fully trust automated evaluation, chiefly because it doesn’t match real-world outcomes; and most watch production for uptime and cost rather than for whether the agent’s answers are right. Yet two-thirds already allow, or are actively building toward, deploying to production on automated evaluation alone.The vendor market is early and unsettled: the most common primary evaluation tools are provider-native evals, tied with no dedicated tooling at all, and a clear majority plan to adopt or switch platforms within the year. Encouragingly, the next dollar is going to observability and — pointedly — human review, suggesting enterprises sense the gap even as they engineer past it. At 157 respondents in a single wave this is a directional read, skewed toward the mid-market — but the direction is clear: autonomy is being granted on the strength of evaluations that the people granting it do not yet trust. The evaluation gap is not a coverage problem that more tests alone will close; it is a problem of evaluations that reflect reality and can be trusted to gate it. The open question for later waves is whether assurance catches up to autonomy — or whether the false-confidence failures move from customer incidents into changes that deploy themselves.Based on survey responses from 157 qualified enterprise respondents (100+ employees), drawn from a single June 2026 wave. This is a directional read rather than a precise measurement — the sample is self-selected, not a probability sample, and skews toward the mid-market. Respondents include product and program managers, consultants and advisors, directors of engineering/IT, and CIOs/CTOs/CISOs, among other functions, across technology/software, retail/consumer, healthcare/life sciences, manufacturing, and other industries.

Researchers say a Claude for Chrome flaw lets rogue extensions trigger Gmail, Docs, and Calendar tasks, with greater risk in unattended mode. The post Claude for Chrome Flaw Puts Gmail at Risk From Rogue Extensions appeared first on TechRepublic.

Across 101 enterprises, agent orchestration is consolidating onto model-provider platforms — Anthropic’s Claude leads by a wide margin — chosen for the gravity of the underlying model and judged on reliable multi-step execution. But the ambition runs well ahead of the reality: most deployed “agents” are still chatbot wrappers, the control plane enterprises expect is deliberately hybrid to avoid lock-in, and real-time fiscal control over token burn remains the exception.This wave of VentureBeat Pulse Research examines enterprise agent orchestration: which platforms enterprises run on, what drives the choice, what they optimize for, how they expect agent control to be structured, and — most revealingly — how orchestrated their deployed “agents” actually are and how tightly they control the cost of running them.The central finding is a gap between orchestration ambition and orchestration reality. Enterprises are consolidating fast onto the major model platforms: Anthropic’s Claude is the primary platform for 40%, more than double any rival, followed by Microsoft (18%) and OpenAI (13%). The choice is driven by “model gravity” — native alignment with a state-of-the-art base model (21%) — and success is judged by reliable, multi-step execution (task completion reliability 32%, multi-step workflow management 28%). Yet asked to assess their portfolios honestly, 71% say a quarter or fewer of their deployed “agents” are true multi-step orchestrated workflows rather than single-prompt chatbot wrappers, and only 10% have crossed the halfway mark. The orchestration layer is being built well ahead of the orchestrated portfolio it is meant to run.That gap shapes the architecture enterprises are putting in place. By the end of 2026 a clear majority (51%) expect a hybrid control plane — provider-native plus external orchestration — and only 6% expect to hand control to a provider-managed service, because vendor lock-in (35%) is the risk they fear most if control lives inside a model provider. Investment follows the build-out: agent workflow tooling leads the spend (34%), with security and permissions enforcement (25%) behind. And fiscal control lags throughout — more than a quarter (27%) have no real-time way to stop a runaway agent before the bill arrives.MethodologyVentureBeat fielded this survey as part of its ongoing Pulse Research series, this instrument focused on enterprise agent orchestration. Responses are filtered to organizations with 100 or more employees (n=101), drawn from a single June 2026 wave; because this is one wave rather than a pooled multi-month sample, the report reads cross-sectionally and does not infer month-over-month trends.By organization size the sample is spread evenly across the enterprise bands: 100–499 employees, 2,500–9,999, and 50,000+ (21% each), with 10,000–49,999 and 500–2,499 (19% each). By role it is senior and buyer-credible: product and program managers (15%), CIO/CTO/CISO (13%), consultants and advisors (13%), and a spread of data, AI, and engineering directors and VPs, with an “Other” function at 18%. On purchasing, 81% are recommenders, influencers, or final decision-makers for AI solutions (66% recommender/influencer, 15% final decision-maker). Technology/Software is the largest industry at 44%, followed by Financial Services (17%) and Healthcare/Life Sciences (8%).At 101 respondents the sample is robust enough to read directionally with reasonable confidence, though it remains self-selected and is not a probability sample.Finding 1: Orchestration runs on model-provider platformsAnthropic’s Claude leads; open frameworks are marginalWe asked which agent orchestration platform enterprises primarily use today. The answer concentrates on the major model providers — and on one in particular.A note on reading these shares. As described in the methodology section, the respondents are self-selected, and this question asked them for a single primary platform — so the figures measure which platform leads each enterprise's deployment, within a self-selected audience of AI-active technical decision-makers. A sample built this way can diverge substantially from spend-weighted market measures, and each VB Pulse survey draws its own sample with its own company-size mix, so vendor figures should not be compared across our surveys either. Read these shares as a portrait of where this cohort has placed its primary orchestration bet today, rather than as market share.The model platforms dominate. Anthropic, Microsoft, OpenAI, Google, and Amazon together account for roughly 80% of deployments (81 of 101), while the open frameworks (LangChain/LangGraph) and custom in-house builds that anchor engineering discussion sit in single digits. Anthropic’s lead — 40%, more than double the next platform — mirrors the “model gravity” selection logic in Finding 2: enterprises are choosing the orchestration layer that comes with the model they want to build on. As with the security vendors in the prior agent-security wave, the tools that define the category in technical circles are not yet where enterprise deployment concentrates. A small 3% are not orchestrating at all.Respondents rate the platforms they run at 3.94 out of 5 overall (109 answered), with “value for money” specifically at 3.94 and “ease of implementation” the weakest score, at 3.85 — placing orchestration near the bottom of our five-tracker satisfaction range, ahead of only evaluation tooling. A rating just under 4 out of 5, from users of whom 96% plan to change their orchestration approach within the year, reads as provisional acceptance: the platforms work well enough to run today, and not well enough to stop the search for something better. The ratings sit alongside near-universal intent to change; this is a layer enterprises tolerate more than they love.Finding 2: Model gravity drives platform selectionThe base model, not the tooling, decides the platformWe asked what most influenced the orchestration platform choice. The single largest factor is the pull of the underlying model — though flexibility and ease of development follow close behind.Model gravity leading is the selection-side explanation for Anthropic’s platform lead: enterprises pick the orchestration environment closest to the frontier model they have standardized on. But the next tier complicates the picture — flexibility across models and tools (17%) and ease of development (17%) say enterprises also want to avoid being trapped by that choice, foreshadowing the lock-in fear in Finding 6. Security and permissions (14%) and total cost of ownership (11%) round out a pragmatic buying logic. Performance (latency/memory) sits last at 4%, a reminder that at this stage of adoption the binding constraints are model fit and optionality, not raw speed.Finding 3: The job is reliable multi-step executionEnterprises just orchestration by whether it completes the workWe asked what enterprises optimize for — their primary success metric for orchestration. Reliability and multi-step workflow management dominate; developer- and user-facing metrics trail.Task completion reliability (32%) and multi-step workflow management (28%) together account for 59% of responses (60 of 101): orchestration succeeds, in the enterprise view, when it reliably carries a task through multiple steps to completion. Developer productivity (17%) matters but is secondary — the inverse of its prominence in framework discussion — and end-user experience (9%) is a minor concern, consistent with orchestration being an internal execution problem rather than a UX one. This reliability-first standard is exactly what makes the Chatbot Trap finding so pointed: enterprises define success as dependable multi-step execution, yet most of their deployed “agents” do not yet do multi-step work at all.The trap is not evenly distributed. Splitting the sample by organization size, 77% of smaller enterprises say a quarter or fewer of their agents do true multi-step work, against 62% of larger ones. Larger enterprises are meaningfully further into genuine multi-step deployment; the chatbot trap is, directionally, a mid-market condition.Finding 4: Consolidate, productionize, and build in-house Three strategic moves are nearly tied for the year aheadWe asked what major change enterprises anticipate in their orchestration strategy over the next 12 months. Three moves cluster at the top, almost evenly split.The top three — building in-house control (25%), standardizing on one framework (24%), and moving agents from sandbox to production (23%) — are statistically indistinguishable and tell a single story: enterprises are moving from experimentation to operational consolidation. They want fewer frameworks, more production exposure, and more ownership of the control layer; only 4% expect no change. The appetite for custom in-house control planes is notable alongside the platform concentration in Finding 1 — enterprises are standardizing on model-provider platforms while simultaneously planning to wrap them in control logic they own, the hybrid posture that Finding 6 makes explicit.Finding 5: Nearly seven in 10 plan to switch — and the biggest group of movers has no shortlist The strategic change enterprises anticipate (previous finding) comes with vendor motion attached. Asked whether they plan to adopt a new, additional, or replacement agent orchestration platform in the next twelve months, more respondents are moving here than in any other layer we track.Asked which platforms they are considering, the most common answer among those in motion is none yet: 29% of all respondents are evaluating without a shortlist, the largest single response after "not considering a change." Among named candidates, OpenAI leads at 16%, followed by LangChain/LangGraph at 12% and Anthropic at 7% — and notably, the independent frameworks draw roughly double their current usage footprint in forward consideration, the same pattern our security tracker found for specialist vendors. Read with this report's concentration and lock-in findings, the picture completes itself: the major model-platform providers hold roughly four-fifths of today's primary usage, vendor lock-in has become the leading fear, 96% anticipate a strategic change — and now the purchase intent to act on all of it, with the largest bloc of buyers still undecided. The most concentrated layer of the agentic stack is also, as of June, the least settled.Finding 6: Investment flows to workflow toolingTooling and permissions lead the spend; monitoring trailsWe asked which orchestration-related investment will grow most next year. Agent workflow tooling leads, with security and permissions enforcement behind.Workflow tooling leading (34%) is the budget-side expression of the reliability-and-multi-step priority in Finding 3: the money is going to the machinery that strings steps together dependably. Security and permissions enforcement (25%) and scaling infrastructure (20%) follow — the investments required to take agents from sandbox into production, the strategic move in Finding 4. Monitoring and debugging draws a smaller 11%, with another 11% reporting flat budgets. The weight on tooling, permissions, and scaling over pure observability signals that enterprises are spending to build and harden orchestration, not merely to watch it run.Finding 7: The control plane will be hybrid — and lock-in is whyEnterprises expect to split control between providers and their own layerWe asked where enterprises expect the primary control plane for agents to live by the end of 2026, and what worries them most if that control sits inside a model-provider platform. A clear majority expect a hybrid model — and vendor lock-in is the reason.Hybrid control is the dominant expectation by a wide margin (51%), and only 6% expect to hand control to a provider-managed service outright. Read together, the hybrid, custom, and externally-abstracted options — every architecture that keeps control at least partly outside the provider — sum to 88% (89 of 101). The reason surfaces directly when we asked about the risk of provider-resident control: vendor lock-in leads at 35% (35 of 101), ahead of security and permissioning limitations (28%) and inflexibility across models and tools (21%). The pattern echoes the prior wave’s “don’t trust the model to police itself” posture — here, enterprises will build on a provider’s platform but decline to be governed entirely by it. The hybrid control plane is the architectural hedge against the lock-in they most fear.The June figure asserting a preference for a hybrid control plane marks movement from earlier. In the April–May survey (n=145), only 34% expected a hybrid control plane, and a greater number (12%) expected to hand control fully to a provider-managed service. These two snapshots don’t yet measure a confirmed longitudinal trend — but the direction of the conversation is unambiguous: toward keeping control.Lock-in is also a new arrival as a top concern. In the April–May wave, the leading concern was security and permissioning limitations (32%), with lock-in second at 24%; by June the two had traded places. The worry about provider platforms appears to be maturing from whether they can be secured to whether they can be replaced.Finding 8: The chatbot trap — most “agents” aren’t agents yetEnterprises admit most deployments are still chatbot wrappersWe asked enterprises to assess their portfolios honestly: what share of their deployed “agents” are true multi-step orchestrated workflows versus simple single-prompt chatbot wrappers. The answer is the defining finding of this wave.This is the gap at the center of the report. Combining the bottom two bands, 71% of enterprises (72 of 101) say a quarter or fewer of their deployed “agents” are genuinely orchestrated — and just 10% (10 of 101) have crossed the halfway mark. The ambition documented in the earlier findings — model-provider platforms, reliability-first success metrics, production rollouts, a deliberate control architecture — runs well ahead of the deployed reality, which remains overwhelmingly single-prompt assistants dressed as agents. This is less a contradiction than a roadmap: the platforms, budgets, and strategies are being put in place precisely because the orchestrated portfolio is still so thin. The open question for later waves is how fast the reality closes on the ambition.Finding 9: Fiscal control is still reactiveOnly a minority can stop a runaway agent before the bill arrivesFinally, we asked how enterprises enforce fiscal control over agent token consumption — the risk that an autonomous loop exhausts a budget before anyone intervenes. Most rely on native caps or after-the-fact monitoring; real-time programmatic control is the exception.More than a quarter of enterprises (27%) admit they have no real-time, programmatic way to stop an agent before a budget-breaking bill arrives — they learn of it from the logs afterward. Another 32% lean entirely on the native caps and throttles built into their primary platform, a control only as good as the provider’s tooling and one that ties back to the lock-in concern of Finding 6. The enterprises building custom gateways (23%) or exploiting cross-model routing to arbitrage cost (19%) are the ones treating token burn as an engineering problem to be controlled deterministically. As with orchestration maturity, fiscal control is an area where the operational reality lags the ambition: agents are moving toward production faster than the cost-control plane around them is being built.It’s worth noting, a split appears according to company size: roughly one in three enterprises under 2,500 employees (34%) exercises only reactive control of agent spend, against 20% of larger enterprises — directional figures, but consistent with the chatbot-trap split. The mid-market is running the least mature agents on the least instrumented budgets.The bottom line: The layer is real; most of the agents aren't yetOrganizations with 100 or more employees describe an orchestration strategy that is consolidating quickly and maturing slowly. They are standardizing — for now — on model-provider platforms, which collectively hold roughly four-fifths of primary usage, chosen for the gravity of the underlying model, and they judge success by reliable multi-step execution. Investment is flowing to workflow tooling and permissions, the strategy is to consolidate frameworks and push agents into production, and the control plane they expect is deliberately hybrid, because vendor lock-in is the risk they fear most. But the standardization is provisional: 68% plan to adopt a new, additional, or replacement orchestration platform within twelve months — the highest switching intent of any layer we track — and the largest group of those movers has not yet shortlisted a candidate. Today's concentration describes where enterprises are, and visibly does not describe where they intend to stay.But the honest self-assessment punctures the ambition. Seventy-one percent say a quarter or fewer of their deployed "agents" are truly orchestrated, only 10% are past the halfway mark, and more than a quarter cannot stop a runaway agent in real time. The orchestration layer — the platforms, the budgets, the control architecture — is being built ahead of the orchestrated portfolio it is meant to run. At 101 respondents in a single June wave this reads as a clear directional signal rather than a precise measurement: enterprises have decided how they want to orchestrate agents well before most of their agents are doing anything an orchestration layer is for. The questions for subsequent waves are whether the deployed reality closes the gap on the ambition — and, with nearly seven in ten buyers in motion and most of them undecided, which platforms the settled stack finally lands on.Based on survey responses from 101 qualified enterprise respondents (100+ employees), drawn from a single June 2026 wave. Because this is one wave rather than a pooled multi-month sample, results read directionally rather than as a confirmed trend. Respondents include product and program managers, CIOs, CTOs and CISOs, consultants and advisors, and directors and VPs of data, AI, and engineering, across Technology/Software, Financial Services, Healthcare, and other sectors.

New Jalisco and OmegaLord phishing kits target Microsoft 365 accounts by abusing device code flows, OAuth tokens, and MFA prompts to maintain access. The post Jalisco, OmegaLord Phishing Kits Target Microsoft 365 Accounts appeared first on TechRepublic.

Microsoft fixed a record 570 security flaws in July 2026 Patch Tuesday, including three zero-days and two exploited bugs. The post Microsoft Fixes Record 570 Security Flaws in Biggest Patch Tuesday Ever appeared first on TechRepublic.

The CMMC assessment pause doesn't remove cybersecurity obligations. Here's why defense contractors should treat it as an opportunity to strengthen governance and AI oversight. The post CMMC Assessment Pause Leaves Defense Contractors Facing a New Risk appeared first on TechRepublic.

Apple is warning iPhone users about FaceTime scams. Learn how the fraud works, what Apple recommends, and how to report suspicious calls. The post Apple Warns Millions of iPhone Users: FaceTime Scams Are Spreading appeared first on TechRepublic.

Microsoft now recommends installing Windows 11 quality updates within three days, citing AI-driven cyberattacks that can exploit new vulnerabilities faster than ever. The post Microsoft Urges Windows 11 Users to Install Updates Within Three Days appeared first on TechRepublic.

The majority of organizations remediate vulnerabilities within a week; supply chain threats surge throughout 2025.

A recent report by Kana analyzed the adoption of AI systems.

1Password on Tuesday launched AI Spend and Consumption Management, a new capability embedded in its SaaS Manager platform that gives IT and finance teams a unified, real-time view of how their organizations consume and spend on AI services from vendors including Anthropic, Cursor, and OpenAI.The move marks the latest strategic expansion for a company that built its reputation on password management for consumers and, over the past three years, has aggressively repositioned itself as a broader identity security and SaaS governance platform for enterprise buyers. With this release, 1Password is staking a claim in one of enterprise technology's newest and most chaotic budget categories: the consumption-based cost of large language models."Executives want teams to build faster with AI, but that speed is creating a new kind of spending pressure," Greg Henry, 1Password's chief financial officer, said in an exclusive interview with VentureBeat. "Developers are consuming tokens at a pace that traditional budgets weren't built to manage, and IT and finance teams are being asked to forecast and justify AI investments without a clear view of what's actually driving costs."The product, now in public preview with broad availability planned for fall 2026, connects directly to vendor admin APIs to pull token-level consumption data daily. It normalizes that data across providers into a single dashboard and allows organizations to set vendor-level spend limits, configure threshold-based alerts via Slack and email, and break down usage by team, user, vendor, and model.Why traditional software budgets can't keep up with AI token pricingThe core challenge 1Password is targeting is structural. Traditional SaaS pricing operates on a per-seat, per-year model that is easy to budget and reconcile. AI pricing does not. Every API call to Claude, GPT-5.6, or a Cursor-powered coding assistant consumes tokens, and the cost of those tokens varies by model, by input versus output, and by the complexity of the task. A single engineering team running agentic workflows can burn through a prepaid token budget in weeks — and the finance team may not notice until the invoice arrives.Henry drew a sharp analogy to a problem enterprises have already lived through once. "Consumption-based pricing isn't new," he said. "We saw it arrive with cloud infrastructure, and it took years to build the tools and disciplines to manage it. AI is the next version of that shift."That comparison resonates across the industry. When Amazon Web Services, Microsoft Azure, and Google Cloud popularized consumption-based pricing for compute and storage in the 2010s, enterprises initially lacked the tooling to monitor and optimize their cloud bills. That gap spawned an entire FinOps ecosystem — companies like CloudHealth, Spot.io, and Apptio built multi-billion-dollar businesses helping organizations understand what they were spending on cloud and why. Henry is explicitly betting that AI token spend will follow the same trajectory, and that organizations that fail to build visibility now will end up, as he put it, "paying far more than they needed to, for far longer than they should have."The scale of the coming wave lends credibility to that bet. Goldman Sachs has estimated that token consumption from AI agents alone will grow 24 times by 2030, a projection driven by the expectation that autonomous AI systems will increasingly execute multi-step workflows — booking travel, writing and deploying code, managing customer service interactions — that generate vastly more API calls than a human sitting at a chat interface.How 1Password's new dashboard tracks every token across Anthropic, Cursor, and OpenAIThe new capability extends 1Password SaaS Manager's existing foundation of application discovery, license management, and spend analytics. It is not a standalone product. Existing SaaS Manager customers can activate it by connecting their supported AI vendor API keys, at which point consumption data flows into a dedicated AI Consumption Management dashboard. Henry confirmed that there is no separate product or add-on fee: "AI Spend and Consumption Management is available to all 1Password SaaS Manager customers."The system provides four core functions. First, it aggregates token usage and spend across Anthropic, Cursor, and OpenAI into a single, normalized view — eliminating the need to toggle between three separate vendor dashboards with three different reporting formats. Second, it enables budget controls: organizations can set vendor-level spend limits, configure percentage-based thresholds, and receive automated alerts when prepaid balances approach depletion. Third, it disaggregates consumption by team, user, vendor, and model, allowing finance and IT to understand not just how much is being spent, but where and by whom. Fourth, it situates AI spend within the broader SaaS portfolio, helping organizations see how token costs relate to their total software investment.Notably, the system captures consumption regardless of whether a human or an AI agent generated it. "Token consumption is captured at the API level regardless of whether a human or an agent is generating it," Henry explained. "Organizations get the total consumption picture, including the spikes that agent loops can create, which can be some of the hardest usage to catch before it becomes a problem."That agent-level visibility matters because autonomous AI systems can generate runaway costs in ways that human users typically cannot. An agentic coding assistant stuck in a retry loop, for example, can consume thousands of dollars in tokens in minutes — with no human in the loop to notice. For now, the product alerts but does not enforce. When asked whether 1Password will eventually give organizations the ability to automatically cut off spending when a threshold is crossed, Henry said the company is "actively evaluating" automatic enforcement but emphasized that visibility must come first: "You can't enforce what you can't see."The choice of launch partners reveals where enterprise AI budgets are under the most pressureThe decision to start with Anthropic, Cursor, and OpenAI — rather than casting a wider net — reflects where enterprise AI adoption and budget strain are most concentrated right now. Henry said the choice was driven entirely by customer demand. "Anthropic, Cursor, and OpenAI are where we're seeing the highest adoption, and where token consumption can move fast and get ahead of the teams responsible for managing it," he said. The company plans to add additional vendors based on customer demand, API availability, and budget impact, though it has not committed to a specific timeline or vendor list.The inclusion of Cursor alongside the two major foundation model providers is telling. Cursor, an AI-powered code editor that has rapidly gained traction among developers, represents a category of AI tool where consumption is particularly difficult to forecast. Unlike a chatbot interface where a user consciously types a prompt, Cursor integrates AI suggestions directly into the development workflow, generating token consumption continuously as developers write code. That ambient, always-on consumption pattern makes it especially prone to budget overruns.Henry also addressed who inside an organization should actually own this problem — and acknowledged that the honest answer right now is no one. "When spend is fragmented across vendor dashboards and finance teams are reconciling it monthly, you're always behind," he said. "AI spend can't be treated as a finance-only or IT-only problem." He noted that the pricing differences between models have become significant enough that the choice of which AI model a team uses is now a meaningful financial decision, one that is pulling CFOs into conversations with IT, product, and engineering leaders "in ways they never had to before."Steve May, director of IT at ServiceTrade, a 1Password customer that has been using the capability, said it addressed a concrete planning gap. "Forecasting tools for AI consumption and spend was one of our biggest gaps in planning because we didn't have a reliable way to track it," May said. He added that the visibility has "prevented overages that would have cost far more to fix after the fact."Where 1Password fits in the fast-consolidating SaaS management market1Password is not the only company racing to solve the AI cost management problem, but the competitive landscape is still fragmented and the category is far from mature.Zylo, a SaaS management platform that Gartner has also recognized as a leader in the space, published its 2026 SaaS Management Index in January showing that AI-native application spend surged 393% year over year in organizations with more than 10,000 employees and 108% overall. Zylo's data also revealed that ChatGPT has become the most expensed application in enterprise environments, highlighting how AI tools are entering organizations through employee credit cards and expense reports — outside formal procurement and governance workflows. Zylo has added its own token-level cost tracking for AI vendors including Anthropic, OpenAI, Cursor, and Perplexity.Meanwhile, according to a comparison published by Coommit in May, Vendr — which focuses more on SaaS negotiation than discovery — tracks AI tools at the contract level but does not yet offer consumption-level visibility. And the FinOps Foundation reported in its 2026 State of FinOps survey that 98% of organizations now actively manage AI costs, up from just 31% in 2024. The broader SaaS management market is also consolidating rapidly. In May, Deel acquired Sastrify, a German SaaS management vendor, and began folding it into its HR platform — a signal that SaaS management capabilities are increasingly being absorbed into adjacent enterprise platforms rather than remaining standalone products.1Password's approach differs from pure-play SaaS management competitors in one important respect: it is building AI cost management on top of an identity security platform, not a FinOps or procurement tool. The company's SaaS Manager product grew out of its 2025 acquisition of Trelica, a UK-based SaaS access management startup whose technology enabled the discovery of unsanctioned applications — so-called shadow IT. As BetaKit reported at the time of that deal, 1Password co-CEO Jeff Shiner described Trelica as "a pioneer in modern SaaS access management" and said the acquisition would accelerate 1Password's Extended Access Management product roadmap by more than a year. CRN noted that Trelica brought more than 300 SaaS integrations to the platform. That identity-first lineage gives 1Password a natural advantage in connecting spend data to specific users and teams — a linkage that matters when the question shifts from "how much are we spending on AI?" to "who is spending it, and is it delivering value?"From password manager to platform company: 1Password's $6.8 billion bet on enterprise identityThe launch raises a question that Henry addressed head-on: whether a company that started as a consumer password manager can credibly compete in enterprise AI cost management."It doesn't feel like a stretch to us. It feels like a natural progression," he said. "For more than 20 years, 1Password has evolved alongside how our customers work. We started by protecting passwords. Then we helped organizations manage secrets, control access, and get visibility into the applications their teams rely on."The company's evolution has been rapid. 1Password raised a $620 million Series C in January 2022 led by ICONIQ Growth, reaching a $6.8 billion valuation — at the time, the largest funding round ever raised by a Canadian company, according to Crunchbase. The round also attracted celebrity investors including Ryan Reynolds, Scarlett Johansson, and Robert Downey Jr. As of early 2025, BetaKit reported that 1Password had surpassed $250 million in annual recurring revenue, with B2B sales accounting for nearly three-quarters of total revenue and the company claiming to be cash-flow positive.In May 2024, 1Password launched Extended Access Management, a platform designed to secure sign-ins across both managed and unmanaged applications and devices. That same year, it acquired Kolide for device trust and, in early 2025, Trelica for SaaS discovery. In June 2026, Gartner named 1Password a Leader in its Magic Quadrant for SaaS Management Platforms. According to 1Password's own blog post on the recognition, its SaaS Manager now supports over 400 integrations and provides visibility into a library of more than 40,000 pre-populated application profiles. Each step has moved the company further from its consumer roots and deeper into enterprise infrastructure. The AI Spend and Consumption Management launch extends that trajectory into financial operations territory — a domain where 1Password will compete not only with SaaS management vendors but potentially with dedicated FinOps platforms and the AI vendors' own billing dashboards.Why high AI token consumption doesn't always mean wasted moneyPerhaps the most revealing part of Henry's commentary concerns what organizations should actually do with the consumption data once they have it. He pushed back forcefully against the assumption that high token consumption automatically signals waste."A team burning through tokens may be building something genuinely valuable," he said. "A lower-usage project might not be moving the business forward at all. What matters is whether that consumption is producing enough business value to justify the spend."Henry drew a distinction between personal productivity — "having a bot summarize your meeting or draft a quick email" — and genuine business outcomes. "What organizations need to see is where consumption is actually driving revenue, efficiency, or something that moves the needle."That framing positions AI Spend and Consumption Management not just as a cost-cutting tool but as a decision-support system for AI investment allocation. If a CFO can see that one engineering team's heavy Claude usage is powering a product feature that drives revenue, while another team's OpenAI spend is funding low-value internal automation, the organization can reallocate budget accordingly rather than imposing across-the-board cuts."When costs rise faster than expected, the instinct is to cut," Henry said. "But most organizations can't yet tell which teams, models, or tools are responsible for the increase, so they end up cutting across the board rather than directing investment toward the AI projects that are actually delivering business value. Blunt cuts on a technology you're counting on for competitive advantage is not a management strategy, it's a missed opportunity."The next enterprise budget crisis is already here — and it's priced per tokenThe product's current scope — three vendor integrations, alerting but not enforcement — is clearly a starting point. Henry signaled that automatic spend limits are on the roadmap and that additional vendor integrations will follow based on customer demand.But the broader trajectory he described suggests 1Password sees this launch as a wedge into a much larger opportunity. "As traditional SaaS products add AI capabilities, their pricing models are going to follow," he said. "Organizations that build visibility and management discipline around consumption now are going to be in a much better position when that happens across the rest of their software portfolio."If Henry is right, the chaos currently confined to AI token budgets is not a temporary growing pain but a preview of how all enterprise software will eventually be priced. A decade ago, companies scrambled to understand their cloud bills. Today, they are scrambling to understand their AI bills. The question is whether the organizations building the dashboards this time around can get ahead of the curve — or whether, as Henry warned, they will end up where so many companies ended up with cloud, realizing too late how much they were overpaying, and for how long.AI Spend and Consumption Management is available now in public preview for 1Password SaaS Manager customers. Broad availability is planned for fall 2026.

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. Understanding what slopsquatting isSlopsquatting 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.How AI creates a supply chain riskTraditionally, 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.Hallucinations are persistent and severeEven 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.Real-world dangers of AI hallucinationsMalicious 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.Why are LLMs hallucinating packages?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.Which LLMs are prone to slopsquatting?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.Vibe coding contributes to the problemSoftware 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.Navigating AI-assisted developmentImplementing 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.

Researchers discovered 8 terabytes of exposed credentials.

The nation intends to assign digital identification numbers to AI agents.

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.Your agents are sharing credentialsOnly 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.Exposure scales with size, and containment does notForty-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.Guarded by whoever shipped the modelThe 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, advisor to G2i, AppOmni, and Andesite, 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."Comfortable, unconvinced, and already shoppingHere 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.Three moves for security directors 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.

Security magazine dives into 6 data breach stories from the last month.

IT services organization Accenture has confirmed it experienced a data breach.