54% of companies have already experienced an AI agent incident

The race toward AI agents is entering a new phase: that of operational risk

The debate around AI in the enterprise has long been dominated by one central question: what can models do, and how quickly can they automate tasks previously carried out by humans? Since the rise of conversational assistants, followed by the arrival of tools capable of chaining together multiple actions, querying business applications, and executing workflows, the conversation has gradually shifted toward “AI agents.” These systems no longer merely respond to a request: they act, call services, manipulate data, and sometimes take initiatives within a defined scope.

But as enthusiasm has grown, another reality has emerged: the more a system acts, the more concrete its exposure to risk becomes. That is precisely what information relayed by VentureBeat AI highlights in an article titled The agent security gap: 54% of enterprises have already had an AI agent incident, and most still let agents share credentials. The finding is direct: 54% of the companies surveyed say they have already experienced at least one incident involving an AI agent. At the same time, credential sharing between agents reportedly remains a common practice, despite the obvious risks it poses in terms of security, auditing, and accountability.

This double signal is important. On the one hand, it shows that incidents are no longer a theoretical scenario confined to research labs or poorly governed proof-of-concepts. On the other, it suggests that many organizations are deploying agents before putting in place governance mechanisms suited to semi-autonomous or autonomous systems. In other words, the battle is no longer being fought solely over model capabilities, response quality, or cost per query. It is now being fought over companies’ ability to control, trace, and secure software that acts on their behalf.

The issue is of primary interest to CIOs, CISOs, platform leaders, and product teams. In many organizations, the industrialization of agents has already begun: internal support, document research, sales assistance, automation of administrative tasks, code generation, access to knowledge bases, orchestration of tickets or purchase requests. What is changing is that these agents are no longer confined to a demo interface. They are connecting to real tools, with real permissions, on real data.

The point raised by VentureBeat AI therefore comes at a pivotal moment. After the experimentation phase and after the rapid integration phase comes the normalization phase. Yet the figures highlighted indicate a gap between the speed of adoption and the maturity of the guardrails. In the recent history of enterprise IT, this kind of gap is nothing unusual: cloud, mobility, SaaS, and even APIs were often adopted faster than the security frameworks meant to accompany them. With AI agents, the difference is that the surface of action is potentially more fluid, harder to predict, and more opaque to audit if the original architecture was not designed for that.

The core of the problem is therefore not only technical. It touches governance, compliance, traceability, and a company’s ability to attribute an action precisely to a system, a context, an authorization, and a level of validation. When an agent consults an internal database, modifies a record, sends a message, retrieves a document, or triggers a process, who carries the operational identity of that action? What permission was used? What rule governed the decision? What event log makes it possible to reconstruct the chain of events? The fact that credential sharing remains widespread shows that these questions have not yet been resolved everywhere.

What the source relayed by VentureBeat AI says: incidents are already real, identities are still poorly managed

The most striking element of the publication picked up by VentureBeat AI lies in this figure: 54% of the companies surveyed say they have already experienced an incident involving an AI agent. Even without having here the detailed typology of each case, the significance of the signal is strong. In the language of the enterprise, an “incident” can cover varied realities: execution error, inappropriate access, mishandling of data, unexpected behavior, security problem, or auditing difficulty. But whatever the details of the cases recorded, the simple fact that a majority of respondents report at least one event of this kind is enough to move the issue from the realm of innovation to that of risk control.

The other key point emphasized by VentureBeat concerns credential sharing between agents. Here again, the stakes are considerable. In a traditional enterprise environment, security teams have spent years trying to reduce shared accounts, reused secrets, and generic identities. The reason is simple: as soon as multiple users, services, or processes use the same credentials, attributing actions becomes more difficult, the principle of least privilege is weakened, and incident response becomes more complicated. Applied to AI agents, this problem takes on a new dimension, because these systems can multiply interactions at high speed and across several applications.

In practice, if several agents share the same login pair, the same token, or the same application secret, it becomes harder to know which agent performed which action, in what context, and with what instructions. Auditing loses granularity. Access control becomes coarser. And remediation, in the event of an incident, may force the suspension of a whole set of automations rather than one specific agent. For an organization subject to compliance, traceability, or segregation-of-duties obligations, this situation creates an organizational vulnerability as much as a technical one.

