How do I manage AI agents as non-human identities in our IAM stack?

Summary

• Treat each AI agent as a first-class, governed identity: in production it runs under a dedicated service principal rather than a person's credentials, so every action carries the agent's own identity and stays auditable.
• On Databricks, agent identity is managed through three integrated layers — Unity Catalog (permissions on assets), the Unity AI Gateway (a runtime control plane for traffic), and service policies (behavior) — one governance model spanning data and AI.
• With on-behalf-of (OBO) execution, an agent inherits the invoking user's real-time permissions: if a user cannot read a table in Unity Catalog, neither can the agent acting for them, and each action is logged against both the user and the agent.
• Agents, models, MCP servers, functions, and connections are registered in Unity Catalog as governed objects, controlled with the same privileges and attribute-based access control (ABAC) policies — including row filters and column masks — used for tables.
• Every model call and tool invocation flows through the Unity AI Gateway, where service policies allow, deny, or require approval and guardrails screen for personal data and prompt injection, with usage and payloads logged for audit and lineage.

How to manage AI agents as non-human identities in your IAM stack

An autonomous agent calls models, invokes tools, and acts on data on its own, so it needs an identity you can grant permissions to, scope, and audit — just like a human user or a service account. On Databricks, agents are managed as governed identities across an integrated model: Unity Catalog governs the assets an agent can use, the Unity AI Gateway governs the traffic it sends at runtime, and service policies govern the behavior that is allowed. Because the same identity and permission model spans data and AI, you define governance once and apply it consistently.

Why Databricks manages AI agents as governed identities

• Dedicated service principals in production. When an agent is deployed to production, it should run under a dedicated service principal rather than a developer's personal identity, so production actions carry the agent's own identity while remaining auditable. Deployed agents authenticate with OAuth or a service principal.
• On-behalf-of user identity. With on-behalf-of (OBO) execution, an agent inherits the invoking user's data permissions in real time rather than using a shared, over-privileged account. If a user cannot access a table in Unity Catalog, neither can the agent acting on their behalf, and every action is logged against both identities — the user who triggered the request and the agent that acted for them.
• Assets governed in Unity Catalog. Unity Catalog manages every model, MCP (Model Context Protocol) server, function, and connection as a securable object, governed with the same privileges you use for tables and volumes. Agents themselves can be registered as agent services so every team's agents live in one place, discoverable and permissioned alongside tables, models, and functions.
• Attribute-based access control. Fine-grained ABAC policies enforce least privilege: row filter policies restrict which records a principal can see (for example, limiting results to a user's region), and column mask policies hide sensitive columns unless a user belongs to a specific group — a direct way to reduce exposure of personal data.
• A runtime control plane. The Unity AI Gateway routes every model and tool request through a central control plane that enforces rate limits, budgets, and usage tracking before a call executes, and logs it after.
• Behavior governed by service policies. Service policies evaluate each request and response — based on the caller's identity, the tool name, or the arguments — and return allow, deny, or require-human-approval, blocking a tool call before it executes when the policy denies it.
• Inline guardrails. At the model layer, guardrails inspect what flows through inference in real time — scanning inputs for personal data and prompt-injection attempts and checking outputs for sensitive content — and run inline on every request, failing closed.
• Scoped access to external tools. When an agent connects to an external MCP server, it acts on behalf of the end user, so it only sees what that user is allowed to see. Admins register the server in Unity Catalog and can scope OAuth permissions per connection — for example, limiting a connection to read-only access — with all activity captured in a central audit table.
• Audit and lineage. Because every request follows a governed path through the gateway, usage, tokens, latency, and cost are logged, optional inference tables can capture full request and response payloads to your own Unity Catalog Delta tables, and end-to-end traces are available for compliance review and debugging.

Getting started

• Read the four pillars of agent governance for the identity, permission, and audit model, then learn how AI governance works on Databricks.
• Register and govern your agents in Unity Catalog, and register shared agents as agent services.
• Configure least-privilege grants, row filters, and column masks on the data and AI assets each agent identity can use, and set rate limits, budgets, and payload logging on model and agent endpoints via the Unity AI Gateway.
• To connect agents to external tools safely, follow connecting agents to external MCP servers.

FAQs

Should an AI agent use a service principal or a user identity?

Both, at different times. In development an agent can authenticate as the developer's workspace identity, but in production it should run under a dedicated service principal so its actions carry the agent's own identity. When the agent acts for a specific person, on-behalf-of execution forwards that user's identity so permissions and audit reflect the real user.

How does Databricks stop an agent from accessing data beyond its permissions?

Agents get least-privilege grants in Unity Catalog, and attribute-based access control applies row filters and column masks to what they can retrieve. With on-behalf-of execution, an agent can only reach data the invoking user is already permitted to access.

How are an AI agent's actions audited?

Every model call and tool invocation flows through the Unity AI Gateway, which logs usage, tokens, latency, and cost, and can capture full request and response payloads to Unity Catalog Delta tables. Actions are recorded against both the agent and the user it acted for, with end-to-end traces for review.

Can agents connect to external tools without over-privileged accounts?

Yes. External MCP servers are registered in Unity Catalog and the agent acts on behalf of the end user, so it only sees what that user is allowed to see. Admins scope OAuth permissions per connection and all activity is captured in a central audit table.