How should identity work for enterprise AI agents?

Summary

• Enterprise AI agents must operate within the authenticated user's identity boundary, inheriting row filters, column masks, and access controls rather than bypassing them.
• On-behalf-of (OBO) token passing ensures agents act with the calling user's identity, preserving audit trails and preventing credential hoarding.
• Provisioning via identity providers (AIM or SCIM) ensures agents run as properly authenticated Databricks users, enabling usage tracking and cost attribution.
• Authorization through Unity Catalog is the enforcement layer: authentication proves who you are, but Unity Catalog decides what you can access.

How should identity work for enterprise AI agents?
Enterprise AI agents must be architected so they operate within the same identity and authorization boundaries as human users. This is the core principle: agents don't get separate credentials, backdoors, or bypass mechanisms. Instead, they inherit the full permission model of the user who invokes them.
This architecture prevents agents from becoming a second, ungoverned access path. Every action is traceable to a specific user's identity in the audit log.

What is identity and authentication for agents?

Identity consists of two layers:
Authentication (AuthN) proves who you are. A user logs in via their identity provider (Okta, Microsoft Entra, Ping Identity, etc.) and receives a credential or token. For agents, authentication means provisioning them as Databricks users. Use either AIM (account identity management) just-in-time provisioning at login or SCIM (system for cross-domain identity management) scheduled sync.
Authorization (AuthZ) enforces what that identity can do. Unity Catalog evaluates access at query time: masked columns return nulls, row filters apply, and grants are enforced.

Key authentication and authorization capabilities to evaluate

Capability	Why it matters
On-behalf-of (OBO) token passing	Agents inherit the calling user's identity. Enables per-user access and audit compliance.
Automatic passthrough via service principal	System-managed service principal with minimal privileges. Simplifies setup.
Manual authentication with UC secrets	Store service principal credentials securely. Use for external API calls.
Just-in-time provisioning (AIM)	Auto-create accounts at SSO login. No pre-provisioning required.
Scheduled sync (SCIM)	SCIM syncs users and groups on a schedule. Use for finer control over directory access.
Identity provider integrations	Okta, Ping Identity, SailPoint, Saviynt extend governance and agent discovery.
Row filters and column masks	Enforced at the SQL engine level. Agents cannot circumvent controls by changing code.

How Databricks approaches enterprise AI agent identity

Databricks uses Unity Catalog as the unified identity and authorization engine for all AI services, including agents. Here's how it works in practice:
Provisioning. Users become Databricks users via your identity provider. AIM auto-creates accounts at SSO login (recommended). SCIM syncs users and groups on a schedule (for finer control).
Authentication in the request. When a user invokes an AI agent via the Databricks platform, the request carries their OAuth token, SAML assertion, or PAT (personal access token). The token proves the user's identity to the system.
Authorization through Unity Catalog. Upon authentication, Unity Catalog evaluates the user's identity against the resource's grants and policies. If the user's identity has SELECT on a table, the agent can query it. If the user lacks permission on a masked column, the agent receives a null value for that column. Row filters evaluate for the user's identity, not the agent's.
Three authentication patterns for agents:

• Automatic passthrough: System-generated service principal with least privilege. Use when no per-user control is needed.
• On-behalf-of (OBO): Agent runs as the calling user. Initialize inside the request handler for per-user access control and audit.
• Manual authentication: Explicit service principal credentials in UC secrets for external API calls.

Critical constraint: never place the gateway in the OBO token path for internal agent-to-Genie or agent-to-MCP calls. The gateway re-issues its own token, which causes current_user() to resolve to the gateway's identity instead of the user's, silently breaking row filters and audit trails.
Partner ecosystem. Databricks integrates with Okta, Ping Identity, SailPoint, and Saviynt to extend identity governance into agent workflows, enabling agent discovery and access certification.

Use cases: when per-user identity matters

Multi-tenant SaaS. Agents must respect customer data isolation. OBO ensures each customer's agent queries only their data, even with shared code.
Regulated industries. In financial services or healthcare, compliance requires audit trails showing which user accessed which data. OBO ensures this: logs show the responsible user's identity.
Decentralized analytics teams. In large organizations, different teams have different data access. A shared analytics agent must respect those boundaries. OBO prevents the agent from becoming a single over-privileged gateway that bypasses team-level access control.

FAQs

Can an agent escalate privileges beyond the calling user?

No. In the OBO model, agents inherit the user's identity and therefore the user's permissions. In the automatic passthrough model, the service principal has fixed, minimal permissions set at deployment time. An agent cannot escalate privileges.

What happens if the user logs out while the agent is running?

If the user's token expires, the agent's requests will fail with an authentication error. This is the correct behavior: the agent should not continue to act on behalf of a user who is no longer authenticated.

Do I need to manage separate credentials for each agent?

No. Agents inherit credentials from the caller (OBO) or use a system-provisioned service principal (automatic passthrough). Databricks manages the credential lifecycle; you don't hardcode secrets in agent code.

How do I audit which agent accessed which data?

Unity Audit logs record every access by agent or user. The log entry captures the identity that performed the action, the resource, the timestamp, and the action type. If you configure the agent to run OBO, the log shows the end user's identity; if the agent runs as a service principal, the log shows the service principal.

Can I use the same agent code with multiple identity models?

Yes. You can mix authentication patterns within the same agent: some calls use OBO, others use a service principal from UC secrets, and others use automatic passthrough. Choose the pattern per use case.