The picture painted by VentureBeat thus highlights a gap between the rapid deployment of agents and the actual maturity of the guardrails. This is probably the most structuring aspect of the news. Companies are no longer at the stage of asking whether agents can be useful: many are already testing them, and some have integrated them into real processes. But the study relayed suggests that a significant part of the market has not yet aligned its identity layer, authorization mechanisms, logging, and supervision policies with the specific nature of these tools.

The fact that VentureBeat insists on credentials is not trivial. In modern IT architecture, identity has become the main security perimeter. That was already true with cloud and distributed applications; it is even more so with AI agents, which often serve as intermediaries between a user, a model, and several information systems. An agent can read, write, trigger, or transmit. If it acts with an identity that is poorly defined, too broad, or shared, the company loses part of its ability to control the consequences of its action.

This reading is particularly relevant for decision-makers who have so far approached agents from the angle of productivity. The economic reasoning is appealing: a well-designed agent can reduce delays, absorb volume, streamline repetitive tasks, and improve access to information. But as soon as it has real permissions in an information system, it also becomes an operational security issue. The potential cost of an incident, a permission error, or a lack of traceability can then cancel out part of the expected gains.

VentureBeat AI’s implicit formula is therefore clear: the question is no longer only “how many agents can we deploy?” but “under what control conditions can we do so without creating unmanageable security debt?” It is this shift in the center of gravity that makes the information important beyond the simple 54% figure.

Why agents pose a different problem from traditional AI assistants

To understand the scope of this warning, AI agents must be distinguished from more passive conversational assistants. An internal chatbot that answers questions based on a document repository already raises issues of confidentiality, response quality, and data governance. But its range of action remains relatively limited if it only returns information. An agent, by contrast, can go further: it can navigate between several tools, retrieve real-time data, execute commands, create objects in an application, transmit content, or trigger sequences of actions.

This orchestration capability changes the nature of the risk. The danger does not come only from a “bad answer” or a textual hallucination. It can come from an erroneous or inappropriate action carried out with legitimate permissions. This is an essential point for security teams. In a traditional system, controls focus on authentication, authorization, logs, approval workflows, and access segmentation. With agents, these building blocks remain necessary, but they must be adapted to software entities that can act on the fly, in chains, sometimes based on instructions formulated in natural language.

Credential sharing, highlighted by VentureBeat, then becomes a marker of maturity. When a company assigns a distinct identity to each agent, limits its permissions to a specific function, logs its actions in detail, and can quickly revoke its access without disrupting the entire system, it moves closer to a governable model. Conversely, when several agents use pooled access, generic secrets, or overly broad permissions, the organization is stacking automation on top of a control base that is not granular enough.

Another aspect must also be emphasized: agents are often presented as layers of abstraction that simplify access to complex systems. That is precisely what makes them attractive to business teams. But this simplification on the usage side can mask greater complexity on the control side. A user no longer needs to know the APIs, interfaces, or exact procedures: the agent handles that. For security, however, this means an additional component is making path decisions, choosing tools, managing contexts, and handling permissions. The more powerful this layer is, the more observable it must be.

The issue of auditing is central here. An organization must be able to reconstruct what an agent did, why it did it, based on what request, with what permissions, and in what environment. If this chain is not available, technical teams lose an essential lever for incident response. The problem is not limited to cybersecurity in the strict sense. It also touches internal compliance, quality control, legal accountability, and business trust. An agent that acts without a reliable audit trail is difficult to industrialize at scale.

The 54% figure reported by VentureBeat therefore takes on particular significance: it suggests that incidents are not only due to the immaturity of the models, but also to the immaturity of deployment architectures. The generative AI industry has communicated extensively about performance, benchmarks, inference costs, context windows, and multimodal capabilities. It has also highlighted agent frameworks and automation demonstrations. But machine identity, privilege separation, logging, and approval mechanisms often remain less visible in commercial messaging, even though they become decisive as soon as systems move into production.

