Share one API key across five AI agents, and a single compromised agent inherits the reach of all five. The attacker immediately benefits from the accumulated permissions of every workflow that the key touches. The forensic trail goes cold at the credential level because five agents on one account leave no record of which agent did what.

Sixty-nine percent of enterprises run agents with credential sharing somewhere in their deployments, according to VentureBeat’s June 2026 Pulse Research wave of 107 enterprises.

That one number explains the buying spree reshaping enterprise security this year. Palo Alto Networks, CrowdStrike, and Cisco have collectively bet more than $22 billion on it in the past year, targeting exactly the layer most enterprises in this survey haven't finished building.

Palo Alto Networks completed its acquisition of CyberArk on February 11 for $21.1 billion in total consideration at close — a deal it announced last July at roughly $25 billion and the largest in the company's history.

CrowdStrike closed its $740 million acquisition of runtime authorization platform SGNL and, by June 15, shipped the first product from the deal, Continuous Identity for AI Agents. CrowdStrike integrated SGNL in less than a year, delivering a product that validates every agent action in real time based on who owns it, who is calling it, and the device's risk posture.

Cisco announced its intent to acquire non-human identity specialist Astrix Security on May 4 for a reported $400 million.

For a security director, this survey reads as a board-level question, not a trend line. It also surfaces a finding no competitor’s data shows, one that exposes which companies are the most at risk.

The data below is the first look at VentureBeat’s Q2 Agentic Security report, drawn from 107 qualified respondents at organizations with more than 100 employees. The full report will be released to attendees at VB Transform, the event in Menlo Park next week (July 14-15) focusing on enterprise autonomous agents.

Forty-five percent are final decision-makers for AI purchases. The sample skews mid-market, so read the numbers as the view from organizations adopting agent security right now rather than from the largest enterprises.

More than half of respondents, 54%, have already had an agent security incident or near-incident. Eighteen percent confirmed an incident, and thirty-six percent caught a near-miss before a breach. Security teams are stopping most of these events at the last control point in the chain, but the rest of the data shows how thin that margin is.

Your agents are sharing credentials

Only 32% of enterprises give every AI agent its own scoped, managed identity. Nearly half (48%) report that some agents have scoped identities, while many still share credentials. Another 32% say agents mostly run on shared API keys or borrowed human and service-account credentials. The survey question allowed more than one selection, and 24 of the 107 respondents chose multiple options — which is why the three categories sum to 112%. Deduplicated by respondent, 74 organizations, or 69%, flagged credential sharing in at least one answer.

One number explains why the acquisitions target this layer. A shared credential converts a single compromised agent into many, and CyberArk's research puts machine identities at 82 for every human in organizations worldwide, with agents as the fastest-growing category of the ratio. Cisco made the same diagnosis when it bought Astrix, whose founders built the company around API keys, service accounts, and OAuth tokens. Cisco’s announcement calls those the credentials AI agents are now “using (and abusing)” to execute work at scale.

Adam Meyers, senior vice president of counter adversary operations at CrowdStrike, described the mechanism directly in an interview with VentureBeat. Some AI systems have their own identities, he said, and in other cases “people give their identity to the AI to take action on their behalf, and that also further kind of murkies the water and makes it very complex.” The murk is the point, because when the identity is shared, attribution dies with it.

Exposure scales with size, and containment does not

Forty-nine percent of enterprises enforce scoped permissions at runtime, and 47% monitor and log agent activity, which can help reduce security incidents. Only 30% sandbox their highest-risk agents, the one control that limits blast radius when the first two fail. Isolation is what keeps a single compromised agent from becoming a deployment-wide event. Enterprises have funded detection and resistance, but the containment layer barely exists.

The sharpest finding in the survey, and the one no vendor report captures, shows up when you split results by company size. The incident rate is 49% for companies with 101 to 1,000 employees, but it shoots up to 63% for companies with more than 1,000. Sandbox isolation moves the other way, falling from 35% to 20% at the larger companies.

