2026-04-22 05:10:36 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文系统阐述企业级Agent安全构建框架，涵盖Skills扫描（静态检测、动态沙箱、LLM意图分析）、准入控制（签名加密）、权限设计（SSO集成、Token网关）、沙箱隔离及审计监控等关键环节，提供可落地的安全解决方案与开源工具参考。 综合评分： 85 文章分类： 安全建设,解决方案,技术标准,应用安全,云安全

cover_image

企业级 Agent 安全构建指南

原创

EBwill EBwill

灾难控制局

2026年4月21日 23:29 上海

在小说阅读器读本章

去阅读

1. Skills 扫描

1.1 静态检测

针对 Skills 内脚本、二进制类文件生成 SBOM 清单，针对 SBOM 进行漏洞、投毒威胁情报检测；
针对 Skills 内脚本、二进制类文件进行传统 SAST 检测，对常见漏洞、硬编码等问题进行检测；
针对 Skills 内脚本、二进制类文件进行静态病毒检测或 HASH 威胁情报检测；
尝试针对关键系统调用位置进行提取，如文件、网络、进程操作。

1.2 动态检测

在有探针的 Sandbox 内进行 Skills 加载操作，仅完成初始化部分，目的是针对可能的投毒危害进行检测，针对新增文件、网络请求进行分析，可以使用静态检测能力+外部威胁情报+人工审核的方式进行。
针对新增文件可以再进行静态检测。

1.3 LLM 分析

针对 Skills.md 和相关依赖进行意图分析，分析是否存在恶意意图；
外部依赖提取，针对如初始化、运行过程中的外部依赖进行提取，然后进入动态检测能力进行动态检测；
针对动、静态检测产出进行告警分析，误报消除+进一步研判；
针对 Skills 进行公司内部标准打 Tag 或分类分级。

2. Skills 准入

经过安全扫描的 Skills 需要进行签名后再上架，签名需要确保防止重打包；对应的 SBOM 等也应当按针对传统制品一样存储管理；
严格意义上讲，企业内 Agent 仅运行运行有内部签名的 Skills；
Skills 除了签名外，也应该有完整的权限体系，虽然硬编码等问题已经在扫描阶段被解决了，但依然会存在敏感信息、非公开知识存在与 Skills 内，因此在除了签名外，也可以考虑针对高安全等级 Skills 进行加密；
个人 Skills 应当适当放开准入条件，即应该在如开发测试 Skills 、积累沉淀阶段加载未经签名的 Skills，这部分安全风险由后续能力进行兜底。

3. Agent 权限设计

Agent 应接入公司 SSO/IAM（废话）；
租户、跨回话隔离；
Memory 设计需要考虑 Skills 风险等级；
Agent 运行不应仅仅考虑SSO权限，应当有类似企业网准入机制，即在安全的、可信的环境下被运行；
Skills 若存在登陆需求（此时硬编码场景应当在扫描阶段识别并拒绝上架），应该由 Agent 封装对应的 Auth Tool，由对应 Auth Tool 调用对应的公司 SSO 鉴权、用户手动输入用户名密码或AKSK；应当尽量避免本地明文配置存储相关凭证（如果公司已经实现了 Passwordless 应当比较简单了）；
最终该场景下的权限应该都收敛成为 delegated/OBO(On-Behalf-Of) 或者 STS Gateway 方案，Agent 不需要管理和存储长期权限的 Token、AKSK，但是实际情况下需要有相对安全的兼容方案。

参考资料：

https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-on-behalf-of-flow
https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html

4. Agent Token Gateway 与 Token 存储

