Two Conflated Problems in AI Agent Authorization: Access Control vs. Entity Binding

As AI Agents rapidly move into production, "authorization" has become a high-frequency buzzword with frustratingly vague semantics. Recently, a developer on Reddit raised a thought-provoking point: what we call "AI agent authorization" actually conflates two fundamentally different problems. This article examines that distinction and explores its implications for real-world system design.

Reddit original post discussion

Two Authorization Problems Compressed Into One Word

As enterprises begin connecting AI agents to internal systems—letting them call databases, APIs, and various resources on behalf of humans—"how to authorize agents" has quickly become a focal point for engineering and security teams. But the original poster argues that the industry often lumps two entirely different problems under the single umbrella of "agent authorization," and this flattening obscures the real technical gap.

The author splits them into Problem A (actual access authorization) and Problem B (post-authorization entity binding correctness). At first glance, both occur at the "agent accessing a resource" stage, but their failure modes and responsible layers are completely different.

Problem A: Agent Access Control

Problem A is the authorization we're all familiar with: an agent (or the human it represents) requests access to a resource or attempts an operation, and the system decides "allow" or "deny."

This is fundamentally the same thing IAM, RBAC, and ABAC have been doing for human users and service accounts—just applied to a new type of principal. IAM (Identity and Access Management) is the overarching framework enterprises use to manage digital identities and resource access; RBAC (Role-Based Access Control) simplifies authorization by assigning permissions to roles and roles to users, making it the most widely adopted model in enterprise environments; ABAC (Attribute-Based Access Control) dynamically computes access decisions based on subject attributes, resource attributes, environmental conditions, and other multi-dimensional factors. These models have been extensively validated over the past two decades—from AWS IAM to Kubernetes RBAC, from HIPAA-compliant healthcare systems to SOX-auditable financial systems, all with mature implementations. However, their design assumption is that the principal is well-defined and static—a human user, a service account, a microservice instance. When AI agents emerge as a new type of principal, they represent both themselves and the human user behind them. This "proxy identity" duality introduces new challenges for traditional models.

The author argues that the real difficulty here isn't conceptual—authorization models are mature—it's adoption in practice.

"Most companies haven't routed their internal agent traffic through any gate at all, so even the most basic RBAC has nowhere to plug in."

In other words, Problem A is an "engineering integration" problem: it's not that people don't know how to do it, it's that they simply haven't done it. Agents barrel through enterprise resources without any unified authorization checkpoint intercepting them. Currently, Anthropic's Model Context Protocol (MCP), OpenAI's function calling specification, and similar efforts are forming de facto standards, but these protocol-level specifications haven't yet converged into a unified integration approach with enterprise authorization infrastructure (such as policy engines like Oso, Permit.io, or AuthZed/SpiceDB). Agent request patterns are unpredictable, request frequencies are extremely high (a single user interaction might trigger dozens of tool calls), and systems need to understand the agent's "intent chain" rather than individual requests—challenges that traditional API Gateway patterns have never faced.

Problem B: Post-Authorization Entity Binding Failure (Data Binding Failure)

The truly subtle and more easily overlooked issue is Problem B. The author's description is highly illuminating: the authorization system has already returned "allow," and the access decision itself is entirely correct—but the specific records returned belong to the wrong entity.

A Typical Scenario

Imagine a customer service AI agent that's legitimately authorized to answer account-related questions. A user asks about their balance, and the AI does indeed have permission to query balances—the authorization gate's judgment is completely correct. But because the query deviated during subject resolution, the AI fetched the balance of a different associated account and returned it to the user.

Unlike traditional applications where engineers write pre-defined parameterized queries, AI agents typically generate database queries or API calls dynamically through large language models (LLMs). This process involves multiple steps: first, the agent understands user intent from conversation context; then it infers which entities and conditions to query; finally, it constructs the specific query statement or API request. In multi-turn conversations, an agent might mistakenly treat another entity mentioned in the context as the query target; when handling ambiguous references (like "that account"), it might resolve to the wrong object; when using function calling, parameter binding can drift due to information mixing in the context window. None of these are traditional SQL injection or privilege escalation issues—they're an entirely new category of semantic-level binding errors.

By strict definition, this is not an authorization failure. The gate dutifully allowed a request that should have been allowed. This is a data-binding/correctness failure that happens to occur at the "seam" right after authorization—a seam that nobody explicitly owns.

The Responsibility Vacuum

The author pinpoints the core of the problem:

Authorization tools' responsibility ends at "allowed"—they don't care whose data is actually returned;
The application layer and database layer typically assume that if authorization approved it, whatever comes back is automatically correct.

So Problem B falls into the vacuum between these two layers. The authorization layer says "my job is done," the data layer says "if you allowed it, I'll assume it's right." When agents autonomously generate queries and dynamically resolve entities, the risk in this vacuum zone is dramatically amplified—because queries written by human engineers are typically hardcoded or rigorously tested, while agent queries are generated on-the-fly and context-driven.

To understand the technical root cause, you need to understand the complexity of "Subject Resolution." In traditional web applications, subject identity is typically determined through JWT tokens, Session Cookies, or OAuth 2.0 access tokens—identity is explicit and tamper-proof. But in AI agent scenarios, subject resolution becomes extraordinarily complex. An agent might simultaneously manage sessions for multiple users (multi-tenant agent), needing to correctly associate each tool call with the corresponding user. An even more complex case is the "delegation chain"—User A authorizes Agent B, Agent B calls Service C, and Service C needs to know the ultimate subject is A, not B. OAuth 2.0's token exchange and on-behalf-of flows attempt to solve this, but when agents make autonomous decisions and dynamically choose call paths, delegation chains may be constructed at runtime, making traditional static configuration approaches unable to cover all cases.

