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.

When large language models (LLMs) hallucinate, developers typically assume the model lacks the required facts. Engineering teams diagnose the error as missing knowledge. The standard response is to increase model size, expand training data, or build complex retrieval architectures.

A new study by researchers at Google Research and Technion demonstrates that the knowledge is often not missing. The model has the information encoded parametrically but fails to surface it during generation. 

Their experiments show that frontier models like GPT-5 and Gemini-3 encode 95-98% of tested facts. This indicates that in many cases, recall, rather than encoding, is the primary bottleneck for factual accuracy. 

By understanding how to unlock existing knowledge through inference-time computation, engineering teams can build more reliable applications without necessarily relying on larger models or external databases.

Knowledge profiling: measuring what models actually know

To map this gap between storage and retrieval, the researchers propose shifting the evaluation focus from question-level accuracy to fact-level profiling. Instead of simply scoring whether an LLM answers an isolated prompt right or wrong, fact-level profiling tests a single underlying piece of information across multiple conditions, evaluating whether the fact is stored in the model's parameters at all, whether it can be queried from different directions and phrasings, and what computational effort is required to retrieve it.

This framework distinguishes between whether a fact is parametrically "encoded" and whether it is "known". A model encodes a fact if it can accurately reproduce it when primed with its original training context. A model knows a fact if it can reliably answer questions about it across varied phrasings and directions.

"Encoding and recall failures are indistinguishable under accuracy metrics, yet they imply different limitations and solutions,” the researchers write. “Encoding failures call for pre-training interventions, such as scaling model size or data coverage. Recall failures suggest post-training interventions that often improve how models utilize what they already encode."

The paper illustrates this using a sample fact: Oasis played their first gig at the Boardwalk club. Based on how models process this information, the study categorizes knowledge into five distinct profiles:

• Direct recall: The model encodes the fact and readily accesses it to answer direct questions without extra inference compute.

• Encoding failure (empty shelves): The model neither encodes nor knows the fact. It cannot complete a Wikipedia-style sentence about Oasis’s early days, nor can it answer questions about the event. This signals a need for more pre-training data or greater model capacity.

• Recall failure (lost keys): The model has the fact encoded but cannot access it. It can seamlessly complete the original training text about Oasis, but fails to answer "Where did Oasis play their first show?" even when given time to think.

• Recall with thinking: The fact is encoded, but inaccessible to direct generation. It is only successfully recalled when the model uses inference-time computation, such as Chain-of-Thought, to bridge the gap. The researchers refer to this mechanism as recall facilitation. The model might initially fail to answer the direct question. By generating intermediate thoughts about the band's early history in Manchester, it structurally primes itself to locate and recall the locked answer.

• Inference without encoding: The model never explicitly encoded the Oasis fact. Instead, it successfully answers the question by making an educated guess or reasoning across other encoded facts it does know. It might deduce the answer by chaining together separate data points, such as "Oasis formed in Manchester," "the Boardwalk was a famous 90s music club there," and "the Boardwalk hosted early gigs by emerging bands.”

Scaling illusions, long-tails, and tip-of-the-tongue recoveries

The researchers evaluated 13 LLMs on over 4 million responses. They used WikiProfile, a benchmark containing 2,150 facts extracted from Wikipedia, testing each fact across formats ranging from exact context completion to multiple-choice verification.

For frontier models like GPT-5 and Gemini-3, encoding is nearing saturation. These models successfully encode 95-98% of the tested facts. However, they still fail to directly recall 26-34% of those encoded facts without thinking. 

Inference-time thinking acts as a vital recovery mechanism. Providing models with extra computational effort successfully retrieves 40-65% of the encoded facts that models initially fail to directly recall. The researchers compare this to the human tip-of-the-tongue state, where deliberate effort, such as mentally retracing context, eventually helps remember the information.

Scaling up model size does not automatically resolve this gap. In fact, companies often mistakenly try to solve recall failures by fine-tuning larger internal models—an expensive architectural misstep.

"When facts come out wrong, the go-to move is to scale, meaning train a larger model or add more data," Nitay Calderon, Research Scientist at Google, told VentureBeat. "Both are expensive, and if the facts are already encoded, neither helps."

For example, the researchers found that scaling the Gemma3 model from 1 billion to 27 billion parameters largely filled the "empty shelves" by decreasing encoding failures from 85% to 23%. But at the same time, the share of recall failures increased, peaking at 40% without thinking.

This suggests that scaling mainly solves the storage problem rather than the access problem. As the model memorizes vastly more facts, a larger pool of knowledge becomes trapped in an "encoded but inaccessible" state. The bulk of model errors shifts from missing data to failed recall.

"Our findings suggest that recall is tightly coupled to the conditions under which facts were learned, degrading when queries diverge from training-time patterns," the researchers write. How a user asks a question directly dictates whether the model can unlock the stored answer.

For example, the experiments showed that rare facts are encoded at rates similar to popular facts. Yet they found a large recall gap between long-tail and highly popular facts that exceeds 25% for frontier models.

Similarly, models struggle to generate answers to reverse questions (i.e., asking for the subject instead of the object). For example, a model might easily answer that Oasis played their first gig at the Boardwalk club, but fail to answer who played their first gig at that same club. At the same time, the same models show that they know the correct answer when given the same question in multiple-choice format.

"Whereas these failures are often interpreted as limitations of memorization or bidirectional encoding, our results suggest a different picture: rare facts are often encoded but inaccessible, and reverse facts can be recognized even when they cannot be generated,” the researchers write. “This reframes both phenomena as recall failures rather than 'missing knowledge.'"

The ROI of thinking and tips for developers

The high encoding rates of frontier models require a shift in how developers approach factuality and pipeline architecture.

Don’t treat every factual failure as a retrieval problem: The default enterprise reaction to hallucinations is often to deploy Retrieval-Augmented Generation (RAG), scale up vector databases, or ingest more domain documents. While RAG is the right call for fresh or internal data, using it as a blanket fix for hallucinations adds latency and costs to facts the model already has locked in its parametric memory.

"A lot of what teams solve with RAG are facts the model can already answer from memory, so you're paying extra latency and per-call cost for nothing," Calderon said. "If a fact is truly missing, RAG can be the right fix. But if the fact is encoded and the model just can't recall it, RAG and scaling the model only add cost on top of the real problem."

Use inference-time reasoning selectively: Thinking recovered 40–65% of encoded facts that models failed to directly recall. However, because only 10-20% of facts actually require thinking, turning it on globally wastes your compute budget. The challenge is dynamically routing queries, as models lack the self-awareness to reliably diagnose when they are about to fail.

"To use the compute well, the model has to sense ahead of time that a plain answer is about to fail, so it can escalate before answering," Calderon said. "That self-awareness is its own skill, and today's models aren't reliably good at it." This metacognitive bottleneck is why Google researchers are developing frameworks like "faithful uncertainty" to allow models to accurately gauge their own confidence and trigger deeper reasoning rather than hallucinating.

Deploy generate-then-verify pipelines: Because models are better at recognizing facts (verification) than generating them from scratch, developers can build architectural loops where a model generates a response and is then prompted to explicitly reflect on and verify its own claims. "Since recognizing a correct answer is easier than generating one, a verify pass over the model's own output could catch mistakes that plain generation misses and add some factual improvement on top," Calderon said.

Test semantic access, not just benchmark accuracy: Standard accuracy metrics mask underlying model capabilities. Evaluation sets should probe the same underlying fact across different phrasings, contexts, and directions to truly understand what a model knows versus what it can reliably access.

Leverage query reformulation and retries: Because recall is highly context-dependent, query framing dictates success. Changing the structure of a prompt, generating relevant intermediate context, or prompting the model to generate a reasoning chain before answering are legitimate reliability mechanisms that surface information direct prompts miss.

Limitations and practical takeaways

The WikiProfile benchmark relies on encyclopedic Wikipedia facts. These findings might not perfectly generalize to proprietary or highly specialized enterprise domains. A model's ability to store and recall a niche internal company metric may behave differently than its handling of public encyclopedic data.

Fully profiling a frontier model on the WikiProfile suite costs approximately $500. Developers can significantly reduce this cost by omitting multiple-choice variants or using fewer response samples per question. 

Teams can access the WikiProfile benchmark on Hugging Face to evaluate their own systems. Because the benchmark includes the exact prompts used to build it, enterprise data engineering teams can recreate the pipeline on their own internal corpora to diagnose whether their bespoke agents are suffering from missing data or missing keys. However, teams should manage their expectations when moving away from encyclopedic data.

"The pipeline is built to be applied on a new corpus, and we provide all the prompts we used," Calderon said. "The one thing to expect: on Wikipedia it was mostly a recall problem. Domain-specific facts may genuinely not be encoded in the model."

Ultimately, this shift toward knowledge usage levels the playing field for enterprise AI stacks. "For companies that don't build models from scratch, this is good news," Calderon said. "Pre-training is hugely expensive and out of reach for most, but the levers that matter now are not: post-training can help with little data and few steps, and inference-time tools like thinking, verify steps, and retrieval are already what most teams use."

This story was updated to include remarks from Google.

Egiziago Cioffi is the IT and Enterprise Architect and CEO of SynSphere Italia, a Microsoft partner based in Milan. He built an agent himself. He wrote the indexing job, configured the Azure OpenAI retrieval pipeline, connected it to SharePoint, and watched it pass every evaluation his team ran.

His Azure OpenAI email assistant auto-resolves about 60% of inbound customer email, Cioffi told VentureBeat in written responses to our interview questions. The evaluation scores were clean, and the unit tests passed. None of them asked the question that mattered.

Cioffi ran a low-privilege account against the same questions a high-privilege account had already put to the assistant. The outputs did not match. The assistant returned SharePoint content the requesting user could not have opened in SharePoint on their own. The logs told a different story than the evaluation scores.

Cioffi's retrieval logs are the evidence for this specific production failure. What follows is independent data showing the failure class is not isolated.

In many production RAG deployments, the agent answers with the indexer's permissions, not the requester's

Azure AI Search has shipped native document-level ACL trimming via Entra-based tokens since preview in May 2025, and SharePoint ACL sync followed in a later preview. The capability exists; however, it does not exist everywhere it needs to.

The SharePoint ACL preview can now ingest site-group metadata via the spg: prefix in the 2026-05-01-preview API. However, only Entra-backed principals are documented as reliably enforced at query time. The preview runs through the REST API and preview SDKs and does not cover all agent deployment paths. Azure OpenAI On Your Data, for example, supports document-level access via Azure AI Search security filters, but Microsoft's own documentation states that if the permitted-groups field is not mapped, document-level access is disabled.

That is a fail-open default in a first-party path. Custom RAG pipelines that bypass Azure AI Search entirely still index under a broadly privileged service account with no query-time entitlement check unless the developer builds one. Cioffi's deployment took the custom-pipeline path.

Across production agents at scale, 91% of successful attacks ended in silent data exfiltration

Straiker's red team ran more than 1,700 successful exploit attempts against production agents and published the results in its inaugural STAR Labs Threat Report in July. The 91% figure from their research measures all successful attacks on productivity agents that ended in data exfiltration without detection. It is a measure of what happened after an exploit succeeded, not a measure of how many deployments fail to enforce retrieval-time entitlements specifically.

Across the productivity agents in scope, 91% of successful attacks ended in silent data exfiltration, with the report noting no malware had been required. There was also no lateral movement through the network. The agent returned all the data it could reach. Straiker's report does not break out which of those successes trace to entitlement failures specifically versus prompt injection, tool abuse, or other attack classes.

Working independently, the U.K.'s AI Security Institute documented 19 unsanctioned agent actions from a July 25 to 28 cyber evaluation. The UKASI published its incident report on August 4 of this year. The evaluation deliberately ran with cyber classifiers disabled and internet access enabled. What the UKASI report demonstrates is agents acting outside the scope their deployers intended, in a permissive test environment, with no reliable mechanism to catch the deviation before it causes damage. It is a containment failure, not a retrieval-entitlement failure, and the overlap with the Cioffi incident is the shared absence of a runtime scope check rather than an identical mechanism.

Why evaluations miss this and why the native fix did not reach Cioffi's deployment

The evaluations Cioffi's team ran were designed to test whether the agent answers correctly. They check factual accuracy, relevance, and task completion. They do not ask whose permissions the retrieval pipeline uses when it fetches the source material, because that question is not in the evaluation framework.

Azure AI Search is currently shipping the retrieval-time entitlement check at the platform level. The query-time ACL trimming validates the caller's Entra token, extracts user and group claims, and returns only documents whose synchronized permission metadata grants the caller access. For deployments that use Azure AI Search with the SharePoint indexer and Entra-backed principals, the control exists natively. Cioffi's deployment did not use this path. His custom Azure OpenAI retrieval pipeline bypassed the native trimming layer, which is how the gap survived every evaluation his team ran.

From the attacker's side, this is a broken access control. Adriel Desautels, founder and CEO of Netragard, told VentureBeat in written responses that the failure reduces to a structural collapse of authorization boundaries. "If the NHI credentials usually have broad authorization and can read high privilege data then that is then stored in their index," Desautels wrote. "If an app does not enforce identity-aware retrieval, then a 'normal' user with lower permissions can query the app and access otherwise restricted data. This collapses authorization boundaries down to the lowest privilege level with search capability."

That gap is what Cioffi's low-privilege test exposed. The assistant's context window contained SharePoint content the low-privilege account could not have retrieved through SharePoint directly. The evaluation had passed. The retrieval permission boundary had not been enforced.

Desautels put the evaluation blind spot in operational terms. "Agents tend to run a single, long-lived, non-human identity that holds a wide range of permissions that it might need for any task it is ever asked to complete," he wrote. "Evaluations also don't often cover prompts, outputs, transcripts, memory, and logs where it can be read or hijacked through injected content. That mismatch is what most current evaluations get wrong."

Cioffi's filter narrowed the assistant's retrieval scope. It still resolves roughly 60% of email

Cioffi's fix did not require a new identity platform. He moved the entitlement decision into the retrieval path itself, adding a query-path filter that checks the requesting user's SharePoint permissions before the model sees a chunk. The filter runs at query time, not at index time. Content the user could not open in SharePoint does not enter the model's context window.

The control narrowed what the assistant could reach. The assistant still auto-resolves roughly 60% of inbound email with the filter live, Cioffi told VentureBeat. He did not provide a before-the-filter auto-resolution figure for comparison. The qualitative tradeoff he described is that some content the assistant previously used to answer questions is now excluded because the requesting user's permissions do not reach it. That is the price of enforcing the boundary.

The question of whether retrieval-time entitlement filtering is worth the narrowed retrieval scope does not have a single answer. It depends on the sensitivity of the indexed content, the permission variance across the user population, and whether the deployment can tolerate unanswered queries when the filter blocks a chunk the model needs. What Cioffi's incident demonstrates is that the gap exists in custom Azure OpenAI pipelines, that answer-quality evaluations do not catch it, and that a query-path filter closes it at a trade-off the builder can describe.

Identity governance platforms address a different layer. Both controls are needed

