从专业、可信，到安全：SIQ Agent Security，让 Agent 行动有边界，完成有依据- 惊觉

从专业、可信，到安全：SIQ Agent Security

NVIDIA DGX Spark Hackathon 工程实践｜面向私域智能业务系统的智能体安全管控。
Skills 给智能体能力，SIQ 给能力边界。
本项目致力于让智能体授权有依据，行动受约束，结果可核验。
把模型部署在自己手里，是掌握智能能力的开始；把权限、执行和证据也掌握在自己手里，才是让这份能力真正进入业务的下一步。

目录
前言：模型搬进了内网，权限问题却不会自动消失
一、三届比赛：专业、可信与安全，是逐层深入的三个问题
二、把“担心不安全”拆成能够实施的管控需求
三、从前沿文献到产品设计：把研究问题变成可执行约束
四、沿系统架构图阅读：三大运行区域，两层共同基础
五、生命周期管控：从一个 Skill 进入系统，到一次动作结束
六、密码学如何进入系统：不是给日志贴一个“防篡改”标签
七、DGX Spark 与 NVIDIA 技术栈：把私域算力变成受控的业务运行环境
八、工程难点：真正困难的是变化、恢复和跨组件一致性
九、实际效果：既看拦截，也看正常工作、异常识别和可复核性
十、把复杂机制做成用户能够操作的产品
十一、部署与复现：先建立身份，再扩大使用范围
十二、商业价值：让已经部署的私域算力能够被放心使用
结语：把算力交给智能体，把边界留给用户
项目与资料入口
参考资料

前言：模型搬进了内网，权限问题却不会自动消失

当一个智能业务系统第一次在 DGX Spark 上运行起来时，最直观的变化，是模型、业务服务和一部分数据处理流程回到了自己的环境。

专业资料可以就地处理，本地模型可以参与分析，业务团队不必为每项任务都把原始材料交给外部推理服务。这是私域部署的重要价值。但随着智能体开始连接文件、终端、接口和 Skills，另一个问题会越来越具体：

数据放在哪里，我们看得见；智能体凭什么操作这些数据，谁来管？

以一个典型的私域业务环境为例：研究智能体可以读取项目材料，报告智能体可以生成文件，运维助手能够调用终端，不同应用还可能共用模型服务和部分知识资源。这时，即使没有把数据发到公网，一次错误的写入、一次跨项目读取、一个权限过大的 Skill，也足以破坏业务边界。

这个场景不是在描述已经发生的泄露事故，而是在说明本项目面对的真实需求：用户已经部署了智能业务系统，却对系统内部的权限、工具执行与责任追溯产生新的顾虑。

私域部署改善的是数据驻留和处理路径的可控性，不会自动解决内部越权、提示注入、权限继承和错误执行。智能体安全需要同时考虑模型、宿主、工具和运行环境，而不是仅要求模型记住“请遵守安全规则”。¹

因此，我们在业务实践之外，系统梳理智能体安全的前沿研究，并结合 NVIDIA 技术栈，在 DGX Spark 上推进本地运行时与执行后端适配，最终形成 SIQ Agent Security：一套围绕 Agent 与 Skill 生命周期，管理权限、检查动作、关联证据的开源智能体安全系统。²³

它的目标不是减少智能体能力，而是让用户有条件、有依据地使用这些能力。
在这里插入图片描述
图1｜私域部署主要解决“在哪里处理数据”，智能体安全继续回答“谁有权以什么方式处理”。图中的绿色管控路径表示已接入的安全检查，不代表整台机器上的所有进程自动受到保护。

一、三届比赛：专业、可信与安全，是逐层深入的三个问题

第一届，Sovereign-IQ 聚焦专业智能体。我们从专业角色、知识分工和协作程序入手，探索智能体如何参与真正的业务工作，而不是只生成一段看起来专业的文字。（详见：Sovereign-IQ主权智感多智能体投研决策系统）

第二届，SIQ Research Engine 聚焦可信智能体。工作重心进一步落到事实、证据和可复核的研究过程：数字从哪里来，结论依据什么，相关材料能否重新定位。（详见：SIQ Research Engine）

这一届，SIQ Agent Security 聚焦安全智能体。在专业能力与可信信息之外，继续处理一个不能省略的问题：当智能体获得工具能力之后，如何让它始终在明确的授权边界内行动？（github-pages：SIQ Agent Security）

这条演进可以概括为：

阶段	核心问题	关注对象
专业智能体	能否把工作做好？	角色、知识和业务流程
可信智能体	结论有没有依据？	事实、来源和核查过程
安全智能体	是否有权这样做？	身份、权限、执行和效果

三者并不是互斥概念。前两届已有隔离和审计实践，这一届是在此基础上，把智能体安全进一步整理成可以独立接入和持续治理的能力。

一份结论准确的报告，仍可能由越权读取生成；一个专业角色，也可能因为拥有过大的工具权限，影响不属于它的项目。内容可信，不能代替行为获准。

因此，企业研究报告只是我们熟悉的验证场景，SIQ Agent Security 的产品主体是安全管控。用户可以继续使用原来的业务系统，通过 SIQ 核对有哪些智能体、装了什么 Skill、授予了哪些权限，以及哪些调用路径真正受到保护。²

二、把“担心不安全”拆成能够实施的管控需求

1. 先看清受保护对象，而不是先增加一个拦截按钮

智能体环境里，至少有三类不同对象：模型服务提供推理能力；宿主框架组织会话和工具调用；Skill 描述或封装业务能力。一个框架内又可能存在多个实例、多个会话和不同安装内容。

如果只看进程名或 Skill 名称，很容易把“机器上有这个东西”“它属于哪个实例”“它当前能执行什么”混为一谈。SIQ 因此将发现候选、安装记录、权限事实与运行身份分别建模，再根据实际证据建立关联。²⁴

看见资产，是治理的起点，不是保护已经生效的证明。

2. 私域内部的风险，往往来自权限组合

一个动作单独看可能合理：读取材料是业务需要，运行脚本是工具能力，访问某个接口是系统配置。但这些能力组合起来，可能超出本次任务的真实需要。

例如，用户只要求分析项目 A，智能体却因为宿主进程拥有更广泛的文件权限而尝试读取项目 B；又或者，一个原本只需本地处理的 Skill，在更新后增加了网络需求。这里的问题，不一定是某一句提示词明显恶意，而是业务边界没有落实到具体调用。

我们据此把产品需求分成几个相互衔接的环节：

