给AI代理行动权限有什么风险，你如何安全地限制它？

Question

Accepted Answer

一旦代理能够**行动** — 删除文件、运行shell命令、调用外部API、花费金钱 — 它的错误（或恶意prompt）就会产生现实世界的后果。防御方法是**最小权限plus批准闸门plus隔离**：只给予它需要的权限、对任何不可逆操作要求确认、在无法造成持久伤害的地方运行它。

## 风险

```text
- DESTRUCTIVE actions  → rm -rf, DROP TABLE, force-push → irreversible data loss
- ARBITRARY shell      → run anything → privilege escalation, exfiltration
- EXTERNAL APIs/$$     → send emails, place orders, spend on cloud/LLM tokens
- SECRET exposure      → leak API keys / .env / tokens into logs or outbound calls
- PROMPT INJECTION     → untrusted input (a web page, an issue) hijacks the agent
```

Prompt注入是最锋利的一刃：代理*读取*的内容可能包含指令，所以代理能调用的任何工具都可被控制该内容的攻击者利用。

## 防护措施

```text
- LEAST PRIVILEGE / ALLOWLIST → only pre-approved commands & paths; deny by default
- APPROVAL FOR DESTRUCTIVE    → human confirms deletes, payments, prod writes
- SANDBOX / DRY-RUN           → preview the action; isolated container, no prod creds
- ISOLATED ENVIRONMENT        → ephemeral VM/branch; blast radius = throwaway box
- AUDIT LOGS                  → record every tool call + args for review
- NO SECRETS IN CONTEXT       → inject via env at runtime; never paste keys into prompts
- NETWORK LIMITS              → egress allowlist; block arbitrary outbound requests
```

```yaml
# Conceptual permission policy
tools:
  read_file:   { allow: true }                 # safe, reversible
  run_shell:   { allow: ["npm test", "git status"] }  # allowlist only
  delete_file: { allow: "ask" }                # human approval required
  send_email:  { allow: "ask", sandbox: true } # dry-run first, then confirm
network:
  egress: ["api.github.com"]                    # everything else blocked
```

这个模式是递进式信任：**读取**是自由的、**可逆写入**成本低廉、**不可逆或外部**操作需要确认、**金钱或生产**需要隔离plus人工审批。

## 为什么这很重要

代理的价值来自让它们行动，但行动正是自信的错误或被劫持的prompt转变为数据删除、密钥泄露或真实扣费的地方。将权限设计为最小权限允许列表、将不可逆操作放在人工批准后面、在带有审计日志的沙箱中运行、以及严格限制secrets和网络出站流量，可以让你获得自主性的杠杆效应，而不用把生产环境押注在模型每次都正确上。