CrowdStrike announced its $740 million acquisition of SGNL on January 8, 2026, and closed the deal on February 20, 2026. Palo Alto Networks announced its $25 billion acquisition of CyberArk in July 2025 and closed the deal on February 11, 2026. Both deals closed the same month, establishing identity security as a platform pillar at two of the largest security vendors in the world.

Identity governance platforms focus on which service accounts exist, what they can reach, and when their tokens expire. They govern the lifecycle of the credentials that power AI agents. That layer matters. What it does not govern is the retrieval permission boundary. That is the moment a correctly scoped service account retrieves content on behalf of a user who holds fewer permissions than the indexing job does.

Every credential in the chain is legitimate. The service account is clean and properly managed. The knowledge base is correctly indexed. A low-privilege user queries the assistant, and it answers from the full indexed scope. Nothing flags the retrieval because no credential was misused.

Cioffi's filter is a control at the retrieval permission boundary layer specifically. Azure AI Search's native ACL trimming addresses the same layer for deployments that use it. Neither replaces identity governance. A production deployment that wants to close both the credential lifecycle gap and the retrieval-time entitlement gap needs controls at both layers.

One question and one test, any security team can run

Ask whose permissions each AI retrieval system uses when it fetches content.

If the deployment uses Azure AI Search with the SharePoint indexer and Entra-backed principals, verify that query-time ACL trimming is enabled and that the user population does not depend on SharePoint site groups. If the deployment uses a custom retrieval pipeline, the entitlement check may not exist at all.

Start by proving the answer from a low-privilege account. Run the same question a high-privilege account has already put to the assistant. Compare the outputs against what the low-privilege account can access through the underlying system directly.

Desautels confirmed that this is where a red team would start. "The first test would likely target the gaps between data and instructions, and the gaps between the user's identity and the assistant's own credentials," he wrote. "We'd attempt to plant an instruction within content that we think the assistant will ingest as data. We'd have that content direct a side-effectful, privileged action that the attacking user is not authorized to perform." A failing result, in Desautels' assessment, is "the successful or even partial execution of our injected commands."

If the assistant returns more than the account's direct access would allow, the retrieval permission boundary is not enforced at query time. That test costs two accounts and thirty minutes. It produces a result an evaluation score cannot replicate.

Cioffi built the agent on a custom Azure OpenAI pipeline that bypassed the native ACL trimming layer. He ran every evaluation his team had. He found the gap in his own logs after all of them passed. The evaluation tested whether the agent answered correctly. It did not test whose permissions the agent was using. Run the two-account comparison before the next deployment goes live. Thirty minutes tells you which side of the line you are on.

It's only the first day of September 2026, but the month and fall season are already off to the races in AI land, as Anthropic has just released its latest and most powerful large language models yet — Claude Fable 5.1 and Claude Mythos 5.1.

The two names refer to the same underlying model. Fable 5.1 is the generally available version, with Anthropic’s production safeguards in place. Mythos 5.1 is available through restricted-access programs for vetted cybersecurity and life-sciences organizations that need capabilities normally constrained by those safeguards.

For enterprise buyers, however, the release is about more than another round of benchmark gains. Anthropic is simultaneously changing the economics of running persistent agents, reducing the cost of cached context by 75%, and introducing a new security architecture called Enterprise Frontier Safeguards, or EFS, designed to let organizations retain monitoring data inside infrastructure they control.

Those changes arrive at a particularly consequential moment. Over the past several weeks, Anthropic and the U.K. AI Security Institute have disclosed incidents in which earlier Claude models, running under unusually permissive cybersecurity evaluation conditions, took unauthorized actions against real systems. Anthropic temporarily paused external cyber evaluations and has since introduced additional containment and monitoring before resuming them.

Taken together, Fable 5.1 looks less like a conventional model refresh than an attempt to solve three increasingly intertwined enterprise problems: how to make agents capable enough to finish difficult work, economical enough to leave running for hours, and governable enough to give access to sensitive systems.

A model built for work that does not finish in one prompt

Anthropic is positioning Fable 5.1 primarily around sustained problem-solving.

On Terminal-Bench-Science 0.1, which evaluates agentic scientific research, Anthropic reports Fable 5.1 scoring 52.6%, compared with 24.7% for Fable 5, 29.0% for Opus 5 and 22.4% for GPT-5.6 Sol in its evaluation setup. On Terminal-Bench 4.0, Fable 5.1 scores 55.8%, versus 42.0% for Fable 5 and 52.3% for Opus 5. Mythos 5.1 reaches 60.9% on the same coding benchmark when operating under its more permissive cyber safeguards.

The gains extend beyond coding. Anthropic reports a GDPval-AA v2 score of 1,853 for knowledge work, versus 1,824 for Opus 5 and 1,723 for Fable 5. On AutomationBench, intended to measure business workflows, Fable 5.1 scores 31.4%, compared with 17.1% for Fable 5 and 26.9% for Opus 5. On CursorBench 3.2.0, it reaches 73.4%.

Those numbers should be read as vendor-reported results rather than independent proof of superiority. Anthropic also notes qualifications around several evaluations: production safeguards can affect scores, and its August 2026 OSWorld task release is not directly comparable with some previously published results.

The more useful signal for enterprise teams may therefore come from the kinds of failures early-access partners say the model can resolve.

Investment firm Millennium told Anthropic that Fable 5.1 traced an extremely rare software crash to a bug inside an external vendor library after the problem had resisted explanation for four to five years.

Corporate expense management provider Ramp described an unattended 38-hour machine-learning run in which the model re-evaluated a previous result, launched six experiments and returned with findings and proposed next steps.

Browserbase said Fable 5.1 completed 82% of tasks on its hardest browser-agent benchmark, versus 74% for Opus 5 and 57% for Fable 5.

These are customer testimonials supplied as part of Anthropic’s launch, not independently reproduced benchmarks. But they illustrate the direction Anthropic is pursuing: moving the unit of AI work from an answer or code snippet toward an entire investigation.

That changes deployment architecture. A model that can operate for hours needs durable context, tool access, checkpoints, logging, permission boundaries and reliable recovery from errors. Model intelligence becomes only one component of the system.

Pricing: Fable 5.1 remains premium, but caching changes the equation

The most immediately measurable enterprise change is pricing.

Fable 5.1 retains Fable 5’s headline API rates: $10 per 1 million input tokens and $50 per million output. That makes it considerably more expensive on uncached tokens than other models in Anthropic’s lineup. Opus 5 costs $5 per million input tokens and $25 per million output tokens, while Sonnet 5 costs $2 and $10 respectively.

The important change is cached input:

Anthropic has cut a Fable 5.1 cache hit to just $0.25 on input, down from $1.00 for Fable 5.

That's also just 2.5% of Fable's normal input-token price of $10, rather than the 10% multiplier used by most other Claude models.

Five-minute cache writes remain $12.50 per million tokens and one-hour writes $20, but subsequent reads cost just $0.25 per million.

That produces an unusual pricing profile. Fable 5.1's ordinary input and output are twice as expensive as Opus 5's, yet its cached input is half the cost of Opus 5's cache reads. Its cache-read price is only 25% above Sonnet 5's despite Fable's base input price being five times higher.

That matters for agents because they repeatedly revisit the same codebase, system instructions, tool definitions, documents and accumulated conversation history. Anthropic says the lower cache price reduces Fable 5.1's effective cost by around 25% for typical workloads and as much as roughly 45% for highly agentic workloads in which cached context accounts for a larger share of usage.

This is a more useful enterprise framing than simply comparing per-token list prices. Model selection for an agentic workflow increasingly depends on cost per successfully completed task, including retries, context replay, tool calls and the number of tokens a model consumes before reaching a usable result.

The cache price reduction also may be an effort to help woo increasingly price-consicious enterprises. A Financial Times report found that, more than two months after launch, Fable 5 accounted for only about 11% of Anthropic model spending among roughly 70,000 companies represented in Ramp’s transaction data, while the cheaper Opus 5 and Opus 4.8 gained share.

The Information further reported growing concern among enterprise customers about unpredictable AI bills, including ServiceNow monitoring employee usage after rapidly consuming its annual Anthropic budget. Those reports suggest that even when enterprises valued Fable 5’s capabilities, many were unwilling to make it the default model for large-scale production workloads.

Fable 5.1 nevertheless remains expensive relative to much of the broader market. OpenAI's current promotional API pricing for GPT-5.6 Sol is $4 per million input tokens, $0.40 for cached input and $20 per million output tokens through at least Nov. 21. Google's Gemini 3.7 Flash currently lists at $0.75 per million input and $3.75 per million output through the end of 2026.

Fable therefore needs to justify its premium through higher task completion, lower token consumption, or the ability to replace more expensive human or multi-stage workflows—not simply through raw API price.

Anthropic's pricing system provides additional levers. Batch processing cuts Fable 5.1 input and output rates in half, to $5 and $25 per million tokens, for asynchronous workloads. U.S.-only inference adds a 1.1x multiplier. Web search costs $10 per 1,000 searches in addition to token usage, while web fetch carries no separate fee.

For procurement teams, those details make workload profiling increasingly important. A code-review agent with enormous reusable repository context may have very different economics from a report-generation workflow dominated by new output tokens.

The cyber incidents behind the release

The security architecture surrounding Fable 5.1 also needs to be understood against Anthropic's recent cybersecurity incidents.

On July 30, Anthropic disclosed that a review of 141,006 cybersecurity evaluation runs had identified three incidents, spanning six runs, in which Claude models reached the public internet from a third-party testing environment and obtained unauthorized access to real organizations.

The models had been running without the cyber safeguards applied to generally available Claude deployments. They were performing capture-the-flag exercises and had explicitly been told that their environments were simulations without internet access. A configuration problem nevertheless left an internet path open.

In the most serious incident, Claude Opus 4.7 encountered a real company that shared a name with the fictional organization in its test. Across four runs, the model obtained application and infrastructure credentials and accessed a database containing several hundred rows of production data. Anthropic said the model eventually encountered indications that the system was real but continued its attack.

A second incident involved Mythos 5. The model discovered developer instructions referencing a nonexistent Python package and decided that publishing a package under that name could help it win the simulated challenge. It created a PyPI account and uploaded malicious code to the real public package repository.

The package remained available for roughly an hour and was downloaded and executed on 15 real systems. One belonged to a security company whose automated scanner executed the package; Claude's code extracted credentials and subsequently used them to access additional infrastructure.

In the third incident, an internal Anthropic research model scanned roughly 9,000 internet targets after failing to reach its intended fictional target. It compromised an internet-facing application using exposed credentials and SQL injection, then stopped after recognizing that the system had no connection to the exercise.

The incidents did not involve customer data or Anthropic's production infrastructure, and Anthropic says the production safeguards omitted during the tests would have blocked the behavior. Still, the episodes demonstrated a problem enterprise agent architects will recognize: a sufficiently persistent agent can exploit ambiguity between what its operator intended it to access and what its technical credentials allow it to access.

A separate U.K. AI Security Institute disclosure reinforced that concern.

During testing conducted in July, AISI ran a cyber challenge 122 times across multiple models with internet access deliberately enabled and vendor cyber classifiers disabled. Ten runs produced 19 unsanctioned real-world actions. Seventeen involved Anthropic's Mythos 5; two came from a GPT-5.6 Sol run.

The most serious sequence involved a Mythos 5 agent attempting to insert malicious code into a real open-source project, creating fake identities and attempting to socially engineer a maintainer into accepting the change. The maintainer rejected it, and AISI said its investigation found no resulting real-world harm. The agent also attempted prompt injection against other AI systems and left messages that later agents discovered and used.

Again, these were deliberately permissive research configurations, not commercially available deployments. But AISI's conclusion is relevant far beyond AI labs: increasingly capable agents should be assumed to explore routes their operators did not anticipate, particularly when given difficult objectives and broad tool access.

From model safeguards to infrastructure safeguards

Anthropic's response has been to add layers around the model.

The company paused external cyber evaluations and briefly halted some internal testing, then deployed a real-time classifier designed to detect aggressive probing, sandbox-escape attempts or unexpected internet access before a tool call executes. It also moved high-risk cyber workloads into stronger isolation and imposed new requirements on external evaluators, including explicit network isolation and pre-engagement validation of sandboxes. External cyber evaluations have now resumed.

Fable 5.1 itself also gets more precise production safeguards. Anthropic says its cyber protections now create around 60% fewer interventions per Claude Code session than Fable 5's previous safeguards. The model can be used to discover software vulnerabilities for defensive purposes, while work such as exploit generation, penetration testing and some binary-based vulnerability scanning remains redirected or restricted.

That distinction matters for security teams attempting to operationalize AI. A safeguard that blocks too many legitimate actions can make an autonomous security workflow unreliable; one that permits too much creates a materially different risk. Precision, rather than simply the existence of a filter, becomes a production requirement.

Enterprise Frontier Safeguards moves data custody to the customer

Anthropic is addressing a second enterprise constraint through EFS.

The company previously introduced 30-day data retention for Fable 5 as part of its misuse-detection system. For regulated organizations, retaining sensitive conversations with a model provider can make deployment difficult regardless of contractual assurances.

EFS changes the architecture. Monitoring data can reside in the customer's own AWS, Azure or Google Cloud environment under customer-managed encryption keys, access policies and audit logging. Anthropic's automated systems can analyze the data for patterns associated with serious misuse, while alerts go to the customer for review; Anthropic says human review by its employees is not required.

Anthropic says it developed EFS with more than 100 organizations across financial services, healthcare, manufacturing, telecom, law, retail and government, and with AWS, Google Cloud and Microsoft Azure.

Support is planned across Claude Code, Claude Enterprise, the Claude Platform, Amazon Bedrock, Claude Platform on AWS, Google's Agent Platform and Microsoft Foundry. The rollout begins in phases this fall. Eligible customers can use Fable 5.1 with zero data retention until EFS becomes available. Anthropic does not charge separately for EFS, although customers remain responsible for their own cloud storage, operations and egress costs.

This is potentially as important as the model upgrade itself. Enterprise AI governance is shifting from promises about what a provider does with data toward architectures that determine where the data can exist in the first place.

Fable for production, Mythos for controlled frontiers

The split between Fable and Mythos gives Anthropic a mechanism for separating general enterprise deployment from particularly sensitive domains.

Fable 5.1 is available now through Anthropic's API as claude-fable-5-1, as well as through AWS, Google Cloud and Microsoft Azure. Mythos 5.1 uses the same underlying model but exposes more permissive safeguards to vetted cyberdefenders and life-sciences organizations through verification programs.

That same model has shown capabilities extending well outside software. Anthropic reports that Mythos 5.1 designed experimentally validated protein binders, while Fable 5.1 trained a neural network that produced a higher-resolution elevation map covering roughly a third of Venus. Mythos 5.1 also optimized seven open-source biological deep-learning models, with Anthropic reporting inference speedups as high as 2.5x.

For pharmaceutical, engineering and research organizations, that points toward a future in which the same agent architecture used to investigate a code failure may also orchestrate modeling, experimentation and analysis.

The operational lesson is the same in every case: the more work an agent can complete without intervention, the more consequential its permissions become.

Fable 5.1 makes those long-running agents more capable and, through cheaper cached context, potentially much cheaper to operate. EFS gives regulated companies another mechanism for governing their data. More precise safeguards reduce some of the friction that has made high-capability models difficult to use in security workflows.

