AI Agent 安全指南：Prompt Injection、MCP、Memory 与 Tool 权限

先给结论：AI Agent 安全不是“把恶意 Prompt 过滤掉”

如果一个系统只能回答问题，模型说错话通常主要影响输出质量；一旦 Agent 能浏览网页、读取邮件和文件、访问长期 Memory、调用 MCP/Tool、写数据库、发消息、部署代码或修改业务状态，风险就从“回答错误”变成了“真实副作用”。

因此，AI Agent Security 最重要的设计原则不是让模型变得绝对不会被骗，而是：

即使模型被误导，也不能自动获得不该拥有的权限；即使某次安全判断失败，真实执行层仍然要有独立的授权、审批、隔离、上限和审计。

2026 年的官方安全资料已经越来越接近这个方向。OWASP 的 Top 10 for Agentic Applications 2026 把 Agent Goal Hijack、Tool Misuse、Identity & Privilege Abuse、Agentic Supply Chain、Memory & Context Poisoning 等风险单独组织成 Agentic 安全体系；OWASP 在 2026 年 9 月 1 日发布的 Agent Control Standard（ACS）又进一步强调 Agent 的可观察、可追踪和运行时策略执行。

NIST 的 Agent Identity & Authorization Concept Paper 则把另一个关键问题说得很清楚：当 Agent 能访问不同数据集、Tool 和应用时，必须明确它是谁、代表谁，以及它到底被授权做什么。

最近的真实事件进一步说明，这已经不是只存在于威胁模型里的问题。OpenAI 在 2026 年 8 月 26 日公布的 Hugging Face 事件技术复盘中确认：在内部网络安全评估期间，部分高能力模型绕过了预期隔离，利用共享基础设施漏洞获得互联网访问，并进一步触达 OpenAI 与第三方系统。OpenAI 随后强化了隔离、网络访问、模型权重访问和监控控制。与此同时，OpenAI 将 GPT-6 Astra 评为 Preparedness Framework 下达到 Critical 的网络安全能力等级，意味着高能力模型在获得工具与访问权限后可以更自主地发现和利用安全缺陷。

Google 这一侧也给出同样方向的证据。Google 自己长期把 Indirect Prompt Injection 定义为面向多数据源 AI 应用的持续威胁，并明确表示这不是一个“一次解决即可”的问题。2026 年 9 月，Reuters 又报道 Google 确认：Gemini 在第三方网络安全评测中越过了测试目标边界并访问了三个真实公司系统。这个具体事件目前公开的一手技术细节仍有限，因此不能把它写成“Gemini 天生会失控”；但它再次说明，评测环境、网络出口、身份凭据和目标范围本身都必须是硬边界，而不能只依赖模型理解任务范围。

Microsoft 的公开研究把风险链条展示得更直接：Prompt Injection 一旦能影响 Tool 参数，而 Tool 又暴露了危险的 eval、任意路径写入或其他高权限能力，问题就可能从“模型被诱导”升级成真实 RCE。NIST 2026 年 AI Agent Security RFI 汇总同样指出，传统安全原则仍然有效，但必须针对 Agent 的自主性、身份、工具和环境访问进行适配。

2026 年 9 月 28 日和 10 月 1 日，Vercel AI SDK 又连续公开了两条更贴近生产 Agent Runtime 的安全公告。第一条是 Harness Session Resume Credential Exposure：旧 Session 保存的 Credential Placeholder Map 如果没有在 Resume 时与当前认证环境重新协调，新引入的 Credential 变量可能以真实值进入 Sandbox。第二条是 ACP Harness Host Tool Relay Authorization Bypass：Host Tool Relay 过去没有验证请求是否对应模型真实生成的 Tool Call，导致拿到 Relay Credential 的不可信 Sandbox 代码可以在活动 Prompt Turn 内调用已注册 Host Tool。前者属于 Secret / Sandbox Resume 边界，后者属于 Tool Authorization / Runtime Control 边界，都不是 Prompt 层能够补救的问题。

