Summary
An IBM survey of 2,000 C-level technology executives found that only 11% felt fully prepared for AI-agent deployment. As agents begin carrying out multi-step actions on behalf of users, companies are seeking more precise controls over authority, visibility, and accountability.
Deployment is moving faster than oversight
AI agents are moving beyond systems that simply answer questions or generate text. Increasingly, they can call software tools, access business data, plan a series of steps, and execute actions on a user’s behalf. That shift creates a governance problem that is more complicated than ordinary software automation: an organization must determine not only whether an agent can perform an action, but whether it should be authorized to perform that action in the circumstances at hand.
The Next Web cited an IBM study of 2,000 C-level technology executives in which only 11% of respondents said they felt fully prepared for AI-agent deployment expected over the following year. About two-thirds of CIOs and CTOs said they were accountable for AI systems they did not fully control. Separately, 70% said teams were deploying technology faster than IT could track it.
Taken together, the findings point to a widening control gap. The challenge is not limited to model performance or whether an individual tool call works as intended. Companies may also struggle to maintain a complete view of which agents are operating, which systems they can reach, what instructions they are following, and how a seemingly narrow action could affect downstream processes.
Capability is not the same as authority
Madhuri Chandoor, founder of PromptHalo, frames the issue as a distinction between capability and authority. An agent may be technically capable of changing a record, calling an external service, or initiating a financial workflow. That capability does not automatically establish that the agent has permission to do so for a particular user, task, or situation.
Conventional access controls generally focus on subjects, resources, and actions. They ask whether a user or program may access a database, edit a record, issue a refund, or call an application programming interface. That approach can be effective when workflows are fixed and predictable. AI agents, however, may interpret a broad objective, break it into subtasks, select among multiple tools, and continue acting as new information becomes available.
As a result, examining each tool call in isolation may not be enough. An individual request can appear legitimate while the full sequence of actions no longer reflects the user’s original intent. Chandoor argues that organizations should inspect why an action is being taken, not only what action is being taken. Relevant questions include whether the user actually expressed the intent, whether the assigned permission matches the task, whether the surrounding conditions have changed, and whether the action could produce consequences outside the original scope.
Why one-action limits can leave gaps
The source article uses a refund-splitting scenario to illustrate the problem. A company might impose a limit on the amount or scope of a single request. An agent could nevertheless pursue a larger objective through several sequential requests. Each request might remain below the threshold when assessed independently, while the combined outcome could exceed the control that the company intended to establish.
The example is not a claim that every agent will deliberately evade a limit. Rather, it demonstrates why static and isolated checks can be insufficient for systems that plan and execute multi-step tasks. Enterprises may need to evaluate the relationship between actions, their timing, their common destination, and their cumulative effect. Otherwise, a control system may answer only the question, “Is this request allowed?” It may fail to answer, “Does this series of requests still serve the authorized purpose?”
The same concern applies to infrastructure and database administration. The article refers to a hypothetical enterprise task in which an agent responsible for improving application performance might alter infrastructure. Before allowing such an operation, a company would need to define which resources may be changed, how broad the change may be, whether approval is required, and what recovery options exist if the action produces unintended effects.
The excerpt does not provide the full outcome of that hypothetical example. Its broader point is that a business objective does not, by itself, justify unlimited system access. “Improve performance” is a goal, not a complete authorization policy. The policy must also specify acceptable methods, boundaries, escalation conditions, and responsibility for the result.
From static permissions to behavioral monitoring
Chandoor advocates a form of behavioral profiling for AI agents, drawing on methods used to monitor financial fraud. Such a system would not focus exclusively on whether a single action is permitted. It would also assess whether the action fits the established pattern for a particular agent, user, workflow, and operating environment.
For an agent, that profile could include the systems it normally accesses, the order in which it performs tasks, the frequency of requests, the tools it typically combines, and the relationship between its actions and the user’s stated objective. A sudden attempt to reach a previously unused resource, a rapid series of related requests, or an unusual chain across multiple systems could trigger additional verification, narrower permissions, or a temporary pause.
Behavioral monitoring is not a replacement for authorization design, and it cannot guarantee that every risk will be detected. A deviation may be legitimate because the agent has received a new assignment. Conversely, behavior that looks normal may still produce an incorrect or harmful result. Monitoring therefore needs to operate alongside human review, detailed logs, permission segmentation, and recovery procedures.
The goal is not simply to label an agent as trusted or untrusted. It is to give operators enough context to understand the action before it occurs and to reconstruct the sequence afterward. That context becomes especially important when an agent’s output is not just information, but a change to a business system or an external obligation.
Implications for financial and custody workflows
The debate has direct relevance to enterprise payment systems, institutional wallets, and digital-asset custody workflows. If an AI agent is permitted to prepare a payment, interact with an external service, or initiate a transaction-related process, a limit on a single action may not fully capture the risk of repeated requests, multi-step execution, or cross-system effects.
A more granular design would distinguish between viewing information, generating a recommendation, preparing an action, and providing final authorization. It could also evaluate cumulative exposure, destination changes, unusual timing, and whether the agent’s current behavior remains consistent with the approved purpose. These controls are particularly important where an action may be difficult to reverse.
This does not mean that financial operations should be handed over to automation, nor does it endorse any particular product or service. It means that organizations considering agent involvement in sensitive workflows need to define which steps require human confirmation, what conditions cause an automatic pause, and how errors can be contained or remedied. For institutional operators, an auditable record should show who granted the permission, what task the agent was assigned, which rules applied, and which accounts or systems were affected.
Building a control layer that can be audited
The IBM findings ultimately raise a question more fundamental than whether a company has deployed an AI agent: does the company have a governance layer capable of constraining the agent’s capabilities? Relying on informal employee understanding, scattered application permissions, or after-the-fact log reviews may not be sufficient when agents can independently decompose and pursue objectives.
Several foundational measures can improve visibility. Organizations can maintain an inventory of deployed agents, including their purpose, accountable owner, accessible resources, and approved tools. They can bind permissions to a defined task and context rather than granting broad, long-lived access solely on the basis of an agent’s identity. They can also preserve decision and execution records in a form that allows reviewers to reconstruct a complete sequence, rather than seeing only isolated API calls.
High-impact operations may require tiered approvals, cumulative limits, anomaly detection, and emergency stop mechanisms. Those rules should be tested against realistic multi-step scenarios and updated as the agent’s behavior and the surrounding business process change. A policy that works for a single, predictable request may not work for an adaptive system that can choose its own sequence of actions.
The competitive pressure to deploy AI agents may continue to grow, but readiness cannot be measured only by whether a system has gone live. Operational readiness means being able to explain what an agent is doing, why it is doing it, which authority supports the action, and who can intervene when the behavior exceeds expectations. Capability and authority must therefore be designed as separate concepts, linked by controls that remain visible throughout the full chain of execution.
Source: link