The chart above shows the same finding at finer granularity: the 49%/63% split above is a binary cut at 1,000 employees, while the bars here break incident rate and isolation rate into four size bands. The red line measures incidents and near-misses, and the navy tracks the one control that contains damage after everything else fails. At organizations with 101 to 250 employees, the two sit 7 points apart, but above 5,000, the gap blows out to 60 points. That top band pools the survey's two largest size groups and holds only 15 respondents, so treat the number as directional. Larger enterprises run more agents across more systems, which drives incidents up while sandboxing, the engineering project that would contain them, goes unfunded. The enterprises with the most agents have the least isolation around them.

The deals target exactly those accounts. Palo Alto Networks, Cisco, and CrowdStrike sell to large enterprises first, where incident rates are highest and containment is the thinnest.

Guarded by whoever shipped the model

The model providers are the security layer. OpenAI's built-in guardrails lead at 51%. Google Cloud reaches 36%, Microsoft Azure's Purview and Copilot Studio DLP 35%, and Anthropic's managed-agent controls 29%. Eighty-two percent of respondents name a provider-native or hyperscaler control as their single primary agent security layer.

The purpose-built specialists are in single digits, with Palo Alto Networks' Prisma AIRS at 7%, CrowdStrike at 6%, and Okta for AI Agents at 4%. Zenity and the dedicated non-human identity platforms are at 3% each. Microsoft Entra Agent ID is the highest-penetration identity-specific control in the dataset at 13%, the only one from a hyperscaler, and it still falls outside the top four. Only 5% of enterprises run no dedicated agent tooling at all, and the rest have tooling that came pre-installed.

Bundled controls lead because they ship free and are enabled by default. Most filter prompts and outputs, but they do not give an agent its own identity or sandbox it. Hyperscalers sell identity-layer products, and Entra Agent ID is in the dataset at 13%, but adoption stays low. The two controls that reward incident data the most, scoped identity and isolation, are the two that the default stack does not include.

Prompt-and-output filters evaluate whether a call looks malicious. That is an intent problem, and intent cannot be solved at the language layer. CrowdStrike CTO Elia Zaitsev drew the line in an interview at RSAC 2026. "Observing actual kinetic actions is a structured, solvable problem," Zaitsev said. "Intent is not." CrowdStrike's Falcon sensor walks the process tree on an endpoint and tracks what agents did, not what agents appeared to intend. A scoped identity and an isolation boundary give that sensor something to track, while a shared credential on a bundled guardrail does not.

Cloud security went through the same cycle a decade ago, and Palo Alto Networks, CrowdStrike, and Wiz built multi-billion-dollar businesses on the gaps native cloud controls left open. Agent security is tracking the same path faster. A misconfigured storage bucket sat open until a human noticed. A misconfigured agent exploits its own over-permissioning on every run, and no human is watching when it does. Merritt Baer, chief security officer at Enkrypt AI and a former deputy CISO at AWS, told VentureBeat that the default layer is thinner than enterprises assume. "Enterprises believe they've 'approved' AI vendors, but what they've actually approved is an interface, not the underlying system," Baer said. "The real dependencies are one or two layers deeper, and those are the ones that fail under stress."

Comfortable, unconvinced, and already shopping

Here is the contradiction worth a keynote slide. Enterprises rate their agent security tooling 4.2 out of 5, with value for money at 4.1 and ease of implementation at 3.9. Those scores would make most SaaS vendors envious.

Only 35% believe their AI-enabled defenses are ahead of AI-enabled attackers, while thirty-two percent call it roughly even. Twenty-one percent say attackers lead, and another 21% say it is too early to tell, showing how enterprises trust their tooling more than they trust its outcomes.

Budgets confirm it. Forty-six percent allocate 6 to 10% of the security budget to agent security, and a full third spend 5% or less. Half the sample has already had an incident or near-miss, but the funding does not match the exposure.

Fifty-nine percent plan to adopt, add, or replace agent security tooling within 12 months, and twenty-nine percent plan to move this quarter. OpenAI leads forward interest at 34%, followed by Google at 30%, Anthropic at 29%, and Azure at 25%. The dedicated vendors draw more interest looking forward than their current single-digit footprint suggests. Satisfied customers do not reshuffle this fast unless they know the stack they're currently using is provisional.

Three moves for security directors