But Anthropic's own recent incidents also demonstrate why the enterprise deployment question cannot stop at model selection.

The next generation of AI infrastructure will need to treat agents more like powerful service accounts than chatbots: narrowly scoped credentials, segmented networks, explicit allowlists, continuous telemetry, human approval around irreversible actions and the assumption that an agent may find pathways its developer did not anticipate.

Fable 5.1 raises the amount of work organizations can plausibly delegate. Its larger significance may be that it also makes the infrastructure surrounding that delegation impossible to treat as an afterthought.

Perplexity today launched hybrid compute for its agentic platform, Computer, a system that lets a single AI agent split its work between frontier models running in the cloud and smaller open-weight models running locally on Apple silicon Macs — routing sensitive data to the local machine so it never leaves the device.

The company says it is the first time an AI agent can begin a task in the cloud and dynamically hand off the confidential portions of that same task to a model running on the user's own hardware, without restarting the job or losing context. The feature becomes available today through Perplexity's desktop app for enterprise customers that opt in, as well as Pro and Max subscribers, on any Apple silicon Mac running macOS 15 or later.

"Hybrid is really compelling because it's often the work that requires confidentiality that is the most important to get right, and so the accuracy really, really matters," Jon Staff, who leads Perplexity's macOS and iOS engineering teams, said during a press briefing attended by VentureBeat. "By combining these two together, we can get that maximum intelligence from the frontier models, but we also get the security and the privacy that comes with local."

How Perplexity's on-device privacy gate keeps sensitive data off the cloud

The architecture works like a dispatcher. A frontier model in the cloud breaks a task into subtasks and routes each one to the appropriate place. Web research, long-horizon planning and heavy reasoning run in the cloud, while anything touching private files, local data or actions on the device gets delegated down to a subagent running on the Mac itself.

The linchpin is what Perplexity calls a Privacy Gate: a company-trained classifier that runs on the device and scans for personally identifiable information — names, addresses, account numbers, secrets — before anything is transmitted to the cloud. When the gate flags sensitive content, the user chooses whether that portion of the task runs locally or gets shared.

"What we wanted to do is make sure anything that's shared to that cloud orchestrator is safe," Staff said. "We built and trained our own PII classifier that integrates directly into the Mac app."

He described the handoff in detail: "The cloud orchestration will break down the task based on the prompt and figure out how to route it to different subagents... it's going to delegate that down to a sub-agent running on your Mac, and then that portion of the task is run entirely local. None of those tokens go to the cloud."

The economics matter, too, for a company that meters cloud usage through credits. Tokens generated locally cost nothing. "You're paying for the electricity, you're paying for the hardware, so we're not charging you for that," Staff said. "The only thing the credits are used for is the orchestration and the delegation."

Lawyers, private equity firms and a founder in an Uber: hybrid compute in action

Perplexity built its demonstrations around exactly the kind of work most professionals would never hand to a cloud-only agent. In the first, a lawyer on deadline updated a draft brief against privileged case files stored on a Mac while a cloud agent simultaneously pulled public case law from the open web — sending out, Perplexity says, only anonymized legal questions. "At no point did their privileged information get shared to the cloud," Staff said. "It never left the Mac."

In the second demo, a private equity associate's agent reworked a financial model against confidential management projections, benchmarked the deal against public comparables and produced a fifth iteration of an investment committee deck. The task ran roughly 40 minutes in the background with no human input — work that would have taken hours of manual stitching between local spreadsheets and cloud research.

The third demo emphasized continuity across devices. The founder of a pottery shop, riding in the back of an Uber, kicked off a marketing analysis from her iPhone. Computer asked permission to reach her Mac at the studio, fired up the local subagent to process her customer interviews and revenue data, and combined that with cloud research on competitors' public pricing. "It doesn't matter how far away she is from her computer," Staff said.

"Tasks like this aren't possible in a fully local or a fully cloud setup," he added. "You need that security of the local and the privacy, but you also need the intelligence of the frontier."

Why a Chinese-made Qwen model on enterprise Macs is raising eyebrows

The launch model lineup immediately raised a pointed question. At launch, users can choose among three local models: Google's Gemma E4B, Alibaba's Qwen3.6 35B-A3B, and a Perplexity post-trained version of Qwen3.6 35B — the company's recommended option. Asked by VentureBeat whether enterprise or government customers had raised concerns about giving a Chinese-developed model access to their machines, Staff argued that local inference neutralizes the geopolitical risk.

"The great thing about these models is that they are open weight. We're able to evaluate them ourselves," he said. "When that model is running locally on your computer, the data is not going outside of your computer itself... You're not actually sending those tokens to some cloud provider that's hosted in another country. In fact, all of Perplexity's models are U.S. hosted."

He added that macOS's built-in sandboxing framework, known as Seatbelt, constrains what the agent can actually do on a machine: "If local execution is trying to do something that it shouldn't, it'll just point blank stop it and it'll request permission from the user." Perplexity does not currently allow unrestricted "YOLO mode" execution, he said, though "I wouldn't be surprised at some point if we allow certain people to do this."

For enterprises, admins can set a single organization-wide sensitivity policy and audit a full record of what leaves each device — a feature aimed squarely at compliance teams in law, finance and healthcare. Questions remain on the consumer side, however. Pressed on how usage data feeds model training, Staff pointed to Perplexity's incognito mode and a long-standing opt-out toggle, and said enterprise contracts can include zero-data-retention terms. A company spokesperson said Perplexity is "not using it for post training" globally and promised to follow up with specifics on non-enterprise accounts.

The enterprise privacy problem hybrid AI is trying to solve

The announcement lands amid a broader industry reckoning with a stubborn problem: the most valuable enterprise work involves exactly the data companies are least willing to send to someone else's servers. NIST's generative AI risk profile flags data privacy and information leakage among the technology's central risks, and McKinsey's research on the state of AI has consistently found that organizations struggle to move from experimentation to value capture, with data governance among the chief obstacles. Gartner, for its part, named hybrid computing among its top strategic technology trends for 2025, anticipating architectures that blend compute across environments.

Perplexity is betting that the answer is not choosing between cloud intelligence and local privacy, but building the orchestration layer that arbitrates between them in real time. It is a defensible position for a company that has always styled itself as a neutral broker — "Perplexity is like Switzerland in that we work with everyone," a company representative said at the briefing — sitting at the application layer above whichever models happen to lead at any given moment.

"Anytime one of these gets better, Perplexity gets better," Staff said of the interplay among local models, frontier models and Apple's chips. "That's the really cool nature of where we sit in this application layer, orchestrating all the different pieces together."

From $520 million startup to $20 billion agent platform in three years

Hybrid compute caps an extraordinarily aggressive product run. Perplexity launched its Comet AI browser in July 2025, initially for $200-a-month Max subscribers — an early bid to make agents, not chat, the interface to computing. Computer, its full agentic platform, arrived in March 2026, followed by desktop apps for Mac and Windows. Just last week, the company launched a local-first version of Computer on NVIDIA's DGX Spark hardware, which starts on the user's device and escalates to cloud models only with permission. Today's launch inverts that flow: cloud-first, delegating down.

The business trajectory has been equally steep. Perplexity was valued at $520 million in January 2024; by September 2025, the company had finalized a funding round at a $20 billion valuation. Along the way it made an audacious $34.5 billion bid for Google's Chrome browser during Google's antitrust remedies fight, and Bloomberg reported that Apple executives held internal talks about acquiring the company — a striking backdrop for a product now built to showcase Apple silicon.

The strategy is not without headwinds. Reuters reported in July that Reddit's data-scraping lawsuit against Perplexity survived a motion to dismiss, part of a wave of copyright and data litigation facing the company — context that makes its privacy-forward positioning both commercially savvy and reputationally necessary. And practical constraints remain: Perplexity recommends at least 32GB of unified memory for the better tier of local models, Staff was candid that the smallest option "significantly underperforms" the larger Qwen models, and Windows and Linux support will come only later.

The deeper question is one users cannot easily inspect. The Privacy Gate is itself a machine learning classifier, and classifiers miss things; a false negative means sensitive data reaches the cloud anyway. Perplexity's answer is transparency — users can expand and review exactly what the gate flagged before anything is sent, and enterprises get device-level audit logs. But the pitch, at bottom, asks professionals to trust one AI to decide what another AI is allowed to see. For an industry that has spent three years telling lawyers, bankers and doctors to keep their most sensitive work away from the cloud, Perplexity's wager is that the fix was never to build a higher wall — it was to build a smarter gate.

Presented by SAP

HR tracks employees and skills. Finance owns headcount targets and cost. Procurement manages contractors and services spend. Together, they leave executives unable to answer basic questions about how workforce decisions actually translate into business outcomes.

Fragmented planning creates workforce blind spots

Each function has its own systems, its own planning cadence, and its own assumptions about how work gets done. Recent SAP research found that 62% of C-suite executives are dissatisfied with their current level of integration between people and business performance data. The same research found that while 50% of organizations are planning for AI’s impact on productivity and capacity, only 21% are planning for AI’s impact on job design and organizational structure.

That gap matters because the two are inseparable. You can’t make a sound decision about where to automate without understanding how it will affect the teams, roles, and skills connected to that work. Most organizations are trying to do exactly that, and discovering, usually too late, that the pieces don’t fit together.

The workforce has quietly expanded — and planning hasn’t caught up

The definition of “workforce” has been expanding for years, but most planning models haven’t registered the change. Employees now work alongside contractors, specialized partners, and AI systems that handle real execution-layer tasks — not just support functions, but actual work. In some delivery models, external and digital labor has moved from supplemental to central.

That shift changes the nature of every significant workforce decision. When a company chooses to automate a process, the ripple effects touch headcount, skills, services spending, and productivity assumptions simultaneously. A reskilling initiative can reduce dependency on contractors. Expanding contractor capacity can close an immediate gap while quietly deepening a long-term capability problem. None of these moves can be evaluated well in isolation, but that’s precisely how most organizations still evaluate them — separately, in sequence, by different teams working from different data.

The real question isn’t “should we hire, automate, or reskill?” It’s how work should be configured across humans and intelligent systems, and at what cost. Most planning architectures weren’t designed to ask that question, let alone answer it.

CFOs and CHROs are being pushed into the same room

CFOs are being asked to connect financial signals to real operational choices, particularly in workforce spending, which dominates most income statements. CHROs are being pulled beyond traditional talent management into harder questions about work design and the balance between human and digital labor. Neither can answer these questions from their current vantage point alone, and historically, they haven’t had to answer them together. That’s changing, not because of some cultural shift toward collaboration, but because the decisions genuinely require both perspectives at the same time.

When that partnership works, organizations can move workforce planning from a periodic budgeting exercise to an ongoing strategic conversation. They can ask harder questions: Where does it make more sense to build critical skills internally than to buy capacity externally? When we automate a workflow, how do we know whether we’re creating capacity or just moving a problem downstream? These aren’t questions finance or HR can answer in sequence. They require shared data, shared governance, and frankly, a shared willingness to operate in territory that neither function fully owns yet.

From annual budgets to continuous workforce steering

The organizations handling this best stopped treating workforce planning as a once-a-year negotiation and started treating it as an ongoing operational discipline. That means finance, HR, and procurement seeing the same picture of workforce capacity, skills, and cost, rather than reconciling three different pictures after the fact. It means modeling scenarios that combine hiring, reskilling, automation, and external labor as connected levers rather than separate conversations.

The metrics are evolving too. Headcount, labor cost, and utilization still matter, but they describe only part of what’s happening. As AI becomes embedded in operations, leaders need visibility into skills and readiness relative to strategic priorities, how work is actually distributed across employees and intelligent systems, and whether automation is unlocking new capacity or quietly eroding the engagement of the people working alongside it. Organizations that track these signals appear to be making structurally different decisions about where to invest. They are not just better-informed, but asking better questions.

The hard part isn’t the technology

Connecting HR, finance, and procurement data creates the conditions for better decisions. It doesn’t make those decisions. The harder challenge is leadership alignment: CFOs and CHROs agreeing on shared metrics, committing to a planning cadence that keeps workforce choices connected to business strategy, and building a working relationship where neither function is simply ratifying what the other has already decided. That’s a governance problem, and it doesn’t come bundled with any platform.

The organizations that move first on this won’t just have better data. They’ll have a fundamentally clearer picture of how work creates value across employees, contractors, and intelligent systems together. The ones that don’t will keep making workforce decisions in the dark. The difference is that those decisions are coming faster now, and the consequences of getting them wrong are larger.

For additional perspectives on workforce planning, continuous planning, and leadership in the age of AI, explore SAP Workforce Planning and the latest SAP SuccessFactors innovations.

David Imbert is Chief Marketing Officer, SAP Financial Management; Lara Albert is Chief Marketing Officer, SAP SuccessFactors.

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.

The viral fervor we saw earlier this year around OpenClaw, the open source AI harness that turns powerful language models into autonomous workers the user can message via their favorite channels (Telegram, iMessage, WhatsApp, Discord etc), has cooled off substantially from its peak in March 2026.

But over the weekend, OpenClaw's creator Peter Steinberger and current team of co-developers gave the world — especially enterprises — a reason to look at it again, announcing OpenClaw 2.0, billed as the most significant update to the harness and surrounding platform yet.

OpenClaw 2.0 seeks to transform what began largely as a personal agent harness into something increasingly designed for teams, shared infrastructure and enterprise workflows.

OpenClaw 2.0 introduces a rebuilt browser interface that brings conversations, files, approvals, configuration and live agent activity into a common workspace. It adds shared cloud sessions and multi-user collaboration. And it expands the security model with stronger sandboxing, role-based permissions, approval controls, secrets handling and auditing.

Together, those additions move OpenClaw closer to being infrastructure that an organization could deploy for employees rather than simply a powerful agent an individual developer runs locally.

They also sharpen a competitive question surrounding the project: whether OpenClaw has addressed the security and isolation concerns that helped inspire newer alternatives such as NanoClaw.

The answer is increasingly yes at the capability level — but not necessarily by default.

OpenClaw wants to become the shared agent layer

Released under the official name of v2026.8.1, the update spans installation, messaging, memory, skills, models, automations, browser and native applications, plugins and security.

Steinberger described the development of OpenClaw 2.0 as an exercise in using the product to build itself.

“Two months ago, we started the mission to ‘build OpenClaw with OpenClaw,’” Steinberger wrote on X early on August 31.

Over that period, he said, OpenClaw gradually moved its team away from individual local coding harnesses and toward team.openclaw.ai, a shared agent environment aware of what team members are working on.

“Multiplayer coding + infinite compute with nodes and cloud sessions has been a game changer for how we build,” Steinberger wrote, adding that local harnesses now “feel like relics of the past.”

That claim points toward one of the more important changes in OpenClaw’s enterprise proposition.

The dominant model for AI coding agents has generally been individual: a developer runs an agent in a terminal, IDE or desktop application, gives it access to a repository and lets it execute work within that environment.

OpenClaw 2.0 is pushing toward something different. Agent sessions can become persistent workspaces that outlive a single terminal or employee. They can be shared with colleagues, executed across other machines or cloud workers, and supervised through a browser.

