An AI Agent Shouldn't Be Able to Execute Everything It Proposes

To propose is not to execute

For a long time, interacting with a chatbot had a simple limit: the system produced information. Between the answer and the outside world there was, as a rule, a filter: the person.

If the assistant told you, “Two meetings overlap; I think you should move Thursday's,” you decided whether the meeting moved.

When the same system is given access to the calendar, the filter changes. It can move the meeting itself. The answer becomes an action, and an error no longer produces just a wrong sentence but a consequence in the world. We discussed this shift and its risks in AI Doesn't Have to Turn Evil to Become Dangerous. Here we ask what has to be built between a proposal and an execution.

It helps to separate three questions that are easy to confuse. The example stays with the calendar:

1. 01

   What should be done? The proposal

   The model proposes: “move Thursday's meeting.”

2. 02

   What can be done? The capability

   The system has access to the calendar, so it can move the meeting.

3. 03

   What is it allowed to do, now, on whose behalf? The authority

   Has the user delegated moving meetings? All of them? Including those with people outside the organization?

The answers can differ. A model can propose something the system cannot execute. A system can execute something it should not execute. And between the two lies a question the model should not answer on its own.

That is why the order matters: model → control layer → tool → action in the world.

1. The model proposes an action.

2. The control layer determines whether the proposal has authority.

3. The tool executes only what passes this layer.

4. The action produces an effect in the world.

We use the terms below in the same sense throughout the article:

Proposal

The action the model selects or recommends. It is an input to the system, not a command.

Capability

What the system can technically execute, through the accesses and tools connected to it.

Permission

The technical and policy boundary that encodes what can be executed: which actions, on which resources, under what conditions.

Authority

What the user or the organization has delegated to the system. Permissions are the form in which authority is expressed technically.

Human approval

An explicit confirmation from a person, required for certain actions, before execution.

By default, permissions should be narrower than capabilities

A model without tools can only produce text. An agent connected to email, documents, customer systems or financial systems can change the state of the digital world around it. The cognitive capability may be the same. The action surface is not. The role of tools among the components that change the nature of a system is discussed in article 1; we don't revisit it here.

There is a trap, though. The access granted to a tool is often broader than the authority the user meant to delegate. Connecting an email account can technically grant the right to read, write and delete any message. The user, perhaps, only wanted the system to reply to appointment confirmations.

The gap between access and authority does not close by itself. It is closed by a layer that expresses authority in a form narrower than raw access. Hence the principle:

“By default” means a starting point, not a permanent prohibition. An agent that can do nothing is not useful. But widening is a decision, with a reason and an author, not a consequence of the technology allowing it.

If an agent can technically delete a document or write to anyone in the address book, it does not follow that this authority should be granted. An agent supporting a sales process might, for example, be allowed to record the outcome of a conversation and propose a follow-up, without being able to modify any field in the company's system.

A permission can be limited by type of action, resource, role, value, time window or context. This is the idea of least privilege, which we placed among the veto mechanisms in article 1. What interests us here is something else: where it is applied.

Why control cannot live only in the prompt

The most obvious solution is to write the limits into the model's instructions: “Don't delete documents. Don't send messages without approval.” Instructions are useful: they steer behavior and reduce errors. But an instruction is an instruction, not a technical guarantee.

A model interprets instructions; it does not execute them the way a program does. It can misunderstand an unforeseen situation or weigh two requirements differently. Through the content it reads (a message, a document, a page), it can receive text that looks like a new instruction. In such a system there is no guarantee that every instruction will be followed in every situation.

That is why the model should not be the final arbiter of its own permissions. If the limit exists only in the text the model reads, compliance depends on the same model we want to limit.

Control has to be applied between the model and the tool. The model proposes an action. A separate layer checks, based on rules the model cannot modify, whether that action may reach the tool. What does not pass the check is not executed, however convincing the proposal was.

Such a layer makes sense only if it meets one condition: it must be simpler and more verifiable than the system it limits. Explicit rules, predictable behavior, something that can be read and tested, not yet another model that has to be interpreted. A layer as opaque as the model merely moves the problem. This is the idea behind the safety principle AITEL describes for A.D.E.: permissions and deterministic controls that limit what the AI can do, with actions that remain verifiable.