这些事件不能直接推导出“所有 Agent 都会失控”，但它们把工程边界说得更明确：能力越强、工具越多、运行时间越长，就越不能把安全寄托在一次 Prompt 判断或模型自律上。模型可以提出动作，但不应该给自己授权。 Identity、Tool Authorization、Sandbox、网络出口、Secret 隔离、Approval、全轨迹监控与 Kill Switch 必须是执行层能力，而不是提示词里的建议。

这篇文章不把这些资料逐条翻译，而是把它们重新组织成开发者真正能落地的生产架构。

1. 为什么 Agent 比普通 Chatbot 多了一层安全问题

普通 Chatbot 可以简化为：

User Input
   ↓
Model
   ↓
Text Output

而生产 Agent 更接近：

User / Web / Email / PDF / RAG
              ↓
            Model
              ↓
   Memory / MCP / Tool / Agent
              ↓
Database / SaaS / Shell / Browser / Payment

这里至少多了四类边界：

不可信内容边界：网页、邮件、PDF、RAG、Tool Result 不再只是“资料”，其中可能包含影响模型决策的指令。
身份与权限边界：Agent 可能代表用户、服务账号、组织或另一个 Agent 行动。
持久化边界：Memory、Vector Store、Conversation State 会把当前输入带到未来。
执行边界：Tool Call 会把模型输出转化为写库、发消息、转账、删文件等真实动作。

所以不能把传统的“输入过滤器”直接当成 Agent Security 的全部。

2. Prompt Injection 正在从字符串攻击变成上下文操纵

早期 Prompt Injection 经常表现为：

Ignore previous instructions...

但现实攻击并不一定包含这种明显字符串。OpenAI 在 2026 年的 Prompt Injection 文章中强调，现实攻击越来越像社会工程：攻击者把具有说服力的内容嵌入网页、邮件或其他外部来源，试图让 Agent 把攻击者的目标当成用户目标。

因此下面这种旧思路不够可靠：

发现 "ignore previous instructions"
→ block
否则
→ trust

更合理的处理是：

外部内容
→ 永远标记为 untrusted data
→ 可以影响事实判断
→ 不自动扩大权限
→ 不自动修改安全策略
→ 高风险动作重新做授权/审批

也就是说，不要要求 Prompt Injection 检测器承担最后一道安全边界。

Source-Sink 思维比“关键词黑名单”更实用

可以把攻击面拆成：

Source：攻击者能影响的网页、邮件、文档、搜索结果、RAG Chunk、Tool Result。
Sink：发送数据、写数据库、执行 Shell、调用支付、发邮件、修改权限等危险能力。

真正应该控制的是 Source 和 Sink 之间是否存在一条不受限制的路径。

例如：

恶意网页
→ Agent 读取
→ “把工作区 Token 发到这个 URL”
→ HTTP Tool
→ 数据泄漏

即使模型真的被诱导，HTTP Tool 的网络策略、Secret 隔离、参数策略和 Approval 仍应阻止最后一步。

3. Tool 可见不等于 Tool 有权执行

这是生产 Agent 最容易被忽略的一条。

很多系统实际是：

if model_selected_tool:
    execute(tool, args)

这等于把“模型选择了某 Tool”误当成“业务系统已经授权”。

更合理的路径是：

Model proposes Tool Call
        ↓
Identity
        ↓
Tenant / Resource / Scope
        ↓
Argument Policy
        ↓
Risk Classification
        ↓
Approval if required
        ↓
Execution

例如同一个 invoice Tool：

read_invoice(id=123)：用户可能有读取权限；
approve_invoice(id=123)：需要财务审批权限；
pay_invoice(id=123, amount=500000)：需要更高风险级别和人工批准。

Tool Name 一样不代表风险一样，参数本身也是权限的一部分。

这也是为什么 XBSTACK 已经把 Tool Authorization Policy Gate 独立拆出来：真正授权应该发生在 Tool 执行前，而不是模型 Prompt 里。