风险发生的位置	需要检查的问题	SIQ 对应能力
发现与接入	这是什么实例，来源和归属是否清楚？	只读盘点、候选确认、受管身份与会话登记
Skill 安装和更新	内容有没有改变，能力需求是否扩大？	静态准入、内容摘要、差异与权限预览
授权	谁批准了哪些工具、文件和网络范围？	人工确认的 Grant、任务 Intent、权限事实
工具调用	参数是否符合本次任务，来源依据是否有效？	运行时授权、参数来源与 SEC 复验
审批与恢复	条件变化后能否继续，重试会不会重复执行？	最终复查、执行预留、未知状态保留
执行与结果	后端是否真正限制行为，结果有没有相应证据？	OpenShell 适配、签名回执、效果与完成判定

这不是把六个功能放在同一个页面，而是要求前一个环节产生的对象，能够被后一个环节准确核对。³⁴⁵

3. 防护对象明确，信任前提也必须明确

本项目重点处理已接入调用路径上的错误提议、不可信内容影响、来源或上下文冒用，以及审批和执行之间的状态变化。安全运行时、可信签发者和效果观察器本身仍属于需要保护的基础。³

尤其在本地桌面模式中，两个进程即使职责分离，只要运行在同一用户权限下，就不能据此宣称能抵御任意恶意同用户程序。需要更强执行隔离的任务，应结合实际支持的 OpenShell 配置和宿主边界，而不是把一个本地 HTTP 服务叫作“绝对安全沙箱”。³⁶

三、从前沿文献到产品设计：把研究问题变成可执行约束

做智能体安全，容易走向两个极端：只改提示词，或者搭出一个巨大平台，却说不清它在哪一步解决了什么风险。

我们的做法，是先把文献讨论的问题转成工程问题，再对应到机制、接口和对照实验。仓库的 research/ 目录按文献、研究问题、方法、实验和证据组织阅读路径。⁷

1. 不把模型当作最终安全权威

《Agent Security is a Systems Problem》主张将模型视为不可信组件，在系统层执行安全不变量，并将这种方法作为模型鲁棒性工作的补充。¹

对本项目而言，这意味着：模型可以解释任务、选择能力、提出动作，但不能拿到安全运行时的签名私钥，也不能通过生成一段文字为自己扩大权限。

于是，权限签发、调用裁决和结果核验被放到独立的运行时职责中；业务 Agent 获取的只是完成工作所需要的接口，不是管理整个安全系统的身份。³

2. 不可信数据不能自行变成控制指令

CaMeL 将可信请求中的控制流、数据流与工具能力约束分开处理；AuthGraph 则研究授权基线与实际参数来源之间的对齐关系。它们的方法不同，但都提醒我们：仅判断工具名或最终字符串，可能遗漏授权来源的问题。⁸⁹

SIQ 对应的工程重点，是将来源引用与具体参数绑定，并在当前任务、作用域和内容摘要下复验。它不依赖工具在返回文本里自称“这是用户要求的”。¹⁰

3. 不把模型表态当作实际执行结果

SafeClawBench 区分语义层面的攻击接受、审计可见证据和沙箱中观察到的工具或状态变化。这个区分有助于避免将“模型同意了”与“危险效果发生了”合并成一个数字。¹¹

我们进一步把调用后报告、效果材料和完成判定分开：既检查是否阻断不被允许的动作，也检查工具返回成功时，要求的效果是否真正满足。¹²

4. 文献启发不是实验成绩，方法借鉴也不等于完整复现

SIQ 吸收的是系统分权、来源约束、生命周期治理和分阶段验证的思路。它没有因为引用某篇论文，就继承那篇论文的攻击成功率；也不把自己的固定测试语料重命名为外部基准。⁷

本项目的技术价值，需要落在自己的源码与对照结果上：检查了哪些条件，错误时如何拒绝，状态如何恢复，以及对应证据能支持多大范围的结论。

四、沿系统架构图阅读：三大运行区域，两层共同基础

README 的系统架构全景把产品分成三个主要区域：本机安全运行时、DGX Spark／OpenShell 执行环境、企业控制面。密码学信任链与版本化数据合同贯穿其中。²¹³
在这里插入图片描述
图2｜SIQ Agent Security系统架构：业务 Agent 继续负责规划和调用 Skills；SIQ 本地运行时负责身份、授权、来源、审批与效果核验；OpenShell 是可选的受约束执行后端；企业控制面通过 Edge／Connector 做集中治理。

工程全景图建议紧接图2放置。 README 中的 docs/siq-agent-security-architecture.svg/png 信息更完整，适合作为“工程事实图”；发布前应将图右上角历史 0.4.0 / 2cd6116 角标同步为当前架构快照说明，避免把旧版本标签误解为当前 Latest。简化图负责“让读者看懂”，README 全景图负责“让技术读者看到真实模块与边界”。¹³¹⁴

理解这两张图的关键，不是记住每个模块名，而是看清“谁可以发出什么请求，谁必须做独立判断”。

1. 本机安全运行时：接近工具调用，但不依赖模型作裁决

apps/agentshield 是 Go 实现的本地核心。它包含资产盘点、静态准入、Grant、Intent、来源、SEC、审批恢复、回执和效果核验等模块，同时提供本地管理 API 与内嵌控制台。个人模式不要求额外部署企业数据库，也不要求模型服务在线才能执行权限检查。³

接口职责分为管理面和决策面。管理面用于准入、授权与相应确认操作；决策面用于已接入调用的裁决和观察。能够向系统询问“这次动作是否允许”，不等于能够调用管理接口给自己创建许可。¹³⁴

本地配对解决的是“这个浏览器是否可以管理当前实例”，而不是“智能体是否可以读取某份资料”。当前 0.4.1 延续固定 24 小时管理会话：刷新不续期，浏览器连接请求本身也不产生任何智能体业务权限；业务动作仍需要独立授权与运行时检查。²¹⁵¹⁶

2. 宿主适配器：把裁决接到真正的调用前后

运行时适配器不是另一个安全引擎，而是连接原生宿主协议与本地裁决的桥。它需要从宿主取得实际实例、会话和工具调用身份，在调用前请求检查，在调用后提交关联观察。⁵

一个有效接入要回答：钩子是否被宿主加载？本次调用是否真的经过它？请求超时或身份无效时会发生什么？调用后的结果能否关联回同一个动作？

因此，文件安装成功只是接入的一部分，正常与越权用例、失联行为、撤权和审批恢复都需要分别验证。⁵

3. DGX Spark／OpenShell：承载模型工作负载与受约束执行

DGX Spark 提供本地计算环境。OpenShell 在受支持的配置中提供执行隔离与策略约束。SIQ 负责将已批准的范围转成后端可以表达的限制，并核对目标、策略状态及对应行为。⁶

可以把两者的区别理解为：SIQ 检查“这次动作是否有依据”，执行后端限制“进程在环境里能够怎样行动”。

例如，网络策略允许访问某个业务域名，只说明存在一条受限网络路径；向该域名的哪个对象提交什么内容，仍可能需要更细的任务授权和参数检查。反过来，应用层已拒绝，也不能替代对未接入代码路径的隔离。

