An agent is only useful if it can act, and it can only act if you give it access. That same access is exactly what an attacker gets if they manage to hijack it. There is no configuration that is both powerful and risk-free. So the question is always the same: what is the minimum that makes the tool useful for what I want from it?
This morning we reported on an agent intended to cover messaging, calendar and payments. Here is how to think it through before granting anything.
The principle of least privilege
It comes from IT security and dates back fifty years: grant only what the task requires, and nothing more.
Applied to agents, it breaks down into four dimensions that are often conflated.
Scope. Which services, which folders, which inboxes. An agent that organises your work calendar does not need your personal messages.
Type of action. Reading is not writing, writing is not deleting, and none of those is paying. Most useful use cases need nothing more than reading.
Duration. Access granted for a task should expire with it. Permanent access granted for a one-off need is the most common case and the most avoidable.
The cap. For anything involving money, a maximum amount per transaction and per period. We noted, regarding the opening of trading to agents, that the absence of a cap literally means the possible loss of everything in the compartment.
The most widespread mistake is connecting an agent with your main account, the one that has all the rights. It is quick, and it amounts to giving it your keys rather than a key. The right practice is to create a dedicated account with restricted rights, which can be revoked without disrupting anything else. We wrote this regarding scoped tokens: you do not hand over the resource, you hand over a bounded, traceable permission.
The five concrete checks
Take stock of what is already connected. Most people discover along the way permissions granted months ago for a trial, never revoked. This is the starting point for everything else.
Separate your worlds. Work and personal, sensitive documents and ordinary ones. An agent with access to one should not have access to the other.
Require confirmation for the irreversible. Deleting, sending, paying, sharing. These actions should require explicit validation, even if it is less fluid. This is the criterion we proposed in our article on delegation: what is reversible can be automated, the rest requires a human.
Look at memory. An agent that retains information from one session to the next can be poisoned durably, as we documented with a flaw exploiting precisely that mechanism. Check what is retained, and purge if necessary.
Treat outside content as hostile. An agent that reads emails, web pages or received documents is processing content someone else wrote. We showed that invisible text is enough to manipulate it. If your agent reads from the outside and can act, that is the combination to watch first.
The right reflex before granting
One question is enough, and it replaces a risk analysis: if someone took control of this agent tomorrow, what could they do?
Not "is it likely", but "what would be possible". If the answer includes things you could not undo — money gone, a message sent, a document shared — the scope is too broad for the use case.
What to take away
None of these precautions are specific to AI: they are the principles of access management, applied to a new kind of user.
What is new is how easy it is to grant. Connecting a service takes two clicks, and the screen listing the requested permissions is the one nobody reads. That is exactly where the security of these tools is decided, far more than in the robustness of the model.