This is not a guarantee. A control layer can be misconfigured or have errors of its own; we come back to this below. But it moves the limit from a place where it depends on the model's cooperation to a place where it can be verified. Instructions remain useful as a first layer, not as the last.

Permissions are not safety

There is a tempting conclusion: if we have permissions, the system is safe. It is not. Permissions set the boundary of what can be executed. They do not guarantee that a permitted action is correct. A permitted message can reach the wrong recipient, a permitted amount can be the wrong amount, and a rule applied correctly can be the wrong rule.

Safety comes from several layers that answer different questions:

Permissions

What can be executed, in principle.

Policies and rules

Under what conditions: thresholds, categories, context.

Verification

Of parameters before execution (the recipient, the amount) and of the result afterwards.

Monitoring

Detecting unusual behavior or drift in good time.

Audit

Reconstructing and checking afterwards what happened.

Escalation

Passing a case to a person, at defined triggers.

Human override

The ability to stop, revoke or undo.

The list is not meant to be worked through like a form. What matters is what it shows: each layer answers a different question, and none answers them all. Veto mechanisms are discussed in article 1; here we only place permissions among them, as the first filter, not the last.

Verifiable before, reversible after, irreversible in the real world

The level of control cannot depend only on the action itself. It has to take three distinct things into account, often confused:

Verifiability

Can we check before execution whether the parameters are correct? A draft can be read before sending. A call cannot be “read” beforehand.

Reversibility

Can we go back after execution? A modified document can be restored from an earlier version.

Effect in the real world

Some effects cannot be undone even if the application offers rollback. A sent email cannot be “unsent,” and a call that has been made cannot be taken back.

A wrong draft gets corrected. A message sent to the wrong person does not, because someone has already read it.

An action that is easy to verify beforehand can be given more autonomy than one that cannot be verified. But when the effect extends beyond the system (communication with third parties, calls, payments), reversibility inside the application is not a sufficient argument for more autonomy.

Consequence depends on more than reversibility

Reversibility is one dimension, not the only one. The same action can call for different levels of control depending on:

• Uncertainty: how sure the interpretation of the situation or the data is.
• Data sensitivity: personal, confidential, medical or financial data.
• Impact on third parties: people who were not part of the conversation and have delegated nothing.
• Legal or contractual obligations: what binds the organization and in which jurisdiction.
• Frequency: how often the action is repeated.
• Scale: how many people or systems are affected.

The last two matter more than they seem. Many small actions, each harmless and reversible, can together produce a large effect. A thousand messages sent from a single wrong interpretation are a problem of a different nature than one message. Control has to see the aggregate too, not just the isolated action.

Context matters as well. Automatically sending an appointment confirmation is not equivalent to sending a message by which a company accepts a contractual obligation. A rigid catalog of actions cannot make this distinction on its own; the rules have to take context into account.

There are categories where the question is not how much autonomy the agent should get: contractual obligations, financial operations, decisions that affect the rights or access of other people, and other comparable actions. As a design direction, the decision here stays with a human, or the action is excluded from the agent's authority. An agent can prepare, document or propose. It should not, on its own, bind an organization or decide on someone's rights. From AITEL's perspective, broad autonomy is not the right direction for these areas.

Who controls the control system?

There is a legitimate objection. If the rules and permissions are written by people, they can be wrong. A control layer can be too broad, configured in a hurry, or fall behind the processes it limits. The honest answer is not that the problem disappears. It is a set of principles that make it easier to observe and to correct:

• Narrow default limits. A system starts with little and receives more only when justified.
• Explicit, recorded expansion. Every widening of authority is a decision with an author, a moment and a reason, and it leaves a trace.
• Gradual expansion. From preparing an action, to executing it with approval, to executing within set limits, as results justify it.
• Monitoring outcomes. Granted autonomy is adjusted according to what actually happens, not what was assumed.
• A control layer simpler and more testable than the model. Rules that can be read, tested and changed, unlike the behavior of a model.
• Risk tolerance set by the user or organization, within the limits the product sets. Whoever is accountable for a process decides how much risk to accept; the product fixes the ceilings beyond which one cannot go.

