This is the fifth and final article in the five-part Agentic AI Governance series. Part 4 covered the control plane for what an agent does; this piece covers what happens to the data it touches.
Key Takeaways
- The smallest unit of data governance is changing: from a file stored in a particular place, to a single context assembly performed by an AI agent.
- Traditional controls assume that data has a fixed storage location. However, the data and knowledge that an agent assembles in real time did not previously exist in any system, carries no classification label, and was approved in advance by no one.
- The three governance principles are identity, purpose and lineage: who assembled the data, for what reason, and from which sources.
- Most AI data traffic no longer travels only through the human-machine conversation. It also travels through three machine-to-machine channels: tool calls, connectors and memory.
- Judged by the supervisory requirements of the EU AI Act, what matters is not what you blocked, but what you can prove. Accountability requires evidence, and that evidence must be retained in full.
1. A Combination of Data That Nobody Approved
It is Monday morning. A user activates an AI agent and gives it a single instruction: prepare for next week's renewal meeting with a particular customer.
The instruction is one sentence, but what the agent does next is not one action. Within ninety seconds it reads the contract terms and payment history held in the customer relationship management (CRM) system, works through six months of the account manager's email, checks three open tickets in the service desk, retrieves the receivables ageing from the finance system, and locates last year's service level report on a shared drive. It then produces a two-page briefing.
The briefing is useful, and it follows the instruction exactly. The difficulty lies in the new combination of data behind it. Who owns that combination? For how long should it be retained? Who approved the decision that complaint records may sit in the same document as financial ageing data? And if the customer exercises the right to erasure tomorrow, where would you begin?
No one can answer these questions, because no one made these decisions. What deserves particular attention is that nothing in the process went wrong. This is not a security incident. This is the system working as designed — and that is precisely the problem.
Figure 1 — A combination of data that nobody approved.
2. Traditional Data Governance Governs Data at Rest
The scenario above is difficult to govern for a reason that lies not in the technology, but in the framework we continue to apply. For twenty years, data governance has rested on a single assumption: data has a fixed storage location.
That assumption supports almost every control we have. We classify data in order to label what sits in a given location. We apply access control in order to decide who may reach that location. We deploy data loss prevention (DLP) in order to intercept files leaving that location. The first question that each of these controls asks is the same: where is the data?
Before examining why the assumption is beginning to fail, one point should be clarified. In 2023, the greatest corporate fear about generative AI was that a model would absorb company data into its training. By 2026 this is no longer the central concern, because the contractual terms of mainstream enterprise offerings now generally exclude the use of customer data for model training. That path has largely been closed by contract.
The real risk has therefore moved. It no longer sits in the model weights; it sits in the movement, retention and access of data. In Opinion 28/2024, the European Data Protection Board (EDPB) held that an AI model trained on personal data cannot automatically be regarded as anonymous, that anonymity must be assessed case by case, and that the threshold is high. That opinion, however, concerns the model itself. What an enterprise security team faces every day is the data circulating around the model, which is rarely part of any inventory.
Figure 2 — Traditional data governance governs data at rest.
3. The New Smallest Unit: the Context Assembly Event
If data no longer has a fixed storage location, data governance needs a different smallest unit.
The former unit was the file. The unit that now matters is the context assembly event: the moment at which an agent draws data from several sources and assembles it into a single working context in order to complete a task.
This shift matters because what context assembly produces has three properties that the older framework cannot handle.
First, it is temporary. The assembled set of data disperses once the task ends. It resides in no database, and conventional asset inventories therefore cannot capture it.
Second, it is derived. It is not any one source document, but a recombination of several, so the classification labels attached to the source documents do not travel with it. More troublesome still, sensitivity can rise through recombination. A complaint record on its own is not sensitive. A receivables ageing report on its own is not sensitive. Placed together, they constitute a creditworthiness judgement about a named customer.
Third, it is autonomous. Which data to retrieve is decided by the agent during execution, and not fixed in a process at design time. In other words, the decision is usually taken when no person is present.
Taken together, these three properties leave the old governance principles of location and classification without purchase. They should be replaced by three new governance principles: identity (who assembled the data), purpose (why it was assembled) and lineage (which sources it came from). Where those three questions can be answered, governance holds. Where they cannot, even the most complete policy document remains a paper exercise.
Figure 3. The smallest unit of governance is shifting from the file to the context assembly event.
4. Three Invisible Channels
Applying those three principles requires visibility of how data moves. The next question is therefore a practical one: if you were to examine AI data flows in your organisation today, where would you look?
For most organisations the answer is the conversation log: what an employee typed, and what the model replied.
That answer was correct in 2023. In 2026 it covers only a small part of the picture, because under an agentic architecture data travels mainly through three other channels that no person observes.
- Tool calls. The agent decides autonomously which function to call and which parameters to pass. Those parameters may contain personal data that the agent read from elsewhere seconds earlier.
- Connectors. The agent reads from and writes to external systems through connectors: email, ticketing, CRM and cloud storage. Traffic on this channel may substantially exceed direct conversation with the model, and it flows in both directions. The OWASP Top 10 for Agentic Applications, published by the OWASP GenAI Security Project, places Tool Misuse (ASI02) and Identity & Privilege Abuse (ASI03) among the three highest risks for agentic applications, and this is the layer they describe.
- Memory. Content that an agent retains in order to remain coherent across tasks. Once personal data has been written into long-term memory or a vector index, executing the right to erasure becomes an engineering problem rather than a procedural one.
Figure 4. Tool calls, connectors and memory are the three channels no person reviews.
These three channels share one characteristic: no person reviews them at any point. A control that inspects only prompts and responses is equivalent to fitting a lock to the front door while three doors at the back remain open.
5. Assembly Must Be Attributable
Once movement is visible, the next question is to whom these actions belong. This is the first of the three governance principles: identity — and increasingly, non-human identity, since most of these actions are now taken by agents rather than people. A policy can only take effect if the platform knows who is acting, and that condition is now breaking down.
The reason is that agents act under delegated authority. Each one requires credentials, and the number of non-human identities (NHIs) in use has therefore begun to exceed the number of human ones. In its 2026 survey of identity threats and defences, which drew on more than 500 security professionals worldwide, the SANS Institute found that 76% of organisations report growth in NHIs and that 74% already use AI agents or automations that require credentials. It also found that 92% do not rotate machine credentials on a ninety-day cycle, usually because they fear that rotation would break a service account already in operation.
Volume, however, is not the most serious issue. Attribution is. A joint survey published in February 2026 by the Cloud Security Alliance and Strata Identity found that only 18% of respondents have high confidence that their existing identity systems can handle agent identities effectively, and that only 23% of organisations have an enterprise-wide strategy for agent identity management. Okta's 2026 global CISO research found that fewer than half of respondents could state with confidence where their agents are, what those agents can access, and which actions they are authorised to take.
This is no longer only a security matter. Article 5(2) GDPR requires a controller to be able to demonstrate compliance with the principles relating to processing. Where an organisation cannot distinguish an access performed by a person from one performed by an agent, the chain of accountability breaks at its most basic link.
Figure 5 — Assembly must be attributable.
6. Three Structural Tensions, and the Regulatory Clock
Identity is only the first of the three governance principles. Placing purpose and lineage alongside it, within the European regulatory context, reveals three tensions between agents and the EU data protection framework that will not resolve on their own.
Purpose limitation against context engineering. Article 5(1)(b) GDPR requires personal data to be used only for the purposes specified at collection. An agent, in order to perform its task well, will combine into a single context data that was collected under different purposes and different legal bases. Contact details collected on the basis of marketing consent and payment records collected as necessary for the performance of a contract have no boundary between them inside a context window.
Data minimisation against retrieval augmentation. Article 5(1)(c) requires processing to be limited to what is necessary. The engineering instinct behind retrieval-augmented generation (RAG) points in the opposite direction: more context is generally better than less. The two run against each other, and at present there is no clean technical resolution.
The right to erasure against broken lineage. Article 17 gives a data subject the right to obtain erasure. But if you cannot reconstruct which sources a particular output drew on, you cannot confirm whether personal data remains in the derived material.
None of these three tensions becomes smaller because a regulatory deadline moves. The regulatory clock itself only adjusted timing, not obligations — the Digital Omnibus pushed the high-risk deadlines out while transparency duties held (see Part 1 and Part 3 for the full timeline).
Figure 6. The Digital Omnibus moved the timing of the EU AI Act's high-risk obligations, not their substance.
A postponement is not a pause. The high-risk obligations moved back by sixteen months; the transparency obligations already apply, and inventory work does not get easier because more time is on the clock.
Reform on the GDPR side, including the discussion of a clearer legitimate interest basis for the development and training of AI, is proceeding on a different timetable and is considerably more contested. The European Data Protection Board and the European Data Protection Supervisor set out objections to parts of it in a joint opinion in February 2026. That track remains in progress and is not yet settled.
7. From Blocking to Proving
Read together, the preceding sections point to one conclusion. What European regulation actually requires is not a record of what you blocked, but evidence of what you can prove. The accountability principle in the GDPR and the record-keeping obligation in Article 12 of the AI Act point to the same thing: you must be able to produce evidence.
What, then, does a control plane capable of governing context assembly events require? At minimum, six control points: identity and privilege scope resolved on entry; available resources constrained during assembly; real-time inspection on egress; model selection made traceable during orchestration; returned content inspected on ingress; and evidence retained throughout.
Together, these six control points are what turn a log into an AI audit trail — something you can hand to an assessor, not just something you can search.
This is the design reasoning behind AnyInsight. The platform provides more than 20 large language models, more than 350 built-in agents and more than 500 enterprise system connectors, so that employees can genuinely use it. At the same time, a zero-trust generative AI firewall sits between users, workflows and models, inspecting both egress and ingress in real time.
Three design decisions deserve particular mention, because they address the problems set out in the three preceding sections.
- Connector Log. Every operation that an agent performs against an external system through a connector is recorded in full, and the policy engine enforces inspection at this layer. This addresses the channel described in section 4, which carries the greatest volume and receives the least attention.
- Data Vault. All interactions are retained in full, whether or not they breached a policy. The choice appears redundant but is decisive: the credibility of an audit depends on the completeness of the evidence, and a log that preserves only violations cannot be used to demonstrate compliance.
- Walled workspace. A three-tier identity structure of organisation, workspace and user, with resources assigned per workspace and roles scoped to least privilege by default. This answers the attribution problem set out in section 5.
The platform is deployed across multiple regions, and data belonging to EU customers can remain within the European Union. It holds ISO/IEC 27001 certification, and adoption of ISO/IEC 42001, the management system standard for artificial intelligence, is planned for the first half of 2027.
Figure 7 — From blocking to proving: three design decisions.
8. Three Questions for a CISO
You do not need a forty-page assessment to measure the maturity of your governance. Three questions are enough.
First: can you list every AI agent operating in your organisation, together with its privilege scope and its named owner? If the answer is “roughly”, the answer is no.
Second: take any AI output at random. Can you reconstruct which data sources it used? If you cannot, lineage is broken, and a data subject's request for access under Article 15 cannot be answered.
Third: does your connector traffic receive the same inspection and retention as your conversation traffic? If it does not, you are guarding the front door only.
These three questions correspond to identity, to lineage, and to the channel that this article identified at the outset as the easiest to overlook.
Figure 8 — Three questions for a CISO.
9. Conclusion
When generative AI first appeared, the data governance question was whether employees would paste confidential material into a chat box. That question has not gone away, but it is no longer the largest one.
When AI begins to fetch data on its own, the object of governance shifts from human behaviour to machine judgement. This calls for a different smallest unit, different governance principles, and an architecture that leaves evidence behind at every assembly event. Productivity and control need not be traded against each other, but they must be designed as one system.
To find out how this architecture can be applied in your environment, visit anyinsight.ai
Figure 9 — Productivity and control need not be traded against each other.
The Agentic AI Governance Series, Start to Finish
You've reached the end of the series. Here is the whole arc in five lines:
Part 1 — Zero Trust for AI: The 5-Checkpoint Framework for AI Agents
The takeaway: identity, scope, a real gate on actions, and a complete record — Zero Trust applied to what agents actually do.
Part 2 — From Shadow AI to Shadow Agents: The Gap in Your AI Policy
The takeaway: shadow AI is a confidentiality problem; shadow agents are an integrity problem, and your edge controls cannot see them.
Part 3 — Security for Agentic AI
The takeaway: the numbers, OWASP's Top 10 for Agentic Applications, and a 90-day plan to close the gap.
Part 4 — Filtering Prompts Is Not Governing AI
Part 5 — When AI Starts Fetching Its Own Data ← You are here
The takeaway: prompt-level filtering covers one moment out of many — an AI control plane has to cover the rest.
The takeaway (this article): governance moves from the file to the context assembly event — identity, purpose and lineage, not just storage location.
