- 背景：当前AI Agent已经很普及了，那么有一个关键地方在于如果使用外部第三方/非官方 Skill和工具，如何保证安全性------AI Agent 真正的安全边界是什么？
别再只防 Prompt Injection：AI Agent 真正危险的是"执行权"
过去讨论 AI Agent 安全，很多人的第一反应仍然是：
Prompt Injection（提示词注入）。
攻击者在网页、邮件、README、MCP Tool Description 里塞一段恶意指令，让模型忽略原来的任务，执行攻击者希望它执行的操作。
这当然是问题。
但当今天的 Agent 已经可以：读取与修改文件、执行 Shell终端命令
访问数据库、调用 SaaS API、连接 MCP Server、下载与加载第三方 Skill和工具、读取 Secret、访问互联网
只盯着 Prompt Injection显然不够。
安全边界都在哪
真正决定一次攻击最终能造成多大损失的，不只是模型会不会被骗？ ，还有模型被骗以后，到底有权限做什么？
这才是 Agent 安全真正应该解决的问题。
Anthropic 在 2026 年讨论 Claude containment 时也把问题明确描述为控制 Agent 的 blast radius（爆炸半径 / 最大损害范围）：模型层的防御是概率性的，而进程 Sandbox（沙箱）、文件系统边界、网络出口控制等环境级机制负责提供更硬的边界。
因此，一个更完整的 Agent 安全模型应该是：多重筛选、硬性兜底（即保证即使执行也没有大影响）
text
┌─ Static Scanner
Skill / MCP / Plugin ┤
└─ Semantic Scanner
↓
Capability Extraction
↓
Capability Manifest
↓
Policy Engine
↓
┌───────────────┼───────────────┐
↓ ↓ ↓
FS Network Secrets
↓ ↓ ↓
Runtime Capability Gateway
↓
Sandbox Runtime
↓
Behavioral Monitor
↓
OTel Trace
↓
Signed AttestationAgent 为什么比普通 Chatbot 危险？
- 传统 Chatbot 模型即使被 Prompt Injection 攻击，很多时候最坏的结果仍然只是：输出错误内容、泄露上下文、违反用户意图
- 但 Agent 不一样。LLM可以自主调用，尤其是给它mode模式权限很大。所以⚠️注意限制它的权限，权限决定即便两个模型被攻击成功的概率完全一样，它们的风险也完全不同。
- Agent 风险估算
compromise 在安全语境里不是"妥协"，而是被攻破、被控制、失陷。P(Compromise)即系统被成功攻击 / Agent 被攻击者操控的概率
Risk≈P(Compromise)×BlastRadius \text{Risk} \approx P(\text{Compromise}) \times \text{BlastRadius} Risk≈P(Compromise)×BlastRadius
传统 Prompt 防御主要在降低第一项P(Compromise)P(\text{Compromise})P(Compromise)，而 Runtime Security（运行时安全）主要是在压低 BlastRadius\text{BlastRadius}BlastRadius
- Agent 越强，Sandbox 和权限模型反而越重要。
Anthropic 也明确指出，模型防御不可能单独承担全部安全责任；外部 Tool、文件、网络和 MCP（Model Context Protocol，模型上下文协议）内容既可能带来传统软件供应链风险，也可能成为 Prompt Injection 的输入渠道。
第一道防线：Static Scanner
- 一个第三方 Skill 进入系统以后，第一件事情不是运行，而是进行开销小的静态扫描，检查：Shell 命令、文件系统访问、网络请求、代码执行、硬编码 Secret、可疑下载地址、依赖包、混淆代码、恶意 Payload、权限提升、系统配置修改
- 现在已经有真实项目在做这件事。如 Cisco 的
skill-scanner组合：
text
YARA / Pattern
+
AST
+
Dataflow Analysis
+
LLM Semantic Analysis
+
Policy其中 AST 是 Abstract Syntax Tree（抽象语法树） ，Dataflow Analysis 是数据流分析。
不只是搜索固定危险字符串 如rm -rf/curl/eval，还试图理解数据流从哪来、怎么处理、到哪去，比如把secret发送到外部网络
- Cisco 自己也明确强调，Scanner 只能提供 best-effort detection（尽力检测），没有发现问题并不等于 Skill 安全 。
不是100%安全，还要进入下一层筛选。
第二道防线：Semantic Scanner
-
Agent Skill 说明**代码不是唯一的可执行逻辑。**因为 LLM 会解释自然语言，并可能执行它。即安全防范还需要理解自然语言意图
-
Snyk Agent Scan 目前已经直接扫描 MCP Server、Tool Description 和 Agent Skill，并检测包括 Prompt Injection、Tool Poisoning、恶意自然语言 Payload、Credential Handling 等风险。
- 但是 Scanner 也不能保证拦截所有危险，因为存在：没发现问题 False Negative、被入侵的 Dependency、Remote MCP 更新、实时生成的指令、动态下载（执行中再下载恶意内容）、Zero-day（都还未定义的新漏洞）
- 所以需要进入下一步安全拦截步骤
第三道防线：Capability Extraction+Capability Manifest
- Capability 可以翻译为能力 / 权限能力。
- Capability Extraction（能力提取）：运行前提取该文件所需的最小权限并配置
- Capability Manifest：让 Skill 主动声明自己需要什么，提取出来以后，最好形成一个标准 Manifest（清单）。例如：
yaml
name: github-reviewer
filesystem:
read:
- "./src/**"
write:
- "./reports/**"
network:
allow:
- "api.github.com"
secrets:
allow:
- "GITHUB_TOKEN"
process:
allow:
- "git"
shell:
enabled: false- 安全系统比较两个集合：Declared Capability和Actual Capability
理想状态必须满足Cactual⊆CallowedC_{\text{actual}} \subseteq C_{\text{allowed}}Cactual⊆Callowed
一旦运行请求权限>声明，Runtime 应该直接DENY拒绝。
第四道防线：Policy Engine
- Manifest 不是权限，只是表示Skill 希望获得这个 Capability。
- 真正决定是否批准的是：Policy Engine，给出的结果可以是DENY、ALLOW、REQUIRE HUMAN APPROVAL（ASK）
- 如果进一步做企业级系统，还可能根据：用户身份、Skill 来源、环境、数据敏感级别、操作风险、时间、资源等，动态决定权限。
权限必须拆开颗粒度
- Capability 的组合可能很危险，每个权限看起来都不起眼。
- 所以安全系统应该至少把权限拆成不同 Domain：
text
Filesystem
Network
Secrets
Process
Shell
Database
Cloud API
Browser
User Interaction- Snyk 现在也已经把类似风险作为组合问题处理：例如同时接触 private data、untrusted content 和 destructive capabilities 会显著放大攻击后果。
第五道防线：Runtime Capability Gateway：真正关键的一层
- 执行阶段中实时拦截------Runtime Capability Gateway，所有敏感操作必须经过它。分别进入对应的Gateway，比如Filesystem/Network Gateway，再进行Policy Check/Egress Policy
第六道防线：Sandbox Runtime
- 不要让不可信代码和宿主机站在同一个权限域：沙箱隔离。Sandbox 可以限制几乎所有细分权限
- Prompt 层的"不要做坏事"和 OS（Operating System，操作系统）层的"你根本没有权限做"不是一个级别的安全保证。
Anthropic 对 Agent containment 的描述也是这个方向：Process Sandbox、VM（Virtual Machine，虚拟机）、Filesystem Boundary 和 Egress Control 用于给 Agent 建立硬边界。
- Runtime Enforcement：Sandbox 还不等于全部，虽然Sandbox 给出了边界，但仍然需要 Runtime Enforcement。
- 进一步细粒度拆分，如允许A还要细拆分为可读/可写/可发送数据到A/可接受来自A的数据，权限继续从资源层面拆分到操作层面
例如：
text
GitHub:
read_repository: allow
create_issue: allow
delete_repository: deny
Git:
status: allow
diff: allow
push: ask- 结论：Capability Security比工具白名单更安全。
监控：Behavioral Monitor
- 为什么需要：每一个单独操作可能都没有直接违反 Policy，但是整体行为明显异常。例如某 Skill 在一分钟内
text
读取 8,000 个文件
访问 200 个域名
连续查询 Secret
启动 50 个进程- 观察：访问模式、调用频率、权限使用、网络目的地、数据流向、进程树、异常失败、策略拒绝，区分为正常/可以/截流/终止/人工确认
- OpenTelemetry Trace：Trace（链路追踪），记录 Trace、Metric 和 Log；其中一个 Trace 由多个 Span 构成，每个 Span 表示一次具体操作。记录对应用户、对应Agent、对应Skill、执行明细、工具调用和相关数据、每个安全层给出的决定、文件系统使用明细、网络明细、异常日志。如
text
Trace ID: xxx
14:03:21 skill loaded
14:03:22 requested GITHUB_TOKEN
14:03:22 policy allowed
14:03:24 POST api.github.com
14:03:26 repository deleted可审计性完全不同。
区分 Trace 和 Attestation
- 这是最后一个容易混淆的概念。
Trace 回答：
运行过程中发生了什么？
Attestation 回答：
你凭什么相信这个 Artifact / Skill / Scan Result 的来源和状态？
- 因为安全层的决策也可以伪造
- Attestation 需要读懂并记录skill、资源、版本、结果、Capability Manifest、来源，给出为什么是这个决定，生成Signed Attestation经过密码学签名的证明。Skill Registry 完全显示为：
text
Skill: github-reviewer
Version: 1.4.2
Digest: sha256:xxxx
Source:
github.com/xxx
Scan:
Cisco Scanner 2.x
PASS
Capabilities:
FS: ./repo/**
Network: api.github.com
Secrets: GITHUB_TOKEN
Attestation:
✓ Signature valid
✓ Provenance valid
✓ Manifest verified最终完整安全模型
每一层解决的问题完全不同：
| 层 | 回答的问题 |
|---|---|
| Scanner | 它看起来有没有危险？ |
| Capability Extraction | 它实际上想使用什么能力？ |
| Manifest | 它声明自己需要什么？ |
| Policy Engine | 我愿意给它什么？ |
| Capability Gateway | 所有敏感操作是否经过控制？ |
| Sandbox | 即使被攻陷，它最多能碰到什么？ |
| Runtime Enforcement | 它现在这个操作允许吗？ |
| Behavioral Monitor | 它整体行为是否异常？ |
| Trace | 它到底做过什么？ |
| Attestation | 我如何证明它是谁、从哪来、经过什么检查？ |
没有哪一层能够单独解决 Agent 安全。
真正应该改变的安全思维
真正成熟的安全模型应该假设：
text
LLM 可能判断错误
Prompt Injection 可能成功
Skill 可能恶意
Dependency 可能失陷
Remote MCP 可能改变
Scanner 可能漏报然后继续问：
即使这些全部发生，系统最多允许攻击者做到什么？
这才是 Runtime Security 真正解决的问题。
Agent Security=Least Privilege+Isolation+Enforcement+Observability+Verifiability\text{Agent Security}= \text{Least Privilege} + \text{Isolation} + \text{Enforcement} + \text{Observability} + \text{Verifiability} Agent Security=Least Privilege+Isolation+Enforcement+Observability+Verifiability
最小权限+隔离+强制执行+可观测性+可验证性
构建一个即使模型犯错、Skill 恶意、Prompt Injection 成功，也能够限制损害范围的系统。