把安全代理接进统一入口：Gemini Enterprise 如何编排身份、数据与 AI 防线

预计阅读时间：11 分钟

攻击者正在用 AI 加快漏洞利用、钓鱼和横向移动，防守方真正稀缺的却不只是模型能力，而是散落在身份、终端、网络、云、数据和应用系统里的企业上下文。Google Cloud 正在扩展 Gemini Enterprise 的安全生态，把合作伙伴提供的安全代理与 AI 运行时防护带进同一个交互和编排入口。

这件事的价值并不是“用聊天窗口替代所有控制台”，而是让调查、决策、审批和处置共享同一份上下文，同时保留最小权限、人工确认和审计证据。

两类能力解决的是不同问题

这批合作伙伴能力大致可以分为两组，但两者并非完全互斥。

1. 供安全团队直接调用的专业代理

这类代理把自然语言意图转换成查询、调查或受控操作。例如：

Britive 的紧急终止代理可以确认被入侵的人员或非人员身份、列出活跃特权会话，并在人工批准后撤销会话、禁用身份和收集审计上下文。
Qualys ROCky 可根据现有 Qualys 权限回答 Log4Shell 暴露面、修复优先级和 CISA KEV 时限等问题，并支持准备或部署补丁。
Ping Identity 提供面向员工的 MFA 重置和设备恢复自助能力，通过委托认证减少帮助台工单。
Fastly AEDA 将企业自身遥测与匿名化的全球威胁情报结合，用于调查边缘和基础设施异常。
Endor Labs、Snyk 分别把应用安全发现的分类、可利用性判断，以及 AI 生成代码和依赖项检查带进开发流程。
Exabeam、Splunk、CrowdStrike 将行为分析、遥测、调查和响应连接起来，帮助 SOC 编排跨工具流程。
Zscaler Risk360 汇总零信任信号，量化风险与潜在财务影响，并给出处置建议。

关键变化是：分析人员不必先记住每个产品的查询语言和菜单位置，而可以从“这个账号是否仍有特权会话”或“哪些 Log4Shell 风险应该今天修复”这样的业务问题开始。

不过，自然语言只是入口，不应成为授权依据。真正执行动作时，仍需要稳定的资源标识、调用者权限、审批状态和可验证的策略结果。

2. 保护 AI 与代理工作负载的防线

另一组产品关注代理本身可能带来的新风险：提示注入、敏感数据泄露、越权调用、恶意工具使用，以及无法识别的代理流量。

Check Point、CrowdStrike、Fortinet 和 Menlo Security 提供 AI 工作负载发现、风险监控、提示注入检测、数据泄露防护及运行时控制。
Cyberhaven、Cyera 和 Thales 把数据分类、数据血缘、机器身份、委托权限和细粒度访问策略结合起来，判断代理是否有权接触或传递敏感数据。
Obsidian Security 与 Palo Alto Networks 帮助发现云和 AI 环境中的代理、过高权限、治理缺口及隐藏风险。
Transmit Security 识别访问客户应用的代理活动及其来源和意图，从而区分合法委托与恶意自动化。
Acalvio ShadowPlex 使用网络诱饵、蜜罐账号、RAG 诱饵和 honeytoken 捕获未经授权的交互。

这种防护不能只放在模型前面。一个完整控制面至少应覆盖输入提示、检索数据、工具调用、模型输出、代理间通信和最终副作用。

从一句指令到可审计处置

以“隔离疑似失陷的服务账号”为例，一个可靠流程不应该直接把自然语言映射成禁用命令。更稳妥的步骤是：

将账号名称解析为不可歧义的身份 ID。
查询活跃会话、特权、近期行为和相关告警。
生成拟执行计划，标出业务影响和回滚方式。
要求具备相应角色的人员批准高风险动作。
撤销会话、禁用身份或降低权限。
将请求者、审批人、证据、工具结果和时间写入事件记录。

下面是一个供应商中立的示意工作流。字段是假设设计，不代表 Gemini Enterprise 或任何合作伙伴的真实 API；可以将其中的 connector 和动作名称替换为组织已经部署的连接器。

apiVersion: security.example/v1alpha1
kind: AgentWorkflow
metadata:
  name: contain-compromised-identity
