In Part 1, I split AI agents into two kinds: agents that work on a person’s behalf with that person’s permissions, and agents that run under their own identity. Controls on the agent help with both. I think protecting the data helps with both too, but in different ways, and it’s worth being specific about each.
Agents with their own identity keep multiplying
Agents that run under their own identity are the hardest to keep track of. Each one has its own access, and each new one has to be found, given the right permissions, and monitored before a control on the agent covers it.
Today a company might run a few dozen of them. Over the next few years that could turn into thousands, many started by other agents, running on different vendors’ models and reaching other systems through connections nobody set up by hand. A control on the agent has to keep pace with all of that just to hold the coverage it already has. I don’t think that’s a flaw in anyone’s engineering. The number of these identities doesn’t have a ceiling, so the work of covering them doesn’t have an end.
Palo Alto Networks’ 2026 Identity Security Landscape report puts some numbers on it. Companies now average 109 machine identities for every human one, up from 82 a year earlier, and 40% of those machine identities can reach company data.
What protecting the data means
PKWARE has worked at the file level since the company started in 1986 (PKZIP shipped in 1989), so this is an approach we’ve been building toward for a long time, well before anyone was talking about agents.
PK Protect finds sensitive data on endpoints, in the cloud, in Microsoft 365, and on z/OS and IBM i mainframes, and classifies it under one classification policy. What happens next depends on the data and how people use it. Some of it gets encrypted, some gets masked or redacted, and some gets quarantined or deleted.
Protecting data doesn’t have to break the work built on it. Format-preserving encryption keeps protected data in the format applications expect. An encrypted card number, for example, still looks like a card number to the system that stores it, so the applications and workflows built on that data keep working.
For agents with their own identity
When PK Protect encrypts a file, the protection stays on the file after it moves. PK Protect’s key management service issues and manages the keys, and your directory service decides who can use each one. If an agent running under its own identity hasn’t been given access to the key, it can reach the file and still can’t read what’s inside, even if the rest of its access was set too broadly. Adding more of these agents doesn’t mean changing the protection on the data.
For agents working on a person’s behalf
Encryption doesn’t stop these agents, and I don’t want to suggest it does. If a person can open a file, an assistant working for them can open it too.
The usual answer here is least privilege: cut each person’s access down to what their job needs, so their assistant can reach less too. Least-privilege tools do a good job of finding where access is too broad and tightening it, and I think that’s worth doing. But least privilege changes who can open a file. It doesn’t change what’s in the file, so anyone who keeps access, and every assistant working for them, still sees all of it. Once a copy leaves the system where those permissions live, the permissions don’t go with it either.
PK Protect works on the data itself, and it does that natively. It finds sensitive data sitting where it shouldn’t be, like a customer export on a shared drive or old payroll files in a team folder, and then acts on it directly. It deletes what shouldn’t exist, encrypts what should only be open to certain people, and masks or redacts sensitive values people don’t need to see. Many tools in this space find these problems and either flag them for someone to fix or hand the fix to a separate product. With PK Protect, finding the problem and fixing it happen in the same product.
That matters for assistants because an assistant can only surface what its user can read. A masked value stays masked for the people who keep access to the file. A deleted file can’t be surfaced by anyone. And an encrypted file stays unreadable to anyone without access to its key, even after a copy ends up somewhere the original permissions don’t reach.
What PK Protect doesn’t do
PK Protect doesn’t monitor agents. It won’t tell you which agents reached your data, it doesn’t govern their access, and it won’t stop an assistant from reading what its user is allowed to read. Agent governance is a separate category of tool, it’s a legitimate one, and it’s the one BigID and Varonis are building.
| Situation | Control on the agent | Protection on the data |
|---|---|---|
| Agent working on a person’s behalf | Limits what the agent does with that person’s access | Limits how much that person, and so the agent, can read |
| Agent with its own identity | Each one has to be found, given permissions, and monitored | It can’t read encrypted files unless its identity has access to the key |
| When a new agent shows up | The control has to be extended to cover it | The protection on the data doesn’t change |
Nothing is future-proof, and I won’t claim this is. I think the strongest setup uses both: controls on the agent for what it’s allowed to do, and protection on the data for what it can actually read. If you only do one, the number of agents keeps deciding how exposed your data is.
Part 3 gets into how this shows up when you’re evaluating vendors, including the two categories it gets confused with most: DLP and DSPM.
Sources
2026 Identity Security Landscape, Palo Alto Networks, survey of 2,930 cybersecurity leaders.