Sensitive-data flow mapping
Trace sensitive information through the whole agent workflow
Sensitive-data flow mapping becomes relevant when the organisation cannot explain which systems receive or retain information used by an agent. A focused review would examine a data item or category moving between source, context, model, tool, memory and logs. This is most relevant to privacy owners and data governance teams, especially where teams must distinguish intended architecture and observed flow.
Locate the privacy question inside the processing path
- System and connector inventory
- Establish the processing activity and the information boundary.
- Intended architecture
- Identify the condition requiring a separate technical check.
- Provider, logging and retention configurations
- Expose the downstream conditions that qualify the conclusion.
- A data-flow uncertainty and action register
- Route unresolved questions to the appropriate decision owner.
Decision at stake
Trace sensitive information through the whole agent workflow
Make the decision explicit
- Privacy owners and data governance teams
- The organisation cannot explain which systems receive or retain information used by an agent.
- Decision
- Where sensitive information travels and which unknown flows prevent a review or control decision.
- Intended architecture
- Use system and connector inventory to establish the relevant starting condition.
For privacy owners and data governance teams, the immediate question is where sensitive information travels and which unknown flows prevent a review or control decision. This is most useful when there is a real choice between proceeding, changing the design, collecting more evidence or narrowing the intended use. The starting conversation should identify that choice and its consequence before deciding how much work the topic warrants.
A diagram could stop at the model endpoint while missing information retained in observability, support or downstream tool systems. A useful review follows a data item or category moving between source, context, model, tool, memory and logs, rather than stopping at a convenient component metric or document boundary. The evidence should separate observation, interpretation and recommendation so the accountable owner can see what it supports.
Coverage
Intended architecture and observed flow need different evidence
Keep the review distinctions visible
- Intended architecture
- Check observed flow separately.
- Primary request
- Check telemetry copy separately.
- Raw record
- Check derived summary separately.
Intended architecture versus observed flow
The map would include prompts, model requests, tool arguments, generated outputs and diagnostic artefacts. The goal is to trace actual information movement rather than reproduce only the intended high-level architecture.
Primary request versus telemetry copy
Transformations would preserve lineage between source records and summaries, embeddings or memory items. This makes later questions about access, correction and deletion more concrete without copying raw sensitive content into the map.
Raw record versus derived summary
Each edge would carry an evidence status: observed, configured, documented or unknown. That distinction prevents a provider assertion or assumed telemetry route from appearing as independently verified deployment behaviour.
Illustrative scenario
Case summary to tracker: examine what changes the decision
Examine the constructed decision boundary
Illustrative scenario
- Case summary to tracker
Information passes through prompt, generated summary, task update and logs.
- Copy tracing
Identify raw fields and derived information on each scoped path.
- Evidence status
Mark unobserved flows as assertions or unknowns before changing controls.
A fictional agent summarizes service cases and updates a task tracker. The proposed mapping would trace the source fields, prompt content, generated summary, tracker update and diagnostic logs. Where direct observation is unavailable, the map would mark a documented assertion or unknown. The team could then target evidence requests and control changes at the actual exposure paths.
A diagnostic log might be the only recipient whose retention cannot be confirmed. The map would show that uncertainty and assign a targeted evidence request to the platform owner. The finding would concern an actual missing fact, without speculating that every unobserved provider path necessarily exposes the same information. These are hypothetical decision paths, not observed client outcomes.
Prerequisites
Start with system and connector inventory
Give each input a specific job
- System and connector inventory
- Defines the operating boundary.
- Representative sanitised traces
- Examine primary request.
- Provider, logging and retention configurations
- Shows conditions affecting raw record.
- Privacy and data owner
- Confirm access and a reviewer who can resolve gaps.
For Sensitive-data flow mapping, a named data owner should approve the evidence route and handling rules. The work needs clear purposes, relevant system boundaries and suitable specialist participation. Controlled or sanitised examples should be used where possible, with raw sensitive material retained only in approved systems and access limited to the agreed scope.
Useful starting material would include system and connector inventory; representative sanitised traces; provider, logging and retention configurations. These inputs have different jobs: the first establishes context, the second supplies behaviour or comparison material, and the third exposes operating conditions that may qualify a conclusion. Existing material would be reviewed before requesting new collection, and a missing input would be recorded as an evidence gap rather than treated as a favourable result.
How the work proceeds
Translate approved privacy requirements into observable checks
Follow the evidence through the work
- System and connector inventory
Map the approved processing purpose and scoped information path.
- Representative sanitised traces
Examine this material under the data owner’s handling rules.
- Primary request
Challenge this distinction using an authorised, bounded case.
- A data-flow uncertainty and action register
Separate technical findings from questions requiring qualified legal review.
Map the privacy question
Identify sensitive categories and the workflow’s relevant system boundary. The opening step turns the operating concern into a question that can be examined. It would identify a data item or category moving between source, context, model, tool, memory and logs, the outcome the owner cares about and the conditions that would make an observation decision-relevant. Scope changes would remain explicit if the evidence reveals a different problem.
Define observable criteria
Trace collection, transformation, transmission and retained copies. The comparison material would include representative sanitised traces, with provider, logging and retention configurations available to explain the operating conditions. Differences between intended architecture and observed flow would remain visible beside the observation rather than disappear into a pooled result.
Examine the relevant paths
Reconcile diagrams with configuration and representative execution evidence. The review question would explicitly distinguish primary request from telemetry copy. A material discrepancy would be traced back to system and connector inventory and the relevant execution or decision record, so a proposed change addresses the observed cause rather than the most convenient explanation.
Review findings and limits
Assign owners to unknown flows and privacy-control decisions. The resulting data-flow uncertainty and action register would explain the distinction between raw record and derived summary and identify what further observation would change the recommendation. The privacy and product owner would retain the decision, including whether a narrower scope or a different approach is preferable.
Indicative artefacts
Use a data-flow uncertainty and action register to make the next action explicit
Every artefact needs an operating use
Illustrative working format
- An evidence-linked sensitive-data flow map
- Boundary — system and connector inventory.
- A recipient and retained-copy inventory
- Findings about primary request.
- A data-flow uncertainty and action register
- Action on raw record.
The final artefact set depends on the agreed decision. Useful outputs can include:
- An evidence-linked sensitive-data flow map. The working foundation for the question, including relevant definitions, boundaries and assumptions so another reviewer can understand what was examined.
- A recipient and retained-copy inventory. The substantive observations and interpretation, preserving adverse results, disagreement and limitations that affect how the evidence may be used.
- A data-flow uncertainty and action register. The connection to action: what the owner could do next, what evidence is still missing and what change would justify revisiting the conclusion.
Scope and authority
Technical findings need separate legal and processing decisions
Keep analytical work separate from decision authority
- Approved processing paths and technical checks
- Can include an evidence-linked sensitive-data flow map.
- Privacy and data owner
- Qualified legal and privacy owners interpret requirements and approve processing.
- Legal determinations or guaranteed privacy
- Cannot be inferred from a recipient and retained-copy inventory.
This is a proposed technical and operational privacy scope. It does not determine lawful processing, approve transfers, certify compliance or guarantee that information cannot be disclosed. Qualified privacy, legal and security review would be arranged where the actual processing or test methods require it. To discuss sensitive-data flow mapping, the first practical step is to identify the relevant owner and bring a sanitised description of the decision, the current alternative and the material uncertainty. That gives scoping a concrete starting point without implying a preapproved package or favourable conclusion.
Ways to engage
Related engagement scopes
AI Agent Component Evaluation
Find where agent behaviour breaks down. Follow memory, retrieval and delegation through your workflow, then isolate the components that need attention.
AI Agent Memory Assurance
Examine what your agent remembers, when it retrieves it and whose information it can expose—in the deployment where it actually works.
AI Privacy Engineering Review
Trace personal data through your agent workflow. Examine collection, memory, retrieval, tool access and retention against your agreed requirements.
Continue exploring
Related insights and resources
Protecting agent data and memory
An agent's information footprint extends beyond the conversation. Map the copies, derived records and retrieval paths that influence future actions, then connect each to purpose, access, retention and verifiable handling.
Your agent passed the test. What does that prove?
A release decision needs a traceable connection between expected behaviour, test conditions and observed results. Here is a practical way to build that connection.
AI agents in legal operations: assistance without invented authority
Legal agents can organize evidence and prepare work, but professional judgement, client authority and verified legal positions cannot be delegated by interface.