1. Inventory every agent’s credentials this quarter. Map which agents share credentials with other agents and which run on borrowed human or service-account identities. The goal is not one credential per agent. Agents that touch multiple systems need multiple scoped identities. The goal is zero shared credentials between agents and zero borrowed human identities. Thirteen percent of surveyed enterprises already run Microsoft Entra Agent ID. Okta for AI Agents and the non-human identity specialists sell equivalents. Shared and borrowed credentials are the first thing to eliminate.

2. Sandbox the riskiest agents first. Isolation is the least-adopted control at 30% and the only one that contains blast radius after prevention fails. Rank agents by the sensitivity of what they touch and isolate the top of the list. Above 1,000 employees, where isolation falls to 20%, this is the single highest-return move in the dataset. Sandboxing does not require replacing the agent or the platform. It requires a policy decision and an isolation layer.

3. Match the budget to the incident rate. A third of enterprises fund agent security at 5% or less of the security budget, even though more than half have already had an incident or near-miss. Nine percent allocate more than 25% today. The full report breaks out exposure and containment by company size, showing which bands carry the most risk and the least protection.

The board's question is simpler. If one of our AI agents was compromised this afternoon, which systems did it touch, and whose credentials was it holding? For the 69% of enterprises running agents on shared credentials, the answer is a shrug. The trail goes cold at the key.

The full Q2 Agentic Security report, with the complete vendor matrix, industry cuts, and the full dataset behind these charts, debuts July 14 and 15 at VB Transform, held at Hotel Nia in Menlo Park. The open question it leaves is whether enterprises close the agent security gap on their own terms, or whether a confirmed breach closes it for them.

A team routing queries across a coding specialist, a logic specialist, and a generalist model assumes each will cover the others' blind spots. A new study evaluating 67 frontier models from 21 providers shows that assumption is mathematically flawed — and the flaw has a name: the co-failure ceiling.

The assumption works like this: as long as two models don't usually fail on the exact same prompts, combining them is supposed to create a safety net against failures.

The real limit on orchestration is not how often models disagree, but the percentage of prompts where every model in the pool gives the wrong answer at once. By ignoring the co-failure ceiling, enterprises are building complex, expensive routing infrastructure to chase performance gains that do not exist. Fortunately, developers can use this same math to build a cost-free test that determines exactly when multi-model orchestration will actually pay off.

The hidden costs of the multi-model strategy

To orchestrate multiple language models, developers typically rely on three architectures. Model routers act as traffic cops, sending complex queries to expensive models and simple queries to cheaper ones. Cascades send every prompt to a cheap model first, only escalating to a premium model if the initial system signals low confidence. Finally, approaches like Mixture-of-Agents (MoA) fuse multiple models by asking them the same question and generating a synthesized answer from their combined outputs.

These architectures introduce a "shadow price" to inference costs. Every time a development team implements a router or a cascade, they pay a premium in added system latency, complex infrastructure maintenance, and increased governance risks across multiple API providers.

To justify these operational costs, engineers rely on “pairwise error correlation” to select their model pool. Imagine a developer has Model A, which writes excellent Python but fails at SQL, and Model B, which writes excellent SQL but fails at Python. Because they fail on different types of prompts, their pairwise error correlation is low. The developer assumes that by placing a routing layer in front of them, they have created a composite system that rarely fails at coding.

According to the study, throwing diverse models together based on low correlation can actually hurt performance if the models are not equally capable — when you vote across diverse but unequal models, the weaker ones often gang up and outvote the smartest one.

Josef Chen, author of the paper, told VentureBeat that in their experiments, "Naive majority voting across unequal models had negative mean gain (minus 10 points on our hard mix): diverse-but-weaker members outvote the strong one." The actionable advice for developers is to "combine only models within a matched quality band." If you cannot match quality, take the single-model baseline and spend your budget on the best model available.

The paper provides one bright spot for this approach regarding MoA architectures. When building ensembles, teams often use "Self-MoA," where they query the same premium model multiple times to generate a synthesized answer. The researchers found that at matched quality, building a diverse ensemble of models with low pairwise correlation beats a high-correlation Self-MoA setup.

