通过 Model Context Protocol 确保代理互动安全性的最佳实践

MySQL   |  PostgreSQL   |  SQL Server

预览

此功能受服务专用条款的“通用服务条款”部分中的“非正式版产品条款”的约束。 非正式版功能“按原样”提供，可能只能获得有限的支持。 如需了解详情，请参阅 发布阶段说明。

Model Context Protocol (MCP) 可标准化生成式 AI 智能体与 Cloud SQL for PostgreSQL 的连接方式。 由于自主智能体存在固有风险，因此缓解提示注入等漏洞需要采用责任共担模式，将平台控制机制与安全应用设计相结合。
如需设计和部署使用 Google Cloud Model Context Protocol (MCP) 工具的 AI 应用，请遵循本指南中的最佳实践。

准备工作

使用 MCP 工具时，应用的安全性取决于代理的互动模型。如需了解智能体的使用对将智能体与 MCP 服务器集成相关的安全 风险有何影响，请参阅AI 安全性 。

安全责任

作为客户，您负责智能体平台的安全配置和运行。

遵循最小权限原则

使用具有最小范围的服务帐号运行智能体。这是第一层也是最关键的防御层。

• 专用身份：为每个使用 MCP 工具的唯一智能体或应用创建一个单独的专用服务帐号。请勿重复使用现有 SA，尤其是具有广泛权限的 SA。
• 最小范围：仅向服务帐号授予必要的 Identity and Access Management (IAM) 角色，例如 alloydb.viewer，而不是 alloydb.admin。如果智能体只需要对特定数据集的读取权限，请使用自定义 IAM 角色将访问权限限制为智能体功能所需的绝对最小值。
• 职责分离： 如果智能体既需要对数据的读取权限，又需要对日志或临时存储空间的写入权限，请使用两个单独的服务账号：一个账号用于高风险数据访问权限（范围最小），另一个账号用于低风险操作任务。

使用数据库原生精细控制机制

为了获得最强的防御能力，请将 IAM 角色与数据库本身提供的精细访问权限控制机制相结合。这样可以确保，即使攻击者入侵了智能体的 IAM 令牌，损害范围也会受到数据库引擎内部权限的限制，例如阻止 DROP TABLE 命令。

产品	粒度控制机制	重点
Cloud SQL 和 AlloyDB	数据库级角色，例如 PostgreSQL 和 MySQL 中的 CREATE ROLE。	管理特定数据库实例和架构中的权限。
BigQuery	列级访问权限控制（使用政策标记）	即使在授权表中，也要限制智能体对敏感列（例如 PII）的访问权限。
Spanner	精细访问权限控制（具有 GRANT/REVOKE 的数据库角色）	对表和列强制执行精确的读取/写入/更新权限。
Firestore	IAM 角色和 IAM 条件	使用 IAM 角色和 IAM 条件配置每个数据库的访问权限。
Bigtable	IAM 角色	Bigtable 通过 IAM 角色在项目级层、实例级层和表级层提供精细控制。

安全智能体设计

仅限智能体的模型需要针对提示注入攻击实施强大的应用级防御，此类攻击会尝试替换系统提示。如需了解更多 信息，请参阅 AI 安全性和 安全性。

将数据和用户输入视为不可信

将最终用户的输入或智能体从外部来源（例如网页搜索结果或第三方文档）提取的数据视为不可信。

实现操作选择模式

避免使用开放式 计划和执行 架构，在此类架构中 系统会将高级任务规范与机械执行分离。 请改用限制模型自由度的设计模式。

• 操作选择器模式： 模型的工作仅是将用户请求转换为一小部分预定义的安全函数之一。操作逻辑是硬编码的，无法由 LLM 修改。这有助于使智能体免受针对控制流的注入攻击。
• 双 LLM 模式： 使用执行核心任务的主 LLM（操作 LLM）和预先过滤用户提示以查找恶意意图并事后过滤操作 LLM 的输出以查找未经授权的操作或数据泄露的辅助高安全 LLM（护栏 LLM）。

防止未经授权的工具链接

智能体必须仅调用任务所需的工具。确保编排代码可防止以下情况：

• 动态工具： 智能体不得能够动态注册新工具或更改现有工具的权限。
• 许可名单强制执行： 在智能体的初始系统提示和后端代码中声明智能体可以访问的函数或数据库表的许可名单。如需查看 Gemini CLI 示例，请参阅限制 工具访问权限。

限制多租户数据库中的数据访问权限

execute_sql 等通用工具允许调用方执行数据库查询，这些查询可以读取 IAM 和数据库权限允许访问的任何数据。当您创建在没有人机协同的情况下访问多租户应用中的数据的智能体时，可能需要进一步限制数据访问权限。

为确保智能体只能读取其有权访问的数据的子集，我们建议您使用MCP Toolbox for Databases等框架创建自定义工具。如需了解详情，请参阅预构建工具与自定义工具。

例如，假设您的数据库在 Orders 表中存储所有最终用户的订单。您正在开发一个与用户互动并可以查找用户订单的聊天智能体。聊天智能体有权读取整个 Orders 表，但一个最终用户不得能够请求有关其他用户订单的信息。

