“But what about data protection?” – Agentic Work as an Information-Flow Problem

As soon as AI comes up, sooner or later someone says:

“But what about data protection?”

The objection is not wrong. Anyone connecting AI systems or coding agents to company information, personal data, or security-sensitive systems should think very carefully about what information is being processed. But that sentence alone is not yet a risk analysis.

AI
↓
"Data protection!"

is technically about as informative as:

Internet
↓
"Security!"

Both point to a real problem space. Neither answers a concrete question.

The discussion only becomes useful once we look at the actual information flow:

Information
↓
Source
↓
Authorization
↓
Agent / Tool
↓
Context
↓
Processing
↓
Output / Artifact / Memory

What information flows where? Why is it needed there? Who is allowed to see it? Which systems process it? Which trust boundary does it cross? What additional artifacts are created from it? And what would happen if that information became visible somewhere it was not supposed to be visible?

That is where the discussion changes. Agentic Work is not only a data-protection problem. It is an information-flow and trust-boundary problem. Data protection is an important dimension of that problem, but it is only one dimension.

This connects directly to the previous article in this series. That article treated architecture as a constraint: architecture limits which structural solutions an agent is allowed to produce in the first place. Information protection extends that idea. Architecture answers what may be connected to what. Information protection adds who may see what, what may flow where, and what may be derived from it.

Architecture therefore constrains the structural solution space. A trust boundary constrains the permitted context and action space.

A Sensitive Domain Does Not Automatically Mean a Sensitive Development Context

I have worked in technical leadership for roughly 15 years and spent a substantial part of that time in domains such as healthcare and the public sector. Both domains contain information whose need for strong protection is beyond dispute. Even so, I have never had to develop against real, highly sensitive production data during that time.

That is explicitly a personal experience, not a general claim about how software development must be organized. There are systems, companies, and roles in which developers do work with production-like or production data. Even so, this experience highlights an important point for me:

The existence of highly sensitive data in a system does not automatically mean that this data is part of the normal development or agent context.

That distinction disappears surprisingly quickly in many AI discussions. A medical system processes health data. It does not follow that a developer or coding agent must therefore see real health data. Development and production environments can be separated; development processes can work with synthetic test data, anonymized data, pseudonymized data, or dedicated test datasets. Access rights can be structured so that a developer can understand and change large parts of a system without ever seeing the actual production data.

The German Data Protection Conference also recommends checking, when developing AI systems, whether the relevant purpose can be achieved using synthetic or anonymized data. Pseudonymized data must not be confused with anonymous data: if a person can still be reassociated using additional information, the data remains personal data in principle. Truly anonymized information, by contrast, no longer falls under the GDPR. [DSK – Technical and organizational measures for AI systems]

The technical question should therefore not be whether the overall system contains sensitive data. It should be:

Which of that data does this particular development process or agent actually need?

That may sound like a small shift. In reality, it changes the whole problem, because we are no longer talking abstractly about a sensitive domain. We are talking about a concrete data flow.

Data Protection Is Only One Dimension of Information Protection

The term data protection itself is often used more broadly in technical discussions than is useful.

The GDPR protects personal data. That means information relating to an identified or identifiable natural person. This can include obvious information such as names or email addresses, but depending on the context also identifiers, online identifiers, customer numbers, logs, or IP addresses. [GDPR, Art. 4 – EUR-Lex]

Additional requirements apply to certain kinds of information. Article 9 GDPR includes, among other things, health data, genetic data, certain biometric data, political opinions, religious or philosophical beliefs, trade-union membership, and information concerning a person’s sex life or sexual orientation. [GDPR, Art. 9 – EUR-Lex]

But there is also a large class of information with no personal-data dimension at all that may still require very strong protection: source code, architecture, unreleased products, algorithms, research results, internal strategies, contracts, pricing, or proprietary processes. Some of this may even qualify as a trade secret under certain conditions. German trade-secret law looks, among other things, at whether the information is not generally known or readily accessible, has commercial value, and is subject to reasonable secrecy measures. That does not mean every piece of non-public source code automatically qualifies as a trade secret. It does show very clearly that economically valuable information can deserve protection even without any personal-data dimension. [§ 2 GeschGehG]

Then there is information for which neither data protection nor classic trade-secret protection is the primary question: API keys, tokens, private keys, cloud configurations, internal network structures, security architectures, vulnerability information, or other credentials. Here too, asking whether personal data is involved would obviously be insufficient.

