Data Governance for Agentic AI: Controlling What Agents Can See and Send

If you are deploying agents against real enterprise data, this is the exposure that turns a capable agent into a liability. Traditional systems accessed data through fixed, predictable paths that governance could reason about. An agent accesses data dynamically, deciding what to retrieve based on the task, and it produces output that may contain that data, sent to destinations that depend on what it decided to do. The read side and the send side are both governed poorly by controls designed for deterministic access, and closing both is the work.

The read side: controlling what the agent can see

The instinct when giving an agent access is generosity: grant broad access so the agent has whatever it might need to be helpful. This is the wrong instinct, and it is the source of the read-side exposure. An agent with broad data access can retrieve information the current task does not warrant, information the user it is serving is not entitled to, or sensitive data that should never enter the agent’s context at all. The breadth that feels like enablement is the breadth that lets the agent see across boundaries it should respect.

The control is scoping the agent’s access to what its task and its user actually require, which is the bounded action space applied to data. The agent should access the minimum necessary, and critically, that scope has to respect the entitlements of the user the agent is acting for, because an agent serving a user must not become a way for that user to reach data they could not access directly. This is a specific and dangerous failure: an agent with broad access, serving a user with narrow entitlements, that retrieves and surfaces data the user was never permitted to see, using the agent as an entitlement-bypass. Scoping access per task and per user, so the agent inherits rather than exceeds the user’s permissions, is the read-side discipline, and it is more complex than static access control because the appropriate scope changes with the task.

The send side: controlling what the agent can transmit

The read side is the half teams think about. The send side is the half that surprises them. An agent produces output, and that output can contain sensitive data, and the agent may transmit that output to destinations, another system, an external service, a message to a person, that the data should not reach. The agent that read data appropriately can still leak it on the way out, by including sensitive information in an output that goes somewhere it should not, and controlling what the agent sees does nothing to control what it sends.

This requires governing the agent’s outputs and destinations, not only its inputs. What can the agent include in its output, and where can that output go? An agent that can send data externally needs controls on what data may leave and to which destinations, because an agent free to transmit whatever it produces to wherever the task suggests is an exfiltration path, whether triggered by a mistake or by a manipulated input. The send-side exposure is heightened by the fact that the agent’s behaviour is influenced by its inputs, which means a manipulated or malicious input could attempt to induce the agent to send sensitive data to an attacker-chosen destination, making output and destination control a security boundary rather than only a governance one. Governing the send side means constraining what leaves and where it goes, with the same seriousness applied to the read side.

The trade-off, and why this is harder than access control

Governing both sides has a real cost in capability and engineering, and pretending otherwise leads to the over-broad grants that cause the exposure. Tighter data governance means the agent can do less, because access scoped to the task and outputs constrained by destination reduce the agent’s flexibility, and there is a genuine tension between an agent’s usefulness and its data safety. An agent given everything is more capable and less safe, and the right point on that spectrum is a deliberate decision informed by the sensitivity of the data and the consequences of leakage, rather than a default of maximum access for maximum helpfulness.

What makes this harder than traditional data governance is the agent’s nature on both sides. The agent decides dynamically what to access, so the governance cannot rely on fixed access paths and has to reason about access that changes per task. The agent produces non-deterministic output, so you cannot fully predict what it will include, which means output governance has to inspect and constrain what the agent actually produces rather than trusting it to handle data correctly. And the agent is influenced by its inputs, so both sides carry a security dimension that deterministic systems did not. Traditional data governance controlled predictable systems accessing data through known paths. Agentic data governance controls a non-deterministic actor deciding dynamically what to read and generating unpredictably what to send, which is a genuinely harder problem requiring controls on both boundaries and the tracing to audit what the agent actually accessed and transmitted.

Where it almost broke

We deployed an agent with broad data access, granted generously so it could be maximally helpful across a range of tasks, and the exposure surfaced on the read side first. The agent, serving users with varying entitlements, was able to retrieve and surface information that some of those users were not permitted to access directly, because the agent’s broad access did not respect the user’s narrower entitlements. The agent had become, unintentionally, a way for users to reach data their own permissions would have blocked, and this was a governance failure waiting to become a compliance incident.

The correction governed both boundaries. On the read side, we scoped the agent’s access to the task and, crucially, to the entitlements of the user it was serving, so the agent could never exceed what the user could access directly. On the send side, which examination showed was equally exposed, we constrained what the agent could include in outputs and which destinations those outputs could reach, closing the exfiltration path that broad send capability had left open. We added tracing of what the agent accessed and transmitted, so both boundaries were auditable. The agent became less broadly capable and safe to operate against real data. The lesson was that giving an agent data access creates a two-sided governance problem, and controlling what it sees is only half of it.

Govern both boundaries or govern neither

The reframe that makes agentic data access safe is recognising that data governance for agentic AI has two boundaries, and controlling one while ignoring the other leaves the exposure open. What the agent can see and what the agent can send are separate controls, and an agent governed on the read side can still leak on the send side, which means both have to be engineered with the sensitivity of the data in mind. The generosity that makes an agent broadly capable is precisely what makes it a governance liability on both sides.

The teams that operate agents against sensitive data safely are the ones that scoped access to task and user entitlement on the read side, constrained outputs and destinations on the send side, and made both boundaries auditable through tracing. An agent given broad access to be helpful is an agent that can read and transmit across boundaries it should respect. Controlling what it sees and what it sends, deliberately and on both sides, is what lets an agent work with real enterprise data without becoming the path through which that data escapes.