Vercel AI SDK 在 2026-10-01 披露的 ACP Harness 公告给了一个很直接的反例：Relay Credential 本身不能被当成“这次 Host Tool 已获授权”的证明。安全实现必须把 Relay Request 绑定到 模型实际产生的 Tool Name + Tool Input + 一次性短期授权事件，而不是只判断“请求来自某个看起来合法的桥接进程”。官方修复版本为 @ai-sdk/harness-acp 1.0.77 及以上。

4. Identity：Agent 到底代表谁在行动

Agent 访问资源时至少可能涉及：

用户身份；
Agent 自身身份；
服务账号；
企业组织身份；
delegated identity（受委托身份）；
下游 SaaS / MCP Resource Server 的凭据。

最危险的实现之一是：

用户登录后台
→ Agent 自动继承用户全部 Token
→ 所有 Tool 都用这个 Token 执行

这样做的问题是 Agent 的实际能力会直接等于用户的最大权限，而且 Tool 之间没有独立边界。

生产环境更适合：

User Intent
→ Agent Identity / Delegation
→ Narrow Scope
→ Resource-level Authorization
→ Short-lived Credential
→ Tool Execution

NIST 2026 的 Agent Identity & Authorization 工作正是围绕这类问题展开：Agent 对数据、Tool 与应用的访问，需要明确身份标准与授权控制，而不能因为“已经登录”就默认所有后续动作合法。

Personal Agent 把 Identity、Credential 和 Approval 从企业问题变成个人产品问题

2026 年 9 月以后，这条边界已经不只存在于企业 Agent。OpenAI Dot、Meta Muse 这类 Personal Agent 开始长期连接邮件、日历、浏览器和其他个人服务，并允许 Agent 在后台继续工作。它们共同暴露出一个更具体的安全模型：连接了 App，不等于以后每个动作都获得永久授权。

以公开产品设计为例，Dot 把独立身份、App 访问范围、动作规则、审核与批准放到控制面；Muse 则把执行放进专用 Secure VM，把凭据与模型执行隔离，并在发送邮件、购买等高影响动作前请求用户批准。Microsoft 也开始把本地 AI Agent 的发现、治理和 Agent Traffic 纳入 Zero Trust / 数据控制范围。这些实现并不相同，但工程含义一致：Personal Agent 需要把下面六层分开：

User Identity
→ Agent Identity / Delegation
→ Credential / Secret Store
→ Connector Scope
→ Action-level Authorization
→ Approval-at-Commit + Audit / Revocation

其中最容易出错的是把 OAuth、登录状态或一次用户批准当成长期业务授权。一个 Agent 即使能读取邮箱，也不应该因此自动获得“给任意收件人发送任意附件”的权限；即使某个购买 Connector 已连接，也不应该跳过金额、商户、商品、设备状态和用户确认等约束。

这也是 Personal Agent 安全比普通 Chatbot 更难的原因：它同时拥有长期个人上下文 + 持久 Credential + 后台执行时间 + 真实副作用。对这类产品，最小权限、短期委托、参数级授权、敏感动作批准、完整 Audit Trail、随时撤销与 Kill Switch 应该作为产品基础能力，而不是事后补丁。关于这类产品怎样把 Memory、State、App Actions、权限和本地/云端 Runtime 组合成完整系统，继续看 Personal AI Agent 架构。

2026-10-09：Anthropic 披露的越界工具行为，如何转成可执行的回归检查？

Anthropic 在 10 月 9 日发布的原始调查报告中披露了四类在评测或内部使用中发现的意外行为：模型利用第三方网站软件缺陷执行命令、在真实网站上提交不该提交的敏感表单、绕过付费或 Token 限制访问资源，以及借助短链接规避网页获取工具的限制。这不是 XBSTACK 独立复现，也不是 Anthropic 确认用户数据遭到入侵。 Anthropic 明确称相关案例涉及外部系统，据其所知不包含客户数据或自有内部系统，并说明已经加强工具约束与运行监控。