However, when teams use that same pairwise correlation metric to predict the absolute accuracy of their overall system, the math breaks down.

"So teams pay the orchestration overhead up front (latency, complexity, multi-provider operations) on the assumption that a diversity dividend arrives later," Chen said. "Usually it doesn't, because today's best models agree, and, worse, they fail on the same queries … the prompt simply carries little signal about which model will be the one that's right when the frontier disagrees."

Why the math fails: the co-failure ceiling

The core finding of the study centers on a metric called the "co-failure rate" — the formal name for the all-wrong scenario described above. No router, voting system, or cascade can ever achieve an accuracy higher than the ceiling it imposes.

The coding, logic, and generalist pool shows low pairwise correlation on routine prompts — they rarely fail together. But the co-failure ceiling represents the obscure, highly complex edge case that pushes past the limits of current AI architectures. If a prompt is so difficult that all three models hallucinate or fail, it does not matter how intelligently the router distributes the task. The entire pool wipes out at once.

The researchers tested their 67-model pool, which included GPT-5.5, Claude Opus 4.8, and Gemini 3.1 Pro, on the open-ended MATH-500 math benchmark. Based on standard pairwise correlation, statistical models predicted that the entire pool would wipe out simultaneously on only 2.3% of the questions. In reality, the co-failure rate was 5.2%.

Standard correlation metrics underestimated the failure rate by roughly 2.25 times. The culprit is not just independent difficulty, but a shared failure point.

"The driver is what we call a common-mode atom: a slice of queries on which the entire market fails together, which no pairwise statistic can see," Chen said. "Adding a 20th model to your pool doesn't buy tail coverage. The tail is shared."

The researchers also found that task format directly triggers co-failure. When they took graduate-level science questions from the GPQA benchmark and changed them from multiple-choice to free-response formats, the all-wrong tail expanded to 12.7%.

Developers can engineer around the ceiling, though. "The engineering implication is uncomfortable: multi-model setups buy the least exactly where teams want them most, on open-ended generation," Chen said. "Anywhere you can convert generation into verification or constrained selection (structured outputs, checkable answers, execution tests), you reopen the ceiling."

Ultimately, the researchers found this ceiling limits AI applications in two distinct ways, depending on the domain:

• Ceiling-bound environments (e.g., open-ended math): The co-failure rate is high. The task is too hard, and all models fail simultaneously. No amount of routing can bypass the lack of underlying capability.

• Realizability-bound environments (e.g., graduate-level science): The co-failure rate is near zero, meaning at least one model in the pool usually knows the answer. However, the models disagree so subtly that a routing layer cannot reliably pick the correct answer without an omniscient oracle.

The $0 pre-deployment sanity check

Before dedicating engineering hours to building a router, teams can calculate their absolute performance ceiling for free using a mathematical formula called a Clopper-Pearson bound.

The Clopper-Pearson bound operates as a worst-case scenario calculator. If you flip a coin ten times and get eight heads, you cannot guarantee the coin will land on heads 80% of the time forever. The bound takes a small sample of test questions and outputs a mathematically guaranteed ceiling.

Applied to language models, suppose a team tests a pool of five agents on 50 sample queries and finds they all fail together on just two questions. A developer might assume their multi-agent system will achieve 96% accuracy in production. The Clopper-Pearson formula corrects this optimism. It analyzes the small sample size and provides a mathematical guarantee that the true co-failure rate could actually be as high as 12%.

To use this in practice, enterprises must build a held-out dataset. A fintech company, for example, could take 200 complex customer support tickets from the previous quarter and have human agents write perfect resolutions to serve as a benchmark. While this sounds like a heavy manual project, mature engineering teams can automate the entire ceiling calculation.

"Integration is trivial: it's a counting job over eval logs teams already produce," Chen notes, "so it runs in the same CI stage as the eval suite and re-triggers whenever the model pool or the workload changes."

The engineering team then runs its candidate models against these 200 tickets once and records the results. When they want to evaluate multi-model configurations, they can use the co-failure rate measure to predict the maximum accuracy they can get from the system without running extra queries.

