Meta is entering the increasingly competitive real-time speech-to-text market with Muse Voice Transcribe, a new audio perception model that combines streaming transcription, endpoint detection and speaker diarization for more than 20 speakers — at a public API price of just $0.18 per hour of processed audio.

Developed by Meta Superintelligence Labs, Muse is designed to process speech while it happens rather than waiting for a recording to finish. Meta’s launch post for Muse Voice Transcribe says the model supports long audio exceeding an hour, seamless multilingual code-switching, language and keyword biasing, and diarization without a separate post-processing pipeline. The model was trained across more than 70 languages, with 25 extensively validated for the initial release.

The 20-plus-speaker figure is substantial, but it is not a world record. A review of current vendor documentation turns up systems with higher published ceilings. Speechmatics' real-time transcription service says it can identify 50 speakers by default and up to 100 when the limit is increased, while Amazon Transcribe's diarization documentation specifies a maximum of 30 unique speakers, including for streaming transcription. (Speechmatics)

Muse nevertheless lands toward the high end of the market, and Meta's broader proposition is arguably more important than the raw maximum: high-capacity real-time diarization combined with low-latency transcription, endpointing, multilingual code-switching and aggressive API pricing in the same model.

For enterprise developers building meeting systems, call analytics, live assistants or ambient AI, that combination could matter more than who holds the speaker-count record.

Diarization is becoming part of the core voice stack

Traditional speech recognition answers a relatively simple question: What was said? Diarization adds another: Who said it?

That distinction becomes critical as transcripts feed downstream AI systems. A meeting assistant can correctly transcribe every sentence and still create an unreliable corporate record if it attributes an approval, commitment or objection to the wrong participant. The same issue affects customer-service analytics, compliance workflows and AI agents operating in rooms where several people can speak.

Muse incorporates speaker attribution directly into its autoregressive multimodal architecture. Meta says audio arrives in 80-millisecond chunks, or 12.5 chunks per second, with each transformed into a soft token. At each step, the model decides whether to consume more audio or emit text. Meta calls this mechanism adaptive delay: rather than applying one latency budget to every word, Muse can wait longer when speech is ambiguous and commit earlier when it has enough context. Meta says reinforcement learning combines word-error-rate and delay rewards to train that behavior. Meta's technical explanation of Muse details the architecture. (Meta AI Research)

Speaker attribution and endpointing then become part of the same token sequence. A <|start_of_turn|> token marks a potential new speaker turn, tokens such as <|speaker_A|> identify the speaker, and separate onset and endpoint tokens identify speech boundaries. Meta says it trains ASR, diarization and endpointing together rather than running speaker clustering as an unrelated downstream process.

Meta's Model API speech-to-text documentation also exposes diarization as a first-class operating mode alongside push-to-talk and endpointing. Speaker labels such as A and B are scoped to a session rather than verified identities, and the API provides turn-level rather than word-level timestamps.

20+ speakers is high, but Speechmatics goes considerably higher

Speaker-count comparisons require care because vendors implement diarization differently and do not all publish a maximum.

Speechmatics currently makes the strongest explicit real-time capacity claim found in this review. Its real-time STT documentation says speaker diarization is available live, while its real-time FAQ says the system supports 50 speakers by default and can be increased to 100.

AWS likewise exceeds Meta's stated figure: Amazon Transcribe can differentiate a maximum of 30 unique speakers, and AWS provides explicit instructions for speaker partitioning in a streaming transcription.

Soniox supports diarization in both real-time and asynchronous processing, but documents a maximum of 15 speakers per session. AssemblyAI's streaming diarization system lets developers set max_speakers between one and 10. Both companies caution that live speaker attribution is more difficult because streaming systems must make decisions with less future audio context than offline models.

xAI's current Speech-to-Text API also supports speaker diarization in streaming mode, but its documentation reviewed for this story does not publish a maximum diarized-speaker count, so a direct ceiling comparison with Muse is not possible. (X.ai Docs)

That means it would be inaccurate to describe Muse's 20-plus capability as a new global record. The highest explicitly documented real-time number identified in this survey is Speechmatics' configurable 100-speaker ceiling.

Meta also does not demonstrate 20-plus simultaneous participants in its launch material. Its principal live demonstration uses eight speakers, while its long-form recording contains 11 labeled participants. The 20-plus number is a stated model capability rather than the participant count in the public demos.

At $0.18 per hour, Muse competes aggressively on price