4. 企业控制面：把不同环境组织成治理流程

企业侧使用 FastAPI、SQLAlchemy、PostgreSQL、Worker、Web 和 Edge／Connector，管理环境、设备、资产、证据、风险、策略审批与审计。它是独立服务入口，不因为和个人运行时在同一源码仓库里，就自动拥有个人实例的管理权限。¹⁷

Edge 是环境侧的采集和证据传输代理；本机运行时则处理已接入的工具授权。两者职责不同，不能把“Edge 扫描成功”当成“工具已经被阻断”。¹⁸

5. 密码学与合同：让跨组件关系可以核对

图4-1：组件与授权链路

密码学绑定内容与身份，数据合同定义字段、类型、状态和使用条件。前端、Go、Python、Edge 和宿主适配器，必须对“已批准”“已生效”“已执行”“已核验”具有一致理解。⁴

从一个任务的视角，主要关系可以简化为：

受信用户／组织身份
       │ 明确批准的范围与任务要求
       ▼
Grant + Intent + 可信上下文／来源／SEC
       │
原有业务 Agent → 宿主适配器 → 本地运行时检查
                                  │
                         允许／拒绝／待审批
                                  │
                          宿主工具／OpenShell
                                  │
                     调用后观察 + 签名动作回执
                                  │
                         已接入的效果采集
                                  │
                    任务核验、审计与可选企业同步

这是职责关系示意，不表示每条调用都已经具备所有可选环节，也不表示个人和企业身份可以互换。³⁵¹⁷

五、生命周期管控：从一个 Skill 进入系统，到一次动作结束

为了把这条安全链放回真实业务，我们继续沿用前两届熟悉的“企业研究报告生成与交付”作为参考应用：准备阶段只读材料并生成候选报告，执行阶段再固定交付要求、重核来源与权限、执行写入／受控交付，最后用实际效果材料判断任务状态。演示接收端是受控 HTTP receiver，不发送真实外部邮件。¹²

在这里插入图片描述
图3｜业务只是载体，安全主线是“准备—固定执行要求—重核来源—运行时授权—执行—效果核验”。任何一个关键条件不成立，都不会用后续步骤反向补齐授权。

1. 资产发现：先保存可核对的事实，不急着宣布“已纳管”

SIQ 的发现结果保留来源、候选与证据关系。个人端可以查看实例、项目、Skill、模型连接及网关检查；企业端再通过目录、框架、MCP、进程、容器或集群等 Connector 汇总环境资产。²¹⁷

一个目录里出现了某个 Skill，可能只能证明文件存在。要继续认定它已经被某个宿主加载，需要额外证据；要确认一条运行调用属于该安装，还需要运行身份和上下文绑定。

这种分层避免了一个常见误解：资产管理页面上已经出现对象，用户便以为它所有的行为都受到了保护。

2. 静态准入：审查能力声明，也审查包本身的边界

准入不仅是扫描提示词。合同同时处理内容摘要、扫描限额、路径逃逸和发现项的处置。超过限制或出现符号链接逃逸等指定条件时，准入结论需要进入隔离，而不是忽略异常继续安装。⁴

正常流程是：导入候选，暂存和检查，展示目标与权限需求，用户明确确认后再执行安装。更新则继续核对新旧内容和授权条件，避免新版本在名称不变的情况下悄悄改变行为。²

例如，一个旧版 Skill 只处理本地文件，新版增加了网络工具需求，系统不能只依据“以前批准过这个名称”就继承新增权限。批准要指向具体内容和范围，而不是指向一个永远不变的标签。

静态检查用于发现已知风险与不合法结构，不承担证明任意程序在任何输入下都安全的任务；后续运行时检查仍然必要。

3. 权限五态：声明、推断、观察和生效不能混写

SIQ 的权限事实分为五种状态：⁴¹⁷

状态	表示什么	一个直观例子
`declared`	组件明确声明的能力需求	Skill 写明需要网络请求工具
`inferred`	根据分析得到的推断	静态内容提示可能涉及某类资源
`observed`	在指定范围内实际观察到的事实	已采集到某次相关调用或配置观察
`effective`	有相应授权修订与后端读回依据的生效权限事实	部署后读回匹配所要求的授权状态
`unknown`	材料不足，不能确定	找到安装内容，但没有运行加载证据

五态不是一个可以凭经验自动逐级升级的进度条。声明可以与实际状态存在差距，观察到一次行为也不代表它获得授权。

effective 同样需要按证明范围阅读：**权限配置得到确认，与某条动作已经经过真实阻断实验，是不同层级。**产品既要展示当前权限，也要展示依据是什么。⁴⁶

4. Grant 与 Intent：长期能力不等于本次任务的无限许可

Grant 描述经确认的权限边界；Intent 进一步表达一次任务的主体、工具、资源和参数约束。Grant 的默认处置为拒绝，批准者类型由合同限定为人类；生效事实需要读回和授权修订依据。⁴

假设一个分析智能体平时有项目目录读写能力，本次用户却只要求“读取指定材料，生成摘要，不保存、不发送”。此时，框架具备文件写入工具并不能代替本次任务授权。

用一句概念性表达说明这种关系：

本次可执行范围，受已授予权限、任务要求、可信上下文、参数来源和当前状态共同限制。

这是帮助理解的约束关系，不是声称任何一份文本 Intent 都会被系统自动视为用户同意。有效授权来自受信管理入口，模型输出不能直接成为签发凭据。³⁴

5. 来源绑定：把“为什么可以用这个值”带到执行点

以接收人参数为例，单独检查字符串会丢掉一个重要信息：它是来自用户确认的目录，还是来自不可信网页和工具返回？

SIQ 在参数路径上绑定来源引用。实际的 MatchParameters 实现会读取参数值并计算摘要，逐一解析所有提交的来源引用，核对当前作用域、来源有效性、内容摘要、允许的来源类型与最低信任条件。重复绑定、缺失引用和不匹配内容都有相应拒绝路径。¹⁰

更重要的是，它不是“找到一个可信引用就放行”。同一绑定提交多个引用时，各引用都要通过检查，不能把一个合法来源夹在一组不合法来源里蒙混过关。代码在同次检查中复用图遍历结果，但不以减少校验来换速度。¹⁰

公开的同值对照中，两个相同接收地址分别来自可信目录和 MCP；在任务明确要求可信目录确认的条件下，前者可以获准，后者被拒绝。¹⁹

合法的值可以复制，合法的授权依据不能靠复制值获得。

在这里插入图片描述
图4｜同一 [email protected]，可信目录来源与 MCP 工具返回的字符串值完全相同；在本次 Intent 明确要求可信联系人目录确认时，授权结果取决于“值＋来源＋作用域”，而不是字符串长得是否一样。

