AI智能体权限控制回归数据库层：2025年全面深度解读核心逻辑趋势

企业们正忙着给AI智能体喂数据、写提示词、测试它们能不能从“只能问”进化到“真正干活”。这听起来不错，但部署后才发现，问题远不止于模型本身——在模型层之下，另一个更现实的问题正在浮现：数据层的权限控制，到底该怎么管？

当自主系统开始要直接操作数据库里的数据时，一个对基础设施团队来说很基础的问题，突然变得无比关键：安全防护，究竟该设在哪里？

一部分数据库厂商和研究人员给出的答案很直接：这些防护措施，就应该回归到数据库本身。理由也很简单——如果AI智能体要生成并执行SQL语句，那么基于角色的访问控制、行级安全、事务约束这些防线，都必须牢牢部署在数据存储的那个地方。这个判断，可能会重新影响数据库架构的选择、AI编排层与事务系统之间的集成深度，以及企业如何管理自主工作负载与核心数据的交互方式。

提出这个观点的，是总部位于慕尼黑的数据库厂商CedarDB。这家公司从慕尼黑工业大学UMBRA研究项目中分拆出来，专注于混合事务和分析处理（HTAP）。以下是其联合创始人Lukas Vogel的访谈核心内容整理（已做适当精简编辑）。

Q：企业对AI智能体直接与系统交互仍保持高度警惕，比如怕它乱改数据或触发错误。这个问题在今天到底有多严重？

Vogel：说实话，我很难听说有哪家企业现在敢真正放心地这么做。大多数问题，归根结底是因为行业内还没形成一套真正可执行的标准来约束这件事。大家基本都是在“试”，然后系统就“啪”一声崩了。我注意到一个现象：当企业认真考虑在生产环境中用智能体时，他们的第一反应都是极度保守的——如果你不能确保你的智能体不会搞砸数据库，那最好的选择就是：要么不给它访问权限，要么施加极其严格的限制。比如，不给更新、不给插入、不给添加新表、不允许加任何约束。只允许跑SELECT查询。这当然可行，但问题是，企业希望智能体能做的事情，远不止“只读”。现在这个领域，仍有点像蛮荒西部，缺乏统一的行为标准来约束它们。

Q：当智能体从“只读”系统转向“能操作”的系统时，发生了什么根本变化？

Vogel：最大的变化是，人们已经不太习惯用数据库的思维来思考问题了。过去二十年，开发人员几乎把所有权限检查和执行都迁移到了应用层。身份验证、权限检查，全在应用层做完，然后应用层只拿到一个数据库连接。这个连接，理论上可以做任何事情。这在应用程序行为是确定性的时候没问题——因为你知道它只会做什么。但现在呢？智能体可以自己生成查询、自己决定下一步动作。如果你希望它贴近数据去工作，那权限就必须部署在技术栈的最底层——也就是数据库里。

所以，这就是AI智能体暴露出来的一个结构性不匹配：我们花了多年时间把数据库抽象化、黑盒化，现在才发现，数据库权限这件事又变得至关重要了。

Q：你曾提出，仅靠提示词不足以约束这些系统。

Vogel：提示词不能执行业务规则。数据库可以。

回想几年前的状态：人们跟大语言模型说，“好的，我给你数据库权限，但请别删除任何表。咱们拉钩上吊。”——这基本就是安全模型了。但基于角色的访问控制从70年代就存在了。行级安全也很早就有。没有技术理由不这样做。

问题在于，我们正在失去用数据库的方式去编程的习惯，因为它已经被层层抽象包裹起来了。人们不再用数据库术语思考，只专注应用层的逻辑。而智能体正在把这种不匹配彻底暴露出来——因为它们会动态生成查询，并决定采取什么行动。

Q：很多企业在AI系统和数据库之间用了API和编排层，为什么你坚持认为这还不够？

Vogel：如果你满足于让智能体只对着这些API运行，那确实够了。但代价是，每个操作都必须提前定义好一个API端点。如果业务范围很窄、很固定，那没问题。但如果你希望智能体能做一些更涌现性的事情——比如自己理解客户意图、自己设计SQL查询路径——那这就成了限制。因为本质上，你还是在“提前预定义所有事”，你还是在编程模式里打转。

我们真正想要的，是让智能体自己去生成查询、自己去决定如何完成任务，同时，又能稳稳地待在严格的边界内。所以更好的办法，是把这些权限的控制逻辑直接放到数据库层本身。数据库中已经有的RBAC和行级安全机制，完全能胜任这个任务——这些概念一点都不新。