Meta's pricing makes the competitive picture more interesting.

According to its Muse Voice Transcribe developer page, Muse costs $3 per 1,000 minutes, or $0.18 per hour. Streaming and non-streaming transcription cost the same, and Meta says zero-data-retention processing is priced at parity with standard processing. Billing applies to audio actually processed and is rounded down to whole seconds.

Standardizing publicly posted rates to one hour of streaming audio gives the following rough comparison:

The comparison is necessarily imperfect. Qwen's price varies by deployment geography; its international real-time rate of $0.00009 per second works out to about $0.324 per hour. Google's Gemini figure is an estimated blended token cost rather than a flat hourly tariff. AWS prices vary by region and usage tier. ElevenLabs lists $0.39 per hour on its API pricing page but advertises $0.28 per hour or lower on annual Business plans.

Deepgram's pricing particularly illustrates why feature-level comparisons matter: its current Nova-3 Multilingual streaming rate is about $0.35 per hour, but speaker diarization costs another $0.002 per minute, bringing the comparable total to roughly $0.47 per hour. AssemblyAI similarly lists $0.45 per hour for Universal-3.5 Pro Realtime and another $0.12 per hour for streaming diarization.

Cartesia is harder to normalize because Ink-2 is packaged through monthly credit plans rather than a simple metered PAYG hourly rate. Its $5 Pro plan includes roughly nine hours and 16 minutes of Ink-2 transcription, which works out to about $0.54 per transcription hour if every credit is consumed exclusively on STT. That should not be treated as equivalent to a standalone $0.54 hourly API tariff.

Even with those caveats, Muse's positioning is clear. It is not the absolute cheapest streaming transcription service — Soniox currently publishes a lower equivalent rate — but $0.18 per hour with diarization included puts Meta toward the low end of the market, especially against providers that charge separately for speaker attribution.

At 1,000 hours of processed audio, Meta's public rate implies roughly $180 in transcription charges.

Meta also leads its launch accuracy benchmarks

Price matters less if it comes with a large accuracy penalty. Meta's benchmark material argues the opposite.

On the Artificial Analysis AA-WER Streaming Index supplied with the launch, Muse records a 3.1% final-transcription word error rate, ahead of Cartesia Ink-2 at 3.4%, ElevenLabs Scribe v2 Realtime at 3.6%, Qwen3 ASR Flash Realtime at 3.7%, GPT Live Transcribe and Grok Speech to Text Streaming at 3.9%, and Gemini 3.5 Transcribe Live and AssemblyAI U3.5 Realtime Pro at 4.0%.

Meta points out that Muse took the number one spot on third-party independent AI benchmarking firm Artificial Analysis' streaming speech-to-text evaluation as of September 1. Meta published the following benchmark charts in its launch post.

Its diarization result may be even more relevant to the product's positioning. Meta reports an average 17.5% diarization error rate across AMI-IHM, AMI-SDM and VoxConverse, lower than the competing systems shown in its chart.

Speaker capacity and diarization error rate should not be conflated. A platform capable of representing 100 people is not automatically better at correctly attributing speech than one supporting 20, and Meta's benchmark does not test every competitor operating at its advertised maximum speaker count.

There are deployment tradeoffs as well. Meta's API currently provides turn-level but not word-level timestamps, and it does not expose word-level confidence scores, sound-event detection or emotion detection. The documentation also specifies eight concurrent streams per tenant by default and real-time sessions of up to 60 minutes before an application must reconnect.

Still, Muse's launch creates an unusually sharp price-performance proposition. Its 20-plus-speaker diarization does not establish a world record, but the record may be the less important metric. For enterprise developers, the larger question is whether a service can preserve speaker attribution, accurate text and usable turn boundaries while a complicated real-world conversation is still unfolding.

At $0.18 per hour, with 20-plus-speaker diarization inside the same real-time model that currently leads Meta's supplied streaming accuracy benchmarks, Muse Voice Transcribe gives enterprise teams a serious new option for meeting intelligence, live transcription and voice-agent infrastructure — while putting additional pressure on competitors to compete on speaker-aware accuracy and total operating cost, not merely raw speech recognition.

When enterprise buyers build out their next AI accelerator evaluation list this cycle, they're more likely to put a non-Nvidia chip on it than Nvidia's own next-generation GPU. According to VentureBeat's July VB Pulse survey of 170 AI infrastructure respondents, 39.4% said they're likely to evaluate non-Nvidia accelerators — AWS Trainium, Google TPU, AMD Instinct, Intel Gaudi or in-house ASICs — over the next 12 months, compared with 25.3% for Nvidia Blackwell (GB300) or other next-generation Nvidia GPUs, a 14-point gap.