This tension is all the stronger because the promise of agents rests on relative autonomy. The more autonomous an agent is, the more it needs a clear permissions framework, explicit action limits, and defined checkpoints. Without that, the company gains execution fluidity but loses governance readability. The paper relayed by VentureBeat rightly reminds us that this loss of readability is not abstract: it is already translating into reported incidents.

A strong signal for CIOs and CISOs: identity, auditing, and least privilege are becoming priorities again

For IT departments and security leaders, the most useful information is not only that incidents exist, but where the point of fragility lies. By emphasizing credential sharing, VentureBeat AI points to a very concrete weakness: many companies still seem to manage agents like simple scripts or secondary technical extensions, when they should be treated as full-fledged actors in the information system.

In an enterprise security logic, this implies several well-known principles, but their application to agents is not always mature. The first is the principle of least privilege: each agent should have only the permissions strictly necessary for its mission. The second is the uniqueness of identity: one agent, one identity, one scope. The third is traceability: every important action must be logged in a usable way. The fourth is revocability: an agent’s access must be suspendable quickly without a domino effect on other automations.

The fact that these principles seem classic does not make them any less urgent. On the contrary, the gap highlighted by the study shows that agent adoption risks reproducing mistakes already seen in other technology waves: rapid deployment, delayed governance, then urgent catch-up after the first incidents. The difference, once again, is that agents can act across several systems at once and that their execution logic may be harder to anticipate than a traditional deterministic workflow.

For product teams integrating agents into internal or external applications, the message is just as clear. The quality of an agent is not measured only by its ability to accomplish a task, but also by its ability to do so within a verifiable framework. An agent that is impressive in a demo can become a risk in production if it offers neither identity isolation, nor fine-grained access control, nor a usable action history. User experience can no longer be separated from security architecture.

The issue also has a budgetary and organizational dimension. Many companies have invested in observability platforms, IAM tools, secret management solutions, compliance policies, and validation processes. The arrival of agents forces these investments to be re-read from a new angle: are they capable of taking into account software entities that decide and act more flexibly than a traditional application service? If the answer is no, the industrialization of agents will require not only technical choices, but also an adaptation of governance frameworks.

This question resonates with the broader evolution of the market. For the past two years, major AI, cloud, and enterprise software providers have multiplied announcements around copilots, assistants, and agents. The vocabulary varies, and so do the levels of autonomy, but the underlying trend is clear: AI must no longer only assist, it must execute. Yet execution mechanically brings issues of accountability. When a system proposes, the human can still filter. When it acts, the control chain must be much more robust.

The signal sent by VentureBeat AI can therefore be read as a salutary reminder for the most advanced organizations. Companies that have already moved beyond pilots and are beginning to connect agents to ERPs, CRMs, ticketing tools, document repositories, or financial systems would do well to consider agent security not as a side project, but as a condition for scale. Without that, automation risks running into growing distrust from security teams, business teams, and sometimes compliance functions.

What this changes for the French and European market

For French companies and, more broadly, European ones, the warning relayed by VentureBeat takes on a particular coloring. The continent generally has a stronger sensitivity to issues of compliance, data protection, and traceability than some other markets. Without extrapolating beyond the facts of the source, it can be said that any increase in incidents related to AI agents mechanically reinforces attention paid to access governance, processing documentation, and the ability to demonstrate what was done by whom or by what.

In large French organizations, AI projects already face several validation lines: security, legal, procurement, architecture, compliance, sometimes business representatives, and sometimes data protection. As long as AI remained mainly in a logic of writing assistance, document search, or analysis, some companies could accept a higher degree of uncertainty, provided uses were limited. With agents, this compromise becomes more difficult. As soon as a system can act in a production environment, expectations in terms of auditing and control rise by a notch.

For mid-sized companies and large groups, this could accelerate a segmentation of the market. On one side, agent solutions capable of demonstrating better integration with identity systems, access policies, and logging could gain credibility. On the other, offers that are attractive functionally but vague on governance could encounter more resistance during large-scale deployments. The issue is not only whether the agent “works,” but whether it can pass the filters of the regulated enterprise.

