Data exfiltration is the unauthorized movement of data out of a trust boundary. Reading it without permission is a different event. Destroying it is a third. Systems that blur the three end up with controls that stop the wrong one.
Three things that get called the same word
Unauthorized access is someone reading what they should not. Confidentiality is violated; the data has not moved.
Exfiltration is data crossing the boundary outward. It needs two ingredients access does not — a channel, and something willing to put data into it.
Destruction is data damaged or removed. It costs integrity and availability, and it may involve no disclosure at all.
The distinction pays because the controls differ. Access control answers who may read. Exfiltration control answers what may leave. A system can enforce the first perfectly and still leak, because almost every leak that matters involves a party with entirely legitimate read access plus an outbound channel. The converse is true and underrated: an intrusion that reads everything but cannot send anything is contained.
Two things follow. Where the boundary sits is the whole definition, and somebody has to draw that line on purpose. And exfiltration is not a bandwidth event — the payloads that matter usually fit in a URL.
The channels that matter in an AI system
An outbound tool call
The direct one. Any tool whose arguments reach a party outside the boundary is an outbound channel, whether or not it is named send. Email, an HTTP request, a chat post, a write to shared storage. Search counts too — the query is data leaving, and a model can put anything into a query.
A rendered URL that fetches
Content that pulls a remote resource the instant it is displayed, with no click. The mechanism is zero-click exfiltration; what earns it a place here is that it needs no tool and no approval, only a renderer.
Content echoed into a reply
The agent is legitimately writing to an outside party and includes something that should have stayed inside. There is no exploit — the channel was approved, the payload was not. This is the most common case and the least likely to be logged as a security event, because it is indistinguishable from the work.
A summary that leaks what it summarized
The output is not a copy, and it still carries the information. The candidate's references were mixed discloses without quoting anyone. Stripping identifiers does not help when the inference survives, and an aggregate over a small population names people. There is no clean line here, because the value of a summary is exactly the information it preserved.
Why agents sharpen the problem
Conventional architectures separate reading from sending, often by accident: the service holding the database credential is not the service that talks to the internet.
An agent collapses that separation deliberately. The private conversation, the retrieved documents, earlier tool results and the outbound tool all sit in one context — and the thing choosing what goes into the outbound call is a model that may have just read a document written by a stranger. That is the confused deputy arrangement with a network connection attached.
Two aggravating factors. The judgment moves from per-message to per-field at machine speed: should this sentence go to this person used to be a decision a human made once, immediately before hitting send. And you cannot simply close the channel, because sending is the job.
Three classes of mitigation
Reduce what it can see. The cheapest, and the only one that caps the worst case no matter how the model is steered. Scope retrieval to the task. Do not load a mailbox to answer a question about one thread. Keep credentials out of any context that also ingests untrusted text. What is not in the context cannot leave in a tool call.
Reduce what it can send. Constrain the outbound surface instead of trusting the payload — recipients chosen by a human rather than by the model, structured fields rather than a free-text blob, no general-purpose HTTP client, markup neutralized so nothing auto-fetches. The honest limit is that a constrained channel is still a channel. A tool that can only answer yes or no emits a bit per call.
Make the outbound step require a human. The specific content, in final form, approved immediately before it goes — not a notification afterwards, and not a standing grant given when the integration was connected. This one has its own failure mode: gates decay into reflex when they fire constantly. Put them where reversal stops being possible, and nowhere else.
None is sufficient alone, which is the argument for a full agent safety checklist rather than a favourite.
One implementation
What RelayLink carries between assistants is a fixed set of composed fields — an ask, a short summary, a context brief, a handful of optional structured sections — rather than a transcript. The format has no file field and no attachment of any kind, so the first mitigation lands at the message boundary instead of on the model's discretion. The send is split across two calls, with the confirmation checked on the server rather than requested in a prompt, so no single model output completes a delivery.
Relayed content is neutralized before an assistant reads it: a markdown image becomes inert text that still shows the URL but can no longer fetch it, and a link is flattened to text plus a parenthesised address. The web page a recipient opens permits no scripts and no images at all, so nothing on it can beacon even if the encoding failed.
The concessions belong here too. Nothing is end-to-end encrypted — the relay composes the email and renders the web view, so it holds the plaintext. And there is no recall: once a package is delivered, no tool removes it. That is why the review sits before the send.
The question worth carrying into any tool you connect is not whether it has a security page, but which of the three classes it implements and where each is enforced. To see the third working on a real message, connect your assistant.