The Data-Sharing Problem for Third-Party AI Agents

This is a deep dive into the problem addressed by Agentic Data Enclaves: how to share data safely with your partners’ agents. The starting point is your need to share data without surrendering sovereignty.

Access control decides what an agent may access. Data sovereignty requires control over everything that happens next.

The governed yes creates business value

Safe third-party agent access can increase revenue. It lets you start data-dependent partnerships sooner, run them on live information, and permit valuable work that a competitor must delay, narrow, or refuse.

It can also lower cost. You do less repeated preparation, redaction, reconciliation, and maintenance of partner-specific copies and interfaces. Depending on the relationship, this means a shorter deal cycle, better supply and service coordination, lower integration cost, or a data-enabled business that was previously too risky to permit.

This is not merely compliance or loss avoidance. Data sovereignty becomes productive capacity.

You need to share data and remain sovereign over it

Enterprises share data because their business relationships require it. A supplier needs current demand and inventory data. An adviser needs records for diligence. An auditor needs evidence. A regulator needs access to the facts behind a filing. A trading partner needs operational changes as they happen. These are legitimate uses and preventing them carries a real economic cost.

Agents make this work faster and more continuous, but they also expose a limit in the controls built for people and applications. An authorized agent can inspect a corpus, combine records, infer facts that no single record states, send material to a model or another third party, preserve the result in working state, and produce artifacts for its principal. Every read in that sequence may be permitted while the final disclosure is not.

So you must satisfy two requirements at once:

1. permit a third party to use the data needed for legitimate work, and
2. remain sovereign over the data throughout that work.

This applies to a bounded visit and to a live relationship in which data, authority, and policy continue to change.

Legitimate agent access looks like exfil

To controls built before agents, legitimate access and illicit exfil can look the same: software reads sensitive data at machine speed, combines it, sends context to tools and models, and keeps the result.

Old controls can tell a known partner from an intruder. They cannot determine from the activity alone whether an agent is forming an authorized answer or compiling an unapproved body of knowledge. Identity can establish who asked. It cannot make the resulting information flows safe.

The difference has to come from what the enterprise can enforce over the work, the agent’s memory, and what leaves.

The request is legitimate

The easy security problem is the intruder who has no right to enter. The harder commercial problem is the partner who has a valid reason to enter but does not have an unlimited right to know.

Today that partner wants to arrive with its own agent, model preferences, tools, and operating methods. Its request may be properly authenticated, supported by a contract, and delegated by an identified employee. None of this makes the partner hostile. It also does not give the partner custody of your whole data corpus or authority to decide what may be learned from it.

The distinction matters because controls designed only to reject illegitimate requests force the enterprise into a false choice. It can refuse the work, in which case the partnership loses the speed and reach of agentic computation, or it can grant ordinary access and rely on the counterparty’s systems, retention practices, and later compliance.

You need a third answer: permit the work under the data owner’s continuing authority.

Access control ends at the read

Authentication establishes an identity. Authorization associates that identity with permitted actions and resources. Least privilege narrows those permissions. These are necessary controls, but their usual object is the access event itself.

Once a permitted read has returned something to an authorized process controlled by the consumer, ordinary access control has done its work. It does not govern the process memory into which the value was copied, the inferences drawn from it, the summary written later, the prompt sent to another model, or the dataset created by joining it with other permitted reads.

This is the difference between access control and information-flow control: permission to observe a value does not settle where information derived from that value may subsequently flow.

This can happen even when every component behaves as configured. A partner can receive ten individually authorized facts and derive an eleventh fact that the owner would not have released. A text filter can find a source value while missing a paraphrase or an aggregation. A row-level policy can govern the rows returned while saying nothing about a model trained or updated from them. The problem is not necessarily a violation at entry. The problem is the lack of continuing control after entry.

Your partner needs context, not a data dump

Enterprise knowledge is divided among operational systems, documents, prior decisions, local vocabularies, exceptions, and people. A third-party agent that receives an extract may have the records and still lack their meaning. The data owner must then assemble, reconcile, redact, and explain the material before useful work can begin.

This work delays the relationship and recurs whenever the source data changes. Each bespoke package creates another copy to secure, another version to reconcile, and another partial account of what the enterprise knows. Internal silos remain in place, while the cost of crossing them is paid again for every partner.

