ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

【AI】Agent 安全:Skill、Tool、MCP 与运行时权限

2026/9/29 6:17:09 拓冰建站 浏览量
【AI】Agent 安全:Skill、Tool、MCP 与运行时权限 背景当前AI Agent已经很普及了那么有一个关键地方在于如果使用外部第三方/非官方 Skill和工具如何保证安全性——AI Agent 真正的安全边界是什么别再只防 Prompt InjectionAI 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 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}BlastRadiusAgent 越强Sandbox 和权限模型反而越重要。Anthropic 也明确指出模型防御不可能单独承担全部安全责任外部 Tool、文件、网络和 MCPModel 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 ScannerAgent 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 ExtractionCapability ManifestCapability 可以翻译为能力 / 权限能力。Capability Extraction能力提取运行前提取该文件所需的最小权限并配置Capability Manifest让 Skill 主动声明自己需要什么提取出来以后最好形成一个标准 Manifest清单。例如name:github-reviewerfilesystem:read:-./src/**write:-./reports/**network:allow:-api.github.comsecrets:allow:-GITHUB_TOKENprocess:allow:-gitshell:enabled:false安全系统比较两个集合Declared Capability和Actual Capability理想状态必须满足Cactual⊆CallowedC_{\text{actual}} \subseteq C_{\text{allowed}}Cactual​⊆Callowed​一旦运行请求权限声明Runtime 应该直接DENY拒绝。第四道防线Policy EngineManifest 不是权限只是表示Skill 希望获得这个 Capability。真正决定是否批准的是Policy Engine给出的结果可以是DENY、ALLOW、REQUIRE HUMAN APPROVALASK如果进一步做企业级系统还可能根据用户身份、Skill 来源、环境、数据敏感级别、操作风险、时间、资源等动态决定权限。权限必须拆开颗粒度Capability 的组合可能很危险每个权限看起来都不起眼。所以安全系统应该至少把权限拆成不同 DomainFilesystem Network Secrets Process Shell Database Cloud API Browser User InteractionSnyk 现在也已经把类似风险作为组合问题处理例如同时接触 private data、untrusted content 和 destructive capabilities 会显著放大攻击后果。第五道防线Runtime Capability Gateway真正关键的一层执行阶段中实时拦截——Runtime Capability Gateway所有敏感操作必须经过它。分别进入对应的Gateway比如Filesystem/Network Gateway再进行Policy Check/Egress Policy第六道防线Sandbox Runtime不要让不可信代码和宿主机站在同一个权限域沙箱隔离。Sandbox 可以限制几乎所有细分权限Prompt 层的“不要做坏事”和 OSOperating System操作系统层的“你根本没有权限做”不是一个级别的安全保证。Anthropic 对 Agent containment 的描述也是这个方向Process Sandbox、VMVirtual Machine虚拟机、Filesystem Boundary 和 Egress Control 用于给 Agent 建立硬边界。Runtime EnforcementSandbox 还不等于全部虽然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 TraceTrace链路追踪记录 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最终完整安全模型每一层解决的问题完全不同层回答的问题Scanner它看起来有没有危险Capability Extraction它实际上想使用什么能力Manifest它声明自己需要什么Policy Engine我愿意给它什么Capability Gateway所有敏感操作是否经过控制Sandbox即使被攻陷它最多能碰到什么Runtime Enforcement它现在这个操作允许吗Behavioral Monitor它整体行为是否异常Trace它到底做过什么Attestation我如何证明它是谁、从哪来、经过什么检查没有哪一层能够单独解决 Agent 安全。真正应该改变的安全思维真正成熟的安全模型应该假设LLM 可能判断错误 Prompt Injection 可能成功 Skill 可能恶意 Dependency 可能失陷 Remote MCP 可能改变 Scanner 可能漏报然后继续问即使这些全部发生系统最多允许攻击者做到什么这才是 Runtime Security 真正解决的问题。Agent SecurityLeast PrivilegeIsolationEnforcementObservabilityVerifiability\text{Agent Security} \text{Least Privilege} \text{Isolation} \text{Enforcement} \text{Observability} \text{Verifiability}Agent SecurityLeast PrivilegeIsolationEnforcementObservabilityVerifiability最小权限隔离强制执行可观测性可验证性构建一个即使模型犯错、Skill 恶意、Prompt Injection 成功也能够限制损害范围的系统。大厂方案桌面智能体 WorkBuddy 的多层安全防护实践沙箱隔离技术Sandbox最基础的技术是沙箱将 Agent 限制在隔离空间内限制目录访问、网络、CPU 和内存资源类似程序员线上服务部署的 Docker 容器防止单点故障引发全局崩溃。文件自动备份与无感恢复针对大模型可能“改错文件”的问题WorkBuddy 设有文件备份机制。开启后会自动备份修改前的文件用户不仅能手动查找还可通过自然语言如“帮我恢复上一版”触发底层备份恢复技能对用户完全无感。软删除与回收站机制针对文件直接被 remove 删除的风险WorkBuddy 将大模型返回的 remove 命令包装为“移入回收站”操作既避免了频繁手动确认的繁琐又实现了安全兜底。日志审计与意图识别可观测性/日志审计提供详细的操作命令审计与分类分级日志方便用户追溯问题。意图识别通过大模型的语义理解来判断任务是否危险例如尝试编写并执行危险的删除脚本时会被直接拦截。高级定制与模型自由切换WorkBuddy 还支持更极客的配置如命令和网络访问的黑白名单、备份策略定制。