spec:
  input:
    required:
      - identity_id
      - incident_id
  executionIdentity:
    mode: delegated
    maxPrivilege: identity-containment
    ttl: 15m
  steps:
    - id: resolve
      connector: identity-directory
      action: getIdentityByImmutableId
      with:
        id: ${input.identity_id}

    - id: inspect
      connector: privileged-access
      action: listActiveSessions
      with:
        identity: ${steps.resolve.output.id}

    - id: plan
      action: generateContainmentPlan
      readOnly: true

    - id: approve
      action: requireHumanApproval
      policy:
        approverRole: incident-commander
        expiresIn: 10m
        show:
          - steps.inspect.output
          - steps.plan.output

    - id: revoke
      connector: privileged-access
      action: revokeSessions
      when: ${steps.approve.output.approved == true}

    - id: disable
      connector: identity-directory
      action: disableIdentity
      when: ${steps.approve.output.approved == true}

    - id: record
      connector: incident-management
      action: appendEvidence
      always: true
      with:
        incident: ${input.incident_id}

还可以在真正调用连接器前设置一个本地策略门。下面的 Bash 示例可以直接运行，依赖 jq；它只模拟审批检查，不会连接或修改任何生产系统。

#!/usr/bin/env bash
set -euo pipefail

command -v jq >/dev/null || {
  echo 'This example requires jq.' >&2
  exit 1
}

cat > containment-request.json <<'JSON'
{
  "incident_id": "INC-2048",
  "identity_id": "svc-prod-deployer-01",
  "action": "revoke_sessions_and_disable",
  "risk": "critical",
  "approval": {
    "approved": true,
    "approver_role": "incident-commander",
    "ticket": "CHG-8821"
  }
}
JSON

jq -e '
  .identity_id != null and
  .incident_id != null and
  .action == "revoke_sessions_and_disable" and
  .approval.approved == true and
  .approval.approver_role == "incident-commander" and
  (.approval.ticket | length > 0)
' containment-request.json >/dev/null || {
  echo 'DENY: missing identity, approval, role, or change ticket' >&2
  exit 1
}

echo 'ALLOW: policy gate passed; hand request to the approved connector'
jq '{incident_id, identity_id, action, approval}' containment-request.json

生产实现还应校验审批是否过期、审批人是否与请求者分离、身份是否属于关键系统，以及连接器返回的实际变更是否与计划一致。不要让模型自己声称“已经完成”；必须以目标系统的响应和后续查询作为成功证据。

统一入口不等于统一信任

多代理编排扩大了效率，也扩大了故障和攻击的传播半径。接入合作伙伴代理时，应重点检查以下边界。

权限边界

读取告警的代理不应默认拥有封禁账号、部署补丁或修改网络策略的权限。为每个动作建立单独的服务身份和短期凭据，并把委托范围限制到具体资源、租户和时间窗口。

数据边界

发送给模型的内容可能包含源代码、凭据、客户记录或调查证据。需要在检索和输出阶段实施分类、脱敏与 DLP，并记录代理访问了哪些数据，而不只是记录最终回答。

运行时边界

提示注入可能藏在网页、工单、日志字段、代码注释和 RAG 文档中。外部内容应始终被视为不可信数据，不能因为它被模型读取，就自动变成系统指令或工具参数。

审计边界

一条完整审计链至少要包含：原始请求、解析后的目标、采用的证据、策略判定、审批记录、工具调用参数、目标系统响应和回滚结果。敏感值可以哈希或脱敏，但不能只保存一段自然语言摘要。

落地时从窄而高价值的流程开始

不要一开始就建设一个能自动处理所有安全事件的“超级代理”。更现实的采用顺序是：

先接入只读调查，例如漏洞暴露查询、风险汇总或会话枚举。
再加入可预览、可审批、可回滚的单一动作。
用独立日志验证代理报告与目标系统状态是否一致。
对提示注入、连接器超时、权限不足、重复执行和审批过期进行故障演练。
同时衡量平均发现时间、平均控制时间、误操作率、人工复核量和回滚成功率。

Gemini Enterprise 的合作伙伴生态展示了一种值得关注的架构方向：以统一界面承载多产品上下文，再通过专业代理完成多步安全工作流。真正决定它能否进入生产环境的，不是对话是否流畅，而是每一步能否做到权限可限、动作可批、数据可控、结果可证。