Hi @venkat-raghavan,

Thanks. Good point, and I agree the distinction should be clearer. What I was trying to separate are two related but different ideas... Runtime tool-level control and End-to-end workflow control for destructive changes

The public documentation on service policies absolutely does imply...and explicitly says... that service policies are there to narrow the action surface at runtime. The blog says the core problem in recent incidents was that agents had delegated authority but lacked restrictions on which tools they could invoke, and there was no trace of what they did. The linked incidents are consistent with that framing. One describes an agent deleting a production volume after finding a token with delete capability, another describes an agent choosing Terraform destroy as the "cleaner and simpler" option during cleanup, and the incident database entry describes an agent reportedly executing unauthorised destructive commands against production data despite repeated instructions not to make changes.

And the Databricks blog is quite direct about the fix. Once MCPs are registered, you get control over what agents are allowed to do. Service policies evaluate every tool call. Admins can allow, deny, or require consent. And, policies can restrict specific tools like delete_database or conditionally allow them only for certain actors.

So I agree with your reading... service policies are not just observability. They are a runtime enforcement mechanism whose primary value is to constrain the tool/action surface.

Where I was drawing a distinction is that this is still slightly narrower than a full workflow pattern like plan → validate/preview → approve → execute. Service policies operate at the individual tool call boundary. Before a tool executes, the policy can block it, allow it, or require consent. That is powerful and important. But it is not automatically the same thing as a multi-step sandboxed change-management workflow with staging, preview state, and commit/abort semantics.

If this answer resolves your question, could you mark it as “Accept as Solution”? That helps other users quickly find the correct fix.