Summary: Identity controls decide whether an AI agent gets in. This article explains why CISOs also need to control which sensitive data that authorized agent actually sees, and how applying least privilege at the data layer reduces exposure without breaking AI workflows.
Security teams have spent the past year working through a familiar checklist for AI agents. Who built this agent? How does it authenticate? Which systems can it reach, and who signed off on that? These are the right questions, and the industry has made real progress answering them. Identity providers are extending their platforms to cover non-human identities, and most enterprises now treat an agent’s credentials with the same seriousness they give an employee’s.
There is another question, though, and it tends to get skipped once the agent is safely inside. If an agent is authorized to query a system, should it automatically see everything that system sends back? In most environments today, it does, whether the task calls for it or not.
Authentication tells you who is at the door. Authorization tells you which rooms they can enter. Neither tells you what they should be allowed to pick up once they are inside. As AI becomes an active participant in enterprise workflows, security leaders need to think beyond controlling access to systems and start controlling exposure to the sensitive data within them.
AI Changes What “Access” Means
It is tempting to treat this as the old access control problem with a new actor. It isn’t, and the difference comes down to what happens after the data is retrieved.
When a human employee opens a customer record, they scan for the fields they need, finish the task, and close the screen. Plenty of other information passes in front of them along the way, but it usually stops there. An AI agent behaves very differently. In a single run it might pull data from several systems, pass it between tools, fold it into a prompt, write it into an output, trigger a downstream action, and hand the whole thing to another agent. Every stop along that path is a new place where sensitive data can land, including transcripts, agent memory, and logs that were built to keep conversations rather than to guard regulated information.
That changes the question worth asking. It is no longer just whether the agent can access a system. It is what information actually needs to move through this workflow for the job to get done. That question is harder to answer, but it is far more useful.
You Might Also Like: A Rule in a Prompt Is Not a Security Control
The Problem With Inherited Permissions
Most agents don’t get purpose-built permissions. They inherit them from a service account, a delegated user session, or an API role that already exists in the enterprise. Those permissions were designed around systems, not tasks, which means they usually grant access to complete records.
Consider a customer service agent answering a simple question about a delayed order. To do its job, it needs the customer’s name, the order number, and the shipping status. The record it retrieves, however, may also include a date of birth, payment details, account identifiers, and a home address. The agent’s request is completely legitimate. Every control did exactly what it was configured to do. And yet a set of sensitive values just traveled into an AI workflow for no reason at all.
This is the distinction that matters most. The agent isn’t unauthorized; the data is overexposed. Most security tooling is designed to catch unauthorized activity, so this pattern rarely triggers an alert, because nothing about it looks abnormal. It simply repeats thousands of times a day in the background.
You Might Also Like: Why Your AI Oversight Is Probably a Rubber Stamp — And What Real Control Looks Like
Least Privilege Needs a Data Dimension
Least privilege has always asked a straightforward question: which systems, applications, and resources should this identity be allowed to reach? For AI, organizations need to add a second question. What is the minimum sensitive data required to complete this specific task?
Asking both shifts the security model from Identity → Resource to Identity → Task → Data. An agent can have a perfectly valid reason to query a customer database and still have no reason to receive every sensitive field in the record it gets back. Recognizing that gap is the first step toward closing it.
None of this requires a new security philosophy. Many organizations already apply the same thinking to human analysts through column-level masking in their data platforms. The work now is extending that principle to a path that moves faster, touches more systems, and is far less predictable than a person running a query.
Protect Data Before It Reaches the AI
The instinctive response is to ask the model to behave. Tell it in the system prompt not to repeat account numbers, and trust it to comply. The trouble is that instructions are guidance, not control, and they do nothing about the data that has already been written into a transcript or stored in an agent’s memory.
A more durable approach reduces exposure before sensitive information ever enters the AI interaction. Sensitive values are identified as they move. Policy is evaluated for the agent, the task, and the context. Anything the workflow doesn’t need is protected, either by swapping it for a reversible placeholder or by removing it outright. The agent receives only what is necessary, and the real value is restored only when an authorized person or process asks for it, with that restoration recorded.
It is worth being clear about what this approach is not trying to do. The goal isn’t to keep AI away from sensitive systems, because blocking tends to push usage toward tools nobody sanctioned. It also isn’t to strip every sensitive value and hope the workflow survives, since an agent that can’t reference an account at all will quickly stop being useful. A reversible placeholder lets the agent know that an account number exists, and work with it, without ever seeing the digits. Useful access stays useful, and it no longer turns into unnecessary exposure by default.
Scale Makes This More Urgent
If agents were going to stay a handful of pilot projects, a case-by-case review might be enough. They aren’t. Gartner predicts that by 2028 the average global Fortune 500 enterprise will have more than 150,000 agents in use, up from fewer than 15 in 2025, and it warns that the resulting sprawl exposes organizations to risks that include oversharing and data loss.
Even if the real number lands well below that forecast, manually reasoning about what every agent might encounter is not a realistic plan. So the question has to change. Instead of asking whether you can trust a particular agent, the more scalable question is whether you can consistently enforce what sensitive data is exposed, regardless of which authorized agent makes the request. The first question has to be answered one agent at a time. The second can be answered once, in policy, and applied everywhere.
Identity and Data Controls Work Together
None of this suggests that identity security matters less. This isn’t identity versus data security, and treating it that way would leave gaps on both sides.
Identity establishes who or what is interacting with enterprise resources and what it is allowed to do. Data security determines which sensitive information should be exposed within that authorized interaction. Each control covers something the other can’t see, and a mature AI security program needs both working in concert. If you want a simple way to remember it, try this: authenticate the agent, authorize the action, and minimize the data.
You Might Also Like: AI is Your Newest Sensitive Data Store. Treat it Like One
What Security Leaders Should Start Asking
You don’t need to buy anything to start pressure-testing your current posture. Begin with visibility by asking what sensitive information your AI agents can reach today, and whether access to a record automatically exposes every sensitive field inside it. For many teams, the honest answer to that second question is yes, and knowing that is useful in itself.
From there, look at control and accountability. Can protection policies adapt based on the agent, the task, or the context? Can sensitive values remain protected while the AI still completes its work? Who is allowed to restore protected information, and can you audit when data was protected, accessed, or restored? These questions tend to surface where current controls stop, which is exactly where the conversation about AI data exposure should begin.
The Bottom Line
An AI agent having permission to retrieve data doesn’t mean it needs to see all of that data. As enterprises move from dozens of agents to potentially thousands, least privilege will need to apply not only to the systems agents can access, but also to the data they are allowed to see once they get there. The organizations that build that discipline now will be the ones able to scale AI with confidence rather than caution.