For software vendors and integrators present in France, the message is highly operational. Business departments may be attracted by the promise of rapid automation, but the decision to industrialize will increasingly depend on the ability to answer precise questions: how is the agent authenticated? Are its permissions individualized? Can its actions be traced end to end? What happens in the event of an incident? How do you cut access without breaking the entire chain? The fact that VentureBeat emphasizes credential sharing shows that these questions are not a matter of theoretical refinement: they go to the heart of production deployment.

The French-speaking market also has a cultural particularity: IT and security functions often retain significant weight in validating technological transformations. This can slow some experiments, but also prevent overly rapid deployments. In this context, the 54% figure can serve as a point of support for CISOs asking for stricter guardrails before broadly opening access to agents. It can also push CIOs to require cleaner architectures from the pilot phase onward, rather than correcting poorly designed identity or permission choices later.

For French companies already engaged in generative AI programs, the issue could translate into a rebalancing of priorities. After an initial phase centered on use cases, models, and costs, a second phase could prioritize governance layers: directories, secrets, access policies, observability, environment separation, human approvals, and remediation procedures. VentureBeat’s signal does not indicate which solutions will prevail, but it clarifies one thing: the maturity of an agent project is no longer measured only by what it automates, but by how controllable it remains.

Finally, it should be noted that this issue also concerns the public sector, sensitive operators, and organizations subject to strong sovereignty or security constraints. Here again, without extrapolating beyond the source, it can be said that the existence of already observed incidents and the persistence of credential sharing make any naive approach to agent deployment more difficult. In these environments, the acceptability of agents will probably depend on architectural guarantees at least as much as on their functional performance.

The market’s next step: fewer demonstrations, more verifiable governance

What the information relayed by VentureBeat AI ultimately reveals is a maturity transition. The AI agent market has made a great deal of progress in demonstrating value: the ability to chain tasks, query several tools, and produce usable results with less human intervention. Now, another requirement is asserting itself: proving that this autonomy can be governed. The 54% figure and the persistence of credential sharing indicate that this proof has not yet been delivered consistently across companies.

In the short term, this situation could produce a paradoxical effect. On the one hand, incidents may reinforce the caution of some organizations, or even slow deployments. On the other, they can accelerate the professionalization of the segment. Companies will not necessarily give up on agents if they see them as a real productivity lever. However, they could become much more demanding about implementation conditions: dedicated identity, fine-grained permissions, secret policies, supervision, audit trails, and validation of sensitive actions.

This evolution is consistent with the history of enterprise technologies. The first waves of adoption often favor speed, experimentation, and visible gains. The following phases impose standards, controls, and more rigorous architectures. AI agents seem to be entering this second sequence. The challenge is no longer to convince people that they can do something useful, but to demonstrate that they can do it without weakening the organization.

For technology providers, this probably means product messaging will have to evolve. Promises of performance, automation, and user experience will remain important, but they will no longer be enough. Buyers will want more precise answers on machine identity, privilege separation, logging, environment isolation, and remediation. The fact that VentureBeat highlights credential sharing clearly shows that security fundamentals are returning to the forefront, even in a market presented as radically new.

For user companies, the lesson is even more structural. Agents must not be considered a simple AI layer pasted onto the existing stack, but as operational actors in the information system. As such, they call for identity, accountability, and control rules comparable to, or even stricter than, those required for other critical components. If this discipline is not put in place, the promised autonomy can quickly turn into a blind spot.

In the French-speaking context, this shift could also revalue hybrid profiles capable of linking AI, architecture, and cybersecurity. The organizations that succeed best will not only be those that identify the best use cases, but those that know how to articulate innovation and governance from the design stage. The study cited by VentureBeat does not yet provide all the details of a future industry standard, but it already sets a very clear dividing line: companies that treat agents as traceable and controllable identities will give themselves a better chance of making them a lasting lever; those that continue to connect them with shared access and incomplete visibility expose themselves to seeing the promise of efficiency run up against a much more prosaic reality, that of operational security.