Authorization for human users in enterprise software is well understood. A user logs in, their identity is verified, and their access rights determine which database rows, API endpoints, and application features are available to them. AI Agent Authorization extends this model to cover non-human software actors that operate autonomously, often on behalf of multiple different users, and that may attempt to access data through multiple interfaces simultaneously.
Getting agent authorization wrong has asymmetric consequences. A human accidentally accessing a restricted table generates an audit alert. An autonomous agent doing the same thing at machine speed across thousands of records in minutes generates a compliance disaster.
Three Authorization Models
Model 1: Static Service Account
The simplest and least safe pattern. The agent authenticates as a dedicated service account with a fixed set of permissions that never change. This pattern is acceptable for tightly scoped automation agents with no user-facing component, such as a nightly data quality monitoring bot. It fails for any agent that serves multiple users with different access rights, because the service account becomes a shared credential that bypasses individual user-level policies.
Model 2: Credential Delegation
The recommended pattern for user-facing Agentic AI systems. When a user initiates an analytical session, the identity provider issues the agent a short-lived access token derived from the user's own identity through an OAuth 2.0 token exchange. The agent presents this delegated token to Dremio when executing SQL queries. Dremio evaluates the token, recognizes the underlying human user's identity, and applies that user's exact Row-Level Security and Column-Masking policies at query execution time. The agent physically cannot return data the user is not permitted to see.
Model 3: Scope-Limited Agent Identities
For autonomous agents that run on schedules without a human in the loop (such as the Autonomous BI monitoring agents described elsewhere in this Knowledge Base), a dedicated agent identity with narrowly scoped permissions is appropriate. The agent identity in Apache Polaris is granted read access only to specific namespaces and is explicitly denied write permissions, schema modification rights, and access to any PII-classified columns. This is the principle of least privilege applied to automated systems.
Tool-Level Authorization
Beyond data access, agent authorization must cover the toolset the agent may invoke. In a Python-based orchestration framework, each tool (the SQL query tool, the file write tool, the email notification tool) should perform an authorization check before executing. A read-only analytics agent should not have the email notification tool registered in its toolset at all. The tool registry itself is an authorization boundary, not just an organizational convenience.
Audit Trail Requirements
Every authorization decision, whether granted or denied, should be written to an immutable log stored in the lakehouse. When a compliance audit asks "Did the AI agent access customer PII on March 15th?", the authorization audit log provides a definitive, cryptographically signed answer. Without this log, the organization is left reconstructing agent behavior from incomplete inference.
