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.

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.

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.

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.

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.

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.

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.