How can we prevent an agent from making unauthorized changes?

Summary

• Prevent unauthorized agent changes with defense in depth on the Databricks Platform, all governed by Unity Catalog: least-privilege permissions, on-behalf-of identity, runtime service policies, guardrails, and audit.
• Least privilege. Everything an agent can touch — tools, functions, MCP servers, external connections — is a Unity Catalog securable, so you grant only the privileges each agent needs and revoke the rest.
• On-behalf-of identity. An agent inherits the invoking user's permissions in real time, so if a user cannot change data, neither can the agent acting for them — and every action is logged against both identities.
• Service policies. Service policies evaluate every tool call before it runs and can allow, deny, or require human approval — so a destructive or write action can be blocked or held for consent.
• Guardrails and audit. Built-in guardrails screen for prompt injection and unsafe content inline on every request, and every governance decision and action is captured in audit logs and lineage.

How can we prevent an agent from making unauthorized changes?

An AI agent can call tools, run code, and reach enterprise systems on its own, so preventing unauthorized changes means controlling what it is allowed to do at runtime — not only what it was designed to do. The Databricks Platform applies defense in depth, governed by Unity Catalog: least-privilege permissions decide what an agent can touch, on-behalf-of identity scopes it to a user's own access, service policies decide whether each action proceeds, guardrails screen the content flowing through it, and audit logs record everything. See governing AI agents at scale with Unity Catalog.

Why the Databricks Platform prevents unauthorized agent changes

• Least-privilege permissions. In Unity Catalog, an agent's tools and connections are governed securables: custom function tools with GRANT EXECUTE, external API and MCP (Model Context Protocol) connections with GRANT USE CONNECTION, and registered MCP servers as catalog objects. Grant only the privileges each principal needs and revoke the rest, so an over-permissioned agent cannot become a single point of compromise. See set up AI governance.
• On-behalf-of identity. Rather than running under a broad, shared service account, an agent can pass the invoking user's identity and access resources with that user's permissions in real time. If a user cannot write to a table in Unity Catalog, neither can the agent acting on their behalf, and every action is logged against both the user who triggered it and the agent that acted. See how Unity Catalog secures your agent actions.
• Service policies that allow, deny, or require approval. Service policies are runtime controls attached to registered model and MCP services that evaluate every tool call before it runs — and optionally the result before it returns. Each evaluation returns allow, deny, or require approval, so a policy can block a destructive operation such as deleting a database or require human consent before an agent pushes code or writes to an external system.
• Human-in-the-loop for high-stakes changes. When a service policy returns require-approval, the tool call is held until a person approves it. This is the control for the changes that matter most — destructive operations, external system writes, and high-risk data access — so an agent cannot make those changes unattended.
• Attribute-based access and tool filtering. Define dynamic access with attribute-based access control (ABAC) on governed tags rather than object-by-object, and filter which specific tools within an MCP server are exposed to an agent, reducing the surface an agent can act on.
• Guardrails on every request. Built-in guardrails inspect inputs and outputs inline on every request — blocking prompt-injection and jailbreak attempts, detecting and redacting sensitive data, and screening unsafe content — and can be attached to model and tool services without custom code. See mitigating prompt-injection risk for AI agents.
• Complete audit and lineage. Every governance decision and agent action is captured — including tool calls logged against both the user and the agent identity — so you can reconstruct exactly which objects were accessed, what ran, and when, for compliance and investigation.

Getting started

• Read governing AI agents at scale with Unity Catalog for the permissions, service-policy, and guardrail layers.
• Register agent tools as Unity Catalog securables and grant least-privilege access: GRANT EXECUTE on function tools and GRANT USE CONNECTION on external connections.
• Create and attach a service policy to allow, deny, or require approval on your agent's tool and model calls.
• Configure AI governance to enable on-behalf-of authentication, guardrails, and audit.

FAQs

How do I stop an agent from performing a destructive or write action?

Attach a service policy to the tool or model service. Service policies evaluate every call before it runs and can allow, deny, or require human approval, so a destructive operation like deleting a database can be blocked or held for consent.

How do I ensure an agent cannot exceed a user's permissions?

Run the agent with on-behalf-of identity. It inherits the invoking user's Unity Catalog permissions in real time, so if a user cannot change a table or column, the agent acting for them cannot either.

How do I require a human to approve high-stakes changes?

Configure a service policy that returns require-approval, which holds the tool call until a person approves it — the control for destructive operations, external system writes, and high-risk data access.

Are agent actions auditable?

Yes. Every governance decision and agent action is captured in audit logs and lineage, including tool calls logged against both the invoking user and the agent identity.