Nvidia remains the default in most production environments. But organizations are building real optionality into their accelerator strategy rather than treating Nvidia as the only evaluation worth doing.

The finding sits inside a broader pattern: enterprises are expanding and optimizing the AI infrastructure they already operate before making another major platform change. Greater infrastructure activity did not produce greater urgency to switch platforms. The share of respondents expecting a platform change within three months fell from 38.3% in June to 28.8% in July, even as production adoption, accelerator utilization, and exploration of neoclouds and open-source infrastructure all rose.

Where is enterprise AI infrastructure actually growing?

The July data shows organizations operating AI infrastructure more intensively and putting more provider platforms into production.

Microsoft Azure posted the largest production adoption growth among the major platforms measured, with the share of respondents reporting Azure in production increasing from 29% in June to 47.1% in July, an 18.1 percentage-point increase. Some of that jump reflects who was surveyed: July's respondent base skewed more up-market than June's (57% at organizations above 1,000 employees, versus 37% in June), and Azure adoption rises with company size in both waves. Google's Gemini was the most-used platform in both waves, with the share of respondents reporting it in production rising from 41.1% in June to 47.6% in July, narrowly ahead of Azure.

The share of respondents reporting OpenAI in production rose from 40.2% to 49.4%. Anthropic production adoption increased from 12.1% to 24.7%. 

Among enterprises that operate their own GPUs, the share running at half capacity or less fell from 83% in June (100 respondents) to 69% in July (155 respondents), with the share above 50% utilization rising from 13% to 23%.

The definition of infrastructure effectiveness is also becoming more operational. The share of respondents who selected uptime and reliability as important effectiveness measures increased from 42.1% to 51.2%. The share selecting throughput rose from 21.5% to 24.7%.

Ease of implementation improved from an average rating of 3.84 to 4.04 on a five-point scale. Overall satisfaction moved only slightly, from 4.07 to 4.14, while perceived value was essentially unchanged at approximately 3.9.

That combination is telling. Enterprises are not reporting a dramatic improvement in value simply because they are deploying more infrastructure. They are becoming more capable operators with better architectures, but they are also setting a higher bar for what that infrastructure must deliver, with reliability leading the way.

Why is platform-change urgency shifting outward?

The strongest counter-signal in the July findings is the declining share of respondents who plan to make an immediate platform change.

The share expecting a change within zero to three months declined by 9.5 percentage points. The share expecting a change within three to six months rose by 4.1 points, while the six-to-12-month window rose by 5.3 points. The share with no planned change remained effectively flat at approximately 40%.

Urgency is shifting outward, with the open-weight-model and open-source-harness debate playing a role in which pieces get enhanced versus fully replaced.

The selection criteria support that interpretation. Integration with existing cloud and data stack was the top factor in both waves, holding steady at 41.1% in June and 40.0% in July. The share of respondents prioritizing performance increased from 24.3% to 35.3%. The share prioritizing cost per million tokens increased from 7.5% to 15.9%, while the share prioritizing access to GPUs rose from 18.7% to 23.5%.

By contrast, the share selecting broad total cost of ownership as a leading factor fell from 34.6% to 21.8%.

The market appears to be moving from general infrastructure planning toward workload-level scrutiny. Buyers increasingly want to know how a platform performs under production inference, how reliably it operates and what each unit of useful work costs.

Interest in Nvidia alternatives is concentrated at the top

That 39.4% figure was 31.8% in June, already climbing before this wave. The alternatives enterprises are weighing include AWS Trainium, Google TPU, AMD Instinct, Intel Gaudi and other in-house ASICs.

Interest was even stronger among respondents with strategic purchasing authority, though the C-suite sample is small: the share of C-suite respondents likely to evaluate non-Nvidia accelerators rose from 42.9% (6 of 14) in June to 57.1% (12 of 21) in July. Among final decision-makers, the same interest rose from 35.4% to 50%.

This was especially true for organizations in the small and medium-size business tiers. Among organizations with 251 to 1,000 employees, the share increased from 41.4% to 53.2%. Among organizations with 101 to 250 employees, it rose from 33.3% to 57.7%.

These findings show organizations building optionality into their accelerator strategy.