这个能力基于已登记、可验证的结构化来源关系，不等于能自动识别任意自然语言推理的真实来源。

6. 会话风险状态：不能脱离此前接触的数据判断后续动作

来源检查解决“参数依据是什么”，会话风险状态进一步关注“这次执行此前接触过什么”。运行时维护秘密、个人信息、不可信内容和私密资源等相关标签，并结合出站动作进入策略判断。²⁰

它处理的不是一句话是否含有危险关键词，而是连续操作的关系：同一个会话在接触敏感材料和不可信输入之后，再尝试出站，不能只因为最后一次工具名看起来正常，就忽略之前积累的状态。

当前实现也明确保留已有风险标签，不通过清空标签美化后续判断；会话容量不足时，不会为腾出位置而按普通缓存淘汰方式丢掉带风险状态的会话。具体结果仍由适用的授权、规则和观察覆盖共同决定，不是对任意文本进行完美语义污点追踪。²⁰

这样，输入静态规则、参数来源约束和会话状态形成互补：分别处理已知内容风险、授权依据与连续行为条件。

7. SEC：证明调用归属于哪个安装，而不是只认 Skill 名称

SEC，即 Skill Execution Context，用来绑定具体安装与执行上下文。它本身不新增权限，也不扩大资源范围。²¹

源码中，SEC 不只是一个 Skill ID，而是同时记录：宿主平台、实例、Agent、会话和适用任务；Skill 内容摘要及可选版本；安装记录及其签名；关联 Grant 的身份与摘要；签发时间、有效期和签名格式。²¹

这样，系统检查的对象从“名字叫 report 的 Skill”变成“这一实例和会话中、这一安装内容、依据这一授权运行的 Skill”。授权修订、安装变化或上下文不匹配，需要重新处理，不能靠路径相同继续沿用。

SEC 撤销还保留原始记录，追加签名撤销对象，而不是删掉历史以后让系统失去解释依据。它处理调用层的归属冒用，不宣称抵御已失陷宿主或任意同用户恶意代码。²¹

8. 调用时检查：绑定的必须是最终要执行的参数

图5-1 任务执行与效果核验

如果系统检查的是一份参数，执行器拿到的却是稍后被修改的另一份参数，再完整的授权规则也会失去意义。

参考应用的 ToolGateway 在边界处复制并规范化请求，向运行时提交确定的工具、参数和来源绑定。拒绝直接结束本次调用；审批等待保存相应请求。对于发生参数变换的返回，参考应用要求新的提议／授权，不在旧摘要下静默执行另一份参数。²²

运行时合同包含 allow、deny、hold、redact 等结果，但具体宿主是否支持改参、怎样恢复，需要遵循该适配器的协议。不能看到统一枚举，就宣称所有框架具有完全相同的执行能力。普通策略的观察／告警模式也不能放松受管身份和必需授权检查；无效的必需授权不能因为选择了“只审计”就被放行。⁴⁵

9. 审批、重试与崩溃：宁可明确未知，也不盲目重做

异步审批最危险的窗口，在“当时批准”与“现在执行”之间。

SIQ 的受支持恢复路径会重呈原动作身份和参数，在线复查当前授权，再取得持久化签名执行预留。目标工具只有在相应条件满足后才被尝试执行。⁵²²

设想预留已经保存，但响应在网络中丢失。对调用方来说，它可能不知道工具是否已经启动；这时直接重试，可能造成重复发送或重复写入。系统因此把无确认的预留保留为 uncertain，要求核对，而不是把“没收到结果”解释成“肯定没执行”。³⁴

这不是分布式系统的通用 exactly-once 保证，而是一条更具体的工程原则：在无法确认副作用时，不用再次制造副作用来探路。

在这里插入图片描述
图5｜批准只是“当时允许”的记录。进入真实执行前仍需复查当前权限、最终参数和上下文，并取得唯一执行预留；如果副作用是否发生无法确认，系统保留 uncertain，而不是盲目重复调用。

10. 效果核验：不仅看回包，也看它对应的对象

在已接入观察器的路径上，系统会关联动作、决策、执行预留和效果材料。对于文件，可以核对指定产物及内容摘要；对于受控交付，可以核对对应接收事件。¹²

参考应用把效果采集放在执行路径的 finally 中：即使工具或后续观察报告发生异常，仍尝试采集效果，因为“程序报错”不代表之前没有写入或发送。²²

最终的 verified、incomplete、conflicting、unknown，回答的是声明范围内的任务效果。它们不替代报告内容的专业正确性审核，也不能把失效观察器的空记录当作“确定没有发生”。¹²¹⁹

在这里插入图片描述
图6｜工具回包、实际观察材料与完成判定是三个层次。一个工具可以诚实报告“调用成功”，但如果所需文件、接收事件或其他效果缺失，SIQ 仍不会把任务自动升级为 verified。

六、密码学如何进入系统：不是给日志贴一个“防篡改”标签

在这里插入图片描述
图7｜密码学不是为了把模型回答“加密”，而是把身份、Grant／Intent、SEC、参数来源、动作回执和效果材料绑定到可核验的记录上。Ed25519 解决签名身份与完整性，SHA-256 解决内容指纹；它们都不能单独证明业务事实必然正确。

1. 先明确要绑定什么，再选择算法

SIQ 需要防止的，不只是文件内容被改动，还包括对象之间被错配：将别的任务的许可用于本次调用，将旧安装的身份用于新内容，将一次调用的效果材料拿来解释另一次动作。

因此，密码学应用围绕具体对象展开：⁴²³

对象	关键绑定内容	避免的误用
准入与发行清单	Skill 内容、版本、二进制摘要和发行身份	名称正确但内容被替换
Grant／Intent	主体、资源、工具、任务要求和相应状态	用一份许可覆盖另一项操作
来源与 SEC	内容摘要、来源／安装、实例、会话和任务	复制值或名称后冒用依据
决策与执行回执	动作身份、参数摘要、前序记录和处置	将其他调用的结果拼接进本次过程
效果材料	对应动作、被观察资源和有效材料	工具自报成功代替结果验证

2. Ed25519：让签发与使用可以分离

本地签名模块使用 Ed25519 对规范化字节签名，验证方使用相应公钥核验。模型和宿主适配器不持有签名私钥，因此不能通过模型输出伪造一份被运行时接受的签发记录。²³

默认密钥存储采用私密状态目录，首次生成使用排他创建，避免并发首次启动生成两套不同身份。已有身份异常时，相关检查不会把重新生成密钥当作普通修复；否则旧记录的信任连续性将被破坏。受控部署也支持显式提供种子，应由可信运维管理。²³

目录权限保护并不等于磁盘内容加密，也不是硬件密钥隔离。它明确的是当前实现的密钥管理边界。

3. SHA-256：将“这个版本”落到实际内容