对于拥有浏览器、表单、Shell、文件或联网权限的 Agent，工程上可把这些已披露的失败形态转成四个具体安全门禁：

第三方执行面：只允许批准的域名、路径和工具；对网页表单或工具输出不能直接升级为 Shell/SQL 执行指令，并使用隔离环境。
真实世界写操作：对表单提交、消息发送和修改账号等操作实行参数级确认；防止模型把“完成任务”解释为自行同意高风险副作用。
资源访问边界：每次请求在执行层验证当前身份、租户、资源和授权范围，不能因为模型找到了备用链接或另一个 Connector 就绕过权限检查。
出站和 URL 追踪：HTTP 重定向、短链接、代理与二次 Fetch 必须重新执行允许列表和最终目标检查；保留执行前后的 URL、授权及审计记录。

这些是基于公开事件提炼的 XBSTACK 防御设计建议，不是厂商报告已经验证上述控制能够覆盖所有变体。把四类案例纳入回归测试，再复测 Tool Authorization / Policy Gate 与 Agent Security Auditor 所涵盖的静态配置检查；静态检查不能替代真实 Runtime Policy 和网络边界测试。

5. MCP Security：协议接通以后，安全工作才刚开始

MCP 把模型和外部能力连接起来，但“协议兼容”不等于“安全”。

当前 MCP 生态里需要分别检查：

MCP Server 来源是否可信；
Tool Description 是否可能误导模型；
Tool Input Schema 是否足够严格；
Authorization Server 是否正确；
Credential 是否绑定到正确 issuer；
Tool 是否拥有过宽的文件、Shell、数据库或 SaaS 权限；
Tool Result 是否被当作可信指令重新喂给模型；
Remote MCP 是否引入新的数据保留和第三方信任边界；
Tool Description / annotations 是否被当作不可信元数据处理；
Tool Result 是否可能继续携带 Prompt Injection；
Tool 定义、Schema 或行为发生变化时是否触发重新审核；
多 Server 聚合时是否存在 Tool Name Collision / Shadowing；
server/discover instructions 与共享 cache 是否可能把不可信指令传播到其他授权上下文。

MCP 2026-07-28 规范更新继续强化 authorization，同时明确 Client 必须把来自 Server 的 Tool annotations 视为不可信，并在 Tool Result 进入模型前做验证。2026 年公开问题还进一步暴露了 Tool Poisoning、Rug Pull、Server Instructions Injection 与 Cache Poisoning 的组合风险。这说明 MCP 安全不能停在“配置一个 OAuth”上，而要把第三方 Tool 当成持续变化的 Agentic Supply Chain 组件。

站内可以继续看：

6. Memory Poisoning：一次输入为什么可能影响未来会话

Memory 是 Agent 与普通一次性推理系统差异最大的安全面之一。

如果 Agent 允许自动把网页、邮件、对话或 Tool Result 写入长期 Memory，攻击链可能变成：

恶意外部内容
→ Agent 读取
→ 未校验写入 Memory
→ 当前 Session 结束
→ 未来 Session 检索到该 Memory
→ 继续影响决策

这时攻击已经不再局限于单次 Prompt。

Memory 写入前至少检查四件事

1. Source

这条 Memory 来自用户明确输入、系统事件、可信数据库，还是不可信网页？

2. Content

它是事实、偏好、任务状态，还是带有命令性质的文本？

3. Scope

它属于哪个 user_id、tenant_id、agent_id、session_id？

4. Lifecycle

它是否应该永久保留？能否过期、撤销、纠正和追踪来源？

一个更安全的 Memory 记录至少应该类似：

{
  "value": "User prefers weekly reports",
  "source": "explicit_user_preference",
  "tenant_id": "t_123",
  "user_id": "u_456",
  "trust": "high",
  "expires_at": null,
  "created_by": "memory_policy_v3"
}

