Edict 安全加固实战Dashboard 鉴权、文件锁与状态机审计如何守住 AI Agent 系统安全红线【免费下载链接】edict️ 三省六部制 · OpenClaw Multi-Agent Orchestration System — 9 specialized AI agents with real-time dashboard, model config, and full audit trails项目地址: https://gitcode.com/gh_mirrors/edic/edictEdict三省六部制是一个基于 OpenClaw 的多智能体编排系统用 9 个专职 AI Agent 模拟皇帝下诏 → 三省审核 → 六部执行的流程。既然 AI Agent 能自主执行任务、读写文件安全就成了它绕不开的话题。这篇文章带你快速看懂 Edict 的三道安全防线Dashboard 鉴权、文件锁原子更新、状态机一致性审计——新手也能轻松读懂。为什么 AI Agent 系统需要安全红线 ️Edict 的任务从创建到完成要流经多个状态太子起草、中书省拟诏、门下省审核、尚书省派发、六部执行、Review验收。任何一个环节的越权操作都可能让任务乱跳状态、数据文件被并发写坏、甚至看板接口被陌生人访问。Edict 的应对思路可以概括为一句话入口要鉴权、落盘要加锁、流转要审计。下面逐一拆解。第一道防线Dashboard 鉴权用零依赖 JWT 守住看板入口 Dashboard 默认运行在 7891 端口是所有任务、模型配置、技能管理操作的入口。Edict 用纯 Python 标准库实现了一套零外部依赖的 JWT 认证模块核心代码只有 172 行见 auth.py密码哈希hashlib.pbkdf2_hmacSHA-25610 万次迭代 随机盐密码从不以明文落盘Token 签名HMAC-SHA256 签名的 Base64 JSON有效期 24 小时密钥随机生成每次服务启动都会生成新的签名密钥重启后旧 token 全部失效——这是刻意的安全设计时序安全所有密码/签名比对都走hmac.compare_digest防时序攻击在服务端server.py 的_check_auth()方法在每次请求入口统一拦截白名单路径如/healthz、登录接口、静态资源放行其余请求必须携带有效 tokenAuthorization: Bearer或 Cookie否则直接返回 401未登录或会话已过期。 安全建议来自 SECURITY.md不要把data/目录暴露到公网用防火墙限制看板端口访问反向代理时务必启用 HTTPS。第二道防线文件锁让并发写入不再互相覆盖 Edict 的任务数据存储在 JSON 文件中而同时写文件的选手很多调度线程、定时扫描器、HTTP 请求处理……经典的 TOCTOU 竞态会导致后写的线程把先写的修改整个覆盖掉。解决方案是 file_lock.py它提供三个原子操作函数作用atomic_json_read持共享锁读取读期间数据不会半写atomic_json_update持排他锁完成读 → 改 → 写全程atomic_json_write持排他锁直接原子写入两个关键技巧值得学习独立锁文件 跨平台锁锁加在xxx.json.lock上而非数据文件本身避免 rename 导致锁丢失Linux 用fcntl.flockWindows 用msvcrt.locking临时文件 os.replace写入先落到同目录临时文件再原子替换即使进程中途崩溃数据文件也不会出现写了一半的脏数据tests/test_task_mutation_race.py 用多线程并发写专门验证了这套机制无论多少个写者同时改任务每个字段的修改都不会丢失。第三道防线状态机审计CI 守卫让非法流转无处遁形 ⚖️Edict 的任务状态机定义在 task.py 的STATE_TRANSITIONS中每个状态只能流向一组白名单状态Done和Cancelled是终态、没有出边。但真正的亮点在于双实现一致性审计。系统同时存在 JSON 版看板kanban_update.py和 Postgres 版后端两份状态机必须完全一致——否则同一个任务在两边会被允许不同的流转等于开了个后门。tests/test_state_machine_consistency.py 作为 CI 守卫做了四重检查✅ 两侧状态转换表逐项比对任何漂移立即报红✅PendingConfirm待确认状态在两侧都必须存在✅Pending不能是死胡同必须有出边✅ 终态Done/Cancelled不得有任何出边只要有人改了一侧忘了改另一侧CI 就会失败非法流转在合并前就被拦截。额外加分项路径穿越防护 ️除了三大防线Edict 还修过真实的 CWE-22 漏洞file://协议的远程技能地址可以读取任意本地文件。修复后所有路径都必须落在allowed_roots白名单内tests/test_cwe22_file_url.py 用在白名单外放一个秘密文件的攻击场景验证越界读取被拒绝白名单内正常工作。静态文件服务同样做了..路径检查见 server.py 的静态资源处理逻辑。总结给 AI Agent 系统安全上锁的通用思路 Edict 的安全实践对其他 Agent 项目同样有参考价值入口鉴权零成本用标准库实现 JWTPBKDF2 HMAC-SHA256不引入重依赖并发写数据必加锁共享锁读、排他锁写、临时文件原子替换三件套防丢数据规则双写必审计用 CI 测试强制约束多实现的一致性让漂移在合并前暴露路径白名单任何按路径读文件的功能都要有 allowed_roots 兜底对于部署方记住 SECURITY.md 的四条铁律保持更新、data/不上公网、防火墙限端口、反代开 HTTPS。让 AI Agent 放心干活红线得先画好。【免费下载链接】edict️ 三省六部制 · OpenClaw Multi-Agent Orchestration System — 9 specialized AI agents with real-time dashboard, model config, and full audit trails项目地址: https://gitcode.com/gh_mirrors/edic/edict创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Edict 安全加固实战：Dashboard 鉴权、文件锁与状态机审计如何守住 AI Agent 系统安全红线
Edict 安全加固实战Dashboard 鉴权、文件锁与状态机审计如何守住 AI Agent 系统安全红线【免费下载链接】edict️ 三省六部制 · OpenClaw Multi-Agent Orchestration System — 9 specialized AI agents with real-time dashboard, model config, and full audit trails项目地址: https://gitcode.com/gh_mirrors/edic/edictEdict三省六部制是一个基于 OpenClaw 的多智能体编排系统用 9 个专职 AI Agent 模拟皇帝下诏 → 三省审核 → 六部执行的流程。既然 AI Agent 能自主执行任务、读写文件安全就成了它绕不开的话题。这篇文章带你快速看懂 Edict 的三道安全防线Dashboard 鉴权、文件锁原子更新、状态机一致性审计——新手也能轻松读懂。为什么 AI Agent 系统需要安全红线 ️Edict 的任务从创建到完成要流经多个状态太子起草、中书省拟诏、门下省审核、尚书省派发、六部执行、Review验收。任何一个环节的越权操作都可能让任务乱跳状态、数据文件被并发写坏、甚至看板接口被陌生人访问。Edict 的应对思路可以概括为一句话入口要鉴权、落盘要加锁、流转要审计。下面逐一拆解。第一道防线Dashboard 鉴权用零依赖 JWT 守住看板入口 Dashboard 默认运行在 7891 端口是所有任务、模型配置、技能管理操作的入口。Edict 用纯 Python 标准库实现了一套零外部依赖的 JWT 认证模块核心代码只有 172 行见 auth.py密码哈希hashlib.pbkdf2_hmacSHA-25610 万次迭代 随机盐密码从不以明文落盘Token 签名HMAC-SHA256 签名的 Base64 JSON有效期 24 小时密钥随机生成每次服务启动都会生成新的签名密钥重启后旧 token 全部失效——这是刻意的安全设计时序安全所有密码/签名比对都走hmac.compare_digest防时序攻击在服务端server.py 的_check_auth()方法在每次请求入口统一拦截白名单路径如/healthz、登录接口、静态资源放行其余请求必须携带有效 tokenAuthorization: Bearer或 Cookie否则直接返回 401未登录或会话已过期。 安全建议来自 SECURITY.md不要把data/目录暴露到公网用防火墙限制看板端口访问反向代理时务必启用 HTTPS。第二道防线文件锁让并发写入不再互相覆盖 Edict 的任务数据存储在 JSON 文件中而同时写文件的选手很多调度线程、定时扫描器、HTTP 请求处理……经典的 TOCTOU 竞态会导致后写的线程把先写的修改整个覆盖掉。解决方案是 file_lock.py它提供三个原子操作函数作用atomic_json_read持共享锁读取读期间数据不会半写atomic_json_update持排他锁完成读 → 改 → 写全程atomic_json_write持排他锁直接原子写入两个关键技巧值得学习独立锁文件 跨平台锁锁加在xxx.json.lock上而非数据文件本身避免 rename 导致锁丢失Linux 用fcntl.flockWindows 用msvcrt.locking临时文件 os.replace写入先落到同目录临时文件再原子替换即使进程中途崩溃数据文件也不会出现写了一半的脏数据tests/test_task_mutation_race.py 用多线程并发写专门验证了这套机制无论多少个写者同时改任务每个字段的修改都不会丢失。第三道防线状态机审计CI 守卫让非法流转无处遁形 ⚖️Edict 的任务状态机定义在 task.py 的STATE_TRANSITIONS中每个状态只能流向一组白名单状态Done和Cancelled是终态、没有出边。但真正的亮点在于双实现一致性审计。系统同时存在 JSON 版看板kanban_update.py和 Postgres 版后端两份状态机必须完全一致——否则同一个任务在两边会被允许不同的流转等于开了个后门。tests/test_state_machine_consistency.py 作为 CI 守卫做了四重检查✅ 两侧状态转换表逐项比对任何漂移立即报红✅PendingConfirm待确认状态在两侧都必须存在✅Pending不能是死胡同必须有出边✅ 终态Done/Cancelled不得有任何出边只要有人改了一侧忘了改另一侧CI 就会失败非法流转在合并前就被拦截。额外加分项路径穿越防护 ️除了三大防线Edict 还修过真实的 CWE-22 漏洞file://协议的远程技能地址可以读取任意本地文件。修复后所有路径都必须落在allowed_roots白名单内tests/test_cwe22_file_url.py 用在白名单外放一个秘密文件的攻击场景验证越界读取被拒绝白名单内正常工作。静态文件服务同样做了..路径检查见 server.py 的静态资源处理逻辑。总结给 AI Agent 系统安全上锁的通用思路 Edict 的安全实践对其他 Agent 项目同样有参考价值入口鉴权零成本用标准库实现 JWTPBKDF2 HMAC-SHA256不引入重依赖并发写数据必加锁共享锁读、排他锁写、临时文件原子替换三件套防丢数据规则双写必审计用 CI 测试强制约束多实现的一致性让漂移在合并前暴露路径白名单任何按路径读文件的功能都要有 allowed_roots 兜底对于部署方记住 SECURITY.md 的四条铁律保持更新、data/不上公网、防火墙限端口、反代开 HTTPS。让 AI Agent 放心干活红线得先画好。【免费下载链接】edict️ 三省六部制 · OpenClaw Multi-Agent Orchestration System — 9 specialized AI agents with real-time dashboard, model config, and full audit trails项目地址: https://gitcode.com/gh_mirrors/edic/edict创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考