企业官网建设流程全解析

• 背景：当前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 安全模型应该是：多重筛选、硬性兜底（即保证即使执行也没有大影响）

┌─ 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 Attestation

Agent 为什么比普通 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组合：

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（清单）。例如：

name:github-reviewerfilesystem: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：

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的数据，权限继续从资源层面拆分到操作层面

例如：

GitHub: read_repository: allow create_issue: allow delete_repository: deny Git: status: allow diff: allow push: ask

• 结论：Capability Security比工具白名单更安全。

监控：Behavioral Monitor

• 为什么需要：每一个单独操作可能都没有直接违反 Policy，但是整体行为明显异常。例如某 Skill 在一分钟内

读取 8,000 个文件 访问 200 个域名 连续查询 Secret 启动 50 个进程

• 观察：访问模式、调用频率、权限使用、网络目的地、数据流向、进程树、异常失败、策略拒绝，区分为正常/可以/截流/终止/人工确认

• OpenTelemetry Trace：Trace（链路追踪），记录 Trace、Metric 和 Log；其中一个 Trace 由多个 Span 构成，每个 Span 表示一次具体操作。记录对应用户、对应Agent、对应Skill、执行明细、工具调用和相关数据、每个安全层给出的决定、文件系统使用明细、网络明细、异常日志。如

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 完全显示为：

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

最终完整安全模型

每一层解决的问题完全不同：

没有哪一层能够单独解决 Agent 安全。

真正应该改变的安全思维

真正成熟的安全模型应该假设：

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 成功，也能够限制损害范围的系统。

大厂方案

• 桌面智能体 WorkBuddy 的多层安全防护实践

1. 沙箱隔离技术（Sandbox）：最基础的技术是沙箱，将 Agent 限制在隔离空间内，限制目录访问、网络、CPU 和内存资源，类似程序员线上服务部署的 Docker 容器，防止单点故障引发全局崩溃。
2. 文件自动备份与无感恢复：针对大模型可能“改错文件”的问题，WorkBuddy 设有文件备份机制。开启后会自动备份修改前的文件，用户不仅能手动查找，还可通过自然语言（如“帮我恢复上一版”）触发底层备份恢复技能，对用户完全无感。
3. 软删除与回收站机制：针对文件直接被 remove 删除的风险，WorkBuddy 将大模型返回的 remove 命令包装为“移入回收站”操作，既避免了频繁手动确认的繁琐，又实现了安全兜底。
4. 日志审计与意图识别：
   可观测性/日志审计：提供详细的操作命令审计与分类分级日志，方便用户追溯问题。
   意图识别：通过大模型的语义理解来判断任务是否危险（例如尝试编写并执行危险的删除脚本时会被直接拦截）。
5. 高级定制与模型自由切换：WorkBuddy 还支持更极客的配置，如命令和网络访问的黑白名单、备份策略定制。