文章总结： 本文指出当前AIAgent生态存在严重安全治理缺失，类比早期移动应用市场的混乱状态，缺乏代码签名、安全扫描、权限声明等基础机制。文章提出五项核心建议：建立Skill签名验证、自动化安全扫描、权限声明模型、运行时沙箱和审计响应机制，强调需要平台方、开发者和用户共同参与生态安全建设。 综合评分： 85 文章分类： AI安全,安全建设,解决方案,技术标准,供应链安全

AI技能生态的”狂野西部”：安全治理何时到来

bitbot bitbot

Desync InfoSec

2026年4月23日 12:01 北京

在小说阅读器读本章

去阅读

⚠️ 当我们讨论AI Agent的安全问题时，往往聚焦在技术层面。但真正的根源在于：整个生态缺乏基本的安全治理体系。

2025年的AI Agent生态，就像2010年的移动App市场——繁荣、混乱、毫无规则。

没有签名验证、没有安全扫描、没有版本锁定、没有审计日志。一个开发者可以在Skill市场发布任何东西，而平台不会做任何检查。

这不是某个平台的问题，而是整个行业的问题。

一、治理缺失对比表

| | | | | — | — | — | | 安全能力 | 成熟生态 （App Store） | AI Agent生态 （当前状态） | | 代码签名 | ✅ 强制要求 | ❌ 完全缺失 | | 安全扫描 | ✅ 自动化审查 | ❌ 没有审查 | | 权限声明 | ✅ 明确声明 | ❌ 无要求 | | 版本锁定 | ✅ 版本管理 | ❌ 无版本控制 | | 审计日志 | ✅ 完整记录 | ❌ 无记录 | | 沙箱运行 | ✅ 强制沙箱 | ❌ 无隔离 | | 隐私合规 | ✅ 隐私审查 | ❌ 无隐私保护 | | 漏洞响应 | ✅ 快速下架 | ❌ 无响应机制 |

核心问题：AI Agent的Skill/MCP Server拥有等同于桌面应用的权限，但没有经过任何安全审查就直接分发给用户。

二、为什么治理如此困难？

原因1：生态太年轻

AI Agent的Skill生态刚刚起步，开发者优先考虑功能和增长，安全是”以后再考虑”的事。这与早期互联网的发展轨迹如出一辙。

原因2：利益冲突

平台方希望吸引更多开发者和Skill——任何增加准入门槛的措施都可能”赶走”开发者。这是一种典型的”增长vs安全”权衡。

原因3：技术复杂性

传统的安全审查方法（如静态代码分析）难以适用于AI Agent的Skill。因为：

• Skill的行为不仅取决于代码，还取决于LLM如何解读SKILL.md
• 恶意指令可以隐藏在自然语言描述中
• 同一段代码在不同上下文中可能有完全不同的行为

原因4：缺乏标准

没有行业标准定义什么是”安全的Skill”、什么是”合规的MCP Server”。每个平台自行其是。

三、借鉴成熟生态的治理经验

| | | | | — | — | — | | 成熟生态 | 治理机制 | 可借鉴的实践 | | 移动App | App Store审核、权限声明、沙箱运行 | 强制权限声明、运行时权限控制 | | 浏览器扩展 | Manifest V3、权限最小化、CSP | 能力声明模型、内容安全策略 | | 包管理器 | lock文件、签名验证、漏洞扫描 | 依赖锁定、供应链安全 | | 云函数 | IAM策略、最小权限、审计日志 | 细粒度权限、完整审计 |

四、行业建议：建立AI Agent安全基线

建议1：Skill签名与验证

• 开发者必须对Skill进行代码签名
• 平台验证签名有效性后才允许分发
• 用户可查看开发者的身份和历史信誉

建议2：自动化安全扫描

• SKILL.md内容扫描：检测隐写指令和恶意prompt
• 代码静态分析：检测可疑系统调用和网络请求
• 依赖扫描：检查依赖库的已知漏洞

建议3：权限声明模型

# 每个Skill必须声明所需权限（类似Android Manifest）

name: github-tools permissions: network:

• domain: api.github.com methods: [GET, POST] filesystem:
• path: ./projects/** access: read
• path: ./output/** access: write environment:

– GITHUB_TOKEN

建议4：运行时沙箱

• 每个Skill在独立沙箱中运行
• 系统调用受限于声明的权限
• 文件访问通过虚拟化层
• 网络请求经过代理审查

建议5：审计与响应

• 记录所有Skill的执行行为
• 建立漏洞报告和响应机制
• 恶意Skill快速下架流程
• 受影响用户的自动通知

五、谁应该负责？

| | | | — | — | | 角色 | 责任 | | 平台方 | 建立安全审查机制、提供签名基础设施、快速响应漏洞 | | 框架开发者 | 设计安全的权限模型、提供沙箱运行环境 | | Skill开发者 | 遵循最小权限原则、声明所需权限、代码签名 | | 用户 | 只安装可信来源的Skill、审查权限声明、保持更新 | | 安全社区 | 发现和报告漏洞、建立安全最佳实践、推动行业标准 |

六、总结

AI Agent生态的安全治理不是一个技术问题，而是一个生态建设问题。

我们需要在追求创新速度和建立安全基线之间找到平衡。历史告诉我们，安全不是”可以以后再加”的功能——它是基础设施的一部分，必须从一开始就设计进去。

现在就是行动的最佳时机。等到发生大规模安全事件后再来补救，代价将远远超过现在投入的成本。

记住：一个没有治理的生态，最终会因为安全事件而失去用户信任——而信任一旦失去，就很难重建。

💡 系列回顾：本文是”AI Agent安全风险全景”系列的第七篇，也是总结篇。我们从供应链投毒开始，逐一分析了Prompt注入、上下文泄露、权限逃逸、MCP协议缺陷、元数据嗅探等安全风险，最终回到最根本的问题——生态治理。

参考链接：

1. “AI Agent Security: Challenges and Opportunities” – NIST Draft Report 2025
2. Apple App Store Review Guidelines
3. Chrome Web Store Developer Program Policies
4. OWASP Software Component Verification Standard

作者：比特波特 ⚡ AI安全观察

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：Desync InfoSec bitbot bitbot《AI技能生态的”狂野西部”：安全治理何时到来》