The increased attention from C-suite respondents and final decision-makers suggests that accelerator diversity is becoming a strategic infrastructure question, not just a technical one for engineering teams.

Enterprises want to own the harness

The infrastructure findings align with a separate VB Pulse survey of agentic context layers. That survey included 101 substantive respondents in June and 101 respondents in July.

The AI harness is the operational layer connecting models to enterprise data, tools, orchestration, evaluation, identity, security, observability and business processes. It determines what an agent can access, which actions it can take and how the organization evaluates its output.

In July, 36.6% of context-layer respondents said they planned to retain best-of-breed standalone tools alongside their models. Another 36.6% expected to mix provider-native runtimes with standalone tools, while only 5.9% intended to build and own the context layer in-house.

Combined, 79.2% of July respondents favored an approach that maintained at least some architectural control outside a single model provider, compared with approximately 65.3% in June. Only 11.9% of July respondents favored consolidating onto a single model provider’s native context stack, down from 20.8% in June.

Most want to preserve provider choice, independent governance or control over critical components around the model.

The need for that control is becoming clearer. In July, 62.4% of context-layer respondents reported that a governed semantic or context layer was either in production or being built. Production adoption alone increased from 24.8% to 31.7%.

At the same time, 68.3% of July respondents reported experiencing at least one confident-but-wrong agent answer caused by missing or incorrect context, compared with 57.4% of June respondents.

The share expecting to use multiple retrieval architectures by use case increased from 12.9% to 28.7%. The share expecting to mix provider-native and standalone context tools increased from 20.8% to 36.6%.

The emerging architecture is a controlled combination of models, infrastructure, retrieval approaches, context systems and operational tooling selected by workload.

Are neoclouds gaining enterprise traction?

Neoclouds are specialized cloud providers focused heavily on AI infrastructure, particularly access to accelerators and supporting services. The July results suggest that these providers are becoming a more credible part of enterprise multi-provider strategies.

The share of respondents expecting to do more with neoclouds increased from 33% in June to 38% in July. At the same time, the share expecting to do less with neoclouds fell from 9.7% to 5.4%.

The movement was especially pronounced among respondents in the technology and software vertical. The share of that July segment expecting to do more with neoclouds reached 57.6%, compared with 44.4% in June.

Current production adoption remains much smaller than broad expansion intent. Across the named providers measured consistently in both waves, such as CoreWeave, Lambda, Crusoe and Nebius, production use increased from 1.9% of June respondents to 5.9% of July respondents.

The difference between 38% expansion intent and 5.9% current named-provider production use may point to a sizable evaluation and adoption pipeline.

The neocloud demand pipeline is not theoretical. CoreWeave reported around $104 billion in revenue backlog at the end of June, excluding more than $25 billion in additional customer commitments secured during early Q3. Nebius does not disclose a directly comparable backlog metric, but said it could sell its entire 2027 capacity under current terms and reported four second-quarter AI cloud agreements, each averaging more than $1 billion in total contract value.

The larger implication is that neoclouds are becoming a viable source of strategic leverage. They give organizations additional options for accelerator availability, software stacks, workload placement and ammunition for negotiations with hyperscale providers.

Neoclouds will still have to demonstrate enterprise-grade reliability, security, support, networking, and data management capabilities. Specialized compute access may open the door, but durable enterprise adoption will depend on the surrounding operational stack. 

Is open-source AI infrastructure usage growing?

The most accurate answer is that open-source production usage is growing, while broad platform consideration remains relatively flat.

The share of respondents reporting a custom, self-managed open-source production stack increased from 3.7% in June to 12.9% in July. The stack definition included technologies such as PyTorch, Triton, vLLM, Ray and Kubernetes.

The movement was visible across several segments with July bases above 20 respondents:

• Among individual contributors, 23.9% reported production use in July.

• Among recommenders and influencers, 13.7% reported production use in July.

• Among organizations with 251 to 1,000 employees, 12.8% reported production use in July.

The share of respondents using open-source key-value cache tooling, including LMCache and vLLM prefix caching, increased from 6.5% to 11.8%. Among technology and software respondents, usage increased from effectively 0% to 13.3%.

Open-source platform consideration ticked up slightly but remained essentially unchanged, moving from 5.6% to 6.5%.

This combination suggests that growth is concentrated among organizations moving into implementation rather than across a dramatically larger population of evaluators. Open source appears to be deepening inside an active portion of the market.

