Enterprise customers keep asking us how to stop an AI agent from going rogue. They don't mean a movie plot. They mean an agent that reads a table it shouldn't, calls a tool nobody approved, runs up a bill, or repeats an action after a crash.
We already build software where a wrong action has a price. So when customers ask about governing agents, we look at two layers: Databricks for governance and Temporal for durability. In this post I'll show what each layer does and how we put them together.
Treat the agent like a user with a job description
The most useful idea in Databricks' approach is that AI assets are governed the way tables are. Unity Catalog treats models, tools, MCP servers and agents as securable objects, with the same privileges and attribute-based policies you already use for data. An agent is registered as a Unity Catalog model, and the tools it calls are governed as MCP services, functions and connections. There is no second permission system for the data team to learn.
Our position is that an agent should get the narrowest grant that lets it do its job, and nothing by default. If a follow-up agent needs one function, it gets EXECUTE on that function and nothing else in the schema.
Whose identity the agent runs under is the second decision. We'd run it as the user who asked, so it can only reach what that person could reach anyway, and the audit trail names a person instead of a shared service account.
Put a gateway between the agent and everything it calls
Permissions say what an agent may reach. They don't say how much it may use, or what it may say. That is Unity Gateway, the control plane that routes every model and MCP request, applies rate limits and budgets, and records usage across providers. Databricks describes governance in three dimensions: assets, traffic and behavior.
Behavior is handled by service policies, which can allow or deny a request or response based on its content. On an MCP service an input policy can also require human approval. Built-in policies cover PII, prompt injection and unsafe content.
The same shape applies to any irreversible agent action. The agent proposes, and a policy or a person disposes.
A marketing agent with a budget per user
Marketing is where a rogue agent is easiest to picture. It sends outbound email, publishes content, researches accounts and follows up, and every one of those costs money or reputation. For a company like Heddle, we'd build the content agent, blog agent, research agent and follow-up agent in Databricks, covering outbound, content and SEO marketing.
The cost control comes from the gateway. Unity Gateway lets you set per-user thresholds and hard caps on spend, and attribute foundation model cost to users, teams or projects with service tags and request tags. So each person using the agents has a controlled budget, and an agent that loops stops at the cap instead of at the end of the month. Usage tables record who called what and when, which makes the bill explainable.
Give the agent the business's definitions, not its own
Ask for revenue and the agent invents a definition.
Make the agent survive its own failures with Temporal
Governance answers who may do what. It says nothing about what happens when the process dies between two steps. An agent that sends an email, then crashes, then retries from the top has been governed perfectly and still did the wrong thing.
Temporal keeps the state of a run, so failed steps retry on their own and a run that dies halfway doesn't have to start again, as in our Athlinks and Location Services work. We'd put the approval step inside the same workflow, so a person's yes is part of the run's recorded state and a retry doesn't skip it or ask twice.
Start with one agent and one narrow grant
Pick a single agent with a real consequence attached, such as one that sends email or touches customer records. Register its tools as Unity Catalog securables, grant EXECUTE on only what it needs, run it under the user's identity, route its model calls through Unity Gateway with a per-user budget, and wrap its steps in a Temporal workflow with an approval step before anything irreversible. If you want to see how we think about the data side of this, our post on Unity Catalog for AI agents goes through scenarios in detail, and our Databricks work page covers the platform.
The two layers fail in different places, which is why we want both on the same agent. Databricks decides what the agent may reach, say, and spend. Temporal decides what happens when the run breaks halfway. The first thing we'd test is a crash between the approval and the action, to confirm the retry doesn't ask the person twice or send the email a second time. Once one agent runs that way, adding the second and third is mostly a matter of new grants and new workflows.