As enterprises rapidly move from simple AI assistants to autonomous agents, one question has begun to dominate almost every architectural discussion that I’m involved in:

“How should an AI agent get access to enterprise systems?”

At first glance, this appears to be a classic Identity and Access Management (IAM) problem. Architects and CISOs naturally find themselves debating the familiar options: Should agents receive their own unique machine identities? Should they have pre-provisioned, static permissions? Should they dynamically inherit the invoking user's access? Or should every single autonomous action require explicit human approval?

These are all valid questions, but treating this purely as an identity provisioning challenge leads us toward the wrong architectural model.

For the last two decades, IAM has focused on answering a straightforward question: Who should have access to what? We built highly mature enterprise systems centered around provisioning identities, assigning roles, managing entitlements, and performing periodic access reviews. Those core principles continue to be essential for managing humans and traditional applications.

AI agents, however, introduce a completely different operating model. Unlike traditional applications that execute deterministic code paths, agents’ reason, plan, invoke tools, adapt to new information, and dynamically determine their own sequence of actions at runtime. Their behavior is non-deterministic by design. As a result, the enterprise authorization model must evolve from assigning permissions upfront to evaluating actions continuously.

The shift is subtle, but its architectural implications are profound. Instead of asking “What permissions should this agent hold?” we must ask “Should this specific action be allowed under the current circumstances?”

Access Should Be Determined by More Than Identity

When designing access models for agentic workflows, relying on a single vector creates immediate security vulnerabilities. In practice, robust authorization in agentic systems must be determined by the intersection of multiple signals: identity, delegated authority, capabilities, business objectives, and runtime context.

To achieve true Dynamic Least Privilege, architecture must evaluate three distinct vectors simultaneously:

• The Invoking User’s Session (On-Behalf-Of): The active human session establishes the absolute ceiling of authority available to the agent e.g. if a user does not have access to the HR payroll database, an agent operating on that user's behalf must never be able to retrieve it, regardless of how logically the agent reasons that it needs that data to complete its task.

• The Agent’s Capability Profile (Skills): This defines the structural boundaries of what the agent is technically capable of doing e.g. a platform engineering agent may possess the skills to create pull requests, execute shell commands, or modify infrastructure templates. These capabilities describe what the agent can do, not necessarily what it should do in a given session.

• The Assigned Goal (Business Context): This provides the missing link in traditional identity frameworks e.g. an objective such as "resolve a customer support ticket" may legitimately require an agent to read CRM records, update status, or send a confirmation email. However, that objective should not automatically authorize the agent to issue financial refunds or export the entire customer directory, simply because those capabilities exist within its toolset.

From Access Assignment to Action Authorization

Traditional IAM follows a predictable lifecycle: users are provisioned into roles, roles grant permissions, and downstream applications enforce those permissions whenever a resource is requested.

Agentic systems invert this model entirely. Rather than focusing on what permissions an agent permanently owns, every significant interaction with an enterprise system becomes a discrete authorization decision.

When an agent decides to invoke a tool, call an API, query a production database, or execute code, the underlying platform must evaluate whether that specific action remains consistent with the delegated objective, enterprise safety policies, and current risk conditions.

This does not mean introducing paralyzing friction by involving a human for every minor step; doing so would eliminate the productivity benefits of autonomous automation. Instead, enterprise authorization must become increasingly adaptive. Low-risk, highly aligned actions can execute automatically, while higher-risk operations or contextual anomalies automatically trigger step-up verification, reduced execution scopes, or Human-in-the-Loop (HITL) workflows.

Why Intent Matters

Traditional authorization architectures evaluate the subject, resource, action, role, relationship, and environment attributes (RBAC / ABAC / ReBAC). While these dimensions remain vital, autonomous systems introduce a critical new variable to the policy engine: Why is this action being performed?

Consider a standard enterprise scenario - a user instructs an agent to summarize recent customer emails and prepare a draft response. Reading the emails and creating a draft in the CRM clearly align with the requested objective.

Suppose, during execution, the agent encounters a prompt injection or decides on its own that downloading the customer’s entire historical transaction log and uploading it to an external collaboration channel will help it write a more comprehensive response.

From a strict legacy authorization perspective, the invoking user may already have valid read and write permissions across all those internal systems. A traditional gateway would see a valid token and allow the traffic.

From an intent perspective, however, the action completely diverges from the delegated business objective. This is why intent must increasingly become a core authorization signal rather than being treated simply as an LLM prompt analysis technique. It provides the necessary telemetry to evaluate whether the agent's real-time choices continue to support the specific objective originally authorized by the human.

Designing for the Non-Deterministic Loop

To bridge this operational gap without introducing widespread engineering friction, enterprise security architectures are shifting toward a framework known as Intent and Behavior Based Access Control (IBAC).

As detailed in Reva’s recent architectural whitepaper, Intent and Behavior Based Access Control (IBAC): The Next Evolution of Authorization for the Agentic Enterprise, this model extends modern runtime authorization by continuously validating intent alignment, behavioral consistency, and identity continuity at every hop of an AI-driven workflow.

Practically implemented through a real-time policy control layer - this framework shifts the security boundary directly to the semantic and transaction layers. It intercepts the non-deterministic outputs of the reasoning engine and evaluates the specific tool payload and its arguments against deterministic enterprise policies before any backend systems are touched.

What makes this transition fascinating for practitioners is that the foundational building blocks remain reassuringly familiar. Identity providers still authenticate users and workloads. Policy engines like Cedar or OPA remain highly effective for expressing enterprise rules. What changes fundamentally is the richness of the telemetry available to the decision layer, and the granularity of what the engine returns.

Architectural Comparison: Traditional vs. Agentic

A Practical Framework for Agent Authorization

As practitioners, we should resist the temptation to treat AI agents as merely another flavor of privileged service accounts. Instead, it helps to conceptualize agents as temporary decision-makers operating within tightly bounded, delegated business objectives.

For platform engineering and security teams building out these capabilities, five practical design principles should guide the architecture:

1. Enforce Zero Standing Privilege: Agents should not possess long-lived, ambient permissions. Authority should be granted dynamically for the duration of a task and expire immediately upon completion.

2. Separate Capability from Authority: An agent's skills (what it is technically trained or integrated to do) must be structurally separated from its authority (what it is permitted to do in the current session).

3. Authorize Actions, Not Just Sessions: Move away from one-time authentication at the beginning of a session. Every meaningful interaction with an enterprise system - tool invocations, database queries, or privileged API calls, must be evaluated at the moment of execution.

4. Ingest Intent as an Active Signal: Authorization decisions must actively parse the agent's payload and arguments to verify that the step aligns with the approved business objective.

5. Make Human-in-the-Loop Policy-Driven: Escalation to a human operator should not be a byproduct of model uncertainty or low confidence scores. It should be triggered explicitly by enterprise risk thresholds and policy definitions (e.g., any transaction over a specific financial amount or any cross-domain data movement).

The conversation surrounding AI security inside the enterprise frequently begins—and unfortunately ends—with identities and prompt formatting. While those layers remain important parts of defense-in-depth, they only address a fraction of the structural risk.

As autonomous workflows become core to enterprise operations, the real architectural evolution will occur at the authorization layer. The defining question for identity architects is no longer simply "Who has access?" It is cleanly shifting to: "Should this autonomous action be allowed to happen, given the current objective, context, and enterprise policy?" That is where the next generation of enterprise access control is being built.