Your partner needs one governed view of the records, documents, and institutional memory required for the task. The partner’s agent should be able to use that context without receiving custody of the whole corpus. This permits more complete work, removes repeated data preparation and one-off integration from the critical path, and makes information held in separate internal systems useful to an authorized third party without dissolving the boundaries around it.

Agents change the meaning of disclosure

A virtual data room assumes a person who opens selected documents, or accesses database rows, under an agreement and whose activity is bounded by human attention. A third-party agent is an AI-powered program with working state. It can search systematically, invoke tools, delegate work, compare distant parts of a corpus, and retain exact machine representations of what it has processed.

This changes both scale and form. The thing disclosed may be a fact that no source document contains. It may be a statistical result, an embedding, a ranking, a model update, a generated report, a tool side effect, or the mere existence and timing of an output. It may also live inside a carrier that the data-sharing application does not inspect: process memory, a scratch file, a checkpoint, a model prompt, a provider log, a cache, or a network connection.

An agent can, therefore, remain within its nominal read permissions and still carry away more knowledge than the data owner intended to disclose. Governance can no longer stop at the document or API call. It has to cover the complete computation and every boundary through which its information can pass.

The relationship does not end when the visit ends

Many data exchanges have a natural exit event. A diligence review opens, produces a deliverable, and closes. Other valuable relationships do not. Supply, manufacturing, financial, and service relationships depend on facts that change continuously, and a partner’s agent is useful only if it can work from current information.

Periodic exports are a poor answer. They produce stale copies, multiply the number of datasets outside the owner’s control, and detach each later use from the authority and policy under which the copy was made. Direct API access improves freshness, but it gives the counterparty a standing path into the owner’s systems and treats governance as a series of isolated calls. It does not by itself govern accumulated knowledge, derived state, or what the counterparty sends back.

The required relationship is a live, governed exchange.

Curated changes need to move both ways, and each one must remain tied to its source, current authority, policy, and recipient. A policy change or revocation must stop an active subscription or delivery lease, not wait for a new login or a new request.

The same boundary that governs a bounded visit must therefore govern an ongoing transfer. This is the need served by an Agentic Data Enclave’s Transfer Station.

This does more than control the relationship. It removes the delay of periodic packaging and reconciliation, lets both parties act on current information, and reduces the bespoke integration work required to keep a partnership operating. Safety and speed become properties of the same boundary.

Data residency is not data sovereignty

Data residency answers where stored data is located. Data sovereignty concerns who has authority over its use and disclosure. Residency does not entail sovereignty.

Source rows can remain inside a region or VPC while their information leaves in an answer, a prompt, a gradient, a model update, or the state of a visiting process. The research on federated learning makes the point directly: keeping raw training data local does not prevent updates and outputs from revealing information. The same principle applies to all agentic data-sharing. Moving computation to the data removes the need to hand over the source corpus, but location alone does not govern the artifacts produced from it.

A sandbox or microVM is also insufficient by itself. It can isolate a workload and constrain its system interfaces, but containment does not prove which inputs influenced an output. Work on system-wide information-flow control has shown why policies must follow information across application and tenant boundaries rather than stop at process isolation. For an opaque workload, the safe assumption is that an output may depend on every protected source the workload could observe unless a finer-grained mechanism proves otherwise.

Sovereignty therefore requires control of both place and flow. The data owner must control

• where the computation runs,
• what it can observe,
• which external systems it can reach,
• how its derived state is held, and
• what information is allowed to cross the boundary.

The principal is no longer a single person

A third-party agent acts through a chain of authority. A person or organization appoints an agent; the agent may call a subagent, a tool, or a model provider; and a long-running task may continue after the conditions under which it began have changed.

It is useful for the partner to provide signed evidence of this chain. That evidence can establish who asked the agent to do what, for which purpose and period. It cannot grant authority over another enterprise’s data. The partner can state the maximum authority it intended to delegate, but only the data owner can decide what its resources permit.

Effective authority must therefore remain the intersection of the owner’s grant, the partner’s delegation, every later delegation, current owner policy, and the context of the particular action. Each step must narrow or preserve scope rather than enlarge it. Revocation must be local to the data owner and must be able to invalidate one capability or active lease without depending on the partner’s identity provider at the moment of decision.

