An assistant that fabricates an answer wastes time. The same assistant, connected to billing software, can send an unwarranted payment reminder to a strategic client. Connected to procurement systems, it can turn a misinterpretation into a binding order. The decisive change is not just the model’s intelligence: it is its authority to act. Looking ahead to September 2026, the real work of deploying AI agents therefore lies less in chat windows than in the rules governing access to enterprise systems.
From advice to execution, a fundamental shift
The trajectory is already visible in announcements and products that emerged in 2024 and early 2025. Salesforce introduced Agentforce, Microsoft expanded Copilot Studio’s agent capabilities, and OpenAI unveiled Operator, which can interact with web interfaces. These documented milestones do not demonstrate widespread autonomy. They do, however, point in a common direction: moving from a tool that suggests an action to software that attempts to carry it out.
What follows is forward-looking analysis, not a verified assessment of the situation in September 2026. Within businesses, this evolution could shift the central question. Rather than asking only whether AI answers correctly, organizations will need to establish what it can modify, on whose behalf and within what limits. An inaccurate summary can still be corrected. Deleting data or initiating a payment calls for different safeguards.
Consider a fictional but commonplace example: “Sort out this supplier’s overdue invoices.” Does that mean finding missing documents, correcting a reference, preparing a payment or executing it? For an employee, context and procedures generally define the scope of the assignment. For an agent, that sentence can become a series of software calls. Each step requires separate authorization, something the fluidity of conversation tends to obscure.
A service account is not an unlimited mandate
The shortcut would be to give the agent an employee’s credentials and let it get on with the job. That would conflate two things: the permissions a person has to perform their role and those needed for a specific task. A finance manager may have access to every supplier. An agent tasked with checking an invoice does not need the ability to change their bank details.
The principle of least privilege, a long-standing cybersecurity practice, therefore takes on a new dimension. Permissions should be restricted by operation, by resource and, where possible, by time. Reading a file, proposing a change and approving that change are three different powers. Bundling them behind a “connect my business” button makes for an appealing demonstration, but leaves the risk difficult to control.
It is also important to distinguish between the identity of the agent, that of its user and that of the technical service executing the action. Without that separation, an operation simply appears to have been performed by a shared account. It then becomes difficult to establish who requested it and under what delegated authority. An agent must receive a clearly bounded mandate, not silently inherit all of its user’s authority.
A document being consulted can become a trap
Agents combine two sensitive characteristics: they read external content and sometimes have access to powerful tools. An email, web page or shared document can contain malicious instructions aimed at the model. This is the problem of indirect prompt injection: text intended to serve as information attempts to become a command.
Imagine an attachment that discreetly asks the assistant to send a customer data export to an external address, under the pretext of an accounting check. The danger is not that the document itself has any system permissions. It is that the agent uses its own permissions to follow an instruction from an unauthorized source. The boundary between data and commands has then disappeared.
The response cannot rely solely on an instruction to the model: “Ignore suspicious instructions.” Controls must also exist outside it: approved destinations, output filtering, access restrictions and parameter checks before execution. A deterministic component can block a prohibited transfer even if the agent considers it useful. Security must not depend solely on its ability to recognize a trick.
Easier connections do not mean proper authorization
Introduced by Anthropic in November 2024, the Model Context Protocol, or MCP, illustrates the push for a common interface between assistants, data and tools. This type of standard can reduce the work needed to connect a model to a business environment. But technical compatibility alone does not resolve the governance of actions.
A connector specifies how to call a function. It does not necessarily determine whether that function should be accessible in a given situation. A business will still need to examine the permissions requested, the provenance of components and the information transmitted. A tool catalog deserves the same scrutiny as an application catalog: every new connection potentially expands the attack surface.
Human approval must be meaningful
“A human remains in the loop” can become an empty phrase. If someone approves fifty opaque proposals in succession, they risk clicking out of habit. Meaningful approval requires a clear presentation of the exact action, the data involved, its consequences and the evidence supporting the request. For a bank transfer, displaying only “compliant transaction” does not allow for serious scrutiny.
The level of oversight should reflect the risk. Categorizing an internal ticket can remain automatic. Drafting a sales response may require a review. Changing a bank beneficiary or deleting archives may require dual approval. Above all, approval must apply to the parameters actually used in execution: if the amount or recipient changes after approval, that approval is no longer valid.
Track actions and plan for recovery
The conversation alone is not a sufficient audit trail. Records must capture the tools called, the parameters passed, the responses received, the permissions used and the approvals obtained. The goal is not to collect some hypothetical internal reasoning from the model, but to reconstruct observable facts. This logging must itself protect personal data and avoid unnecessarily recording secrets.
Organizations must also prepare for failure. Some actions can be undone; others require a compensating action, and a sent email cannot truly be taken back. Activity limits, an emergency stop and testing against adversarial scenarios become essential. Teams will need to measure not only successful tasks, but also unwanted actions, justified refusals and the time needed to put things right.
What comes next? For September 2026 and beyond, the most credible scenario is not necessarily one in which agents are free to do anything. It is one of graduated autonomy, earned task by task through verifiable results. Starting with a scope in which actions can be reversed, separating proposals from execution, and then expanding permissions after evaluation may seem less spectacular than an unsupervised demonstration. But that may be precisely where the lasting advantage lies: knowing how to entrust an action to AI without surrendering control over its consequences.