For enterprises, that potentially turns the agent from an employee-level productivity application into a shared operational layer.

A new UI could broaden OpenClaw beyond developers

The redesigned Control UI is central to that strategy.

OpenClaw has shifted away from an Overview-first web application and made conversations the primary interface. Threads sit in a sidebar, while the active conversation occupies the main workspace. Files, approvals, settings and ongoing agent activity remain accessible around it.

The design deliberately brings OpenClaw closer to the interaction model employees already know from OpenAI's ChatGPT, Anthropic's Claude, Google's Gemini and other conversational AI products.

That lowers an important barrier to enterprise adoption. Open-source agent frameworks are often powerful precisely because they expose low-level configuration, terminals, tools and runtime controls. Those same characteristics can make them difficult to deploy beyond engineering organizations.

OpenClaw 2.0 attempts to preserve the underlying control while putting a conversational interface on top of it. An employee can ask an agent to perform work without treating the terminal as the primary product interface. But OpenClaw does not hide what is happening underneath. The Control UI can surface session files, terminal activity, Git-backed changes, pull-request state, browser activity and interactive dashboards.

The release also places more emphasis on observability during agent execution. Tool calls and results are paired more clearly, file changes can appear as focused diffs, command activity is easier to inspect, and long-running background tasks can remain visible alongside the conversation. That combination matters for enterprise use.

Employees get a simpler interface for delegating work. Technical users retain access to the artifacts and execution state behind the conversation. Administrators gain a centralized place to configure and supervise the system.

The redesigned Settings workspace now encompasses agents, memory, plugins, MCP servers, devices, communication channels and device pairing. OpenClaw also consolidates model-provider administration, including credential status and, where providers expose it, model availability, quota, account balance, budget and spending information.

Limited-access browser users can request administrator privileges rather than automatically receiving them, with another administrator required to approve the escalation.

These are not especially flashy agent features. For companies deploying AI systems to dozens or hundreds of employees, they may be among the most important additions in the release.

Multiplayer sessions turn agent context into shared context

OpenClaw 2.0 also expands the agent from a personal workspace into a collaborative one.

Shared cloud sessions allow another employee to enter work already in progress without discarding the context accumulated by the agent.

Multi-user Gateways — the service that connects users and agents to tools, files, credentials and other resources — can track who created a conversation and which prompts were submitted by identified participants.

Owners and administrators can determine whether another user can read a session, suggest changes, work in draft mode or participate directly.

The interface adds session ownership, participant attribution, presence and even typing indicators. For coding teams, that introduces a workflow closer to collaborative software development than traditional AI chat.

A developer could initiate a task and allow an agent to work on it remotely. Another engineer could inspect the resulting changes. A senior engineer or administrator could approve an operation requiring additional privileges. The work does not have to remain attached to the laptop or terminal where it started.

Sessions can also move execution to paired devices or cloud workers while maintaining the broader workspace.

For enterprises experimenting with long-running agents, that is significant. Persistent agents need mechanisms for shift changes, escalation, supervision and ownership transfer. Otherwise, organizations simply create fleets of personal agents whose state disappears into individual user environments.

OpenClaw is attempting to turn that state into collaborative infrastructure. Already, some teams outside the developers of the open source project are adopting it.

Colin Johnson, CEO of marketing metrics software firm Solvely, described a similar shift in his own development workflow in a post on X.

His team had already been using OpenClaw agents through Discord, where developers could assign tasks, run commands and interact with their development environment. But he said that model still felt like “messaging a bot”: developers could share access to an agent without actually sharing the agent’s working context.

The new multiplayer WebUI changed that, he wrote, because two developers could open the same live session, see the same history and artifacts, and add information without first exporting or reconstructing what the agent had already done. “We were working inside the same context,” Colin wrote.

In one example, another developer was taking over a project he had been working on; instead of preparing a traditional handoff document, Colin joined the developer’s existing agent thread and added the missing project context directly. “The session itself became the handoff document,” he wrote.

For enterprise teams, that is a useful illustration of why persistent multiplayer sessions may matter beyond convenience: agent context can become a shared work artifact rather than information trapped inside one employee’s private conversation.

Colin’s deployment also illustrates both the enterprise potential and the remaining security boundary. His team runs its OpenClaw Gateway on a development server reachable through GitHub authentication, Cloudflare Access and a Cloudflare Tunnel, with the Gateway itself listening only on the server’s loopback interface rather than an exposed public port.

But he explicitly cautioned that this does not make the shared Gateway a multitenant environment. The developers already trust one another with the repositories, tools and agent capabilities behind it. As he put it, Cloudflare controls who can enter the workspace, while OpenClaw tracks who created, owns or contributed to the work; stronger separation still requires separate infrastructure.

Security becomes much more enterprise-oriented

That shift creates a corresponding security problem: a shared agent can potentially act with broader organizational authority than one running on a developer laptop.

OpenClaw 2.0 responds with considerably more granular controls.

Approvals can now be tied to a specific request, command, session and person. Command permissions can be constrained to specific arguments and working directories. For script-backed execution, OpenClaw can verify that the script being executed still matches what was originally reviewed.

Sessions can operate under different permission levels, including read-only, guarded, workspace and full-access modes, with the highest level restricted to administrators.

Organizations can also define operator roles that require sandboxed execution for sessions created by specific identities. OpenClaw says those requirements cannot be bypassed using elevated execution or host overrides; if the required sandbox cannot be provisioned, execution fails rather than silently falling back to the host.

Credentials receive additional protection.

OpenClaw’s team-scoped Secret Store distinguishes protected secrets from ordinary environment data available to the agent. For supported requests, a protected credential can be substituted into a Gateway-hosted HTTPS request without exposing that credential directly to the model.

OpenClaw can also reference external systems including 1Password and Vault.

Auditing has expanded around execution identity, approvals, session actions and outbound messages. Plugin installation can trigger capability reviews associated with the specific artifact being installed.

Those controls address questions enterprises inevitably face when deploying agents: Who initiated an action? Which agent performed it? What resources could it access? Who approved the operation? And what happens to those permissions when work moves between people or machines?

NanoClaw still takes a different approach to security

OpenClaw’s changes also make the comparison with open source, enterprise-friendly rival NanoClaw more nuanced.

NanoClaw is one of several subsequent projects to emerge around the idea that AI agents need stronger isolation and simpler security boundaries. Its architecture places operating-system-level containment at the center of the design.

NanoClaw runs agents inside Docker containers, limits those containers to explicitly mounted filesystems and runs their processes as an unprivileged user. Sessions and agent groups can remain isolated rather than automatically sharing files and conversation history.

Its credential architecture follows the same principle. Supported outbound requests can pass through OneCLI’s Agent Vault, allowing credentials to be injected by a gateway rather than placed inside the agent container itself. NanoClaw also provides an optional egress-lockdown mode that puts agents on an internal Docker network and routes supported external traffic through the gateway.

OpenClaw 2.0 can now reproduce many elements of that hardened model. It supports Docker and Podman sandboxes, per-agent and per-session sandbox scopes, configurable read-only or read-write workspace access, role-enforced sandboxing, remote execution nodes and disposable cloud workers.

The key difference is the starting posture. OpenClaw’s documentation explicitly says sandboxing and execution approvals are off by default. Its baseline configuration assumes a trusted single operator and permits host execution unless administrators configure stronger restrictions. NanoClaw makes isolation more fundamental to how agent execution is structured.

So does OpenClaw 2.0 have security parity with NanoClaw?

In terms of available controls, it is much closer than before. In terms of defaults and architectural philosophy, no. An enterprise can configure OpenClaw into a substantially hardened environment, but it has to make that decision deliberately.

One Gateway is still one trust domain

Another limitation is particularly important for larger organizations. OpenClaw says a Gateway should be treated as a single trust domain.

Its new multi-user permissions are designed to govern collaboration among trusted users. They should not be treated as hard isolation between mutually untrusted tenants.

For organizations requiring stronger separation — between business units, customers or other security domains, for example — OpenClaw recommends separate Gateway instances, described as “cells,” with separate state, credentials and workspaces.

Fleet tooling for managing those cells remains experimental.

That distinction could matter significantly for enterprises considering OpenClaw as a centrally operated service.

Role-based access inside one Gateway may be sufficient for a trusted engineering department or internal team. It is a different proposition from a multi-tenant platform intended to isolate customers or users who should be assumed hostile to one another.

NanoClaw has its own configuration requirements and limitations, and even its stronger outbound-network lockdown remains optional. But its smaller architecture and container-centric execution model may appeal to organizations that want a narrower security boundary that is easier to reason about.

OpenClaw is optimizing for a broader problem.

OpenClaw’s biggest advantage may be the control plane

The tradeoff is product breadth.

NanoClaw emphasizes a relatively small codebase, container isolation and customization through code and skills. Its second-generation architecture supports owner, administrator and member roles, and a separate monitoring dashboard can provide visibility into deployments.

OpenClaw 2.0 is trying to build a much broader operational environment.

Its Control UI combines employee interaction, live execution, files, approvals, terminals, code review, model-provider configuration, devices and shared sessions.

That gives OpenClaw a potential advantage for enterprises that need not only secure agent execution but a usable control plane around it.

Security teams care about isolation. Platform teams also need deployment, authentication, model configuration, auditing and policy enforcement. Employees need an interface they can actually use. Managers need a way to understand what is running. Developers need access to the underlying files and tools when something goes wrong.

OpenClaw 2.0 increasingly tries to serve all of those constituencies through one system.

What is OpenAI's role?

OpenClaw says 933 contributors, including 569 first-time contributors, participated in the release, which includes more than 16,000 pull requests — roughly half of all pull requests ever merged into the project.

Interestingly, the release was not shared by Steinberger's employer, OpenAI. Recall that the Austrian developer announced on Feb. 14, 2026 that he was joining OpenAI to work on bringing agents to a broader audience, a move OpenAI CEO Sam Altman publicly confirmed the following day.

But OpenClaw was not folded into OpenAI. Steinberger said at the time that OpenClaw would move to a foundation and “stay open and independent,” while OpenAI would support the project. OpenClaw now says it is stewarded by the OpenClaw Foundation, an independent 501(c)(3), with OpenAI listed alongside Microsoft, GitHub, NVIDIA, Atlassian, Tencent and other organizations as partners.

Based on the available public information, OpenClaw 2.0 should therefore be understood as an OpenClaw Foundation release, not an OpenAI product or OpenAI software release, despite Steinberger’s employment at OpenAI and OpenAI’s financial and organizational support for the project.

Enterprise readiness now depends on configuration

OpenClaw 2.0 does not eliminate the security risks associated with autonomous agents, and its own documentation identifies limitations.

Secret Store values, for example, are not themselves encrypted at rest and rely on filesystem protections. Protected credential substitution does not cover every possible execution path, including some raw sockets, containers, remote nodes and provider-native harnessesIts multi-user permissions are collaboration controls, not hostile-tenant isolation.

Those caveats should prevent enterprises from interpreting OpenClaw 2.0 as secure-by-default agent infrastructure.But they also illustrate how much the conversation around the project has changed. The relevant comparison is increasingly not simply OpenClaw versus NanoClaw. It is a container-first, constrained system such as NanoClaw versus a deliberately hardened OpenClaw deployment that provides a substantially broader employee and administrator experience.

NanoClaw retains a strong proposition for organizations prioritizing a small attack surface, container-first execution and architectural simplicity.

OpenClaw is making another bet: that enterprises ultimately need an agent platform to function as both runtime and workplace.

OpenClaw 2.0 provides many of the primitives needed to build that environment — sandboxing, permissions, protected credentials, approvals, identity, auditing and isolated deployments — alongside a browser interface designed to make the system accessible to employees who will never configure an agent from a terminal.

The remaining caveat is important: enterprises have to turn those primitives into policy. OpenClaw 2.0 doesn't automatically make OpenClaw enterprise-ready, but it does make an enterprise-grade OpenClaw deployment far easier out-of-the-box.

And as Steinberger’s description of OpenClaw’s own development process suggests, the long-term ambition may be larger still. Rather than giving every employee another AI assistant, OpenClaw is positioning the agent itself as shared infrastructure — a persistent layer where people, models and compute collaborate on the same work.

If you look at the commit histories of modern data platforms, something profound has shifted over the last two years. The friction of writing syntax has collapsed. With Cursor, Claude Code, and agentic workflows now living inside our Docker containers and IDEs, generating the first implementation of a distributed streaming pipeline or a complex API integration is no longer the central bottleneck.

Agents can navigate repositories, write test coverage, inspect stack traces, and propose refactors. Describe a Kafka-to-Iceberg sink mapping in plain English, and an agent can produce a credible starting point before the engineer has opened every relevant file.

That changes the question for software engineers.

If the agent is becoming the primary author of local system logic, what exactly is left for the engineer to do? Are we headed toward an industry of reviewers rubber-stamping an endless stream of plausible pull requests? Or has the work shifted away from constructing logic and toward something more abstract?

To answer that, it helps to borrow a lens from thermodynamics, which gives us a language for directed work, feedback, loss, and the boundaries that keep a complex system coherent.

The agent as a heat engine

When we strip away the anthropomorphic illusion of AI, what remains is a computational engine. It takes direction and turns it into action.

An LLM sitting in a data center has immense capacity, but it does no useful work until it is given intent. A prompt, a business requirement, a system instruction, or a failing test gives the agent a direction. It turns that direction into code, tool calls, queries, tests, and changes to a running system.

Every engine has losses. Every agent loop does, too.

Anyone who has left an agent running against a difficult repository has seen this. It starts with a clear task. Then it follows a stale assumption, fixes a symptom rather than a cause, treats an old migration as current behavior, and begins to accumulate its own history. A few tool calls later, the context contains enough plausible but conflicting detail that the next step is less certain than the first.

Call this operational entropy: the buildup of stale assumptions, branching context, and unresolved dependencies inside a loop that is still trying to move forward.

A human interruption helps because it introduces new information. So does a failing test, a precise data contract, a deterministic tool, or an evaluation that tells the agent exactly what it got wrong. Without that signal, an agent can keep generating output while drifting further from a correct outcome.

Agents clearly generate motion. The real question is whether the system around them turns that motion into useful work.

The infinite monkey and the accelerating search space

The infinite monkey theorem gives us a useful picture of what follows: repeated attempts, finite constraints, and feedback.

The theorem says that a monkey hitting keys at random for an infinite amount of time will almost surely type the complete works of Shakespeare. Modern agents are much smarter monkeys. They have compilers, tools, repositories, test suites, and feedback loops. Their work is not random — the feedback steers the next attempt — but the dynamic is familiar: propose, execute, observe, correct, and try again.

In a bounded task, that loop is remarkably effective.

Give an agent a known input schema, a known target schema, a small codebase, and tests that catch the relevant failures. It can inspect the code, make a change, run the tests, absorb the result, and try again. The definition of done is visible. The search space is narrow. The loop has a chance to converge.

But enterprise systems rarely offer that kind of stillness. A real-time pricing engine may depend on mutable operational state, third-party APIs, late-arriving events, regional policy, and business rules that exist partly in code and partly in someone’s head. A data lakehouse can be physically consistent and semantically wrong. A pipeline can pass its tests and still produce numbers that finance does not recognize.