Data protection is only one dimension of information protection.

That matters especially for Agentic Work because coding agents often work with information that is entirely unremarkable from a privacy-law perspective and at the same time extremely valuable to a company. An agent does not need to see a single customer name to gain access to the core of a company’s intellectual property.

Two Axes Instead of a Single Label

For technical discussions, I therefore use a simple model. It is not an official GDPR taxonomy and not a legal classification scheme. It is an engineering abstraction that helps me avoid mixing two different questions.

The first axis looks roughly at the personal-data dimension and the associated special legal protection:

no personal data
↓
personal data
↓
special categories of personal data

The second axis instead looks at the potential damage caused by disclosure:

public
↓
internal
↓
confidential
↓
business-critical
↓
existential / dangerous to individuals

The two axes do not necessarily correlate. A business email address can be personal data while still having a comparatively low protection requirement. An unreleased algorithm can contain no personal data at all and still be economically critical. Of course, information can also rank high on both axes.

Two deliberately extreme examples make this difference particularly visible.

On one side, imagine information about a politically persecuted person in the context of an asylum procedure. Political opinions alone already fall under the special categories of personal data in Article 9 GDPR. Depending on the content of the case, additional highly sensitive information may be involved. Unauthorized disclosure here would not merely be an abstract compliance issue. It could have real consequences for a person.

On the other side, imagine a company developing a new technical process. No customer data, no names, no email addresses, no user identifiers, no personal data at all. But the process is the result of years of research and perhaps the company’s main future competitive advantage. Disclosure could be economically catastrophic.

Not personal does not automatically mean uncritical.

For a technical risk analysis, a single label such as personal data: yes / no is therefore not enough. We also have to ask what would happen if that information crossed the wrong trust boundary. That is where data protection becomes part of a broader information-flow question.

The Data Flow Matters More Than the Marketing Label

This distinction also helps with some statements around AI products that can sound reassuring very quickly. One of them is:

Our data is not used for training.

That can be an important property of an offering. It answers exactly one question, however. It does not automatically mean that there is no processing, transfer, storage, logging, retention, involvement of additional service providers, support access, or processing outside a particular region.

The GDPR uses the term processing much more broadly. It includes, among other things, collection, recording, storage, retrieval, consultation, use, disclosure by transmission, making available, combination, and erasure of personal data. Training is therefore only one possible processing step or purpose within a much larger technical process. [GDPR, Art. 4 – EUR-Lex]

The German Data Protection Conference likewise distinguishes, for example, between using input and output data for training and storing an input history. A system can exclude training and still store data. [DSK – Artificial intelligence and data protection]

That is why:

No training is not the same as no processing.

That does not mean that a commercial or externally operated AI system is automatically problematic. It only means that No Training is not a complete description of the data flow. Contractual arrangements, a DPA or equivalent processing agreement, retention, region, subprocessors, technical configuration, and the actual information flow all have to fit together.

The reverse shortcut does not work either. Even if a particular processing operation involving personal data were lawful under data-protection law, it would not automatically follow that the same information may be put into a prompt. A confidentiality agreement may prohibit disclosure, an internal security policy may impose additional limits, the information may constitute a trade secret, or contractual or regulatory restrictions may apply. A user may be authorized to access information inside an internal system without being authorized to transmit it to an external service. And there may be no personal-data dimension at all while the transfer is still completely unacceptable for IP-protection reasons.

A processing operation that is lawful under data-protection law is not automatically organizationally or security-wise permissible.

I am a software architect, not a lawyer. Whether a concrete processing operation is permissible depends on the actual processing context and may require a privacy or legal assessment. But architecture starts earlier: before someone can assess whether a data flow is legally permissible, it should first be technically clear which data flow actually exists.

Agents Expand the Information Surface

With a classic chat, the visible interaction is initially fairly limited: I write a prompt, the system processes it, and I receive an answer. A coding agent can have a completely different radius of action.

Depending on the system, configuration, and task, it may have access to parts of an environment such as:

Repository
Documentation
Tickets
Shell
File System
Environment Variables
Database
Logs
CI/CD
Cloud APIs
Secrets
Browser
External Search

Not every agent has all of these capabilities. That is precisely why the broad question “Is a coding agent secure?” is too vague. An agent with read-only access to a single repository is a fundamentally different security case from an agent that can run shell commands, modify files, call external services, read secrets, and trigger deployments.

