Your AI automations work. But what can they reach?

In many companies, nobody can say how many automations currently have access to customer data. That is not a reproach. It is the mechanical consequence of tools that have become easy to build.

An automation does not simply process information. To do its job, it is granted access. A mailbox, a CRM, a file store, sometimes a database.

Those permissions do not disappear when the tool drops off the radar. They stay open, in the company's name. That is what deserves a look.

Your defense depends on what you know about your systems

ANSSI, France's national cybersecurity agency, handled 1,366 security incidents in 2025, according to its 2025 cyber threat overview published in March 2026. The previous year counted 1,361. The level is not going down.

What stands out in these reports is not the volume. It is the starting position. The attacker explores a system that nobody, on the other side, knows in full.

The chain matters as much as the perimeter. Alain Bouillé, who heads Cesin, the French association of information security leaders, estimates that two thirds of successful attacks come through a supplier. You are not only responsible for your own walls.

So the question is not only how to defend yourself. It is knowing what there is to defend, and where the way in is.

Every automation adds an access path, not just saved time

An automation that sorts your customer requests needs to read your mailbox. The one that creates the matching records needs to write into your CRM.

Those permissions take the form of tokens and API keys. They are credentials, in the same way a password is. They often live in a configuration file, sometimes in a personal account.

Nothing abnormal in that: it is how tools talk to each other. The point to hold is elsewhere. Every tool you add widens what a third party could reach, and the list grows faster than it gets reviewed.

We have covered elsewhere what an automation you no longer see costs you. There is a second side to it, quieter: what it opens.

An application can work perfectly well and stay open

In February 2026, researchers at Wiz published their analysis of Moltbook, an experimental social network for AI agents. The platform worked. Its database, however, was reachable.

The access key was visible in the browser, with no row-level control behind it. According to Wiz, the following were exposed:

• 1.5 million agent authentication tokens;
• around 35,000 email addresses;
• 4,060 private conversations, some containing, in clear text, keys granting access to other services.

Both reading and writing were possible. The researchers reported it, and the team fixed it within hours.

The founder publicly stated he had not written a line of the code himself. Concluding from this that AI produces insecure software would be moving too fast. The application did very well what it was asked to do. It was the front door that had not been closed.

Hand-written software shows exactly the same flaw when nobody reviews that part. What the speed of creation changes is the number of deployments per review.

A tool should hold only the rights its job requires

A tool that only needs to read information often gets, for convenience, the right to modify and delete it. Granting broadly is quicker than fine-tuning.

As long as everything works, nobody notices. The gap matters the day the tool gets it wrong, or the day its key circulates.

The subject becomes sensitive with agents, which chain several actions without intermediate validation. We described that shift in workflow or AI agent. An agent inherits every right it has been given, and uses them at machine speed.

The rule is easy to state, harder to hold. Every permission granted matches an action the tool actually has to perform. The rest gets removed. That is a one-hour review per tool, not a project.

Even with no code of your own, the platform still needs keeping

Many automations contain no in-house code at all. They live on a platform, often installed on your own servers.

In January 2026, the vendor n8n published a security advisory concerning self-hosted instances. In certain configurations, an unauthenticated visitor could read the file system. The fix existed, in a more recent version.

The vendor did its job: it found, published and fixed. Installing the update, however, belongs to whoever hosts.

On hosted platforms, responsibility shifts without disappearing. In May 2026, the security vendor Red Access published a survey. It reported around 380,000 publicly accessible applications, built with AI-assisted development tools. Close to 5,000 exposed sensitive information.

These figures come from a vendor and the platforms concerned dispute them, which calls for caution. Axios did verify several cases, however: a carrier's ship schedules, customer service conversations, clinical trial data.

Their public answer is the part worth reading. Privacy settings are the user's responsibility. That is correct, and it is precisely the point.

The GDPR is about processing, not about AI

One confusion comes up often. The GDPR does not apply because there is AI. It applies because there is personal data.

So the questions are the same as before. Which data, for what purpose, with which provider, for how long, with what safeguards.

What changes is the number of processing operations created without a formal decision. An automation built in two days can send customer data to an external service, without anyone having made the call.

The CNIL, France's data protection authority, points out that security is addressed from the development stage, not after go-live. Knowing where your data lives and who can reach it remains the baseline. It is also what leaves you free to change provider later.

What a tool can reach is a decision, and it can be reviewed

Let us come back to the opening question. It asked how many automations have access to your data. You can answer it another way, and faster.

Take the three that serve you best. For each one, write two columns. What it has access to. What it is allowed to do there, read only, or also write and delete.

In many cases, the gap between the two columns is closed in an afternoon. It is rarely a project, often a review.

A demo proves an idea works. It never proves it is closed. These are two separate checks, and the second almost never asks itself.

Author · M.Baudoux - Senior developer & founder of GDN