Why agentic AI changes what we are actually protecting, and why the most enduring identity in the enterprise may be the data itself.
For nearly three decades, enterprise security has been organized around a single question: who is accessing the data? We learned to authenticate that "who," authorize it, watch its behavior, and revoke it when the relationship ended. Identity became the anchor. Nearly every control a security team trusts today assumes there is a reasonably stable actor on the other end of a request, an actor whose intent can be reasoned about.
That assumption is quietly coming apart.
The employee has not disappeared. They have simply stopped being the thing that touches the data. They describe an objective. An agent interprets it. The agent retrieves documents, queries the CRM, opens a support ticket, invokes a tool through MCP, hands part of the work to a second agent, and revises its plan as it learns more about the task. By the time the work is finished, dozens of autonomous decisions have been made on behalf of one human request.
The Actor Changed, Not the Question
Security teams still ask who is accessing the data. The problem is that "who" no longer resolves to a person.
Is it the employee who asked? The agent that decomposed the task? The tool that read the SharePoint library? The connector? The OAuth token? The session? Each of those identities exists. Most of them exist for seconds. Some are created dynamically, some delegate work to other agents, and some invoke tools they were never expected to touch.
Gidi in his article made the point that sits underneath all of this. For decades, security rested on the assumption that people make the decisions and systems merely execute them. AI agents break that assumption by removing the human judgment checkpoint from the workflow, turning software from a passive execution tool into an active participant in decisions once reserved for people.
Identity did not become less important. It became fluid. And when the actor is fluid, anchoring security to it gets harder every quarter.
Intelligence Is Not Judgment
The instinct is to respond by giving agents better identities. Stronger authentication, tighter scopes, workload identity for every autonomous process. That work matters. It is also not sufficient, because it addresses who the agent is without addressing what the agent understands.
Foundation models are remarkable. They reason, summarize, translate, write code, and coordinate with other agents. But they do not understand the enterprise. An agent does not know that an acquisition code name signals confidential M&A activity. It does not know that a customer identifier sitting next to payroll data creates regulatory exposure. It does not recognize that two individually harmless documents become sensitive the moment they are combined.
A person asks, "Should I?" An agent asks, "Can I?"
That difference is the whole game. Enterprise security has always leaned, quietly, on the assumption that an authenticated actor will exercise reasonable judgment. When the authenticated actor is an autonomous agent optimizing toward a goal, that assumption no longer holds.
The Industry Is Already Moving from Prompts to Actions
The rest of the field is arriving at a version of this conclusion. Gartner argues that AI security is shifting away from inspecting prompts and toward governing autonomous behavior inside the agent's cognitive and execution loop, where the cognitive loop covers reasoning, planning, and orchestration, and the execution loop covers the actions that actually change state. In that framing, the visibility scope expands from user-to-model interactions to human-to-agent, agent-to-agent, agent-to-tool, and machine-to-machine interactions. Gartner's sharpest line is a test for access itself: if an agent cannot prove who it is acting for and why, it should not be granted tools and data. The firm also projects that through 2029, more than half of successful attacks against AI agents will exploit access control weaknesses, using direct or indirect prompt injection as the vector.
OWASP's Agent Observability Standard points the same direction from the engineering side. Its premise is that enterprises cannot trust what they cannot see, so agents must become instrumentable, traceable, and inspectable, with every action traceable back to the reasoning that produced it and the task that originated it.
Both efforts are correct, and both are aimed at the same target: the agent. Which is worth pausing on, because the agent is the part of the picture that disappears and the Identity related to “access” must be anchored to an Identity with, relatively speaking, more permanence.
The One Thing That Doesn't Change
Step back and something becomes hard to unsee. We have handed identities to nearly everything in the enterprise. Users. Service accounts. Workloads. Devices. Applications. Now agents, and the tokens and sessions they ride on. We have given an identity to every actor that moves through the environment.
We never gave one to the data.
We treat data as an object. We classify it, encrypt it, scan it, move it, and label it. For years that was enough, because a human sat between the label and the decision. Public, Confidential, and Restricted told that human what they needed to know. Those same three labels tell an autonomous reasoning system almost nothing.
A customer contract is not "Confidential." It is a relationship with a named customer, governed by specific obligations, connected to other records that change its meaning. A payroll file is not "Restricted." It is a set of employees, their compensation, and the regulatory duties that attach to both. The label describes a sensitivity level. It says nothing about what the data actually is. One might think that classification addresses this, but does it? Especially when it comes to how this data would manifest when working with other fragments of data?
So the reframe is simple to state and consequential to act on. Stop classifying data. Start giving it an identity.
What It Means to Give Data an Identity
Identity is richer than classification because it carries history, relationships, ownership, obligations, and lineage. An identity for a piece of enterprise data would answer questions a label never could. Not just who created it, but who it represents. Which organization owns it. Which regulations govern it, whether HIPAA, GLBA, or GDPR. Which business process produced it. How it relates to other information. Whether AI has already summarized or transformed it. Whether combining it with something else changes what it is.
That is not a heavier classification scheme. It is a different object entirely. And it is the one object in the agentic workflow that does not evaporate after a few milliseconds.
This reframes the security model rather than replacing what came before. Human identity answers who requested the work. Agent identity answers which autonomous entities are acting. Cognitive identity, the visibility into reasoning and tool selection that Gartner and OWASP are both describing, answers why the work is happening the way it is. Data identity answers the question all of them exist to serve: what is actually at stake. One can also think of the actors (human or agentic) also a key component of the Identity that we must attribute to data to be able to reliably secure it.
The first three are becoming ephemeral. The fourth does not move. If it does transition in fragments, its Identity comes along with it and hence must be secured like how it was when it was at rest.
The Question Worth Asking
For years the anchoring question of data security was, "Who is accessing my data?" In an era where the answer is a shifting cloud of agents, tools, and tokens that exist for seconds, that question no longer anchors much of anything.
The better question is, "Do we understand the identity of the data being accessed?"
Because the identities reaching into the enterprise will keep multiplying, delegating, and disappearing. The customers, employees, contracts, and obligations encoded in the data will not. In the age of autonomous AI, the actors are temporary. The foundational data is relatively permanent.
Perhaps it is finally time to give it the identity it deserves.
In the next blog, I will explore how you go about defining and securing this identity.