This is why agent identity is not enough.

The enterprise must be able to answer

• which human authority stands behind the action,
• which agent and workload executed it,
• which bounded capability permitted it, and
• whether that authority was still effective when the action occurred.

The output is where sovereignty is won or lost

Entry policy determines what an agent may observe. Exit policy determines what the counterparty gets to know. If exit is not governed, the owner has delegated the final disclosure decision to the visiting agent and its workload. Without effective exit policy and enforcement, data sovereignty is an illusion.

An output cannot be judged only by its surface. A harmless-looking sentence may derive from a protected source. A rounded number may still identify a small group. A table can disclose information through column selection, row order, precision, or omission. An agent may also influence the rule, transform, summary, or review context used to approve its own output.

This leaves two provenance questions. The first is a confidentiality question: which protected sources influenced the candidate artifact? The second is an integrity question: which guest-controlled values and actions influenced the artifact, its transformation, its presentation, or the decision to release it? A release process that answers only the first can still be manipulated through the second.

Human approval does not remove this requirement. A reviewer must approve the exact canonical artifact, with the relevant source and influence evidence visible. An edit, supplement, transform, or policy change creates a new candidate and invalidates the earlier approval. Otherwise the approval applies to a preview or description while different bytes cross the boundary. This is the problem addressed by robust declassification: an attacker or guest must not be able to manipulate a legitimate release mechanism into disclosing more than the owner’s fixed policy permits.

Audit records an event; proof reconstructs the decision

A conventional audit log records that a user called an endpoint, opened a document, or downloaded a file. This is useful evidence, but it does not usually contain everything needed to determine whether the decision was correct.

To check a past decision independently, you must preserve:

• the request in canonical form,
• the owner grant and delegation chain,
• the policy and trust material then in force,
• the relevant data and memory watermark,
• the state of revocation and usage limits,
• the resulting verdict, and
• the exact artifact released.

A later check must be able to reconstruct the decision without consulting mutable external services or accepting the operator’s present account of past state.

This distinction becomes important during an incident, audit, or dispute. “The log says allow” is an assertion about a past system. Reaching the same verdict from the retained inputs is evidence of what that system was entitled to do. Full execution replay is a further property, but verdict reconstruction is the minimum required to prove why a boundary crossing occurred.

Revocation governs the future, not the past

Revocation can stop new reads, terminate active delivery, prevent another export, or forbid repetition of information released earlier. It cannot make a recipient forget information already delivered.

This limit is not repaired by a deletion instruction, a retraction message, or a later change of policy. Those measures may govern future conduct and may have contractual force, but they do not reverse historical disclosure. Work on dynamic information-flow policy therefore distinguishes prospective revocation and erasure rules from the knowledge already released.

Once information leaves the enclave, it cannot be taken back. Before it leaves, working state can be discarded, a visit can be stopped, and some effects can be compensated. Afterwards, the owner can govern only what happens next. A safe system must make this boundary strict because no audit performed afterwards can undo an incorrect release.

What a sufficient system must make true

A system for third-party agent access is sufficient only if it can establish all of the following:

• The computation runs next to governed data without transferring custody of the source corpus.
• Every read, tool call, model call, side effect, and outward send crosses one owner-controlled enforcement path.
• Authority remains attributable to a human or organization, bounded through every delegation, and locally revocable by the data owner.
• Derived facts and artifacts retain structural provenance to the protected sources that influenced them.
• Guest influence over an artifact, transform, release rule, and review remains visible rather than being mistaken for owner authority.
• The visiting workload cannot take durable memory of the encounter except through an owner-authorized release.
• The owner approves policy-clear outputs automatically and resolves only the residue, while every approval binds the exact artifact that leaves.
• The same boundary governs bounded visits and continuous, bidirectional change, and a revocation stops active flow.
• Every decision can be reconstructed from immutable historical inputs.
• The system distinguishes reversible work from information already disclosed and makes no promise to recall the latter.

These conditions describe an Agentic Data Enclave. They also explain why it must be a property of the environment in which the visiting agent runs rather than a policy the visiting agent is asked to honor.

Read How does an Agentic Data Enclave work? for the mechanism, stage by stage.