• 时间:
  • 分类:

部署了一个 AI Agent，给了它调模型的权限、读 S3 的权限、写数据库的权限。上线后发现它在凌晨 3 点自己跑去扫描了一遍 S3 bucket 列表。不是被攻击了，是 Agent「觉得有必要」。怎么防止这种事？

AI Agent 跟传统应用有个根本区别：行为不完全可预测。传统应用写了什么代码就执行什么，Agent 根据 prompt 和上下文动态决策。

所以安全策略不能只靠「审查代码」，需要「运行时约束 + 事后审计」。

这篇讲四个层面的防护方案，全部基于亚马逊云科技的原生服务。

第一层：IAM 最小权限

给 Agent 配专用 IAM Role，权限遵循最小原则。

举例：一个只需要调 Bedrock 推理的 Agent：

{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Action": ["bedrock:InvokeModel"],
        "Resource": "arn:aws-cn:bedrock:*::foundation-model/anthropic.claude-*"
    }]
}

要点：

  • Action 精确到方法（不用 bedrock:*）
  • Resource 精确到模型（不给全部模型访问权）
  • 用 Condition 加区域限制、token 上限
  • 不给 List/Describe 类权限（Agent 不需要「探索」）

第二层：VPC 网络隔离

Agent 运行在私有子网，不暴露公网。通过 VPC Endpoint 访问 Bedrock、S3 等服务：

  • 流量走亚马逊云科技内网，不经过公网
  • Endpoint 可以加 Policy，在网络层做第二道权限过滤
  • 安全组只放行 443 到 Endpoint

好处：即使 Agent 被 prompt injection 攻击尝试访问外部 URL，网络层直接拒绝。

第三层：CloudTrail + CloudWatch 审计

Agent 的每个 API 调用都被 CloudTrail 记录。配合 CloudWatch 做实时告警：

  • 调用频率异常（5 分钟内 > 100 次）→ 告警
  • 非工作时间活动（北京 22:00-06:00）→ 告警
  • 权限拒绝事件（AccessDenied）→ 告警 + 自动暂停

开启 Bedrock Model Invocation Logging，记录每次模型调用的详细信息。

第四层：Bedrock Guardrails

在模型层面加安全策略：

  • 内容过滤：屏蔽不当内容生成
  • 话题限制：只允许讨论业务相关话题
  • PII 检测：自动识别和脱敏个人信息
  • 词汇过滤：自定义禁用词列表

调用时传入 guardrailIdentifier：

response = client.invoke_model(
    modelId='anthropic.claude-3-sonnet-20240229-v1:0',
    guardrailIdentifier='my-guardrail',
    guardrailVersion='1',
    body=request_body
)

四层组合

IAM（权限） + VPC（网络） + CloudTrail（审计） + Guardrails（内容）

每层独立工作，任何一层被绕过，其他层仍然有效。

关键思维

从「信任 Agent 的代码」转向「约束 Agent 的行为」。

Agent 可能做任何它有权限做的事。安全策略要假设它会，然后用技术手段确保它只做你允许的事。

🔗 Amazon Bedrock：https://aws.amazon.com/cn/bedrock/
🔗 Bedrock Guardrails：https://aws.amazon.com/cn/bedrock/guardrails/
🔗 CloudTrail：https://aws.amazon.com/cn/cloudtrail/

标签: none

添加新评论