One important conclusion the study draws is that on tasks where answers can be definitively checked, combining models rarely beats using the single best model on the market, unless the team possesses an exceptionally strong query-level routing signal.

In an enterprise environment, a definitively checked task has an objective, zero-tolerance answer. This includes generating a SQL query that must execute without error, extracting a specific invoice total from a 50-page PDF, or formatting a JSON payload that perfectly matches a strict schema. For these tasks, enterprises are usually better off paying a premium for the smartest frontier model rather than weaving together three cheaper models and hoping a router picks the correct output. The study didn't test subjective, ungraded tasks like drafting marketing copy — the authors note that whether these findings hold outside their verifiable benchmarks remains an open question.

Because this mathematical check is free, enterprise teams can track their own co-failure rates as new models drop.

"The measurement costs nothing, so any team can track its own co-failure rate across model generations and watch whether the tail is closing," says Chen. Ultimately, "the lever buyers hold is failure-mode heterogeneity and market churn, not model count."

Presented by SAP

Generating code with AI is fast, but getting that code to run reliably inside a large enterprise, integrated with live systems, governed for compliance, and maintainable over years requires foundational work that most organizations underestimate.

While 81% of all organizations have a detailed strategy, only 12–16% reach AI‑driven execution, says SAP's Michael Ameling, CPO of SAP Business Technology Platform, and the reasons rarely come down to the quality of the generated code.

"Across industries, enterprises that have invested heavily in AI tooling are hitting a wall when generated code meets the reality of their existing environments, because generating code and operationalizing it are not the same problem," Ameling says.

There are specific requirements for deploying AI-generated logic at enterprise scale: what data and integration readiness actually look like, how governance works when AI agents move from producing recommendations to executing workflows, and how development teams are changing their role as AI takes over more of the coding work.

Why AI code generation fails in enterprise production environments

The productivity gains from AI code generation are real and well-documented, but the ease of prototyping has given many organizations a misleading sense of how far along they actually are.

"Generating code is one thing," Ameling says. "Enterprise customers, including multinationals and large organizations, need to ensure there are no compromises in compliance or security. Code that runs reliably for ten or twenty years, as it does at many of SAP's largest customers, also has to be maintained, patched, and understood by whoever inherits it. Life cycle management, in other words, does not generate itself."

The issue is rarely the generation quality. Teams build something compelling, then discover they lack access to the data it depends on, or the integrations it assumes, or the permissions required to run it in a real environment. The problem is essentially that AI amplifies an organization's existing data and process maturity, but it can't substitute for it.

This dynamic intensifies as AI moves from producing code to executing actions. Latency, cost, and system load all increase when logic runs continuously against live data rather than rendering a one-time output. The performance requirements of an autonomous agent operating across a multinational's transaction systems are categorically different from those of a developer copilot.

How to connect AI-generated logic to fragmented enterprise systems

The architecture challenge that most enterprise AI projects underestimate is integration. Real enterprise environments are not clean slates: they combine cloud systems, legacy on-premise infrastructure, fragmented data stores, and dozens of business applications that were never designed to talk to each other. Getting AI-generated logic to operate reliably across all of them requires a layer that unifies data access, process context, and governance, and it has to be in place before any agent starts executing. And organizations that see AI as a reason to defer infrastructure modernization are making a mistake.

"The question is not whether to modernize or not. Of course you need to modernize," Ameling says. "But the value you get on top of this is much higher with AI. Federated data access and harmonized process layers are not alternatives to upgrading a fragmented landscape, they're what make the upgrade worthwhile."

At the platform level, this translates into a set of practical requirements: structured data integration, end-to-end process visibility, and the ability to discover and connect to APIs across both modern and legacy systems. SAP's approach with the Business AI Platform draws on tools including its Joule Studio, Integration Suite, Business Data Cloud, and SAP AI Agent Hub enterprise architecture layer to provide that context. The goal is to give AI-generated logic accurate, current knowledge of what a business is doing and how, rather than just access to raw data.

AI agents handle large challenges by dividing them into smaller, autonomous tasks, with each agent responsible for a specific domain, and all coordinated toward a shared outcome. A financial close, for example, involves dozens of discrete sub-processes. Agents handling each task in parallel, within defined constraints, can compress cycle times dramatically, but only if the underlying systems they interact with are coherent and accessible.