With every additional tool, not only its action space but also its information space grows. The German Federal Office for Information Security, for example, points out in the context of application-integrated language models that additional integrations can provide access to documents, websites, programming environments, or other systems and thereby create new attack vectors such as indirect prompt injection. [BSI – Indirect Prompt Injections]

As agency increases, the information and attack surface grows.

That makes a very old security principle central to Agentic Work: Least Privilege.

The question should not be what an agent might conceivably find useful someday, but what it needs for this exact task:

Task
↓
required capabilities
↓
required information
↓
minimum permissions

An agent editing text in a frontend application normally does not need the production database, cloud-admin privileges, secrets, or access to every repository in the company. An analysis of a complex migration may require substantially more context. That is not a contradiction. Least Privilege does not mean as little access as possible. It means as much as necessary and as little as possible.

One of the most important rules in this entire topic follows from that:

Relevant does not automatically mean permissible.

An agent may find a piece of information technically useful. That alone is not a sufficient reason to make that information available to it.

Authorization Belongs Before Retrieval

The distinction becomes especially visible in RAG systems. A very simple mental model of RAG might look like this:

Company knowledge
↓
Retrieval
↓
LLM

Because that knowledge is not trained into the model itself, the setup can initially appear more controllable. It can be. But the authorization questions do not disappear.

The German Data Protection Conference explicitly points out in its RAG guidance that rights and role concepts remain relevant for reference documents and vector databases. It also describes that access control cannot simply be delegated to the language model and that the relevant roles should already be taken into account before the query. [DSK – Data-protection specifics of generative AI systems using RAG]

From an engineering perspective, that leads to a fairly clear sequence:

Identity
↓
Authorization
↓
Retrieval
↓
Context
↓
LLM

Not: retrieve everything, build the context, and only then decide whether the user was actually allowed to see the information.

RAG is not a privacy shield.

Retrieval changes the technical route through which information enters the context. It does not remove existing authorization boundaries. An agent must not receive information merely because it is technically discoverable.

“The Agent Wasn’t Supposed to Get There”

One of my most interesting experiences with coding agents involved exactly this assumption.

In an earlier audit of a large system that had grown over many years, certain particularly protected parts of the source code were explicitly excluded from the coding agent. The agent was not supposed to analyze those areas directly. Later, information about that area nevertheless appeared in audit documents generated by the agent.

Whether that information became visible through indirect dependencies, types, aliases, references from other modules, previously generated documentation, search, or an entirely different analysis path is something I can no longer say with confidence. That is precisely why I do not want to manufacture a cause after the fact.

The interesting point is different:

An area that was technically excluded was apparently still not completely invisible to the agent.

For me, that was a very concrete reminder that “the agent wasn’t supposed to get there” is not a meaningful security description. The word supposed to describes expected behavior. A trust boundary describes a technically enforced boundary.

“The agent wasn’t supposed to get there” is not a reliable trust boundary.

For information with a low protection requirement, a soft restriction may be perfectly adequate. The higher the protection requirement, the less I want to rely on it.

A File Boundary Is Not Automatically an Information Boundary

Assume a file is not readable by an agent:

protected-module.ts
✕ direct access

At that point we only know that the agent cannot read that file directly. We do not yet know that it cannot obtain any information about the protected area.

Information in a software system rarely stays neatly inside a single file. It spreads through contracts, types, dependencies, stack traces, logs, test reports, coverage, static-analysis findings, architecture documentation, tickets, PR descriptions, agent summaries, and other generated artifacts. An interface can reveal something about a protected area without containing its implementation. A stack trace can expose component relationships. A test report describes behavior. An architecture diagram documents dependencies. A ticket may explain why a particular internal mechanism exists. An earlier summary may carry forward information from a context that is no longer accessible later.

This explicitly does not mean that an agent could automatically reconstruct the original source code from such information. That would be a different and much stronger claim. The relevant mechanism is simpler:

Protected information can cross a trust boundary without the original file itself ever crossing that boundary.

Access control on a source file is therefore not yet complete information-flow control. That is not a special GDPR rule; it is an engineering inference. Agents make it particularly relevant because they can combine information from many sources and then create new artifacts from it.

We should therefore ask not only which files an agent may read, but also what information can become visible through allowed sources and what new artifacts can result from that information. Information flow does not end at the input.

