AI Agents · Data Governance

    Where Does Your Data Actually Go When You Use Enterprise AI?

    Enterprise AI is sold as safe because it is called enterprise. But safety is a data path, not a badge. Here is the route one prompt actually travels, drawn stop by stop.

    September 2026 | 10 min read

    Security researchers demonstrated something in 2025 that should reframe how every enterprise thinks about AI risk. They sent an employee an email. The employee never opened it. The company's AI assistant read it anyway, followed instructions buried inside it, retrieved internal documents the sender had no business seeing, and passed them out of the building. Nobody clicked anything. No alert fired. The technique was named EchoLeak, disclosed by Aim Labs against Microsoft 365 Copilot and tracked as CVE-2025-32711. Microsoft patched it server-side in June 2025 and found no evidence it had been used in the wild, which is the point: this was a demonstration, run by researchers, of something the architecture permitted by design.

    What makes that story useful is not the exploit. It is what the exploit reveals: enterprise AI moves your data along a path most organisations have never actually drawn. Nothing in that attack broke. Every component did exactly what it had been built to do.

    Which is why the question that surfaces forty minutes into every AI meeting, usually from someone in legal (where does our data actually go?), is the right question asked far too late. What follows is the map that should have existed first: five stops, one boundary, and seven places a copy comes to rest.

    The five stops a prompt makes inside an enterprise AI systemStops one to three (the prompt, retrieval and tool calls) remain inside your perimeter. A trust boundary then marks where data leaves your control: stop four, the model call, and stop five, the exhaust of logs, retention and sub-processors.THE ROUTE ONE QUESTION ACTUALLY TAKESfive stops, and the single line separating what you govern from what you negotiateInside your perimeterLeaves your control01The promptyour question, the system prompt, the whole history, the attachmentsINSIDE YOUR WALLS02Retrievalyour documents, re-encoded and copied into a second indexINSIDE YOUR WALLS03Tool callsthe agent reads and writes live systems, and pulls records back inINSIDE YOUR WALLSTRUST BOUNDARY · DATA LEAVES HERE04The model calleverything assembled crosses to the provider, in some region, under some contractLEAVES YOUR WALLS05The exhausttraces, abuse logs, retention windows, warehouses, sub-processorsLEAVES YOUR WALLSeerly.ai · the boundary is a contract, not a firewall
    Figure 1. The first three stops are engineering decisions you control outright. The last two are contractual positions you negotiate and re-verify, which is exactly where most governance programmes quietly stop looking.

    The Data Has Already Left the Building

    Before anyone architects anything, employees have been running their own pipeline for two years.
    39.7%
    of AI interactions in enterprise traffic involve sensitive data (Cyberhaven, 2026)
    48%
    of employees have put company information into free public AI tools (Univ. of Melbourne & KPMG, 2025)
    57%
    hide their use of AI at work, and present AI-generated work as their own

    The instinct this provokes (block everything, approve one tool, declare victory) misses the signal. People route around IT because the sanctioned path does not reach the systems they work in. The durable fix is a governed path that is better than the ungoverned one, and you cannot build that without knowing precisely where a governed prompt goes. Shadow AI is what an unmanaged adoption curve looks like from the security side, which is why AI adoption is a people problem before it is a technology one.

    The first place your data goes is rarely your AI vendor. It's a personal account your security team cannot see.

    Eerly AI Studio

    Stop One: The Prompt Is Bigger Than the Question

    What travels is a dossier, not a sentence.

    Users picture a question travelling to a model. What travels is an assembled payload, and two of its properties are consistently underrated by the teams shipping these systems.

    What the user pictures sending versus what actually crosses the wireThe user pictures sending only their question, roughly four percent of the payload. What actually transmits is the system prompt, the full conversation history, retrieved chunks, tool schemas, attachments and the question, and the history is resent on every turn.THE PAYLOAD IS NOT THE QUESTIONindicative proportions of a single request to a model APIWHAT THE USER PICTURES SENDING… and nothing elseWHAT ACTUALLY CROSSES THE WIRE, ON EVERY SINGLE CALLSystem prompt: your rules, in fullConversation history, replayedRetrieved document chunksTool schemas & definitionsAttachments & metadataThe question the user typedModel APIs are stateless, so the whole history is resent each turn: a detail disclosed at turn 3 is re-transmitted at turns 4 through 40.eerly.ai · exposure is not an event, it is a rate
    Figure 2. The question the user typed is the smallest thing in the payload. Everything to the left of it was assembled on their behalf, and travels with it on every call.

    Exposure is not a single event but one repeated for the life of the thread. Model APIs are stateless, so the whole history is resent on every turn: a detail disclosed at turn 3 is re-transmitted at turns 4 through 40. And the system prompt, authored like configuration, reviewed like configuration, yet reading like an internal policy manual, leaves the building on every call. Classify it accordingly.

    Stop Two: Retrieval Makes a Second Copy

    The index is a copy of your documents, not a redaction of them.

    To answer from your own knowledge, a system splits your documents into chunks, converts each into an embedding (a long list of numbers) and stores those vectors in a searchable index. Two comfortable beliefs about that step are wrong, and the diagram shows precisely where each one breaks.

    What happens to a document on its way into the vector indexA document is chunked, embedded and indexed. Its access control list does not survive the chunking step, and the resulting embeddings are reversible back into the original text.WHAT SURVIVES THE TRIP INTO THE INDEXthe text survives, in reversible form; the permissions do not survive at allYour documentACL: FINANCE ONLYChunkssplit into passagesEmbeddings[0.02, -0.71, 0.33 …]Vector indexsearchable by similarityPERMISSIONS STOP HEREThe index has no idea who was allowed to read the source.THE VECTORS ARE REVERSIBLE92% of 32-token inputs recovered exactly (Vec2Text, 2023).Therefore: a vector index inherits the classification of the documents that produced it:same encryption, same access control, same retention, same deletion duty.eerly.ai · an embedding is a copy, not a hash
    Figure 3. Two things cross into the index that most teams assume do not: the text, in recoverable form, and none of the permissions.

    Treating a vector store as a low-sensitivity derived artefact because "it's just numbers" is the most common data-classification error in enterprise AI today. Song & Raghunathan (CCS 2020) recovered 50–70% of input words from sentence embeddings; Vec2Text (EMNLP 2023) recovered 92% of 32-token inputs exactly in-domain, and reconstructed full names from clinical notes. Calibrate that figure honestly: against a production embedding model on out-of-domain text the same method scored 60.9% exact at 32 tokens and 8.0% at 128, so inversion degrades with length and domain shift. It does not disappear, and ALGEN (ACL 2025) has since cut the data an attacker needs to roughly a thousand samples.

    The permissions failure is not theoretical, and EchoLeak was not an isolated case. Researchers at UT Austin's SPARK Lab documented ConfusedPilot, a class of confused-deputy vulnerabilities in RAG assistants in which poisoned documents corrupt responses and content can surface even after access to it is revoked. A Microsoft Research position paper goes further, demonstrating exfiltration against fine-tuning and RAG architectures and arguing that prompt sanitisation, output filtering and isolation are all probabilistic, and that only deterministic, participant-aware ACL enforcement across the pipeline actually holds. And the entitlements those controls would have to enforce are largely unmapped: Microsoft's State of Cloud Permissions Risks found over 70% of identities had used none of their granted permissions in the preceding 90 days. Retrieval does not create an oversharing problem so much as finally exercise the one that was always there. The file share nobody has reviewed since 2019 was safe mainly because it was unsearchable. It is the same neglected corpus behind the enterprise knowledge problem, now suddenly queryable.

    An embedding is a copy of your document, not a redaction of it.

    Eerly AI Studio

    Stop Three: Tool Calls Widen the Reach

    An agent's effective access is the union of its tools, not the permissions of its user.

    The moment a system stops answering and starts acting, the path widens. Tool calls send arguments outward into live systems (ticketing, CRM, ERP, mail, file storage) and pull records back inward. Whatever returns is appended to the context and transmitted to the model on the next call. Action is not a separate data-flow concern from retrieval; action feeds retrieval. (For what these agents actually do once they are wired into a system of record, see our guide to AI agent types and what they do inside SAP.)

    So the governing question changes shape. It is not "what is this user allowed to see?" but "what can every credential this agent holds see in combination, and what happens when one prompt persuades it to combine them?" An agent wired into five systems through five service accounts carries a reach no individual employee possesses, one that appears on no org chart and in no access review.

    One user's permissions versus an agent's effective reachA single user can see one system's records. An agent wired to five service accounts has an effective reach equal to the union of all five, far larger than any individual employee's access.THE REACH NOBODY PUT ON THE ORG CHARTask not what the user may see, but what every credential the agent holds may see, combinedFIVE SERVICE ACCOUNTScrmerpmailticketingfile_storageTHE AGENT'S EFFECTIVE REACHWhat one usercan seeControls: per-resource credentials · read-only by default · one identity per agent · a bounded blast radius per run.eerly.ai · the union is the attack surface
    Figure 4. The difference between the small circle and the large one is the gap every access review misses, because the review looks at people while the reach belongs to a service account nobody thinks of as staff.

    Stop Four: Crossing the Trust Boundary

    Everything assembled crosses a line here. All three variables are configurable, which is exactly why all three get assumed.

    At this point the prompt, the retrieved chunks and the tool output are concatenated and sent to a model. If that model is hosted by a third party, this is the moment your data leaves infrastructure you control and enters infrastructure you merely have a contract about. Three variables decide what that means.

    The three configurable variables at the trust boundaryRetention, training and geography each have an assumption most teams make, and a specific position that should be pinned and evidenced instead.THREE VARIABLES, THREE ASSUMPTIONSwhat teams assume, and what the contract should actually sayRetentionTHE ASSUMPTION“Zero retention meansnothing is kept.”PIN THISAbuse logs up to 30 days;ZDR has named exceptions.TrainingTHE ASSUMPTION“They said they don'ttrain on our data.”PIN THISOff by default on our exacttier, provable in audit.GeographyTHE ASSUMPTION“Region is a latencysetting.”PIN THISNon-EEA = a transfer underGDPR Articles 44–49.eerly.ai · EU AI Act Annex III high-risk duties now apply from 2 Dec 2027 · breaches to €15m or 3% of turnover
    Figure 5. All three are settings, not properties. A setting nobody pinned is a setting somebody else chose on your behalf.

    Read the retention row carefully, because it is the one that catches people. Providers retain more than most teams expect, for defensible reasons: OpenAI generates abuse-monitoring logs for API usage and retains them for up to 30 days, longer where law requires, and even under a zero-data-retention arrangement limited metadata may persist to satisfy legal and safety obligations. "Zero" is a contractual configuration with named exceptions, not an absolute. On training, the operative word is never whether but default. And on geography: under GDPR every call sending personal data outside the EEA is a cross-border transfer, and a prompt containing a customer's name is personal data however incidental it felt to type.

    Retention posture is also a moving target. In August 2026 OpenAI previewed a zero-retention safety system while Anthropic moved toward requiring retained logs for its newest models. An assessment signed off in 2025 may not describe the model you are calling today, so treat retention like a pinned dependency version, not a policy you read once. The regulatory dates move too: Regulation (EU) 2026/1744, in force 27 July 2026, deferred the Annex III high-risk obligations to 2 December 2027 (Annex I to 2 August 2028), while leaving the Article 50 transparency duties on their original August 2026 timeline.

    "We don't train on your data" is a contract setting, not a law of physics. Ask what the default is.

    Eerly AI Studio

    Stop Five: The Exhaust Nobody Budgets For

    The largest copy of your prompts is usually the one you built yourself.

    Tracing can capture prompts, retrieved context, tool arguments and completions verbatim. That makes it simultaneously the most powerful debugging capability in the field and its most significant compliance liability, because a trace stores precisely the payload the rest of the architecture was protecting. The standard itself is careful about this: OpenTelemetry's GenAI semantic conventions deliberately keep message content out of the default attribute set and make capture opt-in behind an explicit flag, precisely because prompt bodies routinely contain names, account numbers and proprietary logic. Which means the exposure at this stop is usually not something a vendor did to you. It is a flag somebody turned on in staging to chase a bug and never turned off. And logs propagate: to the tracing vendor, to dashboards, into the warehouse, out through alert emails. Each hop is a new copy, in a new system, with a new access list, under a retention rule nobody mapped back to the source document's classification.

    Count them honestly and a single question turns out to leave copies in seven distinct places. Only three of those sit inside the perimeter you designed.

    One prompt, seven resting placesA single question produces copies that come to rest in seven distinct systems: the context window, the vector index, audit logs of each system touched, the provider's abuse-monitoring log, your trace store, the analytics warehouse, and dashboards or alert emails.ONE PROMPT, SEVEN RESTING PLACESevery copy is a separate system, with a separate access list, under a separate retention rule1The context windowin flight, rebuilt and resent every turn2The vector indexa second, invertible copy of your documents3Audit logs of every system touchedone entry per tool call, across many owners4The provider's abuse-monitoring loga retention window you negotiate, not set5Your own trace storefull prompts and outputs, verbatim6The analytics warehousetraces piped downstream for reporting7Dashboards and alert emailsexcerpts of real prompts, in the inbox of whoever was on call that nighteerly.ai · four of the seven are created after the answer was returned
    Figure 6. A deletion request against the source document reaches, at best, the first two of these.

    Then there are sub-processors, the vendors behind your vendor. A credible data-protection agreement carries standard contractual clauses covering every one of them, flows residency down the chain rather than stopping at the first hop, and addresses compelled-access regimes such as the US CLOUD Act and FISA 702 with notice, contest and termination triggers. A vendor who cannot produce a current sub-processor list is not telling you they have none. They are telling you they have not looked.

    Most teams encrypt the model call, then log everything it said into a system nobody classified.

    Eerly AI Studio

    Five Questions, and the Weak Answers

    Vendor security pages are written to survive scrutiny, not to invite it.

    Each of the questions below has a reassuring non-answer that sounds like a strong one. Hearing the weak version tells you more than any certification badge on the trust page.

    Five questions to ask any enterprise AI vendorFive questions on region, training defaults, retention, sub-processors and logging, each paired with the weak answer to listen for.FIVE QUESTIONS, AND THE WEAK ANSWER TO LISTEN FORevery one has a reassuring non-answer, and that non-answer is the finding1Where does the model actually run, and in which region?Weak answer: “in the cloud”, with no region named and no way to pin one.2Is training on our data off by default on our exact tier?Weak answer: “you can opt out”, which means it is on right now.3What is the retention window, and what survives zero retention?Weak answer: “for a limited period”, with no number and no list of exceptions.4Who are your sub-processors, and does residency flow down to them?Weak answer: a list that stops at the first hop, or “that’s commercially confidential”.5What do your logs capture, and who inside your company can read them?Weak answer: full prompts retained indefinitely, access scoped to “engineering”.
    Figure 7. Ask these of your vendors, then ask them of your own platform, because on at least two of the five, most internal teams answer no better than the vendors they are auditing.

    The controls that answer those questions are not exotic. They are simply the ones that get skipped, because each sits on a boundary between two teams and therefore belongs, organisationally, to nobody.

    Which control belongs at which stopEach of the five stops has a specific control: minimise before the call, permission-aware retrieval, per-resource tool credentials, a pinned model call, and governed telemetry.ONE CONTROL PER STOPthe whole programme, on one page01The promptMinimise before the call: redact or tokenise on the way in, and classify the system prompt as the document it is.02RetrievalFilter against live entitlements at query time, not an ingestion-time snapshot. Classify the index as you classify the source.03Tool callsPer-resource credentials, read-only by default, one identity per agent, and a bounded blast radius per run.04The model callPin the region, the retention terms and training-off against a specific model version, then re-verify on every upgrade.05The exhaustScrub at the collector, keep traces briefly, scope who may read them, and maintain a reviewed sub-processor register.eerly.ai · five stops, five owners, one document
    Figure 8. If you can name an owner for each of these five rows, you have a programme. If you cannot, you have a diagram.
    Operational takeaway
    Make the data path a reviewable artefact
    Not a slide. A maintained document naming, for each of the five stops, the systems involved, the classification of the data at that point, the retention applied and the contract governing it. If no single document answers "where does our data go" end to end, the honest answer is not "it's secure". It is "we don't know", a finding worth surfacing before a regulator surfaces it for you.

    Sovereignty Is an Architecture, Not a Checkbox

    The industry is moving from asking where data sits to asking who controls the stack that touches it.

    The most useful shift of the past year has been from data residency, which country the bytes sit in, to technical sovereignty: who controls the stack that processes them, and under whose jurisdiction that control sits. It is a better frame because it survives contact with reality. Data can rest inside the EEA and still be reachable under a foreign compelled-access regime. A region setting is a necessary answer, not a complete one.

    None of this argues against enterprise AI. It argues against accepting the word "enterprise" as though it settled anything. Enterprise is not a promise somebody made you. It is a set of controls somebody configured, in a contract somebody signed, over a path somebody drew. When nobody can produce the drawing, the controls are usually partial and the contract is usually older than the model in production. The organisations that avoid that are the ones already treating human-AI collaboration as something to design rather than something to announce.

    Which returns us to that email nobody opened. EchoLeak did not succeed because the technology failed. It succeeded because every component behaved exactly as designed, along a path no one had drawn end to end. The path is finite: five stops, one boundary, seven resting places. It can be documented in an afternoon and verified in a fortnight, and once it is written down it stops being something an organisation takes on faith and becomes something it can actually govern.

    You cannot govern a data path you have never drawn. Draw it once, and most of the hard questions answer themselves.

    Eerly AI Studio

    At Eerly, this is the premise the platform is built on: agents that act across enterprise systems within the permissions teams already have, policy-level control over what an agent is allowed to reach, and execution traceable end to end, so that "where did that data go?" is a query, not an investigation. The path exists whether or not anyone maps it. Mapping it is the whole job.

    Eerly AI Studio

    See the whole data path, on one screen.

    Eerly AI Studio runs agents across your enterprise systems within the permissions your teams already have, with policy-level control over what an agent is allowed to reach and execution traced end to end. Walk the five stops with us against your own stack, and we will show you where each copy comes to rest.

    Book a Demo →

    Sources & Further Reading

    Tejas Sinroja
    Written by
    Tejas Sinroja
    Senior AI Engineer, Eerly AI

    Tejas builds the platform layer beneath Eerly's agents: the isolation, permission and data-path engineering that decides whether an enterprise AI system is something a company can actually put its records through.