Inference vs. Authorization

Why AI agents change the security architecture

The security industry has spent decades getting better at understanding what happened. AI agents are forcing us to get better at controlling what is allowed to happen.

Proofpoint’s $6.3 billion acquisition of Varonis represents a significant moment in the evolution of enterprise security. Bringing together capabilities across identity, data security, permissions, and behavioral intelligence is a logical progression for an industry increasingly focused on understanding how information moves throughout the enterprise. The combination has considerable strategic value, particularly as organizations struggle to understand where sensitive data resides, who can access it, and how that information is being consumed.

But I believe this acquisition also highlights a much larger architectural question facing the security industry: Are we going to infer whether access was appropriate, or explicitly authorize it?

For decades, enterprise security has invested heavily in visibility, monitoring, behavioral analytics, and threat detection. These investments have dramatically improved our ability to identify suspicious activity, understand risk, and respond to security incidents. However, they have also reinforced an architectural assumption that organizations can grant access and subsequently determine whether that access was appropriate by observing how it is used. This model has served us reasonably well in a world where humans primarily interact with applications, but it becomes increasingly problematic as autonomous agents begin interacting directly with enterprise data.

At Immuta, we believe this transition represents one of the most consequential architectural shifts in enterprise security. As AI agents become first-class consumers of data, the industry must move beyond simply understanding what agents are doing and establish mechanisms for explicitly controlling what they are permitted to do. This is why we are betting on authorization.

Understanding the Difference Between Inference and Authorization

Inference-based security attempts to determine whether an action is legitimate by observing behavior, analyzing context, and identifying patterns. Consider a financial analyst accessing customer information from a cloud data warehouse. A security system might evaluate whether the volume of data being accessed is unusual, whether the activity differs from historical patterns, whether the user normally accesses similar information, or whether the behavior resembles a known threat. These observations are valuable because they help identify potential risk, but they do not necessarily establish whether the user was authorized to perform that specific action for that specific purpose. A legitimate action can appear suspicious, while an inappropriate action can appear entirely normal.

Authorization approaches the problem differently. Rather than attempting to infer legitimacy from behavior, authorization determines whether an action is permitted based on explicit policies, identity, entitlements, purpose, and context. It evaluates who is requesting access, what information is being requested, why that information is needed, and under what conditions access should be granted. The resulting decision is enforced before the operation proceeds. Importantly, authorization does not eliminate the need for behavioral intelligence. It establishes a different foundation for making security decisions, one where intelligence informs policy rather than serving as a substitute for permission.

This distinction becomes particularly important when considering how enterprise access has evolved. Historically, applications were the primary interface between humans and data. Organizations built applications, implemented access controls within them, and determined which users could perform particular operations. As enterprise infrastructure evolved toward shared databases, cloud data warehouses, data lakes, SaaS applications, and APIs, access became increasingly distributed. Organizations began relying on identity systems, roles, groups, and platform-specific permissions to manage who could access what, creating an environment heavily dependent on standing privileges.

In this model, users authenticate, receive entitlements, and retain those permissions until something changes. Those permissions may be appropriate for their general responsibilities, but they are not necessarily appropriate for every task they perform. To compensate, the security industry developed increasingly sophisticated capabilities for monitoring how permissions are exercised, including data loss prevention, user behavior analytics, insider threat detection, and data security posture management. These technologies provide essential visibility, but they also expose a fundamental architectural limitation: We have become very good at observing access without becoming equally good at authorizing it for a specific purpose at the moment it is needed.

Why AI Agents Fundamentally Change the Equation

Consider an employee who has access to multiple enterprise systems, including Snowflake, Databricks, Salesforce, ServiceNow, and SharePoint. Those permissions reflect the employee’s responsibilities, but they are generally broader than what is necessary to complete any individual task. Now imagine that employee delegates a task to an AI agent. The agent needs to retrieve information from several systems, analyze the results, and produce a recommendation. To accomplish this, it may invoke tools, interact with APIs, query databases, and delegate portions of the work to additional agents. What was previously a human interacting with a defined application becomes an autonomous execution process operating across multiple systems.

If that agent inherits the employee’s standing privileges, it potentially inherits access far beyond what is necessary for the task. If the agent delegates work to other agents, the problem compounds. The issue is not necessarily malicious behavior. An agent can operate exactly as designed and still access information it should never have needed. It can retrieve excessive data, combine information across security boundaries, or expose sensitive information through downstream operations. None of these actions necessarily needs to look anomalous. In fact, they may appear entirely consistent with the permissions the agent was given.

This is the fundamental limitation of relying on inference as the primary security mechanism for autonomous agents. Behavioral analytics can identify suspicious activity, but they cannot independently establish whether an agent should have been permitted to perform a particular operation. As agents begin executing thousands of operations at machine speed, the opportunity to identify inappropriate access after it occurs becomes increasingly insufficient. The architecture needs to shift from detecting potential misuse of broadly granted permissions to ensuring that permissions are appropriately scoped before they are exercised.

At Immuta, we believe the starting point is straightforward: Every agent needs permission. Not simply an identity, and not unrestricted inheritance of a human user’s entitlements, but authorization that reflects the specific task being performed, the identity on whose behalf the agent is acting, the information it needs, and the conditions under which access should be permitted. This requires treating agents as first-class identities while preserving the relationship between the agent and the human or service responsible for its actions. An agent acting on behalf of an employee should not automatically receive every permission associated with that employee. Instead, authorization should consider both the authority of the human principal and the specific scope of the delegated task.