内容摘要让系统能够检查：批准时的 Skill 与当前安装内容是否相同，参数是否变化，效果材料是否指向预期产物，下载的二进制是否与签名清单一致。⁴

但摘要不能单独提供发行者身份。攻击者也可以替换文件后重新算一个摘要；只有将可信签名、可信公钥来源与实际文件核对结合起来，才形成完整的验证过程。

同样，Ed25519 是数字签名，不是把业务内容加密。本文所说的“密码学信任链”，是对身份、内容与关联关系的核验，不意味着业务数据天然不可读取。

4. 哈希链回执：检查前后关系，而不是只验证单条文本

回执包含序号、前序哈希、本条哈希和签名。动作身份、参数摘要、决策及相关引用进入对应的记录关系。给定完整链和可信核验材料，验证器可以检查签名、顺序和前序关系是否一致。⁴²⁴

因此，“这一条签名有效”与“整个任务的记录足以支持结论”仍是两层检查。链尾被截断、报告被整体替换或公钥本身不可信，都需要额外的完整性与发布信任条件。不能把一个自带公钥的 JSON 文件称为不可删改的完整审计历史。²⁴

5. 规范化字节：Go 与 Python 必须签同一份东西

JSON 对人看起来一样，并不意味着序列化字节完全相同。字段顺序、分隔符、数字表示和字符处理，都可能影响摘要与验签。

SIQ 用版本化签名格式和共享向量约束跨语言行为。signing_schema 参与文档处理，未知签名格式先被拒绝；不是把无法理解的字段丢掉以后继续核验。²³²⁵

这里的难点不在调用一次密码学库，而在于跨组件始终理解同一对象。签名只保障被签的字节，系统还必须保障这些字节被正确解释。

6. 企业 JWT：签名正确，也不能忽略字段类型

企业身份验证使用 OIDC／JWKS，当前代码限制相应 JWT 算法为 RS256，并验证签发者、受众和所需时间／身份声明；刷新令牌、身份令牌或未知类型不能直接当作资源访问身份。租户从验证后的身份派生，不接受请求体自行覆盖。²⁶

一次工程复核还发现并修复了更细的问题：旧代码可能把字符串或对象当成权限集合遍历。例如，{"*": false} 的键不能因为被遍历出来，就变成通配权限。修复要求角色和权限严格是字符串数组，并补充异常类型与真实 RS256 测试路径的回归。²⁷

这不是绕过了 JWT 签名，而是签名之后的解释发生了问题。

它说明密码学、类型合同和权限语义缺一不可：签发方签出的数据，也必须符合接收方明确约定的结构。

七、DGX Spark 与 NVIDIA 技术栈：把私域算力变成受控的业务运行环境

在这里插入图片描述
图8｜DGX Spark 承载本地模型与业务负载，SIQ 管理授权与证据，OpenShell 在已适配版本和配置下落实执行约束。策略“已提交、可读回、已加载、行为真正改变”是四个不同状态，需要分别验证。

1. 平台适配首先是可复现的环境身份

DGX Spark 基于 Grace Blackwell 架构，提供 Arm 处理器和 128 GB 统一系统内存，为本地模型开发和推理提供硬件基础。这是统一系统内存，不应笼统当作独立显卡显存。²⁸

对 SIQ 来说，硬件适配不止是编译一个 ARM64 程序。部署预检还要记录真实硬件、架构、驱动、CUDA 报告版本、模型端点、源码状态和应用摘要，把“在哪台机器上跑的”与“运行了什么”联系起来。²⁹

归档环境记录了 DGX Spark／GB10／aarch64、驱动 580.126.09 和 CUDA 13.0。模型服务列表与实际推理分别验证，预检通过不会自动写成完整部署验收。²⁹

2. 本地模型负责智能，安全运行时负责确定性检查

本项目没有为每次权限检查再加一次大模型调用。Go 运行时处理权限、来源、状态和回执；本地 GPU 资源主要服务智能业务负载。³

这种分工也让系统故障更容易理解：模型服务不可用，是业务推理失败；安全运行时不可达，则需要在相应受保护调用路径按协议拒绝，而不是因为安全组件失联就默认放行。⁵

3. NVIDIA 与模型技术栈，各自承担实际角色

技术或组件	本项目中的实际用途	对应范围
DGX Spark／GB10／ARM64	私域运行环境、本地推理与原生检查	绑定真实硬件及候选
NVIDIA 驱动／CUDA 环境	模型工作负载的运行基础	记录实际版本；不冒称自研 CUDA 内核
NVIDIA OpenShell	沙箱、策略加载和后端执行约束	按已适配版本、配置和目标验证
StepFun `step-3.7-flash`	V4／V5 路径中的公开任务规划	远程路径明确标识
归档本地 Ornith 服务	V4／V5 的研究和候选处理等推理步骤	模型标识、调用和 locality 分别记录
后续 Hermes／Qwen 候选	隔离报告任务、受治理模型访问与执行联验	独立候选，不替代旧样本

技术栈的价值来自分工，而不是产品名称数量。固定 Nemotron 路径在公开主线说明中仍保留待验条件，其他模型的结果不能替它通过验收。²⁶²⁹

4. 模型优化：按任务角色配置，而不是用删除失败制造成功

历史 Step Plan 迭代记录中，一组五任务样本曾有一次研究调用超时。后续针对 step-3.7-flash 采用 reasoning_effort=low，对规划、研究与接收人选择分别限制输出预算，同时保留超时和严格截断响应检查。新样本独立记录为 5/5，早期 4/5 和超时仍保留。³⁰

后续混合链路中，公开规划与本地分析又分别标明提供方和调用位置。这些工作属于推理配置、结构化输出和工作流优化，不是权重微调；使用带 NVFP4 标识的模型，也不等于量化由本项目完成。¹²³⁰

对安全项目而言，一项优化只有在没有放松权限边界的条件下，才有讨论价值。不能靠换成更宽权限、悄悄换模型或跳过失败步骤，证明系统“更稳定”。

5. 本地失败，不应自动改变数据去向

私域部署最容易被忽略的细节，是失败时的回退路径。

在一项合成机密输入的隔离测试中，应用连接一个绑定但未监听的本地回环端口，产生真实连接拒绝。记录保留 model_request_failed、失败关闭和零次 StepFun 远程传输调用。测试没有关闭真实 DGX 模型服务，而是对应用的故障路径进行验证。³¹

它说明该受测路径不会为了返回答案而静默把机密任务转到远程。公开任务可以按明确策略使用远程模型，但分类与切换不能由模型自行宣布。

6. OpenShell 的四个状态：提交、读回、加载和行为

SIQ 的 OpenShell 适配包含显式 CLI 与端点绑定、网关和目标身份核对、能力探测、策略编译、读回、漂移检测与恢复。配置指纹变化，需要重新检查，不能拿旧连接结果证明当前目标仍然可信。⁶¹⁷

