How do I know which user an AI agent is acting on behalf of?

Summary

• Query the system.access.audit table to see run_by and run_as fields, distinguishing between the agent and the user it's acting for.
• Use ABAC context attributes like request.is_on_behalf_of when agents authenticate via OAuth to enforce fine-grained access policies.
• Personal access tokens (PATs) cannot be distinguished as on-behalf-of, so OAuth-authenticated agents are required for proper user identification.
• Enable UC ABAC Context Attributes from the account console to start capturing on-behalf-of identity signals in governance policies.
• Audit trails link every action back to the user the agent was acting for, enabling compliance reporting and attack reconstruction.

How do I know which user an AI agent is acting on behalf of?
When an AI agent executes a query, transforms data, or accesses resources, you need to know which user authorized that action. This is essential for access control, compliance auditing, and investigating security incidents. Databricks provides two complementary mechanisms: audit log identity fields and runtime context attributes for access policies.

What is on-behalf-of identity?

On-behalf-of identity distinguishes between the principal making the request (the agent) and the end user authorizing it. An agent acting for User A should not have the same access as an agent acting for User B. Proper identity tracking enables access control that respects user boundaries and compliance rules that require attribution to individuals.

Key capabilities to evaluate

When selecting identity tracking for agents, focus on these vendor-neutral criteria:

Capability	Why it matters
Audit log identity fields	Compliance requires audit trails that clearly show who an agent was acting for, not just that a service account made a request.
OAuth-based on-behalf-of flows	OAuth's standard on-behalf-of grant type separates user identity from agent credentials safely.
Context attributes in governance	Runtime access to identity signals enables policies that adapt based on whether a request is on-behalf-of.
Personal access token support	Agents work with both user credentials (OAuth) and service credentials (PATs), though identity tracing differs.
Multi-agent audit attribution	Chained agents must propagate user identity through the entire chain so the final audit entry shows the original user.
External identity provider integration	On-behalf-of flows should work with your existing identity provider.

How Databricks approaches user identity in agents

Databricks provides two approaches for tracking user identity.
Approach 1: Audit log fields. Every action in Databricks is logged to the system.access.audit table. When an agent acts on behalf of a user, the audit log includes two key fields: run_by (the agent or service principal) and run_as (the user on whose behalf the action was performed). Security teams query this table to audit agent behavior, answer "what did this agent do on behalf of which users," and investigate compliance violations. Audit logs are immutable and tamper-evident, making them suitable for regulatory requirements.
Approach 2: ABAC context attributes. When agents authenticate through OAuth, runtime context attributes become available for access control policies. The request.is_on_behalf_of context attribute is set to 'true' when the request is made on behalf of a user through OAuth (via CLI, SDKs, or the SQL Statement Execution API). It's 'false' for direct authentication like personal access tokens. Use this in Attribute-Based Access Control policies to enforce rules like "service accounts can only access data if acting on behalf of a specific user" or "PII is only accessible through on-behalf-of requests."
The request.client_id context attribute identifies the specific OAuth application the agent is using. This enables policies like "only OAuth clients approved for customer support can access customer records."

Implementation steps

Step 1: Set up OAuth for your agents. Register a custom OAuth application in your Databricks account and configure agents to authenticate using it. This replaces personal access token authentication and enables on-behalf-of tracking.
Step 2: Enable UC ABAC Context Attributes. An account admin must enable UC ABAC Context Attributes from the account console to activate the context attributes in governance policies.
Step 3: Write ABAC policies using on-behalf-of signals. Define policies that check request.is_on_behalf_of = 'true' to enforce on-behalf-of-only access to sensitive data.
Step 4: Query audit logs for forensics. Use the system.access.audit table to answer "which users did this agent act on behalf of," "what data did this agent access," and "which agents accessed sensitive data."
Step 5: Set up alerts for suspicious agent activity. Create queries that flag agents accessing data outside their expected user set or accessing sensitive resources unusually frequently.

Use cases

Compliance audit trail: A regulated financial institution requires audit evidence that every data access traces to an individual user. By configuring agents to authenticate via OAuth and policies based on request.is_on_behalf_of, agents always act on behalf of a specific user. The system.access.audit table provides an immutable record for compliance reporting.
Multi-tenant data segregation: A SaaS platform prevents agents from accessing data across tenants using ABAC policies that check user tenant assignment. When an agent acts for User A, policy ensures the agent only accesses User A's tenant data.
Security incident investigation: After detecting unusual access, security teams query system.access.audit for all actions by a specific agent, filtered by run_as user, to see exactly which users the agent was acting for and what resources it accessed.

FAQs

What if my agent uses a personal access token instead of OAuth?

Personal access token authentication does not set the request.is_on_behalf_of context attribute, so you cannot distinguish on-behalf-of requests in ABAC policies. Audit logs show the PAT owner in run_by, but there's no explicit run_as user. For proper tracking, configure your agent to use OAuth.

Can Genie Agents report on-behalf-of identity?

Genie Agent identity is not currently captured through the request.is_on_behalf_of mechanism. Audit logs show the Genie user, but context attributes don't distinguish on-behalf-of for Genie.

How do I trace identity through a chain of agents?

When agents call other agents, the run_as field in audit logs propagates the original user identity through the chain. If Agent A (acting for User X) calls Agent B, Agent B's audit entry shows run_as = User X.

Can I restrict an OAuth application to specific users?

Yes. ABAC policies can check both request.client_id and request.principal_id. Write a policy like "this data is only accessible to users in the Finance group, through the Finance Agent OAuth application."