2 Feb 2026

Neil Jennings

I’ve read a lot of posts about Moltbot recently. What an amazing bit of software. Genius, really. And I want to state this categorically - Moltbot is totally fine.

Yes. Totally. Fine.

Of course, it comes with a but, and it’s a pretty big one: Moltbot is not what you need to pay attention to when you’re using Moltbot, it’s what you build with it.

The real problem

Open source software (OSS) is meant to allow developers to build, create, and chase their curiosity. The real issue with OSS lies in the fact that security ≠ privacy. Developers and engineers typically have tremendous insights into protecting information and systems from bad actors and overreach, which is a key component of both cyber security and privacy compliance. While it is necessary for privacy compliance, security alone is not sufficient.

OSS does not, by itself, determine purposes or means of processing. It is simply a conduit. Of course, the code can embed logic about how data is handled, and this is why responsibility lies squarely with the controller that deploys it.

Pipes vs plumbing

It has taken me some time to get to grips with OSS and GDPR compliance. From the privacy lawyer’s point of view, not having a definitive counter party to act as data processor is unsatisfactory. It’s messy and it doesn’t really sit well in our GDPR, e-Privacy and digital regulatory framework. If you’re a dev, it’s not your fault, it’s ours!

OSS isn’t a ‘tool’ in the GDPR sense, it’s more of a blueprint for a system. And that is a critical distinction. OSS like Moltbot is equivalent to pipes, it’s a conduit through which information flows. But OSS is not the ultimate initiator or recipient. GDPR cares about the system (i.e. the entire plumbing structure), not the code (the pipes).

The unsatisfactory issue lies in the fact that GDPR assumes you buy software, but OSS assumes you will build your own.

What’s actually happening with OSS?

When you use OSS to automate clearing your inbox, or update and manage your calendar, broadly speaking, there are several steps that happen:

1. You download the code - nothing has happened yet
2. Add a Gmail token - now the system can read emails
3. Add an OpenAI key - now the system can interpret those emails
4. Grant broad permissions - now the system can act on your behalf
5. The loop starts running - now this happens automatically
6. Emails are sent to external AI service to decide what to do with them
7. Actions are taken without you touching anything

At this point, you aren’t working with one, single processor. You have connected the pipes and now have an entire plumbing (processing) system.

So how does this connect with GDPR?

Well, as with almost anything related to GDPR, the first question to ask is: is personal data being processed? And to this question, there are three possible answers:

• No personal data (no GDPR)
• Personal data (accountability depends on the plumbing system, i.e. the processing chain)
• Uncertain if personal data is involved (This relates to the nuance in the recent SRB case, and the Digital Omnibus updates, where the definition of ‘personal data’ is questioned)

In reality, and without getting into the nuances of pseudonymisation, for OSS to be effective, there must almost certainly be some element of personal data involved. When you use OSS like Moltbot to clear your inbox automatically, it’s very likely that personal data is involved.

Now, it is entirely fair to think that using OSS feels just like using a SaaS vendor, or some sort of software system on licence. But it isn’t the same for the fundamental reason of pipes vs plumbing. With a traditional SaaS vendor, you have an actual entity, that receives and processes personal data, that can enter into a service contract, a Data Protection Agreement, and Standard Contractual Clauses if they are overseas.

In SaaS, accountability has somewhere to attach.

But, open source agentic automation is not a system. It’s pipework. It connects the controller to one or many processors. So there is no single vendor, processor, or accountability anchor. Instead, there can be several processors in the chain (model providers, email platforms, cloud services, etc.) but none that present themselves as the obvious ‘vendor’ in the way a SaaS provider does.

And that is why it isn’t clear under the GDPR processor framework. It’s also why some companies have GDPR compliance gaps that nobody ever knew about - because developers and tech teams use various resources like OSS and API calls, and those aren’t ever thought about as GDPR issues in the same way a SaaS vendor is reviewed, their privacy policy assessed, and a DPA entered into.

OSS is legally invisible when it comes to GDPR.

When does GDPR start to strain?

Back to the main point. OSS is not a problem in and of itself. GDPR is not a problem in and of itself. But when a complex and diffuse system can be built that connects via OSS to a potentially large number of processors, and when there is personal data in play, we arrive at a terminal cliche. Just because you can doesn’t mean you should.

Once the system is running, a number of GDPR requirements that normally feel procedural become difficult to satisfy in practice:

• Data minimisation becomes hard to evidence, because the agent must read broadly to decide what is relevant.
• Purpose limitation becomes blurred, because the system is designed to act on context rather than fixed instructions.
• Privacy by design becomes difficult to demonstrate, because the architecture was assembled from code, APIs and permissions rather than engineered as a coherent product.
• And where personal data is sent to external AI services, processor and transfer obligations arise without any obvious counterparty to anchor them to.

Because the AI decision making does not sit within the OSS - it sits in the external model APIs that the OSS calls - and because the automation is being done by a system that might not have been specifically coded by the user, it raises concerns about accountability and explainability - decisions about personal data are being made by a system whose behaviour you did not explicitly code and cannot easily predict. That is a controller with a lack of control.

What GDPR really demands

That is a lot of trapdoors. Why is this particularly complex? Because we’re talking about many different processors connected via a single OSS tool. So GDPR compliance needs to be mapped to each processor. The pipes are just the means of transport, nothing else.

In a typical setup where OSS is used as processing logic and connects with various downstream processors, data could be flowing through:

• Email providers like Gmail or Microsoft
• An external AI model provider like OpenAI or Anthropic
• A hosting environment like a cloud server, VPS, or local machine with backups
• Local files or databases used for the agent’s persistent memory
• Logging, monitoring, or debugging tools

Assuming there is personal data, each of these is (in GDPR terms) a separate processing entity that may require its own governance, contractual, transfer and transparency considerations.

Persistent memory: the data you didn’t know you created

One aspect of agentic open-source tools that is easy to miss is something often called “persistent memory”. This doesn’t necessarily mean the AI remembers things or has its own separate memory or server. It means the AI tool ‘writes’ down a note and reads them later. Typically, this is through local files, logs, notes or small databases stored on the machine running the code. So the overall system may store:

• Summaries of emails it has read
• Notes about people and conversations
• Records of decisions it has taken
• Contextual information extracted from messages and calendars

While the data has never really left the home system, and it’s not necessarily stored by OpenAI or an external provider (although it might be, so be careful!), you have effectively created an archive of personal data that you might not have realised. In other words, the AI system can create a new, automatically-generated dataset about the data in question.

From a GDPR perspective, this is significant. These records may not be reflected in your retention policies, your Record of Processing Activities, your security controls, or your data maps. This is an internal governance and visibility problem. It isn’t that you added a new vendor, which would be dealt with by a data processing agreement and other clear governance tools. What has happened is you have expanded your data processing footprint without really knowing it.

Transparency: can you actually explain this?

This is one of the most important issues. And it’s one that regulators are very particular about. If you aren’t able to properly explain the system, then you don’t properly understand it, and you can’t properly govern it. It’s that simple. The issue here is not a technical or legal competence one, but a communication gap.

The transparency obligation, like proportionality, underpins a lot of GDPR’s intention, and it can become complex. Articles 12 - 14 require controllers to explain, in clear and accessible language, what happens to personal data, who receives it, and for what purposes. In traditional SaaS, you name the vendor, describe the service, and explain the purpose. But when a system is assembled from open source code, API keys, model providers, email platforms, local memory files, and automation loops, the processing chain becomes significantly more difficult to describe in a way that is both accurate and understandable.

If you had to update your privacy notice to explain this system to a data subject, could you make the update clearly? Could you describe where data goes, how decisions are made, and what records are created along the way? If you would need pages of technical documentation that nobody would understand, then the answer is no. And where processing architecture is too complex to be understood by data subjects, then it’s incredibly difficult to defend under GDPR.

A note on the pseudonymisation paradox

Until very recently, even pseudonymous data was considered personal data. In reality, that meant that, even if the recipient could not reasonably identify a specific individual, if it was possible in theory to identify a specific individual, that data was personal data, and GDPR applied to it. But in 2025, the CJEU in the SRB case rejected that notion (that theoretical identification is sufficient) and said that data is not personal just because someone, somewhere may be able to identify a specific person under ideal circumstances. This was reflected in the recently-published proposed updates to the EU’s digital regulatory environment (the ‘Digital Omnibus’). Note, this is still an evolving area of law, but illustrates how difficult it is to rely on pseudonymous data to limit GDPR exposure.

The paradox here is that, if the data is pseudonymised so as to no longer be personal data, then it’s unlikely the OSS tool can actually do its job. Or, from the other side, if the tool works as it should, then it’s probably personal data, so don’t get your hopes up!

The Data Protection Impact Assessment

Another piece of the GDPR puzzle is the DPIA. It’s required when a new technology is being used and there is a high risk that it could reasonably impact the rights and freedoms of individuals. Given the complexities of the agentic automation system built with OSS like Moltbot, it’s pretty likely the result would be: yes, you need to do a DPIA.

This is exactly the type of situation DPIAs were designed for. Not to justify a decision, but to test whether a decision is defensible at all. A DPIA on a system like this may very reasonably conclude that the risks cannot be mitigated without fundamentally changing how the tool is used. And that is not a failure of the DPIA. That is the DPIA working exactly as intended.

Given the fact that personal data is involved, and there is a potentially highly complex and diffuse system of processors and automation, the critical hurdle to get over is being able to explain the data reality end-to-end. If you don’t put accountability before capability, and you don’t treat each processors in the chain as separate when using OSS, there is a big governance gap that needs to be addressed.

So we’re OK to use Moltbot, yes?

One developer in a recent study of OSS contributors remarked that GDPR’s requirements feel “essentially incompatible with big data, artificial intelligence, blockchain, and machine learning.” Whether or not that is legally correct, it captures something important: modern software architectures are being built in ways that make GDPR’s governance assumptions difficult to realise in practice.

OSS is doing what it’s meant to - publishing code, inspiring experimentation, and avoiding legal overhead by being legally inert. GDPR is also doing what it’s meant to - demanding accountability, appropriate governance, and traceability.

When working with OSS, things like privacy by design, data minimisation, purpose limitation, and third party processor obligations can and will be missed by non-legal / privacy team members. It’s not their job to know this.

As I said at the start, Moltbot is not the problem. OSS is not the problem. The problem is thinking that the whole processing chain is a single item because it’s linked by one, single OSS. 

So yes, Moltbot (and OSS generally) is totally fine, as long as the governance work has been done properly. And that governance layer sits with the user. In the end, the problem does not lie with the tool, or with GDPR. It lies with the invisible system that has no real governance or oversight and operates in ways the controller did not explicitly design or tightly control.

This content is informational only and not legal advice. GLF is not a law firm regulated by the SRA.