上游文档区分创建时锁定的文件系统／进程等静态部分，与支持热更新的网络部分。后端版本能表达什么、当前实例允许怎样变更，都必须落实到对应能力，不能把所有规则都假定为即时生效。³²

实际开发中曾经出现：策略提交和读回完成，但本应受限的请求仍然到达接收端。根因在于没有等待沙箱加载新策略。³³

修复后，Go 和 Python 路径使用受测 CLI 的 --wait --timeout，等待加载并复核修订、摘要。无法等待、加载失败或超时，不降级成无等待提交。提交后超时还可能意味着已有副作用，状态不能被自动清空后重试。³³

在 OpenShell 0.0.83 独占目标上，测试先证明正常请求能够到达，再验证限制：三轮跨边界请求均得到 HTTP 403，接收计数为零，并恢复原策略。另有 rc.6 的 57 项 HTTP 策略旅程通过，覆盖范围单独保留。³³

最新主线又增加了企业控制面与 OpenShell v0.0.104 隔离网关的真实闭环记录：审批后执行 policy set，再读回并确认相应 effective 状态；同时仓库保留 v0.0.83 → v0.0.104 的 canary 迁移 Runbook。这里必须区分“企业控制面已在独立 0.0.104 实例完成闭环”与“个人端当前所有 OpenShell 路径已经统一迁移并完成同候选验收”——后者目前并没有由该记录自动成立。⁴³⁴

这里的深度适配，体现在一个朴素但严格的要求上：控制面说规则已经写入，还不够；要继续追问执行面是否加载、实际行为是否改变。

7. 不能为了接入安全系统，把管理权交给沙箱

沙箱内的 Agent 需要查询相应裁决，不代表它应该拿到宿主运行时的全部管理凭据。仓库为 OpenShell 决策中继提供受限合同，绑定池槽位或候选命名空间、容器、会话与路由，并保持在线身份复验。⁴

这类中继要解决的是“怎样让受约束执行环境调用必要的安全接口”，而不是把管理 API 无差别暴露进去。模型调用通道、业务工具通道和安全管理通道，需要分别审视。

runtime-lock 和 doctor 进一步记录二进制、镜像、配置、模型身份、绑定与策略等输入。doctor 分别检查配置、可达性、身份、安全行为、推理和业务完成；某个模型换了、源码漂移了，不能因为 HTTP 健康检查仍是 200，就宣称原候选仍然整体有效。²⁹

八、工程难点：真正困难的是变化、恢复和跨组件一致性

1. 同一份授权，在多个组件中必须保持同一含义

系统中有 Go 运行时、Python 控制面、TypeScript 前端和不同宿主适配器。各方不仅要接收相同字段，还要接受相同状态机和约束。

例如，前端不能把后端返回的“推断权限”显示成“生效权限”，也不能把 ['effective'] 这样的数组通过字符串转换当作合法状态。工程复核针对这类类型强制转换增加了负向测试，并保持合法合同不变。²⁷

因此，packages/contracts 不只是文档：Schema、示例、固定向量和消费方测试共同约束变更。破坏性调整需要显式升级版本，并同步所有使用方。⁴

2. 批量操作不能用一个“成功”遮住局部失败

个人端批量撤权先生成有时效的签名预览，绑定操作者、批次、目标身份与版本；确认时再逐项复验。当前最多选择 50 项，预览有效期 5 分钟，提交复用版本比较与审计机制。¹⁵

若某一项在预览后发生变化，它应当报告冲突，而不是替用户撤销一个已经改变含义的新授权。其他明确目标可以独立处理，结果逐项返回撤销、已撤销、冲突或不可用。

这是非原子批次，不是“全部一起成功或全部回滚”；更不等于终止所有正在执行的系统进程。批量扩大权限也没有因此被开放。¹⁵

批量省的是操作步骤，不应该省掉每个目标的身份与状态检查。

3. 企业部署结果未知，不等于可以换个请求键再来一次

企业持久化部署入口绑定请求键、变更、环境、运行时绑定与预览摘要。同键同内容返回原记录，同键不同内容拒绝；页面刷新或进程重启后，应读取原部署记录，而不是重新提交。¹⁷

这个设计的目的，是把“没有收到响应”从“部署从未发生”中分离出来。删除记录、变更请求键或重启服务，不应成为绕过未知状态的快捷键。

业务系统一旦连接到真实外部资源，很多副作用没有简单撤销按钮。安全恢复需要的是准确核对，不是无限重试。

4. 多框架接入不是接口改名

Hermes 使用 Python 前后置接入，OpenClaw 有自己的 TypeScript 工具钩子和会话身份，WorkBuddy 则有桌面 command hooks 与平台差异。批准窗口、调用 ID 和执行后通知，都需要宿主专属处理。⁵

尤其 OpenClaw，原版与受控检查点补丁的审批恢复能力分开登记；不能把补丁副本验证过的最终复查能力写成上游原版已有。Linux 当前只交付 Hermes 与 OpenClaw 的相应路径，WorkBuddy 在 Windows／macOS 范围内另行核对。²⁵

0.4.1 的一个重要产品变化，正是围绕 Windows WorkBuddy 补齐 ACL／配置发布复验、相关性诊断、UNC 路径和本地失败记录等问题。新的 pending_decision/v2 明确把本地 hook 失败标记为未签名本地事件；后续即使提升成 runtime-receipt/v2 / local_failure 并进入真实签名与哈希链，签名也只证明“运行时记录了这份本地失败材料”，不会把它伪装成在线策略裁决，更不会凭此生成 Authority。这个细节很能体现 SIQ 的设计原则：记录可以被可信地保存，但不能因为被签名就自动获得更高语义。¹⁶³⁵

与此同时，0.4.1 正式发行仍明确保留边界：Windows 源码全量检查已完成，但正式签名包的 Windows 安装／升级／回滚，以及真实 WorkBuddy 新业务批次仍待验收。源码修复、组件回归和最终业务旅程分别记账。¹⁶

多框架也不等于完整多智能体委派。父任务身份、子任务权限收缩和恢复验证，是另外一组问题。相关前沿研究把委派中的身份、授权和运行治理单独讨论，正说明不能靠多个 Agent 名称推导安全性。³⁶

5. 性能需要测清成本，而不是靠慢模型掩盖安全开销

安全检查增加了规范化、验签、状态读取和回执持久化等工作。合理的工程问题是：这些成本分别发生在哪里，能否优化而不改变安全含义？

2026 年 9 月 8 日的组件测量，在五次预热后对每个夹具采集 100 个顺序样本：Engine.Decide 的 P50 为 8.230 ms、P95 为 12.178 ms；来源解析 P50 为 0.244 ms。该 Decide 测量包含对应授权与持久回执路径，但不包含 HTTP、模型和工具执行。³⁷