The governance and oversight that AI agents require in production

When AI moves from assistant to operational actor, the governance questions loom large, because agents that trigger workflows, update records, and interact with live business systems need the same accountability framework that applies to human employees, i.e., identities, defined privileges, and auditable behavior.

There are two distinct models:

Principal propagation, where an agent acts on a user’s behalf, inheriting that user’s permissions and scope.

System-triggered agents, where the agent operates under its own identity and role-defined privileges, functioning more like an automated HR role than a personal assistant.

Both models require the same underlying infrastructure: an agent hub where operators can see which agents exist, what APIs they can access, and what they are authorized to do. Observability also needs to be operationalized correctly for AI, combined with both technical and business evals.

"In production, openness is very important," Ameling says. "We use OpenTelemetry as a framework, so we can integrate with other solutions, for end-to-end observability of the tool, third-party agents and the like."

On top of that, standard technical evals, which test whether an agent produces consistent outputs, are necessary but not enough. Business evals assess whether an agent is actually moving the performance indicators it was deployed to improve, but it has to work end-to-end.

Where the testing happens is equally important. The traditional software development cycle across dev, test, and production environments breaks down when a model produces different outputs depending on whether it is running against test data or live data. Getting to trustworthy AI in production means accepting that validation looks fundamentally different from what engineering teams have practiced for decades, with live environment testing, even A/B/C testing to ensure outcomes are reliable.

How AI-driven code generation is changing software engineering roles

The role of the developer is not disappearing in this environment, but its center of gravity is shifting. The productivity multiplier is significant when developers can run multiple coding agents in parallel across open terminals, each working on a separate problem and each taking several minutes to complete. But it introduces a new kind of cognitive demand, because humans have to stay in the loop. That means tracking context across concurrent workstreams, evaluating outputs that range across large codebases, and making architectural judgments that no agent can be trusted to make alone.

"The more specific and complete the prompt, the less intervention is required, and developers are learning that bringing more context upfront pays dividends in reduced back-and-forth," Ameling says. "But the output still needs to be understood, not just accepted."

The competitive edge will remain intellectual property, not tooling. The companies that pull ahead will be those that most effectively encode their domain knowledge into the systems they build.

"A manufacturer's process expertise, a financial institution's risk logic, a logistics firm's routing intelligence, these are the assets that AI can accelerate, but only if the organizations that hold them do the work to make them accessible and usable," Ameling says. "Protect that, and apply AI to accelerate your differentiation."

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.

Presented by Oracle NetSuite

Every major technology transition produces a set of assumptions about where the market is headed. The assumptions are often directionally correct, but they tend to underestimate the degree to which organizations adapt new technologies to their own circumstances. AI is following a similar trajectory.

Many current discussions about enterprise AI assume a future in which employees interact with business systems through a common interface. The details vary depending on the prediction, but the destination often looks similar: a conversational system that becomes the primary way people access information, complete tasks, and interact with software.

The history of enterprise technology suggests a more complicated outcome. Organizations rarely adopt new capabilities uniformly because different parts of the business operate under different constraints. A finance team responsible for reporting accuracy, controls, and approvals approaches technology differently than an analytics group exploring operational data. Both groups have different requirements than a customer service organization focused on response times and case resolution. Even when there is broad agreement that a technology is valuable, the path to adoption tends to vary across functions.

The shift to cloud software followed this pattern — some organizations moved aggressively while others spent years operating hybrid environments. Different departments often modernized on different timelines, reflecting the priorities of the work itself rather than any industry consensus about the correct pace of adoption.

There’s no one-size-fits-all AI

AI has accelerated many aspects of technology development, but it has not changed this underlying dynamic. Organizations still evaluate new capabilities through the lens of existing processes, responsibilities, and operational requirements.

For some employees, the most useful AI capabilities may be the least visible ones. A finance manager closing the books is often less interested in a new interface than in shortening a reporting cycle. An operations leader dealing with inventory issues is usually focused on identifying problems earlier and resolving them more quickly. In these situations, the value of AI comes from reducing the amount of effort required to complete existing work.

