Let users limit, confirm and review your AI agent's actions. Spain's privacy regulator advises it.

In a May 2025 demonstration, security researchers at Invariant Labs filed a malicious issue on a public GitHub repository. When the repository's owner then asked an AI agent to review its open issues, the instructions hidden in that issue made the agent copy data from the owner's private repositories into a public pull request (Invariant Labs' write-up). The agent's app asked for confirmation before each tool call by default, but the researchers noted that many users switch that to "Always Allow", so nobody sees an action like this before it runs.

On 27 October 2026, Spain's data protection authority, the AEPD, published a guide for people who let AI agents act for them 2. Its last page lists the controls it says the companies behind those agents "should" offer. In my translation: "Responsibility for AI assistants and agents cannot rest on the user alone." The seven controls, which I have numbered, are 1:

1. Permissions people can understand, which separate looking something up from acting on it.
2. A confirmation step, which the user can configure, for the actions with the most impact.
3. A history of what the agent has done on the user's behalf.
4. A way to stop the agent immediately.
5. Memory management, including deletion.
6. Clear information about who the data is sent to, and whether it is used to train AI.
7. A simple way to exercise data protection rights.

An agent limited to the one public repository could not have reached the private ones, and a confirmation step that stayed on would have asked before the pull request was created. The list is advice, and it creates no new law. But a business customer may only use vendors that give "sufficient guarantees" for its data, and a customer reviewing an agent feature now has a regulator's list to check it against.

Which controls matter most when an agent is attacked?

Permissions first, then confirmation and the history of actions. The AEPD says plainly that no measure removes the risk of an agent being tricked, "so the best protection is to limit what the agent can do if it is tricked" 1. Confirmation catches what the permissions still allow, and the history shows afterwards what happened. If I were building only three this quarter, I would build these.

Permissions that limit what a tricked agent can do

The guide's advice to users is that "reading is not the same as sending, modifying or deleting", and that access should be limited to what the task needs ("one folder, one calendar"). The more content from strangers an agent handles, the less access and ability to act it should have. The AEPD's February 2026 guidance for organisations that use agents calls least privilege "the basic principle" 4, and Invariant Labs' own first recommendation was to limit the agent to the repositories it needs. A product can only offer that if it can grant read access without write access, and access to one folder without the rest.

A confirmation step that shows the details

The guide tells users to require confirmation before the agent sends, publishes, shares, deletes, pays, signs up or accepts terms, and not to grant permanent "always allow" authorisations unless they are really needed. It also tells them to read what they approve: "recipient, amount, date, attachment". A confirmation screen that shows only a summary of the action does not let anyone check those.

The reason is hidden instructions: a web page, email or calendar invitation can carry text, "even invisible to you (white text on a white background)", that makes the agent send data or approve something. The guide tells users to avoid tasks where one agent reads content from strangers, has access to private data and can act in their name, and to require confirmation before any outward action when that cannot be avoided. Simon Willison calls a similar combination the lethal trifecta: access to private data, exposure to untrusted content, and the ability to communicate externally.

The GitHub demonstration shows the limit of this control. The confirmation existed and users switched it off. A product that makes "always allow" the easy choice has the control on paper only.

A history of what the agent did

The guide's advice to users describes the history it has in mind: choose an assistant that lets you check what it accessed, when, and what it changed in each task, and undo changes you disagree with. It also tells users to check "what messages were sent, what files were shared, what purchases were made".

The history also matters to the company behind the agent. An agent reaching data it was not allowed to reach can be a personal data breach under the GDPR even without an attacker 3. The controller then has to notify its regulator within 72 hours of becoming aware of it, unless the breach is unlikely to put people at risk, and a processor must tell the controller without undue delay. I covered this in GDPR counts an AI agent reading personal data past its permissions as a breach. Without a history, nobody can tell whether a breach happened or which data it reached.

Is the AEPD's list a legal requirement?

No. The guide says "should", and it is one national regulator's advice to the public, binding on no company in Spain or anywhere else. Its weight comes from the GDPR duties behind the controls 3. The guide cites no articles, but in my reading the list follows the GDPR's duties of data protection by design (Article 25), security (Article 32), erasure (Article 17), telling people about purposes and recipients (Articles 13 and 14) and making their rights easy to use (Article 12). Those duties name no specific control, but write access to a whole mailbox for a task that only reads one folder is hard to square with them.

For a company selling to businesses, the practical answer is that customers will ask.

Will enterprise customers ask about these controls?

They have reason to. When an agent is a feature of a B2B product, the customer is usually the controller of its users' data, and Article 28(1) lets it use only vendors "providing sufficient guarantees" of appropriate measures 3. Those guarantees are what a security questionnaire and the security annex of a data processing agreement ask a vendor to describe. Expect questions there about what the agent can access, whether it asks before acting, what it logs and how it is stopped.

The guide also tells the customer's staff to use only the assistants their organisation has authorised 1. So if a customer's review does not approve an agent feature, the regulator has told that customer's staff not to use it.

Training a vendor's own models on customer data is a separate question with its own rules, covered in Training a shared AI model on customer data needs each customer's written approval.

If you build an AI agent feature, what should you check?

If your product lets an AI agent act for your users, check it against the seven controls, starting with permissions, confirmation and the history. A missing control can hold up a customer's approval, and after an incident it is where a regulator would look.

• Permissions: let users grant read without write, and one folder or calendar without the rest.
• Confirmation: show the recipient, amount, date and attachment before the agent acts, and do not make "always allow" the easy choice.
• History: log what the agent accessed, sent and changed, where users can see and undo it.
• Stop: one control that halts running and scheduled tasks and revokes the agent's access.
• Memory: show what the agent remembers and let users delete it. The guide warns that deleting a chat, a memory and a connected app "do not have the same effect", so say which does what.
• Privacy policy: update it when a new tool or a training use changes recipients or purposes (tools count as recipients, as I explained in Your AI agent's tool list is the recipient list your privacy policy has to name). Lawcel, the compliance tool we build, can flag that kind of change on the pull request that introduces it.
• Rights: link access and erasure requests from the agent's own settings.