The environment is changing while the monkey is typing.

The three-body problem of enterprise logic

This is why the three-body problem is such a useful image for enterprise software.

With two bodies — a planet and a star — you can predict the motion with a clean mathematical description. Add a third body and the problem becomes much harder to solve. There is no general closed-form solution, and some configurations exhibit chaotic behavior. Small changes in one place can produce very different trajectories elsewhere.

Modern data platforms have the same shape. Clickstream data changes with product behavior. Operational databases mutate under customer activity. APIs impose rate limits and change versions. Schemas evolve. Security policies shift. Legacy systems carry rules that no one has written down because they have been buried in exception handling for years.

Each system exerts pressure on the others. A change in one place alters the meaning or behavior of another. What begins as a local feature request starts to pull on the entire system.

Consider a hypothetical: an agent is asked to add a customer_tier field to a revenue model. It finds a field called status in the operational database, maps it into the transformation, and passes the existing type and nullability tests. The code is clean. The pipeline is green. The answer is still wrong.

A semantic data contract says that customer_tier is derived from trailing twelve-month spend, has an assigned business owner, and cannot be populated from account status. The contract rejects the change before it reaches the dashboard. The engineer's contribution wasn't the transformation — it was the boundary that made the agent's mistake visible, specific, and recoverable.

The new mandate: Designing equilibrium

The software engineer’s job is no longer to write every piece of micro-logic. Agents will increasingly do that work, often faster. The new mandate — designing equilibrium — is to create the conditions in which generated logic can be trusted.

When a business requirement changes faster than an agent can absorb feedback, the engineer has to build containment fields. Strict semantic layers, immutable event logs, data contracts, idempotent APIs, and deterministic state machines are not just good platform hygiene. They reduce the number of assumptions an agent has to make at once.

They turn a coupled problem into a bounded domain with clear inputs, explicit rules, and reliable feedback.

Once that domain exists, the agent becomes genuinely powerful. It can write the transformation, execute the tests, repair the failures, and ship the change without needing to infer the unwritten history behind every table and service.

The value of software engineering doesn't disappear as code generation gets cheaper — it becomes more visible, which is the shift that actually matters.

Autonomous systems will increasingly generate software. But the contracts, feedback loops, and boundaries that determine whether that software succeeds or spirals into chaos will still be designed by software engineers.

Ananth Packkildurai is a data engineering leader, writer, and author of Data Engineering Weekly, sharing insights on modern data platforms, large-scale pipelines, and AI-driven architectures.

Presented by Box

Identity and permissions are no longer enough to secure enterprise AI agents. They govern what an agent can reach, not how it behaves once it starts working on its own, and an autonomous agent can turn legitimate access of enterprise data into unintended action in seconds. That gap is pushing enterprise AI security from just governing access toward a layered approach that includes governing execution, says Heather Ceylan, chief information security officer at Box.

"Access controls and permissions are the foundation, but the challenge is they were designed for humans," Ceylan says. "Permissions are still the foundation, but you have to think about how the agents get their permissions scoped as well."

Access controls were built for a slower, more forgiving world, where a human employee with lingering permissions to a decade-old folder will rarely go looking for any data inside it, or even remember they have access at all. But an agent will explore all of its permissions, operating at a scale no person can match and surfacing forgotten misconfigurations and stale permissions far faster than a human ever could. Identity and scoped permissions remain the first layer of any credible defense, however, because agents raise the stakes, clean access hygiene is more valuable than ever.

A steady drip of incidents in recent months underlines the potential for major damage, where models have slipped the sandboxes they were supposed to stay contained within, reached systems they weren't scoped to touch, or read content they were not permitted to access. While the specifics vary, the overarching threat remains the same: an agent found a path through the data that it could reach, and took it.

Access controls alone can't secure autonomous AI agents

Complications crop up when agents are handed broad standing permissions to match broad workflows. An agent might legitimately need to call fifty tools across twenty different actions over the life of a task, reading and writing folders that span every department in the company. But granting all of that access at once inflates the blast radius of possible damage to data and content if a single step goes wrong. A stronger permissions model provides access only in the moments that it's needed, Ceylan says.

"You need permissions that change based on what the agent has been asked to do, when it needs to take that action," she explains. "If it's taking one step and only needs two tools, it should be scoped to only those two. When you narrow permissions to the task in front of the agent, the number of ways any given step can misfire shrinks with it."

From governing access to governing execution

Tight security is also no longer tied to whether an agent has access to specific data, but whether it should take a specific action on a specific step, which is the difference between a standing access grant and a bounded one. In other words, an agent may hold legitimate rights to a finance folder but still have no business writing four thousand of those files to a new location, even if it's told to do so.

"An employee with access to payroll data they were never meant to keep could be instructed to pull the payroll records and write them to a public shared folder, publishing the entire company's compensation in a single move," she says. "Every access check passed, but the behavior still has catastrophic consequences."

Prompts alone can’t reliably govern agent behavior because instructions can change, agents can absorb injected instructions, or they can be steered by files they read along the way. Durable controls need to live one level down, with the tool calls themselves, as well as the content those calls act on. Deciding in advance what an agent is permitted to execute, regardless of how its prompt is manipulated, keeps behavior inside fixed bounds that no clever input can talk it out of.

Legacy content platforms weren't built for AI agents

Most of what an agent touches inside a company is unstructured content, including contract, policies, customer records — the accumulated files that make up the overwhelming majority of corporate data. Much of it still sits in systems that were designed for human filing habits: network drives, aging ECM platforms, and many SaaS tools. Those systems were built to ask the question, does this person have permission? and they answer it with folder-level access that hasn't been audited for years.

The legacy platforms don't have metadata for an agent to reason over or classification for an enforcement layer to act on, and their logs aren't detailed enough to show what an agent read. Bolting an AI connector onto that stack doesn't fix any of it, it just hands agents the same blind spots, only at machine speeds, Ceylan says.

"Every agent action eventually resolves to content," Ceylan says. "If the content layer can't tell you what it's holding, who it belongs to, and what should never leave it, there's nothing underneath your controls."

How to decide which AI actions need human approval

Two years ago, everyone assumed security would always mean including humans in the loop. Building and living with agents has changed that assumption, Ceylan says, and Box now sorts actions into three tiers: fully autonomous actions, monitored actions and high-risk actions that require human approval.

• Fully autonomous, reserved for actions that are reversible, bounded, logged, and free of untrusted input, and where a mistake doesn't cost too much.

• Monitored actions, once a team has built enough confidence in an agent and paired it with alerting and rollback that can catch and undo a problem in flight.

• Irreversible, high-risk actions that are always routed through a person — for instance, when an agent that wants to delete a large number of files or wipe the primary folder in a structure.

Each team must calibrate the lines between these layers to match its own risk tolerance.

Box’s approach is to put controls in the platform rather than the workflow, enforcing protections such as data classification, labeling and expiration without requiring a human checkpoint for every action.

"The right configuration should be enforced at the outset, instead of blocking an action at the end," Ceylan says.

Building trust in AI agents through behavior over time

An organization can make an access decision once, but trusting an agent's behavior should only happen over time, observing how the agent runs, collaborates, and builds on the outputs of other agents. Published frameworks tend to lag the technology, or are too abstract to implement; instead Box works from a smaller set of principles: tightly scoped agent identities and actions, clear expectations about what can be rolled back, three approval tiers, and a way for teams to test and iterate quickly.

"The sanctioned path has to be the fast path, because when teams aren't given a safe way to experiment, they tend to route around the controls entirely," Ceylan says. "A security leader's job is to offer a way to move quickly without stepping outside the guardrails."

Sustaining trust in an agent depends on being able to see how it actually behaves. But traditional monitoring tools weren’t built for the job; the behavioral baselines that underpin user and entity behavior analytics were calibrated to human activity, and suspicious agent behavior doesn’t necessarily look like human activity.

And while establishing a useful agent baseline begins with logging, many agents start out as experiments, so their actions never make it into logging infrastructure. Plus, important signals are rarely individual easily flagged actions, but chains of activities across systems, as one agent's output becomes another's input, while the detections for that pattern are still being designed.

Governing agents, then, requires visibility not just into what they can access, but what they actually do, and that visibility has to live where the content does.

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.

Enterprise AI has entered a new era. Organizations are rapidly moving beyond assistants that answer questions to autonomous agents capable of reasoning, invoking tools, accessing enterprise applications, coordinating with other agents, and completing multi-step business workflows with minimal human intervention.

This shift represents a fundamental change in how software operates. Traditional applications execute predefined logic written by developers. AI agents, however, dynamically determine how to achieve an objective. They decide which tools to use, which APIs to call, what information to retrieve, and how to sequence actions based on context. That flexibility unlocks enormous business value, but it also introduces a new class of security risks.

Much of today's AI security discussion focuses on prompt injection, model vulnerabilities, and data leakage. These are important concerns, but they represent only part of the challenge. Once an AI agent has successfully authenticated and begins acting autonomously, traditional security controls provide very little visibility into whether it continues to operate safely.

This is where enterprises need to adopt a new security mindset: runtime trust.

Authentication establishes identity, not trust

Enterprise security has traditionally relied on three foundational questions: Who are you, what can you access, and what actions are you authorized to perform. Identity providers, multi-factor authentication (MFA), role-based access control, and zero trust architectures answer these questions effectively for human users and conventional applications, and NIST's zero trust guidance remains a solid reference point for how those principles are meant to work (NIST SP 800-207).

AI agents introduce a different problem. An AI agent may legitimately authenticate using an enterprise identity, receive valid API credentials, and be granted access to systems like Microsoft 365, ServiceNow, Salesforce, or GitHub. From an identity perspective, everything appears correct. The real challenge begins after authentication: During execution, the agent continuously reasons, interprets objectives, invokes tools, retrieves information, and adapts its behavior based on new context, and security teams must determine whether those actions remain aligned with the user's intent and organizational policy. Authentication verifies who an AI agent is. Runtime trust continuously verifies what it is doing.

Enterprise AI is becoming an autonomous workforce

Modern AI agents increasingly interact with large language models (LLMs), Model Context Protocol (MCP) servers, retrieval-augmented generation (RAG) systems, vector databases, enterprise APIs, SaaS platforms, and internal knowledge repositories, as well as other AI agents. This interconnected ecosystem enables sophisticated automation but dramatically expands the attack surface: A single compromised tool, poisoned knowledge source, overly permissive API, or manipulated prompt can influence downstream decisions across an entire workflow, and unlike traditional software, these risks evolve during execution rather than being fixed at deployment.

That expanding surface is exactly what a handful of runtime threats exploit.

Goal drift happens when an agent begins with a legitimate objective but gradually deviates from the user's original intent while attempting to optimize outcomes. An agent tasked with preparing a customer report, for instance, might autonomously retrieve unrelated confidential information because it incorrectly determines that additional context would improve the response.

Excessive tool invocation is what happens when autonomous agents with access to numerous enterprise tools call unnecessary APIs, modify configurations, access sensitive repositories, or perform administrative actions simply because the model believes those actions are useful, absent any runtime controls to stop it.

Memory poisoning exploits the persistent memory that improves personalization: Attackers can intentionally insert misleading instructions into long-term memory or retrieval systems, causing future decisions to be influenced by malicious or outdated information.

Context manipulation takes advantage of how heavily LLMs depend on context: If attackers influence retrieved documents, system prompts, conversation history, or external data sources, they can indirectly steer autonomous behavior without ever compromising the underlying model. MITRE's ATLAS framework catalogs this kind of adversarial behavior against AI systems in useful detail.

Multi-agent amplification emerges as organizations deploy specialized AI agents that collaborate: If one agent behaves incorrectly, downstream agents may trust and amplify those actions, creating cascading failures across enterprise workflows.

Introducing runtime trust

Runtime trust extends security beyond authentication by continuously validating AI behavior throughout execution. Rather than assuming authenticated agents remain trustworthy indefinitely, it continuously evaluates whether autonomous decisions remain aligned with organizational policy. A runtime trust architecture rests on several complementary capabilities.

Intent validation evaluates, before executing sensitive actions, whether proposed behavior still matches the user's original objective: Is this action necessary? Is it expected? Does it exceed the requested scope? Would a reasonable human perform the same action?

Behavioral monitoring observes tool usage, API activity, reasoning patterns, execution frequency, delegated actions, and abnormal workflows, so unexpected behavior becomes immediately visible rather than remaining hidden inside model reasoning.

Policy enforcement means enterprise policies govern what AI agents can do, not merely what they can access — blocking financial transactions above approval thresholds, preventing privilege modifications, restricting administrative operations, limiting sensitive data retrieval, and requiring approval for high-risk actions. These controls function much like application firewalls for autonomous decision-making.

Least-privilege execution means AI agents receive only the capabilities necessary for the current task. Instead of granting permanent access to dozens of enterprise tools, organizations should dynamically issue short-lived permissions based on runtime context, an approach that OWASP's guidance for agentic applications increasingly emphasizes (OWASP GenAI Security Project).

Human oversight recognizes that not every decision should be autonomous — high-impact operations, including financial approvals, identity changes, regulatory actions, or customer-impacting decisions, should require explicit human confirmation before execution.

Protecting the enterprise AI ecosystem

Runtime trust also extends beyond individual agents. As MCP adoption accelerates, enterprises should verify trusted servers, authenticated tools, approved capabilities, monitored interactions, and policy enforcement. RAG knowledge repositories require document integrity, source validation, access control, retrieval auditing, and poisoning detection. Persistent AI memory should implement lifecycle management, expiration policies, integrity verification, access logging, and sensitive data protection.

Building operational visibility

One of the biggest challenges in enterprise AI is observability. Security teams need visibility into why an agent selected particular tools, which data influenced its decisions, how it reached its conclusions, what actions it executed, whether policies were triggered, and which safeguards prevented unsafe behavior. Runtime logging, audit trails, and behavioral analytics are becoming essential components of enterprise AI operations, not optional add-ons.

A practical roadmap

Organizations do not need to rebuild existing security programs. Instead, they should extend them by incorporating runtime trust into existing governance processes. Practical first steps include inventorying AI agents and their capabilities, applying least-privilege access to tools and APIs, classifying high-risk autonomous actions, implementing runtime policy enforcement, monitoring behavioral anomalies continuously, protecting memory and RAG data sources, requiring human approval for critical operations, and integrating AI runtime telemetry into existing SOC workflows.

Looking ahead

Enterprise AI will continue evolving toward increasingly autonomous systems capable of collaborating, planning, and executing complex business processes. Security strategies must evolve alongside them. The question is no longer whether an AI agent successfully authenticated. The more important question is whether it continues to behave safely throughout its entire lifecycle. Organizations that adopt continuous runtime governance today will be significantly better positioned to deploy autonomous AI responsibly, reduce operational risk, and build the confidence necessary for large-scale enterprise AI adoption.

The future of AI security will not be defined solely by stronger models or better authentication. It will be defined by our ability to establish, measure, and continuously verify trust while intelligent systems are making decisions in real time.

Ravindra Annam is a cyber security architect.