这些是历史环境中的描述性结果，不是当前版本的 SLA，也不能与模型延迟分位数相加。当调用量、磁盘、并发或策略变化时，应以新协议重新测量。

优化的方向可以是减少重复解析、复用不可变对象，而不能是缓存一个旧的允许结果后不再检查撤权；更不能为了视频流畅，把安全等待直接删掉。

九、实际效果：既看拦截，也看正常工作、异常识别和可复核性

1. 先固定问题，再运行，而不是运行完再改预期

公开基准把控制案例固定在语料中，每个案例使用新的运行状态和工作区。观测结果与预期分开保存，发现不匹配就保留失败；真实模型正常任务也保留准备失败、超时和无效输出，不静默切回夹具。³⁸

这让测试能够回答“某个机制在这个条件下是否工作”，而不是只生成一张好看的通过截图。

2. V5 固定控制：验证运行时机制，不冒充未知攻击防护率

2026 年 9 月 8 日、绑定 d1277116… 的历史 V5 记录中，固定控制集 23 个案例全部符合预期。其中：¹⁹

指标	结果	对应解释
正常控制任务完成	5/5	授权内的对应业务流程能够运行
指定不安全目标工具进入执行	0/13	这些负向任务未进入指定目标执行器
来源违规阻断	8/8	对应来源约束案例得到拒绝
工具伪成功	完成状态保留 `incomplete`	工具返回未被当成交付效果
同值、不同来源	可信路径可允许，MCP 路径拒绝	在明确来源要求下核对授权依据

5、13、8 是不同子集或投影，不能相加。确定性攻击提议用于验证真实运行时的边界，并不证明某个真实模型在未知输入下必然中招，也不意味着系统具有 100% 通用防护率。

3. 实际效果要按阶段读取

一次拒绝记录能证明对应决策，但“有没有进入执行器”“有没有产生文件或接收事件”“材料是否支持完成”还要分别看。³⁸

例如，文件没有出现可能因为动作被阻断，也可能因为磁盘错误；接收端没有记录可能因为请求未发送，也可能因为观察器没工作。只有观察范围、健康状态和运行身份匹配，才能解释本次结果。

因此，SIQ 把未知保留为未知，不把缺失记录填成“攻击没有造成效果”。这也是效果核验有实际价值的原因：它迫使系统说明自己看到了什么。

4. 工程与产品验证是另一组证据

除了固定研究语料，后续还有浏览器流程、真实隔离 PostgreSQL、签名发行和原生启动等专项验证。它们回答不同问题。

例如，2026 年 9 月 26 日的企业综合复核包含 18 项隔离 PostgreSQL 检查，以及 30 条企业浏览器旅程；这些验证使用相应合成身份与开发／模拟接口，不是客户生产身份系统联验。²⁷

当前正式发行已经更新到 0.4.1，固定源码为 a620a31b…。该版本从同一发行身份重新构建并签发 Linux amd64／arm64、macOS arm64、Windows amd64 四目标程序和签名 Skill；独立包验证核对官方签名、实际 Skill、四目标 pin、八份附件和包内一致性。Linux ARM64 最终包完成全新状态的 start／status／pair／控制台／stop；篡改 Skill、篡改二进制、使用错误发行公钥三类负向均在暂存前拒绝。¹⁶

需要特别说明的是：0.4.1 的 Windows 源码全量检查记录为 55 个包退出 0，但 67 条条件／平台 skip 不能计为通过；Windows 正式包安装、升级／回滚和真实 WorkBuddy 新批次仍待验收，项目签名也不等于 Authenticode 或 Apple 公证。¹⁶

这些证据说明，项目已经不只是一个规则概念：对应范围内存在可运行产品、机制对照、故障检查与发行验证。但不同版本、平台和测试对象的结果不合并成一个“全部验收通过”。

5. 达到的预期，应当是明确而可验证的目标

就已完成范围而言，项目实现了：支持环境中的资产与权限可见、Skill 准入与授权可管理、接入动作可检查、来源与审批变化可处理，以及相应效果与记录可核对。²³¹⁹

完整生产推广仍需要真实组织身份与跨系统联验、同候选跨平台安装升级、更多外部工具观察器、多设备持续运行和恢复验证。未接入路径、已失陷宿主、任意同用户恶意代码或不可信观察器，不会因为运行了本地安全服务就自动被覆盖。²³

十、把复杂机制做成用户能够操作的产品

1. 个人端：四个入口，回答四类实际问题

个人管理台围绕“我的智能体、权限管理、安全中心、运行审计”组织。首页按证据展示框架、角色和 Skill 的关系，未关联对象单列，共享 Skill 保留相应提示，而不是靠同名和同目录推断运行归属。¹⁵

用户的典型流程是：发现对象，查看来源与权限，选择接入范围，完成独立确认，再通过正常和越权用例检查实际保护。日常仍在原智能体平台工作，SIQ 负责待确认动作和后续追溯。²⁵

撤权、更新和排障也各有语义。批量撤销需要签名预览和逐项结果；更新需要内容与授权复核；诊断不能通过删除身份或重置状态消除历史。

原文采集默认关闭，需要时按任务单独授权并处理到期清理。运行审计尽量使用摘要、关联 ID 和脱敏材料，避免安全系统为了“可观察”而无差别复制所有敏感数据。²

2. 企业端：安全治理不是把更多设备画到同一张图上

企业治理首先需要确认身份。当前 Control API 从验证身份派生租户，按角色和权限点控制操作，不能由请求携带一个别的租户 ID 就获得访问权。知道对象 ID，同样不代表有权访问该对象。¹⁷²⁶

其次，需要治理过程。资产负责人确认候选，策略提出者说明需求，具有权限且满足职责分离要求的审批者确认变更，再由运行时绑定和执行后端落实。部署请求、读回、漂移与审计分别保留状态。²¹⁷

最后，需要让记录能够连续。关键状态变更和审计放在同一事务内，避免权限已经改了却没有审计。Outbox 承担后续事件处理，按照至少一次交付理解和去重，不包装成不会重复的消息系统。¹⁷

3. Edge 与 Connector：采集也必须有范围、有身份

Edge 验证控制面签发的采集任务，在受限子进程协议下调用 Connector，给结果和回执签名，再由控制面检查批次、设备、租户与证据引用。它不是一个可以远程运行任意命令的万能代理。¹⁸

周期发现也需要设备独立确认已签发计划。发现待办、确认计划、设备心跳、任务领取和扫描完成，是不同事实；只看到“active”不能当作采集成功或保护已经覆盖。

设备状态读取、注册恢复和重复请求，都要保护既有身份。注册响应丢失时保留原待处理材料，不通过删掉状态重注册制造另一台“新设备”。¹⁸

