给AI agent生产环境的密钥，这能行吗？

Reddit r/AI_Agents 新闻
ai-agents security cloud-infrastructure iam access-control agent-safety

摘要

一种面向AI agent访问生产云基础设施的安全设计方案，采用拆分凭证和审批门控机制，防止在未经人工批准的情况下执行破坏性操作。

我希望我的openclaw能够使用 `gcloud` / `aws` 操作我的真实云环境。问题在于：我无法100%信任它。如果它误解了我的意图，就可能搞砸事情。但我也并不想逐条命令进行审批…… 设想：将凭证拆分成两个服务账号。 **TIER 1 · 只读** **TIER 2 · 破坏性** ────────────────── ──────────────────── agent: gcloud list agent: gcloud rm │ │ │ (无需审批) ▼ ▼ 审批 [✓][✗] │ │ ▼ ▼ 只读密钥 写入密钥 (容器内) (容器内) │ │ ▼ ▼ cloud · 没问题 cloud · 完成 *agent 从未持有写入密钥——它只能请求使用。* 只读密钥agent可以自由使用——列出、描述、dry-run。如果它尝试使用该密钥执行破坏性操作，云环境将直接返回403。 写入密钥agent本身没有。当它确实需要修改某些内容时，必须请求具体的命令。我会收到通知，批准后，命令会在一个一次性容器中运行，密钥仅在该容器内注入。agent进程永远看不到该密钥。 因此，防护墙是 IAM + 进程边界——而不是一个提醒agent小心的提示词。 这在实际中真的能工作吗？还是我忽略了某些显而易见的问题？
查看原文

相似文章

谁授予了你的AI代理权限？

Reddit r/AI_Agents

讨论AI代理工作流中的安全漏洞，即代理在关键步骤中假设存在人类监督，并提出了一个运行时控制平面，用于强制执行权限，并在破坏性操作前要求人工批准，通过Tandem演示进行了说明。