Organizations may be turning to open-source components for greater portability, model choice and control over inference optimization. But ownership also transfers responsibility. Teams adopting self-managed stacks must operate upgrades, security, observability, integration and production support themselves.

That combination of more activity, less urgency and more optionality is the throughline across all of it. Enterprises are running more AI infrastructure while deliberately keeping multiple paths open on chips, clouds and the layer that connects models to their own data. The next platform change, when it comes, will be a choice made from a stronger position.

Notes on methodology

For this article, I compared two independent, cross-sectional infrastructure survey waves: 107 respondents in June 2026 and 170 respondents in July 2026. These waves are not a longitudinal panel, so the findings describe changes between respondent populations rather than changes made by the same organizations. Platform-change timing shares add to slightly more than 100% because a small number of respondents selected more than one window (5 in June, 9 in July).

Sample composition changed between the waves. Respondents selecting the 1–100 employee organization-size category were excluded before calculating results. The remaining wave composition still differed, including a larger July share from organizations with more than 10,000 employees. Month-to-month movements should therefore be treated as directional signals rather than proof of causation. No statistical-significance testing was applied to the comparisons reported here.

The context-layer findings come from a separate survey, with 101 substantive respondents in June and 101 in July. Those results use a different respondent base and are included as supporting evidence, not combined with the infrastructure-survey results.

Infostealers replayed stolen Claude session cookies into paid accounts without ever touching the login page two-factor authentication guards.

The accounts Anthropic flagged were card-billed, self-serve accounts, which is the population no corporate identity provider governs, and no admin console can sign out. Session-cookie replay bypasses SSO as thoroughly as it bypasses 2FA. What SSO provides here is revocation and visibility, not prevention. The company disclosed the campaign in notification emails to affected users, named six stealer families, signed the accounts out, stripped the saved payment methods, and refunded the charges it found.

The burned usage is the small loss. What those sessions could reach is the exposure, and none of it sat behind an identity controlled by an enterprise.

Anthropic told affected users that a bad actor was using common infostealer malware to lift Claude login sessions off their computers and then replaying them to burn the accounts' usage, according to the notification an affected user posted to Reddit and BleepingComputer reported on August 30.

It named Vidar, LummaC2, StealC, RedLine and Acreed on Windows and Atomic Stealer on a small number of Macs, and it described general-purpose malware that copies browser login cookies along with saved passwords. "Your Claude session was likely one of the many things it collected," the email said.

A session cookie is the proof that a login already happened

The attack chain runs in one direction, from an infected machine through a stolen cookie past a checkpoint that never fires, and into everything the account can reach.

Signing the accounts out worked because a replayed cookie dies with the session it copies.

Two-factor authentication guards the login page. The site then hands the browser a cookie so the user stays signed in, and an attacker who copies that cookie and replays it looks to the server like the person who already passed the check. Help Net Security described the mechanism on August 31 as session theft becoming the new credential theft.

Anthropic spotted the theft in the usage meter. Limits were refilled and drained while the owner was away from Claude, the company wrote.

One Redditor who received the notification traced the infection to a pirated game, per BleepingComputer. That is one machine, and Anthropic has not said what the others ran.

Anthropic's notification gave no count. The company had not responded by publication to VentureBeat's questions on how many accounts were affected, whether any Team or Enterprise seats behind SSO were among them, or whether the replayed sessions reached conversation history or connected apps rather than usage alone.

Removing a saved card and refunding charges point to directly billed, self-serve accounts that authenticate through Anthropic's own login rather than a corporate identity provider. Those include personal subscriptions. Team and self-serve Enterprise organizations can also be card-billed, so the deduction is strong rather than closed.

Bugcrowd CEO Dave Gerry told Axios in early August that his company sent employees nearly a dozen emails saying the OpenClaw agent was not allowed on corporate networks, and employees kept trying to download it anyway. A personal Claude subscription on a managed laptop is the same reflex, and it comes with a card on file. LayerX data in Akamai's enterprise AI risk report found 47% of enterprise AI conversations run through personal identities, with Claude at 61%.

The pirated game is one vector. In July, attackers hosted a spoofed Claude download page on the claude.ai domain itself through a public Artifact, and a sponsored Bing ad sent employees searching for "Claude Desktop app" straight to it. Huntress documented the campaign, named FakeAgent, after SectopRAT compromised employees at 29 organizations in two days. The artifact collected roughly 7,100 downloads before Anthropic removed it. A separate campaign pushed a fake Claude installer through a spoofed download site earlier in the year, per Malwarebytes. The vector is not piracy. It is enterprise employees searching for the official app on their work machines.