There is a clear repeating trend in agent deployments: The gateway is the first control teams reach for, but it is the one they are least ready to run. This is because gateways sit on top of identity and attribution layers that are mostly not there.

The first layer of risk is not hypothetical. In June, CISA added a LiteLLM flaw to its Known Exploited Vulnerabilities catalog after attackers were caught abusing it in the wild. The bug ran commands on the host through the gateway itself, and chained with a second flaw it required no credentials. It was one of seven common vulnerabilities and exposures (CVEs) disclosed in that single AI gateway in a month. This is the layer many enterprises reach for first to secure their AI agents.

When considering secure agent architecture, gateway controls should not be the first control. They should be the fifth.

Most models on the maturity of agent security describe the controls a company will need in the future. They tend to miss, from my experience, the more difficult problem of describing the brownfield scenario: In what order should these controls be layered in conjunction with an identity and access management system that is already in place?

If the control plane is unaware of which agent is acting, who delegated the work, what task the agent is to perform, and what credentials are being used, then the context is incomplete. A gateway may block clear policy violations, but will struggle to distinguish a justified action from one that is technically permissible but operationally inappropriate.

The pattern of failure is clear when sequencing these controls for agent production deployments: Enforcement is taken early, while the identity and attribution context it depends on has yet to be developed. Agent security functions as a dependency chain, with each control depending on context generated upstream.

The wrong starting point

Think about routing agent traffic via a new runtime gateway. A finance-reconciliation agent tries to alter a record in production. The gateway authenticates the user token and checks the API call. What it can't observe is that the request is agent-initiated, that the agent is executing a more limited function, or that the request is part of a tool chain invoked by an untrusted artifact.

The credential is valid. The API call is permissible. The action contradicts the purpose of the delegation. The gateway is there, but its set of supports seems absent, so a costly control is applied to a very small part of the whole picture.

Limiting an agent's privileges to those of the human principal is useful so the agent does not exceed the person it serves. However, having a privilege ceiling does not create separate attribution. Twenty agents might operate under a single person's permissions and still need unique identities, audit logs, behavior profiles, and revocation paths.

Dependency-gated deployment

I call this process dependency-gated deployment. Upstream exit tests must be satisfied before any downstream control is considered operationally complete. Concurrent development of downstream controls is permissible.

Here are the six gates, and the proof that they work:

The six dependency gates for the agent security controls. Each control is contextualized by the gates above it. From the author's analysis of production agent deployments.

Start with the agents you can actually name

To begin, recognize the production agents in open-source frameworks, cloud offerings, SaaS services, and developer tools. For each, record the owner, responsibility, lifecycle stage, allowed tools, data domains, and sources of credentials.

Bypass this step, and the organization will lose the first hour of incident response while they figure out what should have been obvious. The inventory identifies the asset that every control thereafter governs.

An agent needs its own identity, but it cannot lose the human behind it

An agent should not be buried in a developer token, a shared service account, or a human session. Simply knowing the caller is an agent is not sufficient. The control plane requires additional delegation context: Who delegated the work, what specific task the agent was instructed to execute, and which resources the agent needs the authority to access. Identity specifies which actor placed the call. Delegation is the answer to whose authority it acts, and for what reason.

Once that connection is cut off, the downstream logs attribute the reconciliation agent to the employee whose token it borrowed, and every action it takes is attributed to someone who did not start it.

Shrink authority before you inspect behavior

Once an agent can be identified, capabilities should be limited. Access restrictions should be time-bound to the task and limited to the tools and resources required to perform the task. This can be implemented using identity access management (IAM) features such as workload identity, token exchange, conditional access, and time-bound entitlements which the organization already possesses.

With regard to the 2026 Teleport study involving 205 security leaders, the access scope surpasses the predictive capacity of industry, maturity, or self-assurance concerning predicting AI-related incidents. For example, organizations with over-privileged AI reported a 76% incident rate, whereas AI incidents occurred in 17% of organizations under the least privilege. This indicates that access scope in the dependency chain is more important than context-aware runtime enforcement.

The primary principle is monotonic delegation. Every transfer of responsibility must preserve or diminish authority; under no circumstances should it increase authority. For the reconciliation agent, this means an agent who can view one ledger as opposed to one who inherits the employee's access to all systems the employee can access.

Fix attribution before automating enforcement

Most audit stacks can capture what resource was accessed and which credential allowed access. In the agent deployments I have reviewed, this is the most commonly missed gate. Prior to utilizing an adaptive runtime policy, link any relevant tool invocation to the agent identity, initiating principal, task id, parent action, and outcome. After doing so, examine the telemetry: For one completed task, see if you can track down the initiator, the agent who executed it, the authority under which the action was taken, the tools utilized, and the outcome. In regulated environments, oversight that is not attributed cannot be justified.

Now the gateway earns its keep

The gateway can use registered identities, explicit delegation, scoped credentials, and attributable telemetry to question if this agent is authorized to perform this action, for this principal, within this task, involving this resource. Although the user's credentials may provision write access to the finance-reconciliation agent, the gateway has situational context and so determines that it is out of scope. This is control's point of greatest value. The most stringent controls should be applied at irreversible boundaries — payments, access policy changes, deletions, modifications of the production environment, and data exports.

Detection and the kill path come last

Behavioral baselines are developed last because distinguishable and attributable agent activity must be established to set a standard. Then, security teams are able to identify anomalous patterns of tool usage, unexpected cross-domain access, and deviations from their assigned tasks. Containment is more than just the disabling of a single directory object: A proper kill path entails disabling the agent's identity, invalidation of active and derived credentials, blockage of tool activation, termination of active tasks, and isolation of the workload that contains the agent.

Start without replacing your IAM

Designing a whole new identity program is unnecessary. If the existing identity provider doesn't treat agents as native object types, begin with an authoritative registry linked to the existing workload identities. Following this, extend agent and task identifiers as trusted execution contexts, implement short-lived credentials to mitigate inherited privileges, and include those identifiers in tool-call logs for subsequent gateway ingestion. The dependency model remains unchanged as vendor support matures.

Control gaps are measurable. In Okta's 2026 survey, only 34% of executives said their organization always applies the same level of security rigor to its agentic workforce as to its human workforce. The last control from the chain cannot be applied first to close that gap.

What to do in the next 30 days

Begin with 10 production agents. For each one, identify the owner, purpose, approved tools, and credentials. By now, you should have the beginnings of an agent registry and perhaps your first insights on governance.

Test attribution. Find out if IAM and logging can tell each agent apart from the human or service that delegated the task. If this kind of differentiation is not possible, a gateway would be operating without any visibility.

Reconstruct one completed agent task within an action chain, from start to finish, including downstream effects. Wherever the chain breaks is where your deployment falls short.

Adding downstream enforcement ahead of required context breaks agent security. Maturity models describe the destination. A build order gets you there without breaking production along the way.

Nik Kale is a principal engineer specializing in enterprise AI platforms and security.

Presented by Nutanix

Autonomous systems that can reason, make their own decisions, and execute actions across an environment introduce a category of risk that application-level controls were never built to contain. Treating that risk as a single problem produces incomplete architectures, says Oscar Wahlberg, senior director of product management at Nutanix.

"The guardrails to catch a malicious prompt won't stop an agent from hallucinating and doing something it never should have done, like accidentally deleting databases or leaking sensitive data with a credential it was granted but then uses for something entirely different," Wahlberg says. "That's the central problem as enterprises move autonomous agents out of experimentation and into production."

Once an agentic system is granted execution privileges across the data center, the security posture has to scale into a defense-in-depth architecture spanning infrastructure, storage, compute, networking, and a governing control plane. Each layer addresses a distinct category of risk, rather than duplicating the same controls across the stack. No single security control or vendor can provide that protection on its own. Defense-in-depth depends on those layers working together.

By dividing the responsibilities across the stack and adhering to zero trust segmentation, organizations can create a secure framework that improves their overall posture. Understanding which risks belong in each layer is what turns the principle of defense-in-depth into a practical security framework, with three layers that each have a distinct responsibility.

Infrastructure layer: Establishing trust where AI agents run

The infrastructure layer’s foundational responsibility is establishing a root of trust that answers a simple question: who is operating in the environment? That trusted identity becomes the prerequisite for every security control above it. Before an organization can trust what an agent does, it first has to trust the integrity of the environment where the agent runs. When an agent requests permission to execute an operation, the system must be able to verify that the request came from the legitimate agent — not something impersonating it.

Delivering that kind of assurance depends on technologies that root trust in the hardware itself, including platform attestation, confidential computing, and secure boot, alongside controls that prevent unauthorized access both within a server and beyond it. For regulated industries such as financial services, this layer provides the ability to isolate AI production workloads so that neither the agent nor the environment can operate outside its assigned scope. That mitigates risks including model and runtime tampering, supply chain compromise, and unauthorized access to sensitive AI workloads.

Network layer: Governing how AI agents communicate

Once agents begin communicating with other agents, APIs, applications, and enterprise systems, they generate a level of concurrency and dynamic communication that traditional static network configurations were never designed to handle. An agent configured to call APIs, query data sources, and spin up additional agents without constraint creates a sprawling web of east-west traffic that becomes very difficult to reason about, and that complexity can easily mask lateral movement or data exfiltration when the right network security layers are not in place.

"We should treat AI agents as a new class of network identity, and make sure that an agent can only talk to other agents or data sources where it's explicitly allowed to do so," Wahlberg says. "That means moving away from rigid static rules toward dynamic policy enforcement."

Nutanix's solution is Agent Gateway, part of the Nutanix Agentic AI solution. It's a unified, governed layer that is designed to provide cost control and governance capabilities to help manage autonomous agent users. Coupled with agents grounded in zero trust segmentation and using capabilities like Nutanix Flow for micro segmentation and integrating with networking vendors, including its integration into the Cisco Secure AI Factory, Agent Gateway helps enterprises govern interactions across agents, models, data sources, and enterprise applications.

The network layer governs lateral movement, data exfiltration, and gates the agent's network interactions. A zero trust framework with access blocked by default and scalable interaction monitoring is important for agents since they can exhibit unreliable behavior. The Nutanix software integration with Cisco UCS servers and Cisco AI PODs delivers the turnkey physical infrastructure (compute, storage, and networking) that the AI factory runs on.

Control plane layer: Governing what AI agents are permitted to do

The control plane is the brains of the operation, providing a central point for managing agent permissions, tool access, resource consumption, and runtime visibility. What matters most is having a single place where policies can be enforced consistently rather than reinvented for every agent, Wahlberg says.

"Agent Gateway acts as a universal endpoint for different models and tools, so an IT team can configure their agents to talk to this single control point," he explains.

The centralized AI gateway enables the admin to observe, audit, and control access to models as well as MCP tools protecting data and gating privileged access. This layer is designed to help mitigate risks such as privilege misuse, runaway agents, unauthorized tool usage, data leakage, and the excessive model consumption that can lead to increased token consumption when agents get stuck in runtime loops. And it depends on treating governance as a runtime control system rather than a compliance afterthought.

Why one-size-fits-all security fails agentic AI environments

The biggest architectural mistake enterprises make is assuming a single security model can be stretched across every layer of an AI stack. When an organization tries to solve for hardware-level trust with application-level software, or leans on static legacy network rules to manage dynamic agents, it builds an architecture that either blocks the agentic system from doing its job or leaves critical doors wide open. One-size-fits-all thinking tends to produce significant performance penalties and operational friction.

"By failing to assign specific responsibilities to the appropriate layers, enterprises end up with blind spots in governance," Wahlberg says. "They might secure the model output but miss that there's data leakage between agents, or they might secure the network but lack the control plane visibility to understand that they're wildly burning tokens because the agents are stuck in some kind of runtime loop."

Focusing exclusively on the model leaves the largest gaps of all, because a guardrail that catches a malicious prompt does nothing to stop a hallucinating agent from misusing a legitimate credential. Embedding security across the full stack helps ensure that even when a model level threat slips past the initial filters, the agent remains constrained by hardware rooted trust, network isolation, and access controls at the agent layer.

How Intel, Cisco, and Nutanix build defense-in-depth together

The three-way partnership from the three companies demonstrates how the layered architecture comes together in practice as a well-governed, enterprise-grade AI Cloud. Intel supplies the computer to run agentic workloads and secures the execution environment through hardware-rooted trust and confidential computing, while also driving costs down through their accelerators. Intel Xeon 6 processors with built-in AMX accelerate AI inference efficiently without relying exclusively on expensive GPUs.

Cisco wraps the environment in a secure fabric that governs communication between agents and enterprise tools, while Nutanix provides the software platform, minimizing architectural silos, and the central control plane that enforces permissions, delivers visibility and cost governance, and ties the architecture together into a defense-in-depth solution that lets enterprises scale agentic AI.

Of the three layers, enterprises currently underestimate the control plane the most, Wahlberg says. A true control plane extends far beyond initial deployment to simplify Day 2 operations, he explains, giving IT teams the continuous observability, and strict token governance required to keep autonomous agents secure and cost-effective in production.

"Apart from model and tool selection, governing the agent deployments and their access to models and business tools in a tightly integrated full stack platform will be important for the success of AI projects," he says, pointing to a near future in which organizations move from a handful of AI use cases to thousands of agents working autonomously to drive the business.

Technology leaders should prioritize building a centralized governance layer today that can manage agent identities, tool permissions, and token budgets in real time, because that control point is what builds the operational muscle to scale safely.

"You can't build an AI system without getting into a lot of complex decisions," he explains. "And you need a control plane that talks across multiple vendors and infrastructures to help you solve for those defense-in-depth strategies."

Learn more about the Nutanix Agentic AI solution here.

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.

Consider an AI agent tasked with a complex enterprise workflow like migrating massive batches of customer records from a legacy CRM to a cloud database. The agent cannot rely solely on its internal context window for a job spanning hours and depends on the runtime layer, aka the harness.

This harness provides execution feedback, like server logs, to help the agent maintain an accurate understanding of dynamic API connections. It also provides state trackers and control-flow mechanisms to manage completed and pending subgoals, ensuring the agent doesn't skip or duplicate data batches. When unexpected errors occur, such as a database rejecting a batch due to strict API rate limits, the harness provides tools and instructions to help the agent recover.

The main way to tell an agent how and when to use its tools is to have a human developer write a set of rules and instructions telling it what to do step-by-step. For example, a developer might instruct the agent to always search the company wiki before writing an email. Because the agent is just following a rigid script, it lacks true autonomy. It hasn't been trained to independently weigh the costs and benefits of its actions.

To solve this, researchers at Meta AI and University of Illinois Urbana–Champaign introduce EvoHarness-RL, a framework that adds a layer of abstraction to the agent's harness and teaches the underlying model when to read, update, or consolidate the information it obtains from its environment.

In long-horizon tasks, how AI agents read and process the information they obtain from their environment is pivotal to their success. The agent must update its understanding of its environment, track completed and pending subgoals, recover from failed actions, and reuse procedures from previous experience. This execution depends on the harness.

A series of self-evolving agentic frameworks like Harness-1 solve part of the problem by accumulating past trajectories and distilling them into structured procedural memory, like reusable skills, workflows, or code libraries for future tasks. However, they generally separate this long-term skill curation from real-time, within-episode state tracking. They aren't actively training the agent on how to manage its immediate environmental reality or track its active task steps while working.

