Oracle 推出 Deep Trust AI 架构，在数据库层约束自主 AI 智能体

Oracle在拉斯维加斯举行的Oracle AI World上发布了Deep Trust AI Architecture。该架构方案将Oracle AI Database、Autonomous AI Database以及APEX AI Application Generator的功能整合在一起。无论哪个应用或哪个AI智能体访问企业数据，安全规则和业务规则都应独立生效。

广告后继续阅读

这背后是一个众所周知的问题。仅在一个应用中实现的规则，只能保护通过该应用进行的访问。而智能体则可以通过Model Context Protocol（MCP）服务器，或借助将自然语言问题转换为SQL的方式，直接访问数据库。此时，仅存储在已被绕过的应用中的检查便不会被执行。MCP只是其中一种可能的访问途径，关键在于控制措施部署在何处。

在数据库中集中执行访问规则和完整性规则已是一项确立的原则。Oracle现将相应机制与面向AI辅助数据访问和应用生成的功能整合为一个共同的架构指导框架。

在数据源处落实身份与业务规则

借助Deep Data Security，管理员应可直接在Oracle AI Database中为用户定义访问规则。据Oracle介绍，数据库会依据来自企业目录的加密签名令牌校验用户身份。在此基础上，数据库决定相应用户可以访问哪些数据。

SQL Assertions为访问控制补充了业务条件。Oracle举例提到超出员工既定限额的支出。相应定义的条件应能阻止数据库接受此类变更，无论提出请求的是传统应用还是AI智能体。

由此，所存规则的遵守不再取决于每个访问应用是否都正确实现了同一项检查。前提仍然是：必要的规则已在数据库中定义，并且对相应访问有效。不过，一个被允许的操作并不因此就自动在业务上合理。

广告后继续阅读

对业务对象的受控访问

对于应用和智能体，Oracle还提供了Deep Trust Data APIs。它们不应再对表执行任意SQL语句，而是应实现对逻辑业务对象的受控读写访问，例如一笔完整的订单。变更规则和数据一致性规则将在数据库中强制执行。

Deep NL2SQL应改进自然语言问题到SQL的转换。为此会纳入企业术语和数据模型信息。用户的更正应在被纳入知识库之前经过验证。

然而，仅有访问控制仍无法保证得到正确的答案。

生成式应用的共同运行时

该架构还包括使用APEXlang进行声明式应用生成。在此过程中，一个AI工具会创建应用描述，由中央APEX运行时执行。由此，共同的功能和保护机制不必为每个生成的应用重新以独立程序代码的形式构建。

另一个层面是软件平台的运行。Oracle为此指向Autonomous AI Database。该服务应自动为底层软件和基础设施栈安装安全更新。因此，该架构方案涵盖四个层面：平台、数据、数据访问和应用开发。

Deep Trust并非某项单独的新服务，而是多项功能协同运作的指导框架。Oracle未给出统一的推出日期或整体价格。因此，具体环境中哪些组件可用、各自有哪些前提条件，必须逐组件核查。

(fo)