No such system guarantees the elimination of errors. A control layer reduces certain risks and makes others visible. A residual risk remains, and responsibility for configuration and for reviewing it periodically remains human.

What the system did must be possible to reconstruct

When a system acts, sooner or later someone asks what happened. Three different things get mixed up here:

Logging

Recording events: which action, when, with which tool, with what result.

Auditability

The ability to reconstruct and verify what happened: who or what initiated the action, which permission allowed it, which rules applied, whether there was human approval.

Explainability

The attempt to understand why the system chose that action. It is a harder problem, and the answer cannot be assumed from logs.

Logs do not automatically explain the model's reasoning. They show what the system received, what the model proposed, what the control layer decided and what was executed. They do not, on their own, show why the model chose that proposal. A good trail makes an incident reconstructable, not necessarily explainable.

Nor do logs detect problems. Monitoring and verification detect problems; logs make it possible to investigate them. Without the former, an incident may be discovered late; without the latter, it cannot be understood.

Used with care, they allow something important: correcting the rules. If a category of actions produces too many errors, authority can be reduced. If a process proves stable, it can be extended. Autonomy becomes something that is managed on the basis of evidence, not just something that is switched on.

Logs can contain personal information about the user and about third parties. The same care applies as for memory: what is kept, for what purpose, for how long and who can consult it. We discussed this in From Answers to Continuity: The Role of Memory in the Move from Chatbot to Digital Entity.

How this principle connects to the A.D.E. architecture

In the way AITEL conceives the A.D.E. architecture, reasoning and action are not the same thing. The model proposes. Operational identity, memory and context inform it, as we saw in the article on memory. Tools execute. Between the proposal and the tool sits a layer of rules, permissions and checks that determines what can become an action. The safety principle AITEL describes for A.D.E. starts from the same idea: explicit limits, not implicit ones, and actions that remain verifiable.

This is a description of principle, not a list of components already implemented in every product.

The examples below are illustrative: design directions, not functions verified as available today. The actual status of each capability is the one shown on the product page.

AITEL Assist

Phone calls are a good example of an action with an irreversible real-world effect: a call that has been made cannot be undone. In such an architecture, the same separation could matter for planned channels too, such as email or calendar: the model could propose a message or a meeting change, and the control layer would determine what can be executed on its own and what requires human approval.

AITEL Sales

As a design direction, commercial communication could be separated from commercial commitments: the agent could hold a conversation and record the outcome, while accepting an obligation would remain a human decision.

AITEL Vision

Detecting an event would be a signal for human review, not an automatic judgment about a person and not an automatically triggered action. What follows remains a person's decision.

The common idea is the same: the model proposes, the tools provide the capability, and authority is granted and enforced separately.

Good autonomy doesn't remove the human. It changes their position.

A question remains. If we limit, verify and approve everything, do we still have an autonomous agent, or just a chatbot that executes commands?

A system that asks for approval at every step does indeed end up as a more complicated interface for things the person could do alone. But the alternative is not unlimited autonomy. The person no longer executes every operation; they set the limits within which the system works. For repetitive, predictable actions with limited consequences, the agent can be given more autonomy. For ambiguous or sensitive ones, or those with a real-world effect that is hard to undo, control returns to the human.

Here there is an opposite trap: too many approvals. A person asked to confirm dozens of actions a day starts pressing “yes” out of inertia. Control becomes a formality. More confirmations do not automatically mean more control; sometimes they mean less, because they hide the ones that matter. Approval should be requested where it counts.

When is human attention warranted? It should not depend only on the model, which can misjudge its own uncertainty. There can also be objective triggers, checkable by the control layer:

• a new recipient;
• a value above a threshold;
• a sensitive category;
• an action unusual compared with the pattern;
• an important change of context.

The model's confidence can be an additional signal, not the only one.

A useful agent is not one that can do anything. It is one that knows what it can do on its own, what it must confirm and where it must stop, because the limits do not depend only on what it has understood but are enforced by an architecture it does not control on its own.

In the first article we started from the idea that risk does not require hostile intentions; it appears when reasoning, memory, tools and autonomy combine. In the second we saw what memory gives a system: continuity. Here we have reached the point where such a system is also given the capability to act.