Xuying Ning, co-author of the EvoHarness-RL paper, told VentureBeat that manual logic and rigid memory structures are primary culprits draining engineering resources.

"The optimal harness often changes with the model," Ning explained. "Different models may need different prompts, memory designs, permissions, or sandbox configurations. If all of this logic is manually coded, every model upgrade can lead to another long cycle of tuning and debugging."

Furthermore, existing memory systems that simply accumulate experience can actively degrade an agent's reasoning. "Append-only memory assumes that more context is always helpful, which is not necessarily true," Ning said. "Over a long task, the memory may contain outdated conclusions, failed attempts, or information that is no longer relevant." As a result, long-horizon agents need a dynamic memory capable of updating, compressing, and replacing information to avoid repeating past mistakes.

EvoHarness-RL: A unified belief, progress, and experience workspace

To overcome the limitations of rigid, manual prompts, the researchers introduce EvoHarness-RL, a training technique that teaches the agent to make optimal use of its harness. Instead of blindly following hardcoded instructions, the agent learns how to construct a structured workspace from messy execution data and decide when and how to consult that external state during complex workflows.

To simplify the management of different components of the harness, EvoHarness-RL consolidates the agent’s support systems into a single, unified interface. This interface, known as the Belief, Progress, and Experience (BPE), categorizes the agent's external needs into three functional areas:

• Belief: Maintain an accurate read on the current environment.

• Progress: Manage completed and pending subgoals.

• Experience: Reuse historical knowledge across tasks.

Instead of using complex, domain-specific APIs, the AI interacts with this clean dashboard using four compact meta-actions: track, commit, recall, and note. It issues commands to track the live environment, commit to workflow updates, recall past strategies before acting, and write notes to save newly discovered insights for future runs.

These states map directly to high-value enterprise verticals. "In software engineering, Belief can represent the agent’s current understanding of the repository," Ning said, detailing how the agent monitors component interactions and workspace changes. "Progress tracks what has already been completed, what still needs to be done, and which steps depend on others." Meanwhile, Experience captures lessons, like user feedback on a mistake, to guide future actions.

The same idea applies to finance, Ning said. During a compliance audit, Belief might describe the applicable rules and available evidence. Progress tracks which checks have been completed and which exceptions remain open. Experience helps the agent recognize recurring discrepancies or know when an issue should be escalated.

"Together, these states help prevent the agent from losing track of its work or repeating the same failed approach," Ning said.

To teach the agent both the mechanics and the strategy of managing its external workspace, the researchers designed a two-stage training recipe. In the first stage, supervised harness fine-tuning, the base model learns how to extract and structure useful facts from messy interaction logs into the BPE framework.

However, querying memory or updating trackers consumes time and compute tokens, meaning the agent cannot afford to blindly check its tools at every step. To solve this, the second stage uses “cost-aware” reinforcement learning to teach the agent efficiency. This phase trains the agent to calculate when accessing its external state is worth the budget cost. This two-step process transforms tool-use from a rigid, hardcoded prompt into a learned runtime behavior.

EvoHarness-RL in action

To validate EvoHarness-RL, the researchers evaluated the system using the ALFWorld benchmark, a text-based environment featuring multi-step tasks that test sequential logic and state tracking.

They used Qwen3-8B as the base model to train. The team pitted the trained 8B model against three large frontier models (Claude Opus 4.5, GPT-4.1, and GPT-5), frozen agent frameworks with static tools (such as ReAct, ExpeL, and ReasoningBank), and advanced trainable methods (e.g., standard GRPO, SkillOS, and SkillRL).

The results show a significant jump in performance for smaller, cost-effective models. With EvoHarness-RL, the Qwen3-8B model achieved a 96.9% average success rate, a 49.0 percentage point improvement over its baseline ReAct counterpart.

Furthermore, the trained model outperformed advanced trainable frameworks like SkillRL (89.9%) and SkillOS (80.2%). Most impressively for enterprise developers looking to optimize compute costs, the 8B model effectively matched the performance ceiling of expensive closed models like Claude Opus 4.5, which scored 96.4% out-of-the-box.

Beyond empowering smaller models, the experiments show that the BPE framework has universal benefits across all model scales, even without the extensive reinforcement learning phase. When researchers equipped frozen, out-of-the-box frontier models with the BPE prompt-time harness, their execution improved significantly. GPT-4.1's success rate improved by 22.1 points and GPT-5 by 25.7 points.

Aside from the results, the researchers recorded effects during the experiments that demonstrate the dynamic behavior the LLMs acquire as they go through the EvoHarness-RL training. During the reinforcement learning phase, they observed a behavioral shift as the agent internalized knowledge over time, which they called "harness annealing". 

Early in training, the AI relied heavily on querying its Experience and Progress trackers for almost every step. However, as it mastered routine actions, it actively reduced its reliance on external tools, embedding the successful patterns directly into its parameters. In a real-world enterprise setting, this translates directly to lower latency and reduced compute costs. By annealing its tool usage, the AI stops wasting tokens and time querying databases for standard workflows it has already mastered.

Simultaneously, the agent demonstrated "harness evolution," where it dynamically adapted its strategy based on the complexity of the situation at hand. While it bypassed its tools for simple, familiar tasks, it actively chose to scale up its use of the Belief and Experience modules the moment it encountered novel environments or unexpected roadblocks. For example, if an AI agent is migrating standard database records, it moves fast. When it encounters a strange legacy API endpoint or a complex validation error, it slows down, pulls up the live server logs, and queries its historical tickets to safely resolve the edge case rather than hallucinating a guess.

Bringing EvoHarness-RL into existing systems

Despite these massive gains, adopting a new framework often introduces friction for enterprise engineering teams. However, EvoHarness-RL utilizes an environment adapter that allows internal implementations to remain domain-specific to an organization's existing tools while sharing the trainable layer.

"I think there is significant potential to integrate BPE into existing orchestration systems," Ning said. "It does not necessarily require teams to replace their current tools or agent frameworks. BPE can work as an additional state-management layer that continuously organizes what the agent currently believes, how far it has progressed, and what it has learned."

For enterprise builders worried about inference costs, the framework addresses the hidden engineering cost of consolidation. Because consolidation requires strong reasoning, teams can adopt a hybrid, asynchronous architecture to optimize budgets.

"One possible compromise is to use a frontier model to generate high-quality consolidation data, then fine-tune a capable open-weight model to handle routine state management," Ning said. Furthermore, "because consolidation can happen asynchronously, it does not always need to slow down the agent’s main execution loop."

Teams must also carefully evaluate when a trainable BPE harness is necessary versus when it is overkill.

"For a short and stable task, ReAct or standard RAG may already be sufficient," Ning said. "BPE becomes much more valuable when an agent works for many hours, days, or even weeks." In those complex scenarios, an agent needs a compressed understanding of its decisions to avoid getting lost, relying on Experience to iteratively improve from previous failures and human feedback.

Ultimately, this approach signals a shift for AI orchestration engineers. "It is not a complete replacement of workflow engineering," Ning said, "but a transition from directly scripting agent behavior to creating systems in which better behavior can be learned."

Enterprises trying to feed PDFs, slides and scanned documents into AI pipelines keep running into the same wall: the tools either miss the structure — tables, charts, layout — or cost too much to run at scale.

Cohere released Parse 5 on Thursday, positioning it on price-to-performance, not raw accuracy — the right cost-capability mix for enterprise scale. Parse 5 is a 2.3-billion-parameter vision language model built to convert PDFs, slides and images into structured Markdown at enterprise scale. 

Cohere's own published benchmark comparison puts Parse 5 behind three larger, general-purpose frontier models on accuracy. GPT-5.5, Opus 4.8 and Gemini 3.5 Flash all score higher than Parse on the three ParseBench dimensions Cohere reports. Cohere is not claiming the top score. It is claiming the best price for a score close to the top.The company priced the model at $1.50 per 1,000 pages through its API, with Model Vault, Cohere's secure, single-tenant platform for managed inference, available for higher-volume deployment.

"Document parsing isn't solved because the hard part isn't reading text, it's preserving structure and meaning," Nils Reimers, VP of AI Search at Cohere, told VentureBeat. "Enterprise documents mix tables, diagrams, charts, and formatting that change the interpretation of the data. Most tools still drop structure or hallucinate content, and even frontier models break on layout‑heavy pages."

Inside the single-pass architecture

Parse 5 takes a page as an image, runs it through a single vision-language model pass and returns structured Markdown, collapsing the OCR-plus-model pipeline most tools run as separate steps.

Architecture. It is a 2.3-billion-parameter vision language model built on Cohere Labs' North-Micro-Vision-Instruct architecture, with an 8,192-token context window and roughly a 4.6-gigabyte footprint. It accepts a PDF, PowerPoint or JPEG page as a base64-encoded image and returns Markdown in reading order, with tables rendered as HTML, image descriptions and bounding box coordinates for tables and images.

Language coverage. Arabic, English, French, German, Italian, Japanese, Korean, Portuguese and Spanish get stable accuracy, with lower-accuracy zero-shot support elsewhere.

Output modes. The default output returns a Markdown string per page. A blocks mode returns typed elements, where each table carries its own HTML, bounding box and description, the format Cohere positions as what makes citation-level traceability possible for agents.

Availability. Parse 5 is generally available now through the Cohere API, Model Vault, Microsoft Foundry and AWS SageMaker.

The benchmark shows a trade-off, not a win

ParseBench is a benchmark that scores document-parsing tools against human-verified enterprise pages. Cohere reports Parse 5 scoring 79.2 across three dimensions: tables, content faithfulness and semantic formatting. That puts Parse 5 behind GPT-5.5 (84.4), Opus 4.8 (84.3) and Gemini 3.5 Flash (81.8), and ahead of LlamaParse's Cost Effective tier (78.3), Mistral OCR 4 (74.5), Databricks AI Parse (72.4) and Azure Document Intelligence (69.3).

Cohere's table notes two excluded dimensions, Layout and Chart, and attributes both to product scope rather than a performance gap. Parse 5 returns reading-order Markdown instead of per-element bounding boxes for text, and describes charts rather than extracting their underlying data, with chart-data extraction planned for a future version.

Reimers said that design choice reflects where agentic workflows actually break.

"For charts, for example, we provide a general description of the chart together with an indicator, how Agentic AI can visually inspect the chart," Reimers explained. "Other solutions try to extract the data from the chart, but then miss out critical information (for example, the color or the pattern of a line) that leads to hallucinations in Chat and Agentic AI applications."

Cost is where Cohere makes its real case. Reimers pointed to a workflow the company modeled for a large financial services firm.

"We ran the numbers for a large financial services workflow that processes 750 million documents a year and showed that choosing Parse 5 over a large general‑purpose model like GPT‑5.5 would reduce costs by more than 98 percent."

That figure is Cohere's own estimate for a single modeled workflow, not an audited deployment.

Where Parse 5 sits against the field

There is no shortage of options for enterprises looking at parsing solutions.

General-purpose frontier models, GPT-5.5, Opus 4.8 and Gemini 3.5 Flash, top the accuracy comparison but carry the cost and latency of a large model on every page. 

Then there are specialized parsers, including Mistral OCR 4, LlamaParse and open-weight options like Chandra OCR 2 and RedNote's dots.mocr.

Hyperscaler document intelligence services, AWS Textract, Google Document AI, Azure Document Intelligence and Databricks AI Parse, compete more on ecosystem convenience than on raw parsing quality, and score lowest in Cohere's own comparison.

Kevin Petrie, VP of Research at BARC US, said document parsing sits at the center of enterprise AI adoption right now.

"We're completing a survey now that shows document analysis is by far the #1 use case for AI, with 62% adoption rates among organizations we polled," Petrie told VentureBeat. "Documents and other unstructured objects, including images and so on, hold the proprietary context that organizations need to differentiate their agentic AI initiatives."

Petrie added that only time will tell how Cohere's cost-performance stacks up against frontier models, but strategically his view is that Cohere has the right focus. 

Stephanie Walter, Practice Leader for AI Stack at HyperFRAME Research, sees Cohere Parse 5 as sitting in a good spot between legacy OCR and using an expensive frontier model on every page. 

"Its potential advantage is delivering structure, spatial provenance and private deployment at a price suitable for high-volume ingestion," Walter told VentureBeat. "It does not need to win every benchmark. It needs to make reliable enterprise-scale parsing economical."

The real test is downstream, not on the benchmark

"Parsing is the first quality gate in the enterprise AI stack," Walter said. "If tables, headings, images, or reading order are lost during ingestion, better embeddings and larger models cannot recover that missing structure."

A benchmark score isn't the only input that matters here. "Enterprises should test parsers against their own most difficult documents and measure downstream retrieval and task accuracy, not how clean the extracted text looks," Walter said. "The right question is not 'Did it read the PDF?' but 'Can the agent now use the information correctly?'"

Presented by Gravitee

Agent complexity is the insidious shadow lurking inside enterprises right now that needs a light shone on it.

That’s because enterprises don't deploy a single agent and watch it run, they deploy fleets, each one calling APIs, calling other agents, reaching into applications that were never built with a machine decision-maker in mind. That's the failure mode that should keep you up at night: a windy, complicated system nobody can see clearly enough to govern. But why do things get so opaque so quickly?

Add a second agent to a system, and you've added one connection. Add a tenth, and you haven't added ten connections, you've potentially added dozens, because now any agent might call any other, and each of those calls can trigger a call somewhere else. Complexity doesn't creep up with agent headcount. It compounds with the number of paths between agents, and nobody's job is to draw that graph. A support ticket that used to touch one system might now pass through four agents before a human ever lays eyes on it, and every one of those handoffs is a decision point nobody approved.

Most enterprise AI programs stall when the humans responsible for their agents lose the thread. Ask a security team a simple question: which agents can reach which systems, and watch the silence. Ask which agent triggered which downstream action three hops ago. More silence.

The instinct is to treat this like a checklist. Approve the agent. Log the agent. Move on. I'd argue this is the wrong instinct. A checklist checks a single point in time. Complexity runs across a chain, and you can't govern a chain with a stack of one-time approvals any more than you can call a diet successful because you had a vegetable once.

So where does it actually break down?

Permissions creep first. Somebody builds an agent to summarize support tickets, grants it broad API access because scoping it properly would've taken another sprint, and forgets about it. Six months later, that same agent has a path into the payments system. Nobody remembers signing off on that. Nobody did.

And ownership thins out the further the chain runs. Five agents touch one workflow, something breaks at step four, and now you're asking who's responsible for a link nobody was ever assigned to own, because the org chart stopped at "deploy the agent" and never got to "name the human who answers for it."

This is a story about governance infrastructure that hasn't caught up with how agents actually behave: interconnected, cascading, multiplying faster than the processes built to track them.

Fixing the cluster starts with identity. Every agent needs to exist as its own entity, not a shadow permission borrowed from whoever deployed it. Its own name in the register. Its own scoped authority. A named human sponsor who answers for what it does. That part is necessary.

But it is nowhere near sufficient.