It also requires moving beyond traditional role-based access controls toward purpose-based authorization. Two requests from the same agent, accessing the same data, may have very different authorization requirements depending on what the agent is attempting to accomplish. An agent analyzing customer churn may legitimately need access to certain customer attributes, but that does not mean it should be permitted to retrieve payment information, employee records, or other sensitive data unrelated to the task. Purpose provides an additional dimension for determining whether access is appropriate. Critically, that purpose must be established through trusted context, such as an authorized workflow or delegated mandate, rather than simply accepting an agent’s own declaration of intent.

Finally, authorization must become dynamic and operate at machine speed. Standing privileges create unnecessary exposure because access remains available even when it is not needed. Just-in-time authorization and zero standing privilege offer a fundamentally different approach, granting narrowly scoped access for the duration of a specific operation or task. Traditional human approval workflows cannot scale to agents executing thousands of operations across enterprise systems, which means routine authorization decisions must become programmatic. Human oversight will remain important for sensitive or exceptional requests, but it must operate within an architecture capable of evaluating and enforcing authorization automatically.

Intelligence Should Inform Authorization, Not Substitute for It

This brings us back to the broader industry conversation. I do not believe inference and authorization are competing technologies. In fact, effective authorization increasingly depends on intelligence. Organizations need to understand the sensitivity of their data, the relationships between identities, the permissions already granted, and the risks associated with particular operations. Behavioral analytics can identify unusual activity, detect emerging threats, and provide signals that influence authorization decisions. An agent exhibiting unusual behavior, for example, might be subject to additional restrictions or required to obtain explicit approval before performing a sensitive operation.

But intelligence alone does not establish authority. A system can understand everything about an identity, a resource, and an observed behavior without necessarily having the mechanism to determine and enforce whether a specific operation should be permitted. The distinction is architectural. Identity establishes who you are. Intelligence establishes what is happening. Authorization determines what you are allowed to do. All three are necessary, but as autonomous agents become direct consumers of enterprise data, authorization becomes the mechanism through which identity and intelligence translate into enforceable security decisions.

This is also why I believe the future of enterprise security will require a more integrated approach across identity, data intelligence, and authorization. Identity providers establish and authenticate principals. Security intelligence platforms provide visibility into data sensitivity, activity, and risk. Authorization systems consume that context to determine whether access should be granted and enforce those decisions across the underlying infrastructure. These capabilities are complementary, but they solve fundamentally different problems. Knowing that an agent is acting on behalf of an authenticated employee does not establish that the agent should access every resource available to that employee. Similarly, knowing that an agent’s behavior appears normal does not establish that the underlying operation is authorized.

Why We Are Betting on Authorization at Immuta

This is the architectural direction we have been building toward at Immuta. We believe enterprises need a consistent authorization layer that operates across their data infrastructure, independent of the individual applications, agents, and platforms consuming that data. Historically, authorization has been fragmented across databases, warehouses, SaaS applications, and APIs, each with its own permission models and enforcement mechanisms. That fragmentation was already difficult to manage for human users. For autonomous agents operating across multiple systems, it becomes an even greater challenge.

Our approach is to bring together the capabilities necessary to establish, execute, and continuously improve authorization decisions. Govern provides the foundation for understanding data and defining access policies. Provision enables access requests, approvals, and exceptions, creating a path toward automated, just-in-time authorization. Agentic Data Access extends these capabilities to autonomous agents through on-behalf-of access, scoped permissions, and just-in-time entitlements. Comply provides the intelligence and observability necessary to understand how access is exercised, identify risk, and continuously improve authorization policies. Together, these capabilities support a transition from static permissions and retrospective monitoring toward dynamic, contextual authorization.

Importantly, this is not about replacing identity providers, data platforms, or security intelligence vendors. It is about connecting those capabilities through a consistent authorization architecture. We believe authorization should become a foundational enterprise service, much like identity and authentication have become over the past several decades. As organizations deploy increasingly autonomous systems, the ability to make and enforce consistent authorization decisions across heterogeneous infrastructure will become essential.

The Next Security Architecture Is About Controlling What Can Happen

The security industry will continue investing in visibility, behavioral analytics, and threat detection, and those investments remain essential. Acquisitions like Proofpoint and Varonis demonstrate the strategic importance of understanding the relationships between people, identities, data, and activity. But I believe the next major architectural shift will be defined by our ability to translate that understanding into explicit, enforceable authorization.

As autonomous agents become increasingly responsible for accessing, analyzing, and acting upon enterprise information, organizations will need to move beyond determining whether behavior appears appropriate. They will need to establish whether the action was authorized in the first place. That means moving from standing privileges to just-in-time access, from broad entitlements to purpose-based authorization, from application-specific controls to consistent enterprise policy, and from human-centric approval processes to machine-speed authorization.

This is not an argument against intelligence. It is an argument for putting intelligence to work where it matters most: informing decisions that can be enforced before access occurs. The future of enterprise security will not be defined solely by how well we understand what agents are doing. It will be defined by how effectively we control what they are allowed to do.

At Immuta, that is the future we are building toward. Because in an autonomous enterprise, every agent needs permission. And permission requires authorization.