Is This Distinction Real?

The original poster maintains intellectual honesty, asking the community: is this distinction real, or have I invented a difference that doesn't matter in practice?

He further poses several key questions—where the real value of this discussion lies:

Have people who've built agent authorization systems actually treated B as a separate concern? Or has it been seamlessly absorbed into the dismissive "obviously you should scope your queries correctly" hand-wave?
Does Problem B already have established terminology? Is it just Row-Level Security (RLS) by another name? Or something fundamentally different?

Problem B's Relationship to Row-Level Security (RLS)

This is an excellent technical follow-up. RLS can indeed enforce at the database layer that "a user can only see rows belonging to them." In a sense, RLS is precisely one of the mechanisms designed to prevent Problem B.

From a technical implementation perspective, RLS is a database-level access control mechanism that allows database administrators to define policies making different rows in the same table visible or invisible to different users. PostgreSQL has natively supported RLS since version 9.5, and SQL Server achieves similar functionality through security predicates. A typical implementation works by having the database engine automatically append a filter condition before query execution, such as WHERE tenant_id = current_setting('app.current_tenant'). The advantage of this mechanism is its "transparency"—application-layer code needs no modification, security policies are enforced at the data engine level, and even if application-layer code has bugs, data won't leak.

But the two cannot be fully equated. RLS is a declarative, data-layer-enforced constraint that requires you to accurately associate the current session context with the row's owner. Problem B's vulnerability lies precisely in the context resolution itself being wrong—the agent incorrectly resolves "the current subject" to a different entity. If the context passed to RLS is already wrong, then RLS will meticulously return "correct rows" for the "wrong subject"—the problem persists.

Therefore, Problem B is more accurately described as a subject resolution and data binding consistency problem. RLS is merely one mitigation measure, not a complete answer. To truly solve this problem, you need to establish an end-to-end identity propagation mechanism across the entire call chain, ensuring that from the moment a user initiates a request to the moment data is ultimately returned, subject identity remains verifiable and cannot be corrupted by the agent's reasoning process.

Implications for AI Agent Security Architecture Design

Though this discussion originates from a simple classification question, it touches on a deep blind spot in AI agent security architecture.

Authorization Passing ≠ Data Correctness

The traditional "authorization" mental model is built on an implicit assumption: if access is allowed, the result is trustworthy and correct. This assumption largely holds in a world of human operations and static queries. But when agents autonomously construct queries and dynamically infer entities, a gap tears open between "allowed" and "correct."

This problem has a closely related concept in security—the "Confused Deputy" problem, first articulated by Norm Hardy in 1988. It describes a program (the deputy) with legitimate privileges being tricked or misled into using those privileges to do something it shouldn't. AI agent Problem B can be viewed as a new variant of the "Confused Deputy" problem in the LLM era: the agent possesses legitimate access rights, but its reasoning process—not an external attacker—causes it to apply those rights to the wrong target.

Who Owns This Seam?

For teams building agent infrastructure, this distinction suggests:

Problem A's solution is to rapidly establish a unified authorization gateway, requiring all agent traffic to pass through an auditable, policy-driven gate. This includes deeply integrating policy engines like OPA (Open Policy Agent) or Cedar with agent orchestration frameworks (such as LangChain, CrewAI, AutoGen, etc.), executing fine-grained permission checks before every tool call.
Problem B's solution requires adding an entity consistency verification layer after authorization but before returning results—ensuring that the subject resolved from the query is indeed the subject indicated by the current authorization context. Concrete engineering practices might include: injecting immutable identity identifiers at the agent's tool-calling layer (rather than letting the LLM infer them), performing "subject consistency assertion" checks on agent-generated queries, and establishing post-hoc audit mechanisms to detect binding drift.

Conflating these two problems leads to a most dangerous outcome: teams believe deploying RBAC makes everything safe, while remaining completely undefended against Problem B. In scenarios involving sensitive personal data—customer service, finance, healthcare—returning "correct data for the wrong entity" causes privacy breaches every bit as severe as actual unauthorized access. From a compliance perspective, GDPR's "purpose limitation" principle and "data minimization" principle both explicitly require that personal data be accessed only by its legitimate owner, not merely by "someone with permission"—here, "having permission" and "correct data subject" must both be satisfied simultaneously.

Conclusion

This developer's decomposition is essentially reminding the entire industry: when designing permission systems for AI agents, you can't just focus on "can it access this"—you also need to ensure "what it accessed is actually what it should see."

As agents increasingly act on behalf of users to perform automated operations, the seam between authorization (authz) and data correctness is likely to become the next repeatedly-stumbled-upon security frontier. Whether it will give rise to new terminology and a new category of tools is worth watching closely. Looking at the current technology ecosystem, some emerging projects have already begun exploring this direction—for example, applying formal verification methods to agents' query generation processes, or building dedicated "identity anchoring" middleware to ensure immutability of subject identity throughout the entire call chain. This field is still in its early stages, but its importance will become rapidly apparent as agent autonomy increases.