At this point there is even a connection to one of my recurring architecture topics. A Big Ball of Mud does not automatically cause privacy violations. High coupling does, however, make understandable boundaries harder to maintain:

clear boundaries
↓
more understandable information paths

versus:

Big Ball of Mud
↓
implicit relationships
↓
less predictable information paths

Clean architecture is therefore not automatically a data-protection measure. But it makes ownership, isolation, dependency control, and therefore the technical enforcement of information boundaries easier.

High coupling makes trust boundaries harder to enforce and verify technically.

With High Protection Requirements, Less Is Often Stronger

A natural answer to particularly sensitive information is to run the model locally. That can be a useful building block. If certain information is not supposed to leave a defined trust boundary, a locally or on-premise operated model can make a substantial difference.

The relevant architecture, however, is not merely LLM local; it is the whole chain:

LLM local
+
Retrieval local
+
Logs local
+
Tools local
+
Memory local
+
no cloud fallbacks
+
no unwanted telemetry

A local model with external retrieval does not create a fully local trust boundary. Neither does a local agent whose tooling then sends information to external APIs. And an on-premise model with unknown external telemetry paths does not solve the problem merely because inference happens locally.

The German Data Protection Conference also notes in its RAG guidance that on-premise architectures can avoid transferring personal data to external model providers, while the overall architecture still has to be considered. [DSK – RAG guidance]

The complete data-flow model remains decisive.

It becomes even more interesting where the protection requirement is genuinely high. There, we should ask a different question first:

Why should this information cross this trust boundary at all?

Security engineering is not only about making risky data flows increasingly secure. Some risks can be handled more elegantly by making sure the data flow does not exist in the first place. Perhaps a synthetic dataset is sufficient. Perhaps an anonymized or reduced excerpt is enough. Perhaps a contract is sufficient. Perhaps a local service can encapsulate a sensitive operation and expose only a less sensitive result to the agent. Perhaps a manual boundary makes sense. And perhaps an agent is simply not the right solution for a particular use case.

With very high protection requirements, the right architecture may be to prevent a data flow from existing at all.

That fits a principle that predates LLMs by a long time: data minimization and privacy by design do not require collecting as much personal data as possible and then protecting it with maximum effort. They require limiting what is actually necessary for the purpose already at design time. [GDPR, Art. 5 and Art. 25 – EUR-Lex]

For Agentic Work, this is a productive way of thinking. The central question should not be what information we can somehow give an agent, but what information we can spare it for the task.

Data Protection Did Not Become Concrete Only Because of AI

This may be the part of the current AI debate that irritates me most.

Organizations have been processing information through external systems for decades: cloud services, SaaS, APIs, communication platforms, support systems, analytics, and external service providers. None of these systems was ever automatically harmless. Purpose, permissions, recipients, storage location, retention, contracts, technical measures, and protection requirements had to be considered for them as well, and still do.

AI changes some risk profiles substantially. Generative models combine information in new ways. RAG makes large knowledge bases semantically searchable. Agents receive tools and can take actions themselves. Prompt injection creates new attack possibilities. Memory and generated artifacts can carry information beyond a single interaction.

Those are real differences. But the underlying question—which information flows where—is not new. The GDPR is technology-neutral. Its principles do not depend on whether personal data is processed by classic SaaS software, an API, or a language model. [GDPR – EUR-Lex]

That is why I find both extremes unhelpful. It is neither true that everything suddenly becomes prohibited simply because AI is involved, nor that an enterprise offering automatically settles everything.

Data protection should not suddenly become absolute merely because the word AI appears. It should become concrete where real data flows and real risks exist.

That is not an argument for less data protection. Quite the opposite: it makes the discussion more precise. Instead of turning AI → data-protection problem into a blanket conclusion, we can ask questions that can actually be answered:

Does the agent need this information?
↓
Is the user allowed to access it?
↓
May the agent process it for this task?
↓
May it cross this trust boundary?
↓
Is access technically constrained?
↓
What artifacts can be created from it?
↓
Can those artifacts carry information further?
↓
How is this verified?

Not every one of these questions is exclusively a data-protection question. Some belong to security, others to architecture, governance, contract law, or compliance. That is precisely why the reflexive phrase “But what about data protection?” is so unhelpful: it mixes too many different problems under one label.

Data Protection as a Constraint

That brings us back to the previous article.

There, the goal was to reduce an agent’s structural solution space. Not every technically possible architecture should be acceptable. Just because an agent could connect a presentation layer directly to a database does not mean we should accept that solution.

