A ticket, a screenshot, a bug in the customer portal. You give a coding agent the task, it finds the cause and prepares a fix. This is precisely why you want these tools: a problem that might have sat in the backlog yesterday becomes something you can tackle today.
Except the screenshot also shows a customer's name. The attached log contains her email address. And the agent has just suggested taking a look at the database.
This is not an argument against AI agents. It is the point where choosing a tool becomes an architecture decision: what information does this task actually need, and where may it go?
The prompt is only the front door
With a chat, you tend to think about the text you enter. That view is too narrow for a coding agent. Depending on its setup, project files, images, terminal output and responses from connected services may join the conversation. What looks like “a little more context” to you can be part of somebody else's personal history.
The practical inventory therefore starts with the task, not the model version. For our customer portal bug, I would follow three stages:
- What goes in? A description of the failure, the affected functionality and synthetic examples. Does the agent really need the entire screenshot and support ticket?
- What gets pulled in along the way? Project files, test output and perhaps a connected service. Adding access does not automatically grant permission to process additional data.
- What remains afterwards? Changes, test reports, conversation history or stored tool output. Results can also contain information that does not belong in a public repository or shared report.
The German data protection authorities' guidance on AI and data protection likewise starts with the specific purpose and necessary processing. My translation for engineering teams: prepare a small, meaningful reproduction before handing over the entire incident.
Perhaps two fictional accounts reproduce the bug. The agent then receives the behavior it needs to understand without meeting the real customer. If that is insufficient, clarify the additional data requirement deliberately. Removing a name from a real record, by itself, is not reliable evidence of anonymization.
“It runs in Azure” is not the whole answer
In my platform projects, I use Azure OpenAI instances for some AI features. I also use coding agents during development. Those are two different processing chains. The configuration of an AI feature inside the product says nothing about where a separately configured development agent sends its requests.
Even within Azure, the details matter. Microsoft's processing-location documentation distinguishes Standard, Global and DataZone deployments. Global processing can take place outside the resource's selected region. Some features also store content or conversation state. “Our Azure account is European” therefore does not describe the complete data flow.
For tool selection, I would record the exact product, plan and configuration. Which other services connect to it? What is stored, used for what purpose and deleted when? Take those answers into the discussion with data protection and information security. A blanket vendor approval that hides these differences gives the team little guidance when the next plugin arrives.
The AI Act and GDPR are not the same thing
The EU AI Act considers factors including an organization's role, the system's use and its risks. Article 4 also makes AI literacy relevant to everyday team practice. The European Commission describes a context-specific approach: people's experience and actual usage matter; a particular certificate is not required.
Alongside that sit GDPR questions: the lawful basis, purpose and safeguards for processing personal data. Depending on the circumstances, processor arrangements, international transfers or a data protection impact assessment may also need attention. Attending a course does not automatically answer those questions.
I would turn this into neither a legal exam for every developer nor a mandatory video everyone watches over lunch. For our portal ticket, a better learning moment is someone demonstrating what the agent would receive, replacing unnecessary real data and explaining why database access stays disabled initially. The team learns something it can use on the next task.
A polite request is not an access restriction
“Do not change production data” is a sensible instruction. But if the agent also receives credentials with broad write permissions, the words and the technical setup disagree. A prompt is not a door lock, even with three exclamation marks.
For the customer portal, I would keep the first pass in a separate test environment. The agent gets approved project files and test data, can prepare a fix and run checks. Production credentials do not belong in that workspace. Publishing and additional system access remain outside this task.
Read-only access is not automatically harmless either. Reading can disclose information without changing a single database row. With an MCP connection, an interface through which agents use additional tools, I therefore care about more than whether it works. I want to know which data and actions it makes accessible.
Then I would test the boundary. Does the test environment actually work without production access? Are unapproved tools genuinely unreachable? Does a test report accidentally contain confidential information? A documented intention is useful. A verified protection is better.
The fix is ready. Is the working arrangement?
Back to the ticket: the agent has prepared a correction. We now check the intended behavior and relevant failure cases. Can the customer access her record again? Does another account's record remain invisible? Does an unauthorized request fail in a controlled way?
Automated tests can preserve these expectations. But they cannot declare processing lawful or reliably detect every unauthorized disclosure. Checking business behavior, restricting access and assessing data protection address different problems. Passing tests are valuable, not universal permission.
For ongoing operations, a collection of a thousand chat messages is not enough. A short, maintained record is more useful: the approved use, tools, data categories, access boundaries and owners. If a new provider or connection arrives, revisit the relevant part.
People also need a clear route when data does reach the wrong tool. Stop the affected use, revoke access where necessary and involve the responsible teams with the information they need. Do not hide it, copy it into more chats or rush to erase every trace. Assessment and response need to follow the organization's incident process.
Experience does not become obsolete. It becomes practical.
My background includes more than 15 years in software development and architecture, including projects in regulated banking and financial environments. Much of what mattered there still matters: ownership, permissions, traceable changes and operations that somebody understands. AI agents can shorten implementation. They do not remove these questions.
At Entwicklerherz, I now combine that experience with agent-assisted development and work on my own platforms, including Fachzirkel and SchemaCommunity. I am excited by how much we can actually build and improve. That is precisely why I do not want an unresolved data access question to undermine the whole effort.
A useful starting point is neither blanket permission nor a blanket ban. It is a clearly described use case the team can handle with suitable tools, limited data and verifiable approvals. I explore the collaboration behind it in “AI agents at work: How to lead your team”.
The important approval is not “We use AI.” It is “For this task, with this data and within these boundaries.”
Want to turn this into a way of working for your team? The Entwicklerherz workshop “Using AI agents safely: Data protection and the EU AI Act in practice” helps you map data flows, define access and approval rules and prepare an initial pilot plan. One day, delivered in German, live online or in-house; dates and pricing on request. Ask about the data protection and AI Act workshop.
As of September 10, 2026. This article presents a technical and organizational perspective. It does not replace case-specific legal assessment and is not a compliance certification.