停止失控AI：Unity Catalog如何保护你的代理操作安全

代理AI的风险已经不再是理论上的。连接到外部工具的代理正在生产中执行破坏性、不可逆的操作：几秒钟内擦除整个数据库、删除数百万行关键数据、并在任务中途删除生产数据库。在每起事件中，代理都是在被授权的范围内行动，但缺乏对可调用工具的任何限制，也没有任何操作记录。

今天，我们推出了治理每个MCP工具的能力，就像治理数据一样，包括细粒度访问控制、策略执行和完整审计跟踪。Unity Catalog现在允许你设置谁可以调用哪些MCP服务器，管理员可以分层服务策略以限制对特定工具（例如delete_database）的访问，或定义调用工具的条件（例如只有管理员可以调用delete_database）。Unity AI Gateway在每次调用时实时强制执行这些策略，并记录每个请求的完整有效载荷。

问题：访问是非此即彼的，工具调用不留痕迹

一个MCP服务器向任何连接的代理暴露一组工具——例如，GitHub MCP可能暴露push_files、delete_file和merge_pull_request；数据库MCP可能暴露execute_query和drop_table。默认情况下，如果代理被授权连接，所有这些工具随时可用。无法设定“此代理可读但不可写”，或“只有高级工程师才能执行此操作”，或“任何人都不应在生产环境中调用管理工具”。

当出现问题时，没有任何东西可以调查。工具调用不出现在模型日志或应用日志中。代理执行的确切操作、参数、代表谁，根本没有任何记录。

这意味着一个配置错误的代理、一个意外的操作，你都无法在事前阻止，也无法在事后解释。

解决方案：Unity Catalog中的MCP治理

Unity Catalog现在治理整个GenAI资产，包括LLM和MCP。一旦注册MCP，你将获得之前缺失的东西：对代理允许执行的操作的控制，以及它们实际执行的操作的完整记录。两者都由Unity AI Gateway在每次MCP调用时实时强制执行。

服务策略允许你编写规则，在每次工具调用到达上游MCP服务器之前和之后进行评估。你决定哪些调用允许、拒绝或需要用户同意。服务策略用SQL定义，允许管理员检查参数，包括调用者属性和其他上下文属性。如果调用未通过策略，则被阻止。

有效载荷日志记录将每个工具调用作为条目捕获到Unity Catalog管理的追踪表中。工具名称、参数、结果、用户身份以及调用是否允许或拒绝。像任何其他表一样用SQL查询。

工作原理

在Unity Catalog中定义策略函数

Unity Catalog允许你注册和治理任何外部MCP（参见我们关于此工作原理的博客！）。服务策略是一个Unity Catalog SQL函数。它接收两个参数：actor（谁在调用）和context（他们在调用什么），并返回允许或拒绝以及原因。

这是一个GitHub MCP的简单策略。它完全阻止文件删除，并阻止合并PR，除非调用者是经批准的工程师：

附加并强制执行

编写后，将策略附加到Unity AI Gateway中的任何MCP服务。从那时起，每个通过该服务路由的工具调用在执行前都经过评估。代理或MCP服务器无需更改代码。

记录并验证

每个工具调用自动捕获到Unity Catalog中的Delta表中。发送一个应被阻止的提示和一个应通过的提示。结果立即出现在日志中，可像任何其他表一样用SQL查询。

开始使用

MCP的服务策略和有效载荷日志记录作为Gated Beta提供，将你已用于数据的相同治理概念扩展到每个MCP调用。要获得早期访问权限，请联系你的Databricks账户团队。