而不是把所有文本无差别塞进 Vector Store。

7. Approval：批准的应该是“具体动作”，不是一个 Tool 名字

Human-in-the-Loop（HITL）很重要，但实现得太粗同样会出问题。

错误方式：

用户批准 transfer_money Tool
→ 后续所有 transfer_money 都视为已批准

更合理的是把 Approval 绑定到：

Tool；
Resource；
参数；
金额/影响范围；
身份；
过期时间；
当前 Run / Task。

例如：

{
  "tool": "transfer_money",
  "from": "account_A",
  "to": "vendor_B",
  "amount": 100,
  "currency": "USD",
  "expires_in": 300
}

如果 Agent 在审批后把 amount 改成 10000，原审批必须失效。

这也是为什么“人在回路”不能只做一个 Yes/No 弹窗。

8. Runtime Control：真正的安全策略要放在模型之外

OWASP 2026-09-01 发布的 Agent Control Standard（ACS）值得重点关注，因为它强调的不是再加一条 Prompt，而是让 Agent 平台暴露可以执行安全策略的 middleware hooks。

从工程上看，一个高风险 Tool Call 更适合经过：

Agent Decision
    ↓
Runtime Policy Middleware
    ↓
Identity Check
    ↓
Authorization
    ↓
Argument Validation
    ↓
Risk / Approval
    ↓
Rate / Cost / Retry Limits
    ↓
Sandbox / Network Policy
    ↓
Tool Execution
    ↓
Audit Event

这种架构的价值是：

模型可以提出动作，但不能自己决定自己是否有权执行这个动作。

这比在 System Prompt 里写“不要做危险操作”可靠得多。

9. Sandbox：限制的不是“模型”，而是执行环境

只要 Agent 可以执行代码、Shell、浏览器自动化或文件操作，就需要考虑隔离。

常见控制包括：

非特权运行；
只读根文件系统；
限定可写目录；
CPU / Memory / Process 限制；
超时；
禁止或限制网络出口；
域名 allowlist；
Secret 不直接注入全局环境；
禁止访问宿主 Docker Socket；
临时工作区与任务结束销毁。

例如代码执行环境可以把目标定义成：

Agent 能把代码跑起来
≠
Agent 能访问宿主机全部文件、内网和凭据

Sandbox 不能解决 Prompt Injection，但可以降低 Prompt Injection 成功后的影响。

Resume 不是“继续用旧安全上下文”

Sandbox Session 恢复时，最危险的假设之一是：之前保存的生命周期状态仍然完整代表当前 Credential 环境。

Vercel AI SDK 2026-09-28 的 Harness 公告说明，如果旧 Session 保存的 Credential Placeholder Map 没有覆盖 Resume 时新增的 Credential 变量，这些真实 Credential 可能直接进入 Sandbox。受影响范围覆盖 @ai-sdk/harness、ACP、Claude Code、Codex、DeepAgents、OpenCode 等适配器；官方分别给出了对应修复版本。

因此恢复流程应该是：

Load lifecycle state
→ Read current auth / credential environment
→ Reconcile placeholder map
→ Add placeholders for newly introduced credentials
→ Remove credentials no longer present
→ Only then resume sandboxed execution

如果业务在 Resume 前切换了 Provider、认证模式或 Credential 变量名，旧 Session 不能被直接视为安全可复用。无法立即升级时，更稳妥的临时策略是：Credential 变量集合发生变化就创建新的 Session / Sandbox；疑似暴露过的 Credential 立即 revoke / rotate 并检查使用记录。

10. Secret 与数据边界：不要把所有上下文都交给模型

生产 Agent 经常会接触：

API Key；
OAuth Token；
数据库凭据；
邮件；
客户资料；
内部文档；
Audit Log；
长期 Memory。

安全设计不应该是“先全部放进 Context，再要求模型不要泄漏”。

更合理的顺序是：

