When an AI can move from recommending an action to executing it
A convincing response is not authorisation. Before connecting AI to an API, separate recommendation, proposal and execution, then define permissions, confirmation, logging and reversal.
An AI can say "you should cancel this subscription" or "send this email." That is text: a recommendation that changes nothing on its own. Something very different is being able to call an API, modify a record, or actually send the message. Confusing the two — the persuasive sentence and the real action — is the design error that turns a convincing answer into an implicit authorization, and it is the boundary to understand before giving an agent a single key. The capability you take away from here is not whether an agent "can" act, but what minimum permission it needs, who confirms each jump, and what happens if it is wrong.
Three steps, and the risk jumps at each
It is worth separating three levels that marketing tends to blur. In the recommendation, the model offers an option and touches nothing: the user decides. In the proposal, it prepares a concrete action — a recipient, an amount, a date, a change — and leaves it ready for review, but still does not execute it. In execution, an integration uses a real permission and modifies an external system: it sends the email, makes the payment, deletes the record. The risk does not grow gradually across these steps; it jumps at the last one, because only there does a wrong interpretation leave consequences in the world instead of on a screen.
That jump matters especially because an agent decides what to do by reading text, and text can be manipulated. If an agent with write permission reads an email, a document, or a page containing hidden instructions, it may end up executing what a third party wanted rather than what its owner asked. It is the same family of risk that worries agent security: the power to act, combined with untrusted input, turns a useful tool into an attack surface. That is why least privilege is not bureaucracy: it is the firewall between a reading error and real harm. And it explains why the fix is not "make the model smarter": however good it is at reasoning, it still decides from text someone else may have written, so the defense lives not in its head but in what its token lets it touch. A brilliant agent with delete permission is more dangerous, not less, than a mediocre one that can only read.
An example grounds it. Picture an agent handling expense reports. At the first step, it flags: "this invoice looks like a duplicate of Tuesday's" — a recommendation a human can ignore. At the second, it prepares the rejection email to the vendor, with the amount and the reason, and leaves it as a draft for someone to read. At the third, it issues the refund or blocks the payment in the accounting system. The same agent, the same intelligence: what changes between harmless and dangerous is not its ability to reason, but which permission is enabled and whether someone confirms before the third step. Designing well is deciding, for each action, which step it stops at by default.
What a permission really is
Google's OAuth 2.0 documentation formalizes it: a token grants access to resources and operations defined by scopes, not to everything the system could do. An agent does not obtain permission because its explanation sounds reasonable or because it "understands" the task; it can execute exactly what its token authorizes, not one step more. Hence the principle of least scope: giving the narrowest permission the task needs reduces the possible harm if the agent misreads an instruction or trips over manipulated information. A read-only token cannot delete even if the model, confused, "decides" that something must be deleted.
Translated into design, that means not using the same rule for everything. An agent can summarize invoices without being able to pay them; it can draft an email without sending it; it can create a purchase request that a person approves before it becomes an order. Human confirmation is not an ornament when the cost of an error is high or hard to reverse: it is the point where the execution step stops until someone accountable says yes.
Why logging is not optional in an agent
Of the four checks that follow, logging deserves its own note, because in an agent that acts it is the only thing that lets you answer the most important question after a failure: why did it do what it did? An assistant that only recommends leaves its trace on the screen; an agent that executes spreads its effects across external systems, and without a record of which instruction it received, what data it read, which permission it used, and what result it produced, an error becomes impossible to reconstruct and therefore to correct or attribute. Traceability is not an audit luxury: it is the condition for discussing a system's failures without responsibility dissolving between "the AI decided it" and "I just pressed a button."
Four questions before automating
From all the above comes a short list that works for any integration. Scope: can the agent read, propose, or also write and delete? Confirmation: is the action reversible, routine, and low-impact — able to run alone — or does it require explicit human approval? Logging: is there a record of the instruction received, the data used, the permission invoked, and the result, so it can be audited later? Reversal: can the effect be undone, paused, or bounded if something goes wrong? A "no" to any of the four does not forbid automating, but marks where a brake is needed before doing so. Reversibility rules over the rest: an action that can be undone tolerates more autonomy than an irreversible one, even if both look equally routine. Sending an email and making a wire transfer may cost the same to type; undoing them does not.
A framework so the brake is not improvised
Those questions are not an improvisation: they fit a recognized framework. The NIST AI Risk Management Framework organizes the work into four functions — govern, map, measure, and manage risk. Applied to an agent that acts, they read like this: govern is defining who is accountable for an action; map is understanding in what context it is used and what it can touch; measure is knowing which failures are watched and with what signals; and manage is having a way to stop, correct, or reverse it. The generative-AI profile that accompanies the framework does not certify any specific integration — there is no seal saying "this agent is safe"; it recalls that risk depends on the use case, and that the same agent can be harmless drafting and dangerous executing.
The practical conclusion is sober and freeing at once: an AI can be very useful without receiving the keys to the system. Most of an assistant's value lives in the first two steps — recommending and proposing — where the cost of an error is a sentence you discard, not a payment you have to recover. The right question in front of any "autonomous agent" promise is not "can it do it?" but "what minimum permission does it need, who confirms the jump to execution, and what exactly happens if it is wrong?" Whoever can ask those three questions can make use of an agent without handing it something it should not have.
Primary sources
This article was produced with artificial intelligence under human editorial oversight.