在不安全的情况下，您仅为智能体配备 execute_sql 工具，这会带来数据泄露的风险。恶意用户可以诱骗智能体读取和返回其他用户的订单。指示智能体强制执行访问规则通常不足以保护数据。

在安全的情况下，您可以为智能体提供更具体的自定义工具（例如 lookup_active_order），其中查询过滤器中用户的身份是在智能体控制之外设置的。

安全配置

Cloud SQL for PostgreSQL 提供 Model Armor，以在 平台级强制执行安全边界。您必须启用并配置这些设置。

启用 Model Armor

使用 gcloud CLI 在模型部署中启用 Model Armor。这会针对已知攻击途径（例如注入和越狱）激活内置保护机制。

以下示例在 Vertex AI 端点上启用 Model Armor。

# Example: Enable Model Armor on a Vertex AI endpoint
gcloud ai endpoints update ENDPOINT_ID \
    --region=REGION \
    --enable-model-armor

如需了解详情和示例，请参阅为 MCP 配置 Model Armor 保护 Google Cloud。

对敏感数据操作强制执行最低安全阈值

Model Armor 可让您对敏感数据操作（例如个人身份信息 (PII) 检测和去标识化）强制执行最低安全阈值。使用 Sensitive Data Protection DeidentifyTemplate 在将敏感信息返回给用户之前隐去或遮盖敏感信息，即使 模型遭到入侵也是如此。

以下是配置的概念示例：

  # Example: Apply a DeidentifyTemplate to filter PII
gcloud ai endpoints update ENDPOINT_ID \
    --region=REGION \
    --model-armor-config-file=model_armor_config.json

在以下示例中，model_armor_config.json 可能会引用 DLP 模板：

{
  "safety_thresholds": {
    "injection": "HIGH",
    "harmful_content": "MEDIUM"
  },
  "data_protection_config": {
    "dlp_deidentify_template": "projects/PROJECT_NUMBER/locations/LOCATION/deidentifyTemplates/DLP_TEMPLATE_ID"
  }
}

审核和可观测性

了解智能体操作对于事件后分析和检测遭到入侵的智能体至关重要。

实现数据恢复策略

虽然 IAM 和数据库原生角色等分层控制机制旨在防止破坏性操作，但您必须制定恢复计划，以防这些防御机制失效。具有写入权限的遭到入侵或幼稚的智能体（“仅限智能体”风险）可能会被诱骗执行 DROP TABLE 等破坏性命令或损坏数据。

针对这种情况的主要防御措施是制定稳健的恢复策略。

几乎所有 Data Cloud 产品都提供数据恢复功能，无论是通过传统备份、时间点恢复 (PITR) 还是数据快照。 您负责启用和配置这些功能。

产品	备份和恢复机制
Cloud SQL	同时支持按需备份和自动备份，让您可以将实例恢复到之前的状态。它还支持时间点恢复 (PITR)。
AlloyDB	默认提供持续备份和恢复。这支持微秒级 PITR，让您可以将集群恢复到保留期内的任何时间点。
BigQuery	数据恢复通过“时间旅行”实现，让您可以访问和恢复过去 7 天内任何时间点的数据。如需长期保留，您可以创建表快照。
Spanner	同时支持按需备份和 PITR。
Firestore	支持自动备份，让您可以将数据库恢复到之前的状态。它还提供 PITR，以防止意外删除或写入。这两项功能默认处于停用状态。
Bigtable	支持按需备份和自动备份。这些备份是完全托管的，可以恢复到新表。

启用 Cloud Audit Logs

确保为 MCP 以及所有相关 Google Cloud 服务 （例如 BigQuery、Cloud SQL、AlloyDB、Firestore 和 Spanner）启用数据访问 审核日志。默认情况下，仅启用管理员 活动审核日志。数据访问审核日志会记录智能体执行的每项读取和写入操作。如需了解详情，请参阅 MCP 的数据 访问审核日志。

审核敏感操作

在 Cloud Logging 中配置提醒，以检测异常或高风险操作。Logs Explorer 查询会识别在 Firestore 中执行 数据写入 操作的服务账号，例如，这是数据渗漏或破坏性攻击的常见目标：

resource.type="firestore_database"
# Filter for data write operations
AND protoPayload.methodName="google.firestore.v1.Firestore.Commit"
# Ensure the caller is an agent service account (modify regex as needed)
AND protoPayload.authenticationInfo.principalEmail=~".*@.*.gserviceaccount.com"
# Exclude expected system calls to reduce noise
AND NOT protoPayload.authenticationInfo.principalEmail=~"system-managed-service-account"

使用智能体专用日志记录

除了 Cloud Audit Logs 之外，还要确保应用代码记录每个智能体决策的以下数据：

• 工具执行： 所调用的 MCP 工具。
• 原始命令： LLM 生成的确切命令，例如 SQL 查询或文档路径。
• 最终操作： 操作是执行（仅限智能体的模型）还是获得批准（有人参与）。如需了解详情，请参阅了解 智能体使用情况。
• 用户和会话 ID： 发起请求的最终用户的标识符。