The AI Data Leak You Miss Is the Agent Acting on Someone's Behalf
An employee pastes a confidential contract into a public AI app. Everyone knows that scenario by now. The harder question is what happens when an AI agent, acting with the employee's permissions, uploads the same file while completing a legitimate task. The destination and the data are identical. The actor in the audit trail is not.
That distinction is moving from theory into product controls. In its September 24 security update, Microsoft said its Purview and Entra Global Secure Access integration is generally available for network-layer data protection across human activity and on-behalf-of agent traffic. Its example is specific: an employee or agent attempts to upload a sensitive document to an unsanctioned AI tool, and a policy stops the transfer before it leaves. Read Microsoft's announcement.
This is not proof that every agent workflow is now safe. It is evidence that the boundary enterprise security teams need to govern is changing. An approved identity can initiate an unapproved data movement, and an agent can make that movement look like routine delegated work.
The identity is legitimate. The transfer may not be.
Consider a procurement agent asked to summarise supplier proposals. It has access to a shared drive because its human sponsor does. During the workflow, it selects a third-party AI service to extract tables from a proposal. The file contains negotiated rates and supplier bank details. The agent is not malicious, and the person who initiated the task had a valid reason to see the document. Neither fact authorises that external upload.
A traditional access review might ask whether the sponsor could open the drive. Yes. An endpoint policy might ask whether the browser or agent process is approved. Perhaps. The useful control question is narrower: may this specific document, at this point in the workflow, go to this destination for this purpose?
That is why network-layer controls are useful but should not be mistaken for the whole answer. They can provide a valuable last checkpoint for traffic they can see and classify. They cannot, by themselves, establish whether an agent's plan was appropriate, whether an API-to-API action escaped their visibility, or whether the service will retain or reuse the data. The security design needs both a boundary control and a decision record.
A practical test for an on-behalf-of agent
Before expanding an agent pilot, run a deliberately awkward transfer test. Give the agent a plausible business request, a permitted source document, et a tempting but unsanctioned destination. Then check five things:
- **Attribution:** Can you identify the human request, agent identity, tool invocation, document et destination as one connected event? A service account name alone is not enough.
- **Classification:** Was the document classified before the attempted upload, et did the policy account for its actual sensitivity rather than its file extension?
- **Decision point:** Was the risky transfer prevented before disclosure, or did someone merely receive an alert after the fact?
- **Exception path:** If the destination is necessary, can an accountable owner approve a narrow exception with a scope et expiry?
- **Recovery:** Can the team revoke the agent's permission, stop the workflow et preserve an intelligible record without disabling all employee AI use?
If one of those answers is unclear, that is a pilot finding, not a reason to declare the agent unsafe forever. Map the gap to an owner and retest. A useful policy is one that changes an observable outcome, not one that simply says agents must be used responsibly.
Do not confuse 'approved agent' with 'approved action'
Security teams often start with an agent inventory. That is necessary, especially when employees install local tools or connect new assistants to work applications without a central review. But an inventory says what exists, not what each agent is allowed to do with a particular piece of information. Our earlier article on AI agent execution policy makes the same distinction at the action layer.
For data movement, build a small matrix around three dimensions: source sensitivity, destination trust and action type. A public document sent to an approved summariser is not the same event as client records sent to a consumer model. Reading a contract for an internal summary is not the same action as sending its full contents to an external endpoint. Make those distinctions enforceable in the tools and routes agents actually use.
It is also worth testing the awkward edges. Does the policy apply when the agent uses a browser rather than a sanctioned API? Does it recognise content copied into a prompt rather than attached as a file? What about a local agent on a managed laptop that calls an external service directly? A control that covers one transfer path is valuable, but coverage must be measured rather than assumed.
The adjacent problem is human Shadow AI. If staff still have no safe way to get work done, they will route around a blanket block, with or without an agent. Aona's AI data loss prevention guideexplains why discovery et context matter alongside enforcement. Find the destinations, classify the flows, give teams approved alternatives, et reserve the strongest friction for genuinely sensitive transfers.
Put the evidence where the decision happened
An incident reviewer should be able to reconstruct a chain, not sift through unrelated logs: who requested the work, which agent ran, what it accessed, which tool it called, what it tried to send, which policy applied and what happened next. If the destination changed midway through a task, that change should be visible. If an exception was granted, the approver and expiry should be visible too.
Microsoft's September announcement is a useful signal because it explicitly includes on-behalf-of agent traffic in a data-protection boundary. It is a vendor description of a capability, not an independent guarantee of coverage in your environment. Test the exact agent routes you operate, including the unmanaged and unsanctioned ones. Keep the distinction between a documented feature and a verified control outcome.
The board-level question is not 'Have we approved AI agents?' It is 'Can we see and stop the wrong data transfer even when the agent has a legitimate job and a legitimate identity?' If that answer depends on knowing the employee first, start with Aona's governance templatesto define ownership et evidence. If you want to map the AI tools et data flows already in use before writing another policy,book a conversation with Aona.
