The headlines on AI agents are impossible to miss, the discourse is all over the map, and the data bears out enormous concern about reliability and vulnerability. Seventy-nine per cent of CIOs at large companies say an AI agent has violated business intent, policy or expectations while staying within its technical parameters, according to a new survey from Dataiku and The Harris Poll. Businesses (and individuals) are handing agents more authority than they can supervise. The problem is architectural, but is accompanied by what appears to be real business value. The fixes starts with acknowledging and mapping vulnerabilities, limiting what each agent is permitted to do, and verification. 

The Toddler Stage Comparison

Anyone who has looked after a toddler knows that a few minutes of unexplained silence is a reason to investigate. (The comparison is to the maturity of the technology, and to the supervision that stage requires, and not intended to anthropomorphize the technology). A system working in the background may be completing exactly the task you intended. It may also be interpreting an incomplete instruction in a way you would never have approved, using access you are unaware it has.

So why are companies handing extensive authority to systems whose behaviour we are still learning to characterize? Generative AI and its current capabilities is just nearly four years old; agentic AI of any maturity level, only about 18 months. We’ve discussed extensively in our research that the only ways to manage agentic systems are to highly scaffold them or isolate the probablistic function.

What 685 CIOs reported

The Harris Poll surveyed 685 CIOs at companies with annual revenues above US$500 million, across the US, UK, France, Germany, the UAE, Japan, South Korea and Singapore, between July 9 and 29, 2026. Thirty-one per cent reported an agent incident with actual customer, financial, compliance or operational impact.

Ninety per cent say they have complete tracking of all their agents. Seventy-two per cent say they cannot consistently confirm whether those agents deliver the business outcomes they were built for. Knowing an agent is running and knowing whether it is working are separate capabilities, and most organizations have only the first.

Enterprises built their operating practices around conventional software: specified workflows, bounded permissions and testable outcomes. That software had bugs, integration failures and badly designed processes too, but its behaviour could be specified and tested. An agent brings interpretation into the workflow itself, selecting steps, filling gaps and deciding how to proceed when circumstances change. The practices that make that dependable are still being built, at the corporate, technical and people levels at once.

An AI agent is a particular system configured to pursue tasks through actions and tools. Agentic AI describes the broader approach of giving AI systems latitude to plan and act, potentially across multiple agents and workflows. The labels are used inconsistently, and buyers have to establish separately how much authority has actually been delegated.

Where ambiguity meets access

It’s an uncomfortable place, and unpredictable. An instruction leaves something unresolved. The system has room to choose how to resolve it. Access to tools turns that choice into an external action. The consequences depend on both the interpretation and what the system is permitted to do with it.

Consider a purchasing agent asked to find a better deal. It could compare prices, contact suppliers, negotiate terms or place an order. Those are separate grants of authority. A lower price might come with a longer commitment, an unapproved counterparty or conditions the business would reject. If those boundaries remain implicit, the agent resolves questions that belong to the organization.

The survey leaves the cause of each incident open, and it documents the conditions that make this problem hard to manage.

Three gaps at once

At the corporate level, 72% of CIOs cannot consistently measure whether all their agents are delivering business outcomes. The same proportion say their AI budget is likely to be cut or frozen if performance targets are missed by the end of 2026. Executives are being pressed to demonstrate value while the machinery for establishing it is incomplete. A task marked finished says little about whether its output was useful, how much checking it required or whether it created work elsewhere.

At the technical level, about six in ten respondents cannot contain a problematic agent on the same day. Only 10% can do so within one to two hours. For systems that contact customers, change records and act across connected applications, that is a substantial intervention gap. Monitoring offers limited protection when execution continues long after a problem is recognized.

At the people level, 84% say employees are building agents and AI applications faster than IT can govern them, and 81% lack complete oversight of agents created outside formal channels. Only 25% are completely confident that non-technical business teams can build AI safely with current tools. The capacity to create has spread faster than the capacity to supervise. Employees need clear answers about what they may connect, which decisions they may delegate and who is responsible when something goes wrong. Telling everyone to experiment leaves those questions open.

The vocabulary compounds the problem. “Assistant” leaves permissions unspecified. “Autonomous” leaves acceptable latitude undefined. “Human oversight” leaves open who can stop a process, and how fast. Frameworks exist; a shared language linking intent, authority, behaviour and accountability is still unevenly established.

Muse and the permissions inside one purchase

The concerns are across magenta platforms, not just corporate. Meta launched Muse on September 8. Meta describes a system that can work across connected services, browse, negotiate and continue tasks after a user closes the app. Users report it asks for access for everything from bank accounts to passport data and while they can choose its level of access, sensitive actions are supposed to require approval, and a separate system called Sentinel has to approve anything Muse sends to the internet. There have already been reported breaches.

The product reflects a familiar platform ambition: becoming the place through which people coordinate their digital lives, a Facebook of AI. Organizing actions across accounts carries consequences beyond organizing a feed. An inferred preference cannot automatically become authorization.

Amazon has already blocked Muse from shopping on its site, according to GeekWire. Amazon says Meta did not tell it Muse would access the store, that the agent does not identify itself while browsing, and that it appears to capture and store customer credentials. Meta says credentials sit in secure storage the agent uses without the model seeing them. The dispute is between platforms, over permission and agent identity; individual shoppers may well have approved their purchases. Amazon has fought this fight before. In March, a federal judge sided with Amazon and barred Perplexity’s Comet agent from the password-protected parts of its site.

Reading information, contacting a seller, negotiating a price and committing money are four distinct grants of permission inside one purchase. A final confirmation cannot recall information already disclosed earlier in the conversation.

What Dataiku recommends

Dataiku recommends four connected capabilities: visibility into agents and their owners, performance measurement tied to business outcomes, governance throughout the lifecycle, and intervention across the environments where agents operate. Its proposed model lets business teams build within a governed environment.

Dataiku sells the management capabilities it recommends, and launched an Agent Management product alongside the report. This is a vendor-sponsored survey of executive perceptions at large companies. It still offers a useful account of the operational gaps respondents describe.

Start with design by necessity

A use case has to start with the need. What is the agent being asked to do and why what is the most limited function that can currently be designed to accomplish the objectives? What are the potential risk risks? Design and specs should give each system only the data, tools, spending limits and operating time required for highly defined tasks. Ambiguity is where containment false apart. Enforce consequential restrictions outside the model’s discretion. Instructions to behave carefully are demonstrably insufficient if the surrounding software permits actions the business cannot tolerate.

Oversight must include notification and intervention. Assign a named owner with the authority, access and time to stop a workflow. Test revocation and shutdown before expanding deployment. Logs should show what the system actually did, including which approvals applied.

Well-designed usage patterns establish the work before it begins: inputs, permitted actions, approval points, acceptable results and conditions requiring a stop. A purchasing workflow might permit comparison while withholding supplier contact and spending authority. Adding negotiation should require a separate decision about counterparties, prices and terms.

Finally, focus on strengths that can be evaluated. Pattern recognition, classification, extraction and comparison support useful work within narrow boundaries. Identifying recurring defects in service tickets or flagging invoice anomalies creates value without granting authority to change customer accounts or release payments. Those applications still require testing, and their usefulness can be established before their reach expands.

Predictable operations allow model responses to vary. They depend on businesses defining acceptable variation, enforcing limits and stopping errors before they become consequential actions. While we are still establishing how these systems behave, giving them more latitude than we can supervise is a deployment choice. We can choose differently.

A guiding principle: don’t hand a twelve month old technology with a highly problematic track record the keys to sensitive functions simply because it can use them.