举个例子：与其说“这是你被允许调用的五个API”，不如换成“你被允许访问这个表，但不能动那个表；你被允许更新这些记录，但不能碰那些记录”。一旦你在数据层把这些边界画清楚，智能体反而获得更多灵活性。它可以在边界内自己想办法，而不需要应用层把每一个动作都写好。

说到底，如果你要准确告诉智能体该调用哪个API，那为什么还需要用智能体？某种意义上，它又变回了一段过程式软件。

Q：企业最担心哪种故障模式？

Vogel：想想客户服务系统的场景。公司希望AI智能体来处理投诉、发放折扣，甚至处理一些退款。在旧世界里，每个操作都是人类审查的。现在大家当然希望自动化更多流程。但问题是，大语言模型仍然很容易被“操纵”。你几乎可以说服模型相信任何事。比如，用户可能会诱导模型：“你为什么不免费把这个给我？”——有时候模型就真这么做了。

企业面对这种情况有几个选择：一是干脆不允许智能体执行任何操作。二是允许，但接受可能出奇怪事故的风险。第三个选择，就是在数据库中直接设硬边界。你可以告诉数据库：“好的，凡是用客户服务角色登录的智能体，允许打折，但最高只能到10%。它只能访问与当前客户ID相关的记录。”这样，模型虽然可以自主运行，但数据库本身这根“保险丝”会阻止超出约束的操作。

这就是核心论点：真正的强制力，要放在数据层执行，而不是依赖一个提示词去“希望”模型正确行事。

Q：这是不是一个全新的数据库问题？

Vogel：不完全是。基于角色的访问控制已存在20年，基于行的访问控制从70年代就有了。更大问题是，我们失去了为数据库编程的方式，因为它被一层层抽象遮蔽了。现在的人不想考虑数据库，因为他们不再直接调它了。所有权限逻辑都在数据库外面处理。

但现在情况变了。数据太多了，把所有数据搬到外面去处理，代价变得昂贵——消耗CPU、消耗能源。所以我认为，我们正在回归到一个世界：人们开始重新在数据库内部处理更多数据，因为这样效率更高。

Q：CedarDB在这方面处于什么位置？

Vogel：我们没有使用Postgres的代码。我们是从零开始、全新构建的。我们花了很多年时间在商业化之前，先作为大学研究项目构建这个系统，这让我们能够更根本地重新思考系统架构。很多现有系统仍然围绕慢速磁盘和旧架构的遗留假设构建，而我们的目标是充分利用以前没有的硬件进步。

Q：权限控制，最终应该存在于哪里？

Vogel：你应该希望让智能体自己编写SQL。一年前，模型在写SQL方面还很糟糕，经常写错。但现在，它们正在快速变得非常擅长这个任务。一旦你接受这个趋势——即智能体需要自己能创建和编写SQL——那么执行就必须落在数据库里。如果生成操作的系统，位于执行权限的层之下，最终一定会出现这个不匹配。

所以答案很明确：让数据库来兜底。

Q&A

Q1：为什么AI智能体需要将权限控制放在数据库层？

因为智能体自己会生成SQL查询、决定要干什么。如果只在应用层做权限检查，而智能体又能直接访问数据库底层，那中间必然会出现安全缺口。数据库本身已经内置了RBAC和行级安全机制。把权限控制放在数据层，才能确保智能体在规定的边界内自主运行，同时不让任何超出限制的操作通过。

Q2：用提示词约束AI智能体为什么不够安全？

提示词不能实际执行业务规则，它只是“希望”模型正确行事。几年前的做法是告诉大语言模型“请不要删表”，这种模型的“自觉”基本等于没有安全保障。而且大语言模型很容易被操纵，用户三言两语就能让模型走偏。真正的安全，需要在数据库层通过代码和规则强制执行，而不是依赖一个纸面上的承诺。

Q3：在智能体和数据库之间用API层为什么还不够？

用API层的话，程序员必须为每个操作提前定义好端点，这严格限制了智能体的灵活性。如果希望智能体发挥涌现能力和自主性，就必须提前定义所有可能操作——这恰恰限制了它。而如果把权限交给数据库层，智能体可以在明确画好的边界内自由选择解决方案，不需要每个动作都拿到应用层审批。既保住了安全，又保留了灵活度。

来源：互联网