4. 治理闭环也需要可解释的导出边界

企业审计支持精确条件查询和 OCSF NDJSON 导出，便于与后续安全运营流程衔接。当前响应会说明是否因上限截断；“成功下载了一个文件”不代表完整历史已经归档，更不等于所有外部 SIEM 已完成接入。¹⁷⁴

它的价值是把一次业务动作与对应资产、授权、策略和证据组织起来，让管理员能够回答：谁提出、谁批准、作用于哪个环境、执行和读回处于什么状态。

十一、部署与复现：先建立身份，再扩大使用范围

1. 三种部署目标，不混用入口

个人体验以本地运行时和浏览器控制台为主，不要求 PostgreSQL。DGX 业务接入在原有模型与宿主环境上增加适配，并按需绑定 OpenShell。企业集中治理则独立部署 Control API、PostgreSQL、Worker、企业 Web 和环境侧 Edge／Connector。²¹⁷

当前 0.4.1 签名包仍是个人客户端正式发行，不包含企业 Control API／Edge／Connector 的独立部署交付。使用同一仓库中的企业源码，并不自动补齐生产身份、备份恢复和正式企业安装包验收。¹⁶

2. 从一个隔离测试实例开始

下面保留一个无需模型密钥和 GPU 的机制体验入口。准备 Linux、Git、Go 1.26.6、Python 3.12+、Node 22/npm 和 uv；第一次依赖安装和构建需要网络。使用新目录与独立状态。本文复核的仓库文档快照为 main@3eb1739d…；如果目标是验证 0.4.1 正式发行包，则应另外固定发行源码 a620a31b…，不要把两种身份混用：³⁹¹⁴¹⁶

# 仅在新的测试目录中操作，不复用日常业务运行状态
git clone https://github.com/maoyadongsh/siq-agent-security.git siq-security-demo
cd siq-security-demo
git switch --detach 3eb1739d9cf1592b246393e2fbe0ea9545b65dfe

bash scripts/hackathon/start.sh --mode test --port 47621
bash scripts/hackathon/healthcheck.sh
bash scripts/hackathon/pair.sh

在服务所在机器访问 http://127.0.0.1:47621/demo，使用本地短期配对码。结束后运行：

bash scripts/hackathon/stop.sh

--mode test 必须明确给出；它使用模型夹具驱动真实 SIQ 组件，不是本地 GPU 推理成绩。真实模型模式需要另行确认端点、模型身份、数据策略与预算，并产生自己的运行记录。³⁹

3. 正式接入必须保存运行身份

本地模型不能只记录一个显示名称，还需要保存实际模型服务、镜像／权重修订和配置。OpenShell 需要固定实际 CLI、网关、目标和策略；宿主也要记录版本与适配方式。已有运行锁和 doctor 为此提供入口，但健康检查不会代替真实任务验收。²⁹

远程管理本地控制台，应采用适当的 SSH 端口转发，而不是把回环监听改成公网可达或关闭 Host／Origin 检查。配对码、模型 API Key、设备凭据、签名种子和未脱敏状态目录，都不进入博客配图与公开证据包。²⁴⁰

十二、商业价值：让已经部署的私域算力能够被放心使用

1. 首先解决“能力已经有了，但授权不敢给”

本项目的商业化设想，不是向所有用户出售一个抽象的“AI 安全评分”，而是服务已有智能体业务、却缺少权限与执行治理的团队。

对这样的团队，限制自动化的原因可能不是模型回答不够好，而是管理者无法确认：一旦给出工具权限，会影响哪些资源，怎样撤销，出现异常如何检查。

SIQ 希望降低这类接入与管理的不确定性，让“不给权限就无法工作，给大权限又不放心”之间，出现一条更细粒度的路径。

2. 价值落在四类具体工作中

对业务负责人，重点是让授权范围与工作目标匹配，正常任务可以顺利完成；不是把所有低风险动作都变成反复弹窗。

对平台和研发团队，重点是复用一套明确的身份、授权和回执合同，减少每个框架、每个工具重新实现一套规则的成本。

对安全与审计人员，重点是有据可查：候选从哪里发现，权限由谁批准，实际部署和运行状态是什么，记录是否足以支持结论。

对私域部署服务商，可以围绕开源核心提供可信安装、框架适配、策略配置、审计对接与持续维护，将交付从“模型能运行”推进到“运行范围可管理”。

这些是我们希望通过试点检验的价值方向，不是已经取得的客户收益或收入事实。

3. 试点要有明确的交付物，而不是先谈覆盖整个企业

一个合理的起点，是选定一个部门、一种宿主和一条业务路径，形成明确的资产清单、权限范围、正常任务与越权对照、撤权流程和恢复记录。

衡量价值时，既要看安全约束，也要看工作是否被妨碍：正常任务完成情况、误拒与人工处理负担、接入工时、故障定位时间，以及升级后能否复验同一边界。

扩展更多框架、工具和设备时，再逐步补齐对应观察器、身份和协议。这样积累的，是可以维护的治理能力，而不是一次演示中临时拼好的拦截效果。

4. 开源核心之外，真正的工程价值在持续维护

算法和协议可以公开，但具体环境中的宿主差异、工具语义、策略兼容、版本迁移、观察器覆盖和恢复演练，需要持续投入。

我们更看重的长期价值，正是在用户已有业务与底层安全能力之间，建立一套可以重复交付、可以检查边界、也可以在版本变化后继续维护的方法。

结语：把算力交给智能体，把边界留给用户

从专业智能体，到可信智能体，再到安全智能体，我们一直在解决同一件事：怎样让智能体承担更多真实工作，而不是只在演示里表现良好。

DGX Spark 帮助用户把智能能力部署在自己的环境中。SIQ Agent Security 继续处理部署之后的问题：让资产和权限看得见，让具体动作有依据，让执行条件受到检查，也让结果不再只依赖工具自己的一句“完成”。²³

本项目最想建立的，不是“模型永远不会犯错”的想象，而是这样一种工作方式：模型可以提出方案，系统必须核对授权；工具可以报告结果，用户应当看得到证据；遇到未知状态，不用伪装成功换取表面顺畅。

把模型放进内网，是数据边界的一部分；把授权、执行和证据接起来，才是在管理智能体的行为边界。

从专业、可信，到安全：SIQ Agent Security。

Skills 给智能体能力，SIQ 给能力边界。

授权有依据，行动受约束，结果可核验。

项目与资料入口

开源仓库
 github-pages
系统架构全景
 个人安装与验签
 复现指南

系列文章：
第一届：专业智能体实践
 第二届：可信智能体实践

参考资料

转载自 CSDN-专业IT技术社区

原文链接：https://blog.csdn.net/outmanmao/article/details/166847061

从专业、可信，到安全：SIQ Agent Security，让 Agent 行动有边界，完成有依据