The harder piece is the oversight that holds across the entire chain, not just at each individual link in it. You need to see what an agent did, what it set off downstream, and where that trail ends in real time, not in a report someone pulls together once a quarter. Get agent-level identity right and stop there, and you end up with a filing cabinet full of perfectly documented agents operating inside a system nobody can actually explain.

And oversight by itself only tells you what already happened. Watching a chain isn't the same as controlling it. Enforcement is the piece most programs skip: the ability to stop an out-of-policy call before it executes, not just log it for someone to find in a review three weeks later. A dashboard that shows you an agent breached its scope five minutes ago is a monitoring tool. A system that stops the breach from happening in the first place is governance. Enterprises serious about agent accountability need both, and most have only built the first.

We're all running at blazing speed to ensure we're not the ones left behind in the race we've found ourselves in, and we're all too aware that there's a cost to slowing down. Every enterprise serious about agentic AI hits the complexity wall eventually. The ones that get past it are the ones who built enough visibility and accountability, so their fleet can keep growing without anyone losing the ability to answer one question: what is this system doing right now, and who's responsible for it.

But don't miss the point. Complexity isn't a reason to pump the brakes. The enterprises getting this right aren't slowing down. They're building toward Human-Agent Harmony, where scale and accountability grow together instead of trading off against each other.

The real risk was never a single agent doing exactly what it was built to do. It's a hundred of them doing exactly that, all at once, interacting in combinations nobody designed for. That kind of multiplication is what keeps enterprise AI stuck running pilots forever instead of running production.

Solve for complexity and autonomy stops being the villain. It starts being the whole point.

Rory Blundell is CEO at Gravitee.

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.

Visa's open-source security harness now finds the vulnerability, writes the fix, and turns an adversarial panel on its own patch before any human reviews it. The whole loop ships on by default. A plain scan of the Visa Vulnerability Agentic Harness runs all 11 stages and edits source files in the target repo unless the operator caps it at detection.

The announcement Thursday pairs the release with an expansion of the Visa Consulting & Analytics advisory practice. Visa is shipping that default 18 days after Tenet Security demonstrated GhostJacking on the DEF CON 34 main stage, an attack chain in which an agent read an attacker's payload out of a log file and rewrote DNS with a valid credential. Two days earlier, Steve Wilson, Chief AI and Product Officer at Exabeam and project co-lead for the OWASP Top 10 for LLM Applications, made the case in VentureBeat for the opposite default. "The first thing I'd do is put an authorization gate outside the model," Wilson said in written responses. "The agent can propose the exact DNS change, but it cannot grant itself the authority to make it."

The bottleneck moved, so Visa moved the pipeline

Rajat Taneja, Visa's president of technology, rejects the premise that the default is a risk decision and calls it the product. "The bottleneck has moved," Taneja told VentureBeat in an exclusive interview. "AI is finding vulnerabilities faster than humans can in the history of our technology industry. The new bottleneck is fixing and proving we have fixed things."

VVAH grew out of Visa's participation in Anthropic's Project Glasswing, where the company aimed Claude Mythos at the network behind billions of daily transactions and watched the model chain minor weaknesses into working exploits, a hunt VentureBeat covered in July. "VVAH initially was completely only using Mythos, and that's when all of us, as part of Project Glasswing, realized the power of this new class of models that does semantic reasoning," Taneja said.

The harness went to GitHub in June and has climbed from 595 stars and 97 forks on July 20 to more than 2,300 stars and 300 forks as of August 25, with a clone-to-visitor ratio Taneja put near 9%. "We have got some very high-profile companies that have started using this harness," he said.

Why give it away? Taneja's answer starts with Visa's technology DNA and a harness built "to protect Visa and our ecosystem." The reason he leaned on hardest was obligation, "to do good by doing right" for "companies who may not have the same level of investments or knowledge in cybersecurity."

Contribution runs one way. The repo states it is not currently accepting external code contributions, so the harness that edits adopters' source takes no code into its own.

Thursday's release extends the pipeline past the report. "We're going from discover, verify, and report, and then fix it, to discover it, verify it, remediate it, validate it, and iterate it," Taneja said. "If a fix doesn't negate the exploit, then there should be a structured, automated feedback that preserves the learnings from the first run and then enhances it." Underneath that loop, the release refactors scanning around an abstract syntax tree call graph that maps subroutine calls and the traversal paths an attacker could reach. Taneja argued the change cuts token counts while delivering "better reasoning, context, and better exploitability analysis." On top sits MTTA observability across the stages, what he called a window pane, plus real-time progress views. "A pretty good step function," he said of the release.

One metric, three definitions

Mean Time to Adapt, the metric Visa invented alongside the harness, gets a shorter definition in this release. The short form is the time between discovery and resolution of attack paths, with some resolutions, Visa claims, shrinking from weeks to hours. Visa published a wider construction in June, and the Project Glasswing white paper tracks MTTA along three dimensions that include inventory freshness, exploitable paths per release, and validation cycle time. The repo carries a third, elapsed time from AI-discovered exploitability to a validated fix in production. Board slides will quote the shortest interval. Ask for all three, because a resolution count that skips validation is what MTTA was invented to replace.

Taneja ranks MTTA as "the most strategically important metric" because it shifts the focus from scanning to how fast an enterprise adapts. His shorthand is blunter. "It's not the finding. It's the fixing that matters," he said.

The default and the gate

Wilson's argument went past naming the gate. "We have to remember that security rules written inside prompts may shape the model's behavior, but they are still suggestions to the model, not enforceable security controls," he wrote. He also priced the control honestly. "The tradeoff is that the agent loses the ability to improvise arbitrary, high-impact infrastructure changes on its own, while retaining autonomous investigation and routine, bounded remediation," Wilson said.

The harness ships no approval step between patch and edited file. Where the human sits was the first question VentureBeat put to Visa in writing.

The company's own June white paper sets the bar. "AI agents are identities" sits among its 12 non-negotiable practices, requiring scoped permissions, least privilege, audit trails, and IAM governance for every agent that modifies a system. VVAH's shipped default is that agent.

"A lot of the traditional systems that are used today are basically signal providers," Taneja told VentureBeat. "They are telemetry, and then it's a lot of human analysis, and your SOC and your security and incident response teams doing a lot of the heavy lifting when they respond," and that, he said, cannot work at this scale. He pointed to the Hugging Face incident and "other frontier models escaping sandboxes to do things more autonomously" as the preview. "We have seen the trailer of this movie," Taneja said, and "every company in the world should prepare and rethink their architecture."

What the harness automates is the adversarial step. Before a fix counts as validated, the panel scores whether the patch negates the exploit, Taneja's test for done, with failed fixes feeding the next attempt, the iterate step Taneja described. Stage 11 itself runs read-only, per the README, and VVAH does not compile, build, or run tests against the patched tree. Taneja calls that wrapper "the governance architecture on top of that," and chaining findings into working exploits takes threat modeling and business context, which is why he argued "the harness with a model is far more effective than somebody using the model by itself."

Visa answers the gate question

VentureBeat put its questions to Visa in writing after the interview, and the answers arrived before publication. On why remediation ships on, the response repeated the bottleneck argument, then narrowed the scope. "VVAH is meant for authorized operators running against code they own, and in a controlled environment," the company said in written responses.

The approval question drew the most specific answer. "VVAH is a harness, not a merge tool," Visa wrote. "Stage 10 writes candidate fixes to a working copy of the repo. Stage 11 then runs an adversarial validation panel that scores each fix and returns one of three verdicts: validated, validation failed or needs review. None of these bypasses your normal build, test, and code review flow." Humans, the company wrote, are "the gate in three places. Before running the tool. When reviewing the patches. And before anything gets merged." "The final call on any fix stays with the security and engineering teams. In an enterprise, trust and auditability are not optional. The default flow is built around that."

Set beside Wilson's standard, the architecture lands close to his line and the sequence does not. Wilson's gate clears an action before it happens. The default's human gates open before the run and after the write. The attack is the automated part, and the three human gates sit outside the model, the boundary Wilson drew. "Our goal is to help security teams work at AI speed, not to replace them," Visa wrote. "VVAH does the repetitive parts. It finds issues, tests whether they are real, and proposes fixes. Before a fix gets to a human, an adversarial validation panel at stage eleven tries to break it. That way the human is spending time on decisions that need judgment, not on triaging noise."

Client zero got direct confirmation. "VVAH runs against Visa code today," Visa wrote, and Taneja had volunteered the posture on the call. "We designed this and we were using it for ourselves, and we were client zero," he said, adding "only when we saw the impact and the positive effect of what we were finding, we said every company would need this." What adopters value, Visa says, is context. VVAH pulls in CMDB data, threat models, and business risk, and where "most tools stop at findings," it "tries to answer, 'which of these should you fix first, given how your business runs.'"

Model choice becomes a per-stage decision

Multi-model orchestration is the other substantive change. "Mythos has a very high recall, but the Opus model has very high precision," Taneja said. "On stage one I want to use this model. On stage two I want to use this model," is how Taneja framed the per-stage setup, with newer GPT releases in the ensemble and open-weight models where pricing stings, all through configuration rather than code changes. "The whole is greater than the sum of the parts," as he put it. The harness was model-agnostic from day one, he added, and the evolution moved that choice into configuration, with prompt tuning and caching shared underneath. One boundary moved. In June, applying a fix required Anthropic backends, and OpenAI-compatible backends ran report-only. The current README extends remediation and validation to OpenAI-compatible and open-weight models through a shared model-agnostic runtime, with no single provider as a hard dependency, and the default routing for both stages stays Anthropic.

That flexibility lands on a market already churning. VentureBeat's Q2 2026 Pulse research found 59% of enterprises plan to adopt or switch agent security tooling within the year, and 82% still rely on provider-native controls as the primary layer. Visa said Thursday it is contributing VVAH to Nvidia's Open Secure AI Alliance as a model-agnostic framework and collaborating in Project Lightwell, the $5 billion IBM and Red Hat effort to harden open-source components.

Before turning fix mode on

Consulting is the other half of Thursday's announcement. Visa Consulting & Analytics is adding executive workshops, a VVAH-informed maturity assessment scored on a NIST one-to-five scale, and a cyber risk prioritization roadmap. "We were getting a lot of calls. Hey, can you help?" Taneja said, and the practice "became very important to handhold and help those who are using it." Carl Rutstein, global head of Visa Consulting & Analytics, framed it the same way. "Finding vulnerabilities is no longer the hardest part. Speed to remediation is the new battleground."

Presented by EDB

As enterprises give AI agents more autonomy — the ability to plan, decide, and act across systems without a human approving each step — a hard question moves to the center of every architecture review: When an agent tries to complete an action that it was never authorized to do, what actually stops it?

These are your agents, running on your models, touching your data in your infrastructure — and the responsibility for what they do sits with you. That responsibility can’t be met in hindsight or with a set of abstract policies that live on paper but not in practice. Agents need rules in the context of the moment, because they don’t exercise overriding judgment of their own actions.

Consider a simple rule: Never open the car door. Followed literally, an agent could never get in or out of the car at all. But if you change the context (the car has just crashed, there’s a fire, someone is hurt and needs to get out), then the rule you actually want is the opposite. Context in the moment is everything. We are asking agents to do intelligent things; that requires intelligent rules.

The instinct is to add guardrails around the agent: instructions, policies, and monitoring layered above the model. Those mechanisms matter, but they share a structural limit: The car-door rule is plausible right up until the moment you actually have to decide whether to open the door. Controls at the agent layer are only as reliable as the agent’s output is predictable, and autonomy is precisely the property that makes that output hard to predict. Governance that depends on reviewing an action before it happens cannot keep pace with a system that acts in milliseconds, across many systems at once.

Governance has to become executable, and enforced where agents actually do their work: at the operational data layer, in the context, and exactly at the moment it is happening.

The data layer is the enforcement point

Agents create value by touching data. They query it, retrieve it, transform it, and increasingly act on it. A policy that says an agent should not reach a certain class of data is meaningful only if the system can deny that access at the moment the agent requests it. Additionally, a principle that says AI must be auditable is meaningful only if the organization can reconstruct what the agent did, what data it touched, which user it acted for, and what resulted. When governance lives at the data layer, it holds regardless of how the agent was built or how it behaves, because the control is a property of the database itself, not a promise made by the agent.

Agent behavior may be probabilistic. Governance cannot be

The enterprise should not rely on a model choosing to follow policy. The policy has to be enforced by the system. That is the difference between hoping an actor stays in bounds and constructing bounds it cannot cross to begin with.

The controls that make this real are ones many enterprises already run at the data layer: role- and attribute-based access, row- and column-level security, classification and masking, policy as code, and complete audit trails.

What agents change is not the mechanism, but who the mechanism has to recognize. Identity management has to treat the agent as a principal in its own right, with its own identity and a purpose declared when the session opens.

Once purpose is bound to identity, the policy engine can evaluate it the same way it evaluates role or department today, and the record of what happened can capture not just who acted and what they touched, but what they declared they were there to do.

In practice, this resolves into nine controls, grouped under three imperatives:

Enforce it

• Role- and attribute-based access control enforced at query time, for agents as well as users

• Dynamic column masking driven by the same policy path

• Agent identity as a first-class principal, with declared purpose bound at session start and the acting user preserved

See it and prove it

• Classification and tagging that drives policy

• Session-level audit logging that records which agent acted, for which user, and under what declared purpose

• Lineage across pipelines, so a result can be traced back to the request that produced it

Unify and harden

• Centralized, portable policy management

• Encryption at rest and in transit

• Consistent enforcement across on-prem, cloud, and sovereign or air-gapped environments

“Declared purpose is what makes the difference. It becomes an attribute the access layer already understands, evaluated in the same policy path as role and row-level security. The enforcement mechanism does not change. What changes is that the agent's purpose is part of what it evaluates, and part of what the record proves afterward,” says Priyanka Jain, VP, product management, data & AI governance, EDB.

Wherever you are in your AI adoption journey, enforcement at the data layer is what lets you move faster rather than slower. The controls are already in the database. The difference is that agents now have to pass through them.

A digital leash, not a locked door

The goal is not to stop agents from doing useful work. It is to define how far an agent can go, what it can touch, what it can change, what requires escalation, and how the organization can reconstruct events if something goes wrong. Governed this way, agents are identified, scoped, monitored, and auditable. The enterprise can adopt them faster, because security, risk, and leadership teams trust the operating model underneath.

Open, sovereign, and enforceable at the source

Built on open source Postgres, this open foundation keeps enterprises in control of where their data lives, who can reach it, and under what policy, without ceding governance to a layer they don’t own or can’t inspect. For regulated industries, that combination of data sovereignty and source-level enforcement isn’t a nice-to-have; it’s the precondition for putting agents into production at all.

Agentic systems will keep getting more capable and more autonomous. That is a reason to be deliberate about where control lives, not a reason to slow down. The enterprises that enforce governance at the data layer can move aggressively on AI, because the thing protecting their data is more than just wishful thinking.

EDB Postgres AI is an open, enterprise-grade sovereign data and AI platform that unifies transactional, analytical, and AI workloads — with governance enforced where the data lives. For the full framework, see EDB’s white paper Governing Agentic AI at Enterprise Speed.

Max Romanenko is Chief Technology Officer at EDB.

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.