At the same time, another group of users increasingly wants direct interaction with AI systems. Analysts, planners, and operational teams often benefit from the ability to explore information conversationally, compare scenarios, and investigate questions that do not fit neatly into predefined reports. For these users, the interface itself becomes valuable because it provides a more flexible way to work with business information.

A customer service representative handling a high volume of inquiries has different requirements than a financial analyst investigating a trend in operating expenses. One benefits from information appearing automatically within an existing process while the other may benefit from the freedom to ask follow-up questions, explore alternative explanations, and move through data more dynamically.

Many organizations are discovering that both patterns exist simultaneously, which reflects a broader reality about how businesses evolve. Operational complexity accumulates gradually, systems multiply, and processes become fragmented. Information becomes distributed across applications, reports, spreadsheets, and workflows and employees spend increasing amounts of time locating information before they can begin acting on it.

Much of the value created by enterprise software over the last several decades came from reducing that fragmentation. Bringing financials, operations, inventory, customer information, planning, and reporting into a common system created a more complete picture of how the business was operating.

AI is beginning to address a related problem. Once information exists within connected systems, employees still need to find it, interpret it, and apply it. Reporting cycles consume time. Routine questions require investigation. Managers often spend considerable effort assembling information before they can make decisions. As organizations grow, these activities become increasingly expensive because they consume attention from people whose expertise is often in short supply.

AI's promise is to reduce the effort required to move from information to action.

At Dura Software, AI-connected workflows are helping automate portions of revenue reporting that previously required manual preparation during each reporting cycle. Sloan Session, CFO at Dura Software, described the arrangement in practical terms: “The agents handle the pull. The humans handle the judgment and the personal touch.”

That observation captures an important aspect of current AI adoption. Most organizations are not attempting to remove judgment from business processes. They are trying to reduce the amount of time spent gathering, organizing, and preparing information so that experienced employees can focus on the decisions that require expertise.

A similar pattern emerged at S&B Filters. Employees previously spent several minutes during customer interactions collecting backorder information from multiple systems. By connecting AI to operational data, the company reduced that process to seconds and eventually extended the capability directly to customers through self-service.

Don’t forget about governance

In both cases, the benefit comes from reducing the friction associated with finding and using information rather than introducing a new interface. The moment information becomes easier to access, questions about access itself become more important. Permissions, approval structures, and security policies exist because businesses need mechanisms for controlling access to information and managing risk. Those requirements do not disappear when employees begin interacting with data through AI systems. If anything, they become more important because AI can make information easier to access.

Berry Carter, CEO of S&B Filters, described the principle clearly. If a user cannot access specific information within NetSuite, that user should not gain access to the same information through an AI assistant. The statement sounds obvious. Implementing it consistently across systems, workflows, and models requires considerably more discipline than the statement itself suggests.

Lauren Polasek, former NetSuite administrator and board member of the Texas NetSuite User Group, recently made a related point. Connecting technology is often the easier part. Organizations still need to determine which tools should be used, who should have access to them, and how governance should evolve as adoption expands.

This is one reason predictions about a single AI interface are difficult to reconcile with how enterprises actually operate. The requirements of a finance organization closing the books are different from those of a customer service team handling thousands of interactions each day. Some AI capabilities will be embedded directly into business processes where employees may barely notice them. Others will provide more direct access to operational information through conversational systems. Many businesses will end up using both approaches because the underlying work is different.

Have AI your way

That perspective has shaped how we think about AI at NetSuite. Some customers want AI embedded directly within operational workflows. Others want the ability to connect NetSuite data to external models and assistants so they can interact with business information through tools that are already part of their daily work. Increasingly, organizations are asking for both.

The NetSuite AI Connector Service and our support for Model Context Protocol (MCP) were designed with that reality in mind. The goal is to allow organizations to connect business information securely to the workflows and systems that make sense for them while continuing to benefit from AI capabilities built directly into NetSuite.

The history of enterprise software suggests that adoption rarely follows a straight line. As organizations adopt AI, business leaders should identify the business objective and the workflows involved so they can match the solution to the reality of the work.

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.