Architecture sets constraints.

Information protection works in a similar way. Just because an agent can technically access a piece of information does not mean that information should be part of its context.

Architecture Constraints
↓
Which structural solutions are permissible?

is complemented by:

Information Constraints
↓
Which information and capabilities are permissible?

For me, that is a much more productive way to think about data protection in Agentic Work. Agents create real data-protection risks, real confidentiality risks, and real security risks. The greater their agency becomes, the greater those risks can become because more information and more actions become reachable.

But these risks are not mystical. They can be analyzed, modeled, and influenced through architecture. They can be limited through permissions, monitored, and verified. And some can be avoided entirely by refusing to allow a particular information flow in the first place.

Data protection is not a knockout criterion for Agentic Work. It is a constraint of the system.

That does not mean data protection is solved. It means we can make it concrete.

One rule remains particularly important:

Relevant does not automatically mean permissible.

The decisive question is not whether an agent can theoretically process information. The decisive question is which information we actually want to make available to it for this exact task.

If we can answer that question clearly, then “AI? But what about data protection?” has already become a much better discussion:

What information should be processed, who is allowed to see it, why does the agent need it, which trust boundary does it cross, what would the consequences of disclosure be, and how do we enforce that boundary technically?

That is not a trivialization of the problem. It is a concretization of it. And that is exactly where the demystification lies.

Requirements, architecture, and information boundaries have now reduced the permissible solution space substantially. It is still not deterministic. Even within well-defined constraints, agents can generate several functionally and technically valid solutions.

The next article therefore turns to the question of how we can use that variance deliberately rather than merely tolerate it:

Diverge · Decide · Converge.

Sources and Framing

GDPR – Regulation (EU) 2016/679, EUR-Lex
Primary legal source for personal data, special categories of personal data, processing, data minimization, privacy by design, security of processing, and other data-protection principles. It defines neither the two-axis model used in this article nor specific trust-boundary models for coding agents.
https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX%3A32016R0679

German Data Protection Conference – Artificial Intelligence and Data Protection, 2024
Regulatory guidance on the use of AI and the separation of different processing steps, including training and the storage of inputs. It is not a general approval or prohibition rule for specific AI products.
https://www.datenschutzkonferenz-online.de/media/oh/20240506_DSK_Orientierungshilfe_KI_und_Datenschutz.pdf

German Data Protection Conference – Technical and Organizational Measures for AI Systems, 2025
Regulatory guidance on data protection by design, data minimization, risk analysis, and possible technical and organizational measures across the lifecycle of AI systems.
https://www.datenschutzkonferenz-online.de/media/oh/DSK-OH_KI-Systeme.pdf

German Data Protection Conference – Data-Protection Specifics of Generative AI Systems Using RAG, 2025
Relevant to rights and role concepts, retrieval, reference documents, vector databases, and on-premise scenarios. The phrase “RAG is not a privacy shield” is a technical condensation used in this article, not a verbatim quotation from the DSK.
https://www.datenschutzkonferenz-online.de/media/oh/DSK_OH_RAG.pdf

BfDI – AI in Public Authorities: Think About Data Protection from the Start, 2025
Guidance for the German federal administration on the use of LLMs and data-protection questions. Its target group is the federal administration; it is not a general legal norm for all companies.
https://www.bfdi.bund.de/SharedDocs/Downloads/DE/DokumenteBfDI/Dokumente-allg/2025/Handreichung-KI.pdf

German Trade Secrets Act – § 2 GeschGehG
Defines trade secrets and their requirements. Personal data and trade secrets are different protection categories that can overlap. Not every piece of non-public source code automatically meets the requirements of a trade secret.
https://www.gesetze-im-internet.de/geschgehg/__2.html

BSI – Indirect Prompt Injections
Technical security guidance on risks associated with application-integrated language models and additional attack vectors created by external content and tool integrations. It is not a legal decision on data-protection permissibility.
https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2023/2023-249034-1032.html

Engineering Inferences in This Article
The two-axis model combining personal-data relevance with potential disclosure damage is not an official GDPR classification. The same applies to Identity → Authorization → Retrieval → Context → LLM, to applying Least Privilege to task-specific agent permissions, and to the statement “A file boundary is not automatically an information boundary.” These models are intended to translate abstract protection requirements into technical boundaries that can be discussed and verified.