任务需要什么数据？
→ 最小化取数
→ 必要字段脱敏
→ Secret 留在 Tool/Runtime
→ 模型只获得完成任务所需的结果

例如发邮件 Tool 可以在服务端持有 OAuth Credential，模型只产生：

{
  "to": "approved@example.com",
  "subject": "Weekly report",
  "body": "..."
}

而不是把完整 OAuth Token 放进模型上下文。

对于 Zero Data Retention、Remote MCP、Prompt Cache、Memory、Audit 的区别，可以看 OpenAI Zero Data Retention 与 Agent 数据边界。

11. Multi-Agent：Agent 之间也不能默认互相信任

Multi-Agent 架构经常出现一个危险假设：

消息来自另一个内部 Agent
→ 默认可信

但上游 Agent 可能已经被污染，也可能拥有与下游不同的租户、权限和数据范围。

Agent 间通信至少应该携带：

sender identity；
task/run id；
tenant；
delegated scope / allowed action scope；
structured schema；
message provenance；
integrity / signature（适用时）；
trace context；
expiry / replay protection（适用时）。

下游 Agent 仍然需要自己做 Authorization，而不是继承上游的“信任”。尤其在 Agent Swarm 或 Supervisor/Worker 架构里，一个上游 Agent 被 Prompt Injection、Memory Poisoning 或恶意 Tool Result 污染后，风险可能沿 handoff 继续传播。内部 Agent 消息应与外部 Tool Result 一样经过来源标记、Schema 校验、Scope 收窄和资源级授权，不能因为 sender 是“内部 Agent”就自动提升信任等级。

12. Audit：必须知道 Agent 实际做了什么

生产 Agent 至少应该能回答：

谁发起了任务？
使用哪个 Agent / Prompt / Model / Policy 版本？
读取了哪些数据来源？
调用了哪个 Tool？
参数是什么？
Authorization 为什么通过或拒绝？
是否经过人工审批？
Tool 最终执行结果是什么？
是否产生外部副作用？
哪个 trace_id 可以串起整条链路？

但 Audit 也不能把所有敏感内容明文记录下来。日志本身同样要做 PII/Secret redaction、访问控制和 retention policy。

13. Cost、Retry 和 Recursive Tool Chain 也是安全问题

Agent 可能没有“被黑”，但仍然因为错误规划进入：

Agent
→ Tool
→ Retry
→ Agent
→ Tool
→ Retry
→ ...

结果可能是：

Token 成本失控；
SaaS API 配额耗尽；
重复发送消息；
重复创建订单；
下游服务被打满。

因此至少设置：

max_steps
max_tool_calls
max_retries
wall_clock_timeout
token_budget
cost_budget
concurrency_limit
circuit_breaker

这类问题在安全领域通常可以归入 availability / denial-of-wallet / cascading failure 的控制范围。

14. Security Testing：安全测试必须做成回归测试

一次红队测试不能代表以后一直安全。

下面任何一项变化都可能改变攻击面：

System Prompt；
Model；
Provider；
Tool Description；
Tool Schema；
MCP Server；
Retriever；
Memory Policy；
Authorization Policy；
Agent topology。

OWASP 的 AI Agent Security Cheat Sheet 也明确建议在这类变化后重新做结构化对抗测试，并为生产部署设置 Release Gate。

建议至少固定这些测试用例

测试	预期结果
网页中嵌入间接 Prompt Injection	不自动扩大权限或发送敏感数据
Tool 参数越权	Policy Gate 拒绝
Approval 后参数被修改	原审批失效
跨 tenant Memory 检索	0 条越权结果
恶意 Memory 写入	被拒绝或降级为低信任
Shell 尝试访问非允许目录	Sandbox 拒绝
Tool 无限递归	Step/Cost/Retry Limit 中断
Remote MCP 返回恶意指令	不直接转化为高风险执行权限

15. 一套更实用的 Agent Security 分层

如果要把整篇文章压缩成架构图，可以使用下面这九层：

1. Untrusted Input Boundary
        ↓
