An email arrives in the purchasing department. The AI assistant summarizes it, retrieves the order, checks the invoice and drafts a reply. So far, it is saving time. But if it can also modify a supplier’s details or initiate a payment, the same scenario takes on a different character. The real issue is no longer just what AI knows, but what it is allowed to do. Looking ahead to September 2026, this boundary is likely to shape the deployment of agents. The examples below draw on public developments before 2026; the developments envisaged remain prospective.
From chatbots that advise to software that acts
An AI agent combines a model, instructions and tools: document search, a browser, database queries, ticket creation and messaging. It can carry out a sequence of operations to achieve a goal. The difference from a conventional chatbot is less dramatic than it might seem, but decisive: its response can become an action within an information system.
This transition was already visible in 2024. Microsoft was introducing autonomous agents in Copilot Studio; Salesforce was launching Agentforce. Anthropic was experimenting with computer use by Claude, then released the Model Context Protocol, or MCP, designed to facilitate connections between AI applications, data and tools. These announcements pointed in a common direction: moving beyond the chat window to take part in business processes.
The promise is tangible. Instead of explaining how to handle a customer return, the agent retrieves the purchase, applies the sales policy and prepares the refund. But every connection adds a capability, and therefore a risk. A model that gets a summary wrong produces a textual error. The same model connected to accounting software can produce an accounting error.
Connectors become security boundaries
Connection protocols reduce the work required to make a tool accessible. They do not, on their own, resolve the question of authorization. Standardizing connections does not mean securing every use. The identity used, the resources accessible and the operations permitted still need to be determined. Reading a customer record is not the same as exporting the entire customer database.
The classic trap is to give the agent an employee’s permissions, or even a highly privileged service account, to avoid roadblocks. This makes the demonstration easier but weakens the production environment. An agent tasked with scheduling a meeting does not need access to human resources archives. One that checks an invoice does not necessarily need the ability to pay it.
The right level of granularity therefore goes beyond a simple “allow” button. It distinguishes between reading, creating, modifying and deleting, but also between scopes, durations and amounts. Temporary access to a specific folder is better than a permanent token covering an entire application. Permissions must be checked by the systems executing the action, not merely reiterated to the model in an instruction.
When a document tries to give orders
With agents, a known threat takes on operational significance: indirect prompt injection. A web page, email or document being consulted contains malicious instructions. The text seeks to divert the agent from its task, for example by asking it to retrieve confidential information and then send it to an external address.
This is not a conventional cyberattack targeting a password. It exploits the model’s difficulty in separating legitimate instructions from content it is only supposed to analyze. A message may present itself as an urgent internal memo or a security procedure. The agent must nevertheless treat it as untrusted data, not as a new authority.
No text filter alone can guarantee this separation. Defenses must also limit the consequences: approved destinations for outgoing messages, secrets inaccessible to the model, isolated environments for certain tasks and independent checks before execution. A manipulated agent without permission to export a database will cause less damage than a supposedly cautious agent with universal access.
Human approval: useful, but no magic solution
“A human will approve it” sounds reassuring. But that person still needs to be shown what they are approving. A window displaying “Continue?” does little to help identify a change in bank details. The confirmation must show the exact action, its target, the data being transmitted and the expected consequences. For a sensitive operation, it should also flag anything unusual.
Submitting everything for approval would, however, be counterproductive. After repeatedly confirming routine actions, users end up clicking mechanically. A better approach is to establish graduated autonomy: let the agent categorize tickets, set boundaries for its sales responses and require enhanced approval for a payment, a bulk deletion or a change in permissions.
- Low impact: automation with logging and after-the-fact checks.
- Medium impact: limits on volume and scope, with the ability to undo actions.
- High impact: explicit approval, potentially including a second check, before execution.
Track actions, rather than claiming to read thoughts
When an error occurs, keeping the conversation is not enough. It is necessary to know which tool was called, with which parameters, under which identity and with what authorization. The result, the time, the system version and any approvals must make it possible to reconstruct the operation. This audit trail links the initial request to the effects actually produced.
Useful traceability is not a purportedly exhaustive transcript of the model’s internal reasoning. It concerns observable facts. It must also respect confidentiality: systematically recording every document consulted could create a second repository of sensitive data. Logs therefore require their own rules for access, retention and protection.
Accountability cannot be delegated to the model
If an agent grants an unauthorized discount, who is accountable for the incident? The team that configured it, the process owner, the software provider? The answer will depend in particular on contracts, applicable obligations and the circumstances. But a company cannot organize its operations around an entity presented as autonomous without designating accountable people.
The GDPR remains relevant whenever personal data is processed. The EU AI Act, adopted in 2024 with a phased implementation schedule, adds obligations depending on use cases and the roles of those involved; it does not automatically classify every agent as a high-risk system. Compliance must examine the actual context, not simply the “agent” label.
In practice, this requires a service owner, an incident procedure and a way to cut off access quickly. Revoking a token, suspending a connector or reverting to manual processing matters as much as choosing the model. Before deployment, tests must include maliciously crafted documents, expired permissions and partially executed operations.
What next? Looking ahead to September 2026, differentiation could shift toward this unobtrusive infrastructure: dedicated identities, temporary permissions, clear approvals and evidence of execution. The most useful agents will not necessarily be those allowed to do everything, but those whose autonomy can be expanded without losing control. For companies, the right first project is therefore not an all-powerful assistant: it is a bounded, measurable and reversible task.