Agent 如果在运行过程中需要管理大量敏感AKSK、Token，这部分不应该直接传入 Skills 上下文，而应该使用 Token Gateway 的方式进行使用，即：Skills -> HTTP Request -> Local Gateway -> Server；
Local Token Gateway 需要实现根证书写入，Agent 设置代理指向该 Proxy，并按约定进行对 Token 进行标识，Gateway 通过中间人的形式对 Token 进行植入；
Token 的实现这里也可以使用 SDK 的方式进行支持，但是考虑到内部 Skills 仓库会有大量外部 Skills 同步进来， SDK 方案不一定能有很好的兼容性，但是长期看 SDK -> 非MITM 的方案应该会更加稳定可靠，可以成为内部自建 Skills 的强制选择；
非 HTTP 场景需要考虑如何进行兼容（未调研）；
Gatway 会成为攻击点，Gateway 应当仅接受 Agent 的调用，因此 Agent 到 Gateway 需要进行鉴权，由于 Gateway 需要被 Agent 拉起，可以通过证书校验 + 验证 Agent 初始化 Token 的方式完成；
Gateway 需要有 Token 适用范围的白名单机制，避免攻击者诱导 Agent 将 Token 打给受攻击者控制的服务器从而导致 Token 泄漏；
Gateway 需要支持 Forward Proxy Chaining，避免在 VPN、SASE 场景下不可用；
Gateway 发出的请求需要在 HTTP Header 中有对应特征标识；
Token 存储简单可以直接使用 OS Keychain，或者通过远端 KMS （过重且离线场景下不友好）。

参考资料：

https://github.com/onecli/onecli
https://github.com/zalando/go-keyring

5. Agent Sandbox

办公等通用场景无法使用容器化方案可以考虑进程级别方案，类似 Claude Code 的方案（Windows下会会退到 WSL）；
企业版和个人应用差异在于：企业版本部分动作是无法被加白的，一定需要人员确认，甚至需要人员进行 OTP 级别确认，这部分在安全意识培训中应当强调人和Agent的责任边界问题；（确认动作需要由Proxy和Sadnbox发起）；
需要针对不同的 Skills、系统操作进行细粒度的权限映射，即哪些默认有权限、哪些需要发起什么等级的人工确认；这部分也可以成为在 Skills 扫描 LLM 评估阶段的一个环节，但是也不能仅依赖 Skills 扫描，还需要有一些基础的内置策略；
Sandbox 还有一部分很重要是需要按安全等级进行 Skills 环境隔离；
需要人员确认的部分应当支持多种方式，CLI内、IM BOT、审批等；
在企业应用场景下一些如直接浏览器操作是否应该禁止需要谨慎的内部评估；
持续的安全测试和对抗。

参考资料：

https://github.com/anthropic-experimental/sandbox-runtime
https://www.anthropic.com/engineering/claude-code-sandboxing
https://code.claude.com/docs/en/sandboxing

6. Agent Auditing

针对 Agent 的关键行为应当有对应的 Auditing 能力，集中式存储并且需要满足合规审计要求；
针对 Agent Auditing Log 做入侵检测和UEBA检测；
也可以考虑内置安全 Skills，针对未签名 Skills 加载进行上报进行异步安全扫描、定期针对用户意图进行识别、定期针对 Skills 版本进行风险检查等工作；
企业 Agent 使用的模型应当仅支持使用公司内部采购或部署的 LLM；
对于公司知识产权保护有很强需求（仅仅签署保密协议不够）+ 本地部署LLM困难的公司可以寻找各云厂商的 AI机密计算解决方案；
在对应的 LLM Gateway 上部署 LLM Guard 进行防护。

开源项目：

https://github.com/QwenLM/Qwen3Guard

7. Agent 数据安全

在 Skills 意图识别阶段，如果需要处理大量生产数据，建议不允许在本地运行，仅允许在类似远端 Agent Server 进行，并针对原始数据经支持有限披露；
同时针对传统的数据安全工作的覆盖度、全面程度、IAM覆盖度等有了更高的要求，源头管理才是解决办法；数据分类分级工具也应该标准化成为服务可以在 Agent 侧进行使用；
针对数据外发操作可以引入安全 Skills 进行 Double Check，而不是仅仅依赖 Sandbox 权限。

本文主要面向的是构建企业级类 Claw Agent 时的主要安全场景和思考，应该还有不少缺漏、错误，欢迎大家指正讨论。

免责声明：

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

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

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

本文转载自：灾难控制局 EBwill EBwill《企业级 Agent 安全构建指南》