Refunds cover the usage. Nothing covers the connectors

A replayed session inherits everything the legitimate one could reach, and Anthropic has not said whether these did. On a Claude account, that means the conversation history, the files uploaded into projects, and any connectors the owner authorized. Anthropic's help center states that connectors let Claude retrieve data and take actions inside connected services and that Claude inherits each person's permissions from the connected service. Read and search operations run without approval. Write actions, including send, reply, forward, share, move, and trash, are approval-gated by default. The exfiltration path is the one that is open. Google Workspace connectors are available to individual Claude accounts, so a personal Pro subscription can hold a live authorization into a Gmail inbox or a Drive folder.

If that inbox is the work inbox, the attacker holding the replayed cookie has a read path into it that the corporate identity provider evaluated once, at the moment the employee clicked allow, and rarely again. On a personal plan, the employee owns that grant. No Claude tenant administrator can sign that account out, and the Workspace or Entra administrator who can pull the underlying grant rarely knows it exists.

Adam Meyers, CrowdStrike's senior vice president of counter adversary operations, put numbers to the market in an August 6 Axios interview. Criminals have been buying and reselling stolen ChatGPT, Claude and Gemini credentials since ChatGPT took off in late 2022, fed by infostealer malware. CrowdStrike's 2026 Threat Hunting Report documents one LLMjacking campaign that pushed nearly 200,000 API requests through a compromised cloud account's AI model access in two minutes.

Meyers drew the line in a July briefing on the report. LLMjacking, in his framing, is stealing the credentials, and cost harvesting is what the buyer does next, manipulating AI resources that belong to the victim "in order to conduct operations and generate massive bills as a byproduct of that," he said. "So think of this as LLM coin mining."

One architect refused to build the same exposure into his product

Tom Kleinpeter, co-founder and chief architect at Common Room, described in written answers to VentureBeat why he held his company's AI agent integrations back through the summer of 2025.

"We rejected local MCP servers early, full stop. That path meant storing a long-lived API key or token on someone's machine. Steal that credential, and you can impersonate the user, pull their data, or do anything else the token allows, indefinitely, until someone notices and manually revokes it. We weren't willing to ship that."

Common Room shipped its first agent integration in October 2025 with Okta's Auth0 handling authentication, separate read and write scopes, and writes off by default, per Kleinpeter.

An AI coding agent working on Common Room's own system proposed caching access tokens in plain text in Redis to cut down on repeated authentication calls, he wrote. It worked, and it would have parked live credentials in shared infrastructure had a human reviewer not caught it before it shipped.

Asked what was acceptable in 2024 and a liability now, he named one thing. "Long-lived, broadly scoped API keys. Those made sense when one human operated one trusted system and stayed in the loop. Agents now run across laptops and multiple clients, often with no human watching in real time."

Okta gave agents governed identities the same week Claude users lost their cookies

Okta made Agent SSO generally available on August 24, registering AI agents as first-class identities in Universal Directory and issuing short-lived, identity-governed tokens in place of stored credentials, according to the company's announcement. The release names Claude as its example of an agent a security team can now govern natively.

Six days later, Anthropic was signing users out because six stealer families had copied the humans' Claude cookies. The agents got governed identities. The people using Claude on their own cards did not.

VentureBeat's July Pulse Research wave on agent security found 63% of 116 enterprises report credential sharing somewhere among their AI agents, and 3% run Okta for AI Agents.

That 3% has a reason, Kayne McGladrey, author of the forthcoming "Cyber Risk is a Myth" and a senior IEEE member, told VentureBeat during a July interview. "It's only those well-resourced companies that are above the poverty line that have met all the prerequisites," he said.

The prerequisites he named are the same controls most enterprises still treat as hygiene, not strategic investment.

"If they don't have their defenses in order, like attack surface management or blast radius containment or basic MFA, that would not be a useful capability or a meaningful spend."

Anthropic's position deserves its hearing. The company told users it has no reason to believe the malware is related to Claude, installed through Claude, or tied to anything they did with Claude, and it warned that signing out stops the stolen sessions while leaving the malware in place to steal the next login.

Both hold, and they are the last thing a provider can do, because the infected device belongs to the customer. On a work laptop, the device belongs to the enterprise, and the control that catches Vidar or LummaC2 before it reads a cookie jar is endpoint detection, the control in this story the security team already runs.

The profession's gap is rarely a missing control anymore, in McGladrey's framing. "I think we've got technical solutions for nearly all of the things that could go wrong, what we don't have is a way of prioritizing those," he argued.

The endpoint team owns the machine. The identity team owns an SSO the account never touched, and the AI governance lead wrote a policy the employee routed around the day the card went on file.

Each of those owners is paid to close a different gap. "Engineering is comped on getting product out the door quickly, your internal audit team is comped on checking boxes to meet your compliance goals, and security is comped and sometimes penalized on a lack of incidents," he argued. "People aren't doing the wrong thing either. They're doing what pays their bills on an ongoing basis."

What security leaders need to do next

Add AI accounts to the infostealer response playbook. When an endpoint alert names a stealer family, treat every AI service session on that machine as compromised, revoke what the enterprise tenant lets you revoke, and have the employee sign out of personal accounts until the machine is clean.

Warn users that the notification itself is now a phishing template. Help Net Security flagged copycat phishing impersonating Anthropic using this campaign as pretext. If the notification lands in a user's inbox, the next email that looks like it may not be from Anthropic.

Count the personal subscriptions on managed devices. Browser telemetry, CASB logs, and expense reports surface the sessions and the payments.

Stop personal AI accounts from holding OAuth grants into corporate Google Workspace or Microsoft 365. Both platforms let administrators restrict third-party app authorization. Use that gate so a work inbox can only be attached from a tenant the security team can revoke.

Revoke the OAuth grants Claude already holds, not just the Claude session. Signing out of Claude invalidates the stolen session but does not revoke the Google or Microsoft grant Claude was already authorized to use. Check Google's third-party app authorizations and Microsoft's enterprise application consents for live grants the sign-out left behind.

Move the heavy users onto the organization-managed tenant. On Team and Enterprise plans, an owner decides whether connectors can be enabled at all.

Put session binding on the renewal agenda. Google shipped Device Bound Session Credentials in Chrome 146 on Windows in April and turned it on by default for Google accounts and Workspace Individual accounts in May, binding each session to a private key in the device's TPM so a copied cookie cannot be refreshed anywhere else. It covers Chrome on Windows only so far, so the Mac victims in this campaign sit outside it. Ask Anthropic and OpenAI for parity and Google for a coverage date before the next contract signs.

Anthropic sent its notification to individuals. The laptop the cookie came from belongs to whoever manages it, and Vidar and LummaC2 will be back for the next login on the same machine.

Presented by Zeta

Every forward-deployed engineering (FDE) pitch sounds identical for the first ten minutes: an engineer embedded on-site, a workflow encoded within weeks, a demo that finally works on the customer's real data. What differs is what happens in the following months, and most vendors will not tell you until you ask directly.

FDE has become one of enterprise AI’s most consequential operating models. Vendors are building entire go-to-market motions around engineers who embed with customers, wire products into operating environments, and make the demo real. Investors often read FDE headcount as a growth signal and buyers read it as a promise of speed. Neither tells you whether the work is becoming a product advantage or simply accumulating as delivery labor.

The test is simple: after an FDE engagement, does the next customer start with more product and fewer unknowns — or just a new services team?

FDE is not one thing. At its weakest, it papers over a product that cannot yet stand on its own, translating by hand what the software should eventually understand. At its strongest, it is a disciplined product-learning function: it finds the edge cases of an AI-native architecture and turns them into reusable capability. The org chart looks the same, but the economics and trajectory do not.

FDE is valuable because it creates automation that powers a system of intelligence. A system of intelligence is more than software that executes workflows. It captures enterprise context, incorporates what it learns from every deployment, and improves the quality of future decisions. Forward-deployed engineers are how that context enters the system in the first place.

The engineers are the context layer

Model choice still matters in some domains. But in many enterprise workflows, the bigger constraint is not the model, it is what the enterprise knows about itself including business rules, exceptions, workflow logic, and definitions that took a decade of operating history to settle. Access to data is not the same as understanding the business.

In one large telecommunications deployment, an initial definition of a “high-intent” customer did not survive contact with the operating systems. The model’s signal said one thing while the retention team’s actual save-desk criteria said another. Those criteria were built from years of which offers actually worked, on which tenure bands, in which regions. No schema documented that logic; it lived in the judgment of people who’d been doing the job for a decade. An engineer had to sit with them, extract the knowledge, and encode it before the intelligence layer we were building could be trusted to trigger an action instead of just a score.

Once that logic was encoded into the intelligence layer, new acquisition and retention use cases could move from idea to execution in days rather than months. Rather than rebuilding the integration each time, teams were adding decisions to a shared foundation.

That kind of work produces more than an answer for one customer. Properly captured, it can become a semantic mapping, a policy module, a workflow template, a connector, or an evaluation that guards the decision in future deployments. The FDE is the context layer delivered first as a person, who then translates and delivers it as product.

Sandbox, mud, and what happens to the learning

The useful question in a diligence call or renewal conversation is not whether a vendor has FDEs. It's whether an engineer touching your environment is playing in a sandbox of tools, or trying to dig you out of the mud.

In the sandbox, FDEs use a general-purpose engine in specific, gnarly environments. Their job is to find where the engine needs a new part, install it, and feed the learning back so that part can ship again. In the mud, the engineer manually constructs a missing capability one customer at a time, and there is no engine underneath waiting to receive the part; instead, it’s another custom build.

Do not mistake these for a clean binary, though. Most companies live somewhere in the middle: reusable playbooks and connectors for the common cases, bespoke judgment for everything else. From the outside, sandbox, mud, and the middle can all look identical: a smart engineer, on-site, writing code against your data. The tell is what happens to what they learn. Either the next deployment begins with fewer unknowns, less custom code, and better tests, or it begins from zero with a prettier deck.

The strategic version of FDE treats every engagement as a disciplined learning loop. It starts with observing the exception in the field, codifying it into a reusable artifact, validating it with an evaluation and security review, releasing it into the product, then measuring whether the next deployment actually got easier. That last step is where most companies quietly fail. Not every field discovery belongs in the core product. Some customer logic is proprietary, temporary, or too idiosyncratic to generalize. Good teams know the difference between three things that get lumped together under “FDE”: product intelligence that compounds across every customer, configurable customer logic that's reusable for one account but shouldn't ship broadly, and one-off services work that is exactly what it looks like.

Customization is expected. The failure lies in not labeling which bucket the work is in, or in losing the learning from the parts that can compound.

This is the difference between a company that gets better at deploying and a product that gets better at understanding. The former can build a capable services business; its advantage lies in execution and relationships. The latter builds compounding product capability that persists after the engineer leaves.

The best FDE organization changes shape

The uncomfortable conclusion for teams building FDE functions is that human translation should shrink per unit of value delivered, even as absolute headcount grows. A fast-growing company may keep adding FDEs while still making each deployment materially lighter because more of the required logic already exists in the product. Each deployment should require less custom engineering than the last, with engineers spending more time extending reusable capabilities than rebuilding the same integrations, workflows, and decision logic.

Track four things:

• engineers per live workflow

• engineering hours per deployment

• time-to-value by vertical

• and the share of implementation work that gets reused rather than rebuilt.

Track one more that matters just as much and gets watched far less: the productization lag, the time between a field discovery, and a tested capability available to the next customer. Over time, that lag should fall, custom engineering should decline, and reuse should increase. If none of these are improving, the organization is delivering, without learning whatever the headcount chart says.

FDE is scaffolding only when it stays outside the building. The goal isn't to eliminate the people doing the work; it's to ensure more of what they learn becomes load-bearing product capability.

Three questions that get past the pitch

1. How is FDE priced?

Pricing is a signal rather than a verdict. A separate professional-services line may reflect honest transparency, bundled FDE may be a loss leader paid for by utilization. The more useful question is whether the contract, renewal, and margin story make clear which work is repeatable productization and which is bespoke delivery.

2. Where does field learning go?

Don't infer this from résumés alone. Ask who owns the handoff from FDE to product, what artifacts are produced, and how quickly they become tested, supported capabilities. The organizational interface is what reveals whether learning compounds, not the job title.

3. What got faster on the last repeat deployment?

Ask for a specific vertical and a specific delta such as fewer engineering hours, fewer weeks to value, fewer custom integrations, or a higher reuse rate. A credible vendor can name what changed and how it was measured. General claims about “learnings” and “playbooks” are not enough.

Enterprise AI creates lasting advantage when every deployment leaves behind more than a satisfied customer. It leaves behind a deeper understanding of how enterprises operate. The goal isn’t simply to deploy AI. It’s to build a system of intelligence that captures enterprise context, converts customer learnings into reusable capability, and compounds over time.

Neej Gore is Chief Data Officer at Zeta.

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.