How can an agent harness enforce permissions and safe tool use?

Summary

• Three complementary layers. On Databricks, agent governance works in three layers: permissions control who can call what, service policies control whether a specific tool call should proceed at runtime, and guardrails control what content flows in and out. See Governing AI agents at scale with Unity Catalog.
• On-behalf-of authentication. With on-behalf-of user token passing, an agent inherits the invoking user's permissions instead of a shared account, and that identity flows end to end — even through multi-agent supervisors down to the deepest tool call.
• Unity Catalog is the single authorization engine. Agent tools are governed as Unity Catalog securables: MCP servers are registered and permissioned, custom function tools use GRANT EXECUTE, and external calls use GRANT USE CONNECTION.
• Runtime service policies. Service policies evaluate every tool call before execution — by tool name, arguments, and caller identity — and return allow, deny, or require user consent, blocking calls that are denied.
• Guardrails, audit, and lineage. Guardrails inspect inputs and outputs inline and fail closed; every action is logged against both the human and the agent identity, with audit logs and MLflow tracing for end-to-end lineage.

How can an agent harness enforce permissions and safe tool use?

An agent harness on Databricks enforces permissions and safe tool use through a multi-layered governance model built into Agent Bricks, the Mosaic AI Agent Framework, and Unity Catalog. The model combines three complementary layers that work together: permissions decide who can call what, service policies decide whether a specific tool call should proceed at runtime, and guardrails decide what content is allowed to flow in and out. See Governing AI agents at scale with Unity Catalog for the full model.

Why Databricks enforces safe agent tool use

• On-behalf-of (OBO) user authentication. Rather than running under a shared service account, an agent can pass the invoking user's identity end to end so it accesses resources with that user's permissions. In multi-agent supervisor scenarios, the human's identity propagates through every sub-agent down to the deepest tool call, so access always reflects the real user. See configuring authentication for agents.
• Per-agent service principals and least privilege. When per-user access is not required, each agent gets its own automatically created service principal with scoped permissions rather than a shared one. Production agents follow least-privilege patterns: grant only what is needed and revoke everything else, scope external calls per connection, and keep bearer tokens out of logs.
• Unity Catalog as the single authorization engine. All agent tools are governed as Unity Catalog securables. External MCP (Model Context Protocol) servers are registered in Unity Catalog with fine-grained permissions, credential management, and audit logging; custom tools built as Unity Catalog functions are governed with GRANT EXECUTE; and external API calls are governed with GRANT USE CONNECTION. Every tool call is evaluated before execution based on the tool name, arguments, and caller identity. See Stop rogue AI: how Unity Catalog secures your agent actions.
• Runtime service policies. Service policies act as a second layer of authorization beyond static grants. They evaluate every tool call before it runs and return allow, deny, or require user consent based on the tool, its arguments, or the caller. For example, a policy can let everyone call a read-only tool while restricting a destructive tool to admins; if the evaluation is deny, the call is blocked.
• Guardrails and AI safety. Guardrails operate at the model layer, inspecting inputs and outputs in real time. They scan inputs for sensitive data (PII) and prompt-injection or jailbreak attempts, check outputs for hallucinations and sensitive content before they reach the user, run inline on every request, and fail closed. See Mitigating prompt injection risk for AI agents.
• Unity AI Gateway control plane. The AI Gateway routes model and MCP service requests from a central control plane, enforcing rate limits and budgets, usage tracking, and service-policy evaluation before requests reach external systems. See How AI governance works on Databricks.
• Audit logging and lineage. Every action is logged against both identities — the real user who triggered the request and the agent that acted on their behalf — capturing which tables were accessed, what operations ran, and when. Combine audit logs with MLflow tracing for end-to-end agent lineage that is joinable by request ID.

Getting started

• Read Governing AI agents at scale with Unity Catalog to understand the permissions, service-policy, and guardrail layers.
• Configure on-behalf-of authentication so agents act with the invoking user's permissions.
• Set up AI governance in the Unity AI Gateway for rate limits, usage tracking, and centralized policy enforcement.
• Register your tools (MCP servers, Unity Catalog functions, and connections) as Unity Catalog securables and grant least-privilege access.

FAQs

What are the layers of agent governance on Databricks?

Three layers work together: permissions control who can call what, service policies control whether a specific tool call should proceed at runtime, and guardrails control what content flows in and out.

How does on-behalf-of authentication keep tool use safe?

The agent inherits the invoking user's permissions and that identity flows end to end — even through multi-agent supervisors — so every tool call and data access reflects the real user rather than a shared account.

How does Unity Catalog govern agent tools?

Unity Catalog is the single authorization engine for agent tools: MCP servers are registered as securables, function tools use GRANT EXECUTE, and external calls use GRANT USE CONNECTION, with every call evaluated before execution.

What do service policies and guardrails do?

Service policies evaluate each tool call at runtime and return allow, deny, or require user consent. Guardrails inspect inputs and outputs inline for sensitive content and injection attempts and fail closed.