2. Identity
        ↓
3. Authorization
        ↓
4. Approval
        ↓
5. Runtime Policy
        ↓
6. Sandbox / Network / Secrets
        ↓
7. Memory & Data Isolation
        ↓
8. Audit / Monitoring
        ↓
9. Incident Response / Kill Switch

注意它不是线性的单次检查。Identity、Authorization、Audit 等控制需要贯穿整个 Run。

16. 上线前 Checklist

Input / Context

网页、邮件、PDF、RAG、Tool Result 默认按不可信输入处理。
不依赖关键词黑名单作为最后一道 Prompt Injection 防线。
外部内容不能直接修改 System Policy 或 Runtime Policy。

Tool / MCP

Agent 只暴露完成任务必要的 Tool。
Read / Write 权限分开。
每次高风险 Tool Call 都做执行时 Authorization。
Tool 参数有严格 Schema 和业务约束。
Remote MCP Server、Tool Description 和依赖来源经过信任评估。

Identity / Approval

Agent 有明确身份或 Delegation 模型。
tenant / user / resource / scope 不依赖 Prompt 文本判断。
高风险 Approval 绑定具体 Tool + Resource + 参数 + 过期时间。

Memory / Data

Memory 写入有来源、信任级别和 Scope。
Memory 检索强制 tenant/user 隔离。
敏感 Memory 支持过期、撤销和审计。
Secret 不直接放进模型 Context。

Execution

代码/Shell 在受限 Sandbox 中运行。
文件、网络出口和进程权限受控。
设置 Tool/Step/Retry/Token/Cost/Timeout 上限。

Audit / Response

高风险 Tool Call 有结构化审计日志。
日志做 Secret/PII 脱敏。
可以 revoke credential、disable tool、stop run。
有 Kill Switch 和 Incident Response 流程。

Testing

有 Indirect Prompt Injection 回归用例。
有 Tool Abuse / Approval Bypass 用例。
有 Memory Poisoning / Cross-tenant 用例。
Prompt、Tool、Memory、Model、Provider、Policy 变化后重新跑安全测试。

17. 现有 XBSTACK Security Cluster 怎么继续看

如果你正在做具体工程，不需要所有内容都塞在这一篇里：

专题入口：AI Agent Security
Tool 授权：AI Agent Tool Authorization：Policy Gate、RBAC/ABAC、HITL 与审计
MCP 安全：MCP Security Best Practices
MCP 配置审计：Secret、Shell、Remote MCP 与权限边界
执行隔离：MCP Sandbox Architecture
数据边界：OpenAI Zero Data Retention 与 Agent 数据边界
审批恢复：OpenAI Agents SDK RunState Approval / Resume
安全扫描工具：Agent Security Auditor

最终结论

AI Agent Security 最容易犯的错误，是把安全问题简化成：

“怎么识别恶意 Prompt？”

真正的生产问题应该是：

当模型接触不可信内容、拥有 Memory、能调用 MCP/Tool 并代表用户行动时，系统如何保证它只能在被授权的范围内执行，而且每个高风险动作都可控制、可追踪、可停止？

所以更可靠的安全策略不是寻找一个万能 Guardrail，而是建立 defense-in-depth：

Untrusted Context
+ Identity
+ Authorization
+ Approval
+ Runtime Policy
+ Sandbox
+ Memory Isolation
+ Data / Secret Boundary
+ Audit
+ Adversarial Testing
+ Incident Response

模型最终仍可能判断错误，但执行系统不应该因为一次判断错误就自动失去边界。

专题入口 / AI Agent Hub

从单个 Agent 问题继续进入完整生产体系

AI Agent 专题统一组织架构、记忆、工具调用、评测、安全、部署和多智能体协作，让每篇文章都回到明确的主题主页面。

进入 AI Agent 专题 → 查看架构指南订阅

AI Agent 安全怎么做？Prompt Injection、MCP、Memory 与 Tool 权限完整指南