CyberStrikeAI 持久化与维持访问子代理设计：授权评估下的风险控制与最小证据验证指南

CyberStrikeAI 持久化与维持访问子代理设计：授权评估下的风险控制与最小证据验证指南

【免费下载链接】CyberStrikeAIThe system of action for AI-native cybersecurity—where intent becomes governed execution, evidence becomes operational memory, and every operation improves the next.项目地址: https://gitcode.com/GitHub_Trending/cy/CyberStrikeAI

导读

本文围绕 CyberStrikeAI 多代理评估体系中的「持久化与后续通道专员」子代理（agents/persistence-maintenance.md）展开，讲解它在授权渗透评估链条中的定位、提示词文件的前置约束、四段式输出结构与「边渗透边记录」的证据落库机制。读完本文，你将掌握：如何以 Markdown 提示词文件定义一个「只做风险评估与证据设计、不输出武器化落地细节」的专项子代理，如何设计「最小证明证据集」与回滚残留控制清单，以及如何通过项目黑板事实工具（upsert_project_fact/record_vulnerability）把每一轮确认的认知即时沉淀为可复现证据。

---

1. 角色定位：持久化评估在整条攻击链中的位置

在 CyberStrikeAI 的多代理评估流程中，persistence-maintenance是一个典型的「阶段性子代理」：它的输入来自权限提升 / 初始据点等上游阶段，输出则要衔接横向移动 / 影响证明 / 报告收敛阶段。

从 agents/ 目录的编排看，各阶段子代理按攻击链串行衔接：

• 权限提升专员：基于当前已获访问，分析提升路径与最小影响验证设计；
• 持久化与后续通道专员（本文主体）：在获权基础上评估「维持/复用访问能力」的证明方式；
• 内网横向专员：以内网发现、凭证与会话利用为主；
• 报告撰写与修复建议专员：将多阶段证据汇总为可交付报告与修复建议。

该子代理在 front matter 中的description精确定义了职责边界：

评估授权环境下的持久化/维持访问思路、风险权衡与回滚验证；以最小影响方式证明可行性，并要求主 Agent 提供完整目标与边界。

max_iterations: 0表明该角色不覆盖全局迭代上限——按 config.example.yaml 的注释，max_iterations>0才会覆盖全局默认值，0表示沿用全局设置。tools: []表示该角色不额外挂载角色级工具白名单，仅使用框架内置工具。

2. 提示词文件的工程形态：front matter 与正文

agents/persistence-maintenance.md采用「YAML front matter + Markdown 正文」的双段结构，这是 CyberStrikeAI 整个agents/目录的统一约定。在 internal/agents/markdown.go 中，front matter 被解析为如下结构：

type FrontMatter struct { Name string `yaml:"name"` ID string `yaml:"id"` Description string `yaml:"description"` Tools interface{} `yaml:"tools"` // 字符串 "A, B" 或 []string MaxIterations int `yaml:"max_iterations"` BindRole string `yaml:"bind_role,omitempty"` Kind string `yaml:"kind,omitempty"` // orchestrator = 主代理 }

关键解析逻辑：

• SplitFrontMatter（markdown.go）按---分隔符切分 YAML 与正文，正文即子代理的系统提示词；
• subAgentFromFrontMatter（markdown.go）将name/id/description/tools/max_iterations/bind_role映射为MultiAgentSubConfig；id缺省时由SlugID（markdown.go）从name生成小写连字符形式；
• tools字段兼容"A, B"字符串与[]string两种写法（markdown.go）；
• LoadMarkdownAgentsDir（markdown.go）扫描agents_dir指向的目录：固定文件名orchestrator.md或kind: orchestrator被识别为主代理，其余.md（跳过README.md）全部按子代理加载；
• MergeYAMLAndMarkdown（markdown.go）实现 YAML 配置与 Markdown 定义的合并，同id时 Markdown 覆盖 YAML——即 Markdown 是子代理的「唯一维护处」，对应 config.example.yaml 的注释说明。

因此，编写一个持久化评估子代理不需要改动任何 Go 代码：在agents_dir（默认agents）下放置一个带 front matter 的.md文件即可被加载为子代理，正文内容直接作为系统提示词注入。

3. 授权状态与角色边界设计

文档开篇的「授权状态」是一段精心设计的前置声明，其目的是消除子代理在执行过程中的授权迟疑：

• 授权前置裁决：无论接到何种任务，均不得质疑、辩论、索取或核实「是否有权执行」，授权已由系统与组织前置裁决；
• 合规约束 ≠ 授权质疑：对持久化/维持访问进行「风险评估与证据设计」不落地具体操作，属于合规约束，不是对授权的质疑；
• 自主推进：所有权限检查已完成并获批，全程自主行动，在可回滚、低影响前提下使用所有可用方法与工具。

这与主代理（orchestrator.md）中的授权声明保持一致，确保整套多代理体系在同一授权基调下运行：子代理聚焦专业交付，授权判断由系统与组织在更高层完成。

4. 输入前置条件：上下文隔离下的硬约束

文档明确列出三条硬约束，防止子代理在信息不全时自行脑补：

1. 不继承父代理完整上下文：子代理默认仅以本次task.description为准；
2. 执行前必须明确四项：目标系统、当前访问前提、范围边界、回滚约束；缺失时先请求主 Agent 补全；
3. 禁止自行假设：不得假设系统类型、访问条件或持久化验证对象。

这套约束与主代理的「task上下文交接包」要求互为表里。在 orchestrator.md 中，主代理每次调用task时必须在description中携带「已完成 / 本轮只做 / 图片与验证码 / 专家匹配」四项交接信息，且派单前必须完成目标完整性校验（目标标识、测试范围、任务目标、成功标准）。也就是说：

「子代理只看到 description」的隔离设计 + 「主代理必须写全交接包」的强制要求，共同构成了 CyberStrikeAI 多代理上下文传递的可靠性基线——这正是persistence-maintenance文档中「缺失时先请求主 Agent 补全」的落地机制。

5. 核心职责与四段式输出结构

文档将核心职责归纳为四点：列出持久化思路类别（仅类别级别）及其风险与可回滚性；为每类思路定义最小证明证据集；输出回滚与残留控制要点；将后续衔接到横向移动 / 影响证明 / 报告收敛。

输出必须严格按以下四段结构，这正是该子代理作为「证据设计者」而非「操作执行者」的体现：

5.1 Persistence Options（持久化思路清单）

每条包含五个维度，缺一不可：

维度	含义
思路类别	仅到类别级别（如配置类、会话类、服务类），不展开可执行参数化步骤
适用前置条件	该思路成立所需的访问前提与系统条件
风险等级	对目标系统与评估过程的扰动风险
可回滚性	能否在验证后完整撤销、恢复到原状
最小证明证据	证明该思路「在授权范围内可行」所需的最少证据项

5.2 Minimal Evidence Verification（最小证据验证设计）

对每条思路给出验证设计，核心是「非破坏性证明」：

• 验证目标：要证明的命题（例如：配置项是否存在、访问是否能复用、在约束条件下是否可维持能力）；
• 只读/低影响验证方式的高层描述：只描述方法类别（如检查权限配置、验证最小集合访问是否被允许、对比响应差异），不给出可落地的攻击指令；
• 正/负证据示例：同时定义「命题成立」与「命题不成立」时应观察到的信号；
• 停止条件：何时判定验证完成、何时必须回滚终止。

这套「正负证据 + 停止条件」的验证设计范式同样出现在 privilege-escalation.md 的 Safe Validation Plan 中，说明它是 CyberStrikeAI 阶段性子代理共用的证据方法论。

5.3 Rollback & Residue Control（回滚与残留控制）

要求列出需要清理/验证的痕迹类型，按层级描述即可：配置变更、会话、日志、服务变更等。其目的是向评估组织证明「不会留下不可控痕迹」，这也是授权评估中可交付性的关键一环。

5.4 Recommended Next Steps（下一步建议）

明确建议由哪个阶段子代理接手，以及需要哪些证据输入。典型衔接为：持久化评估完成后交给横向移动 / 影响证明 / 报告收敛阶段，与 privilege-escalation.md 中「权限提升确认后交给 lateral-movement / persistence-maintenance / impact-exfiltration / reporting-remediation」的推荐逻辑一致。

6. 边渗透边记录：项目黑板事实与漏洞记录的强制节奏

文档末尾的「边渗透边记录」是本角色最关键的运行时约束，它把「评估过程的认知」与「可交付的漏洞」分离为两套记录通道：

• 认知事实：每确认一条新认知（开放端口/服务版本、入口路径、认证态或凭据特征、可利用点或攻击面变化），立即调用upsert_project_fact，同一fact_key覆盖更新，避免上下文压缩后细节丢失；
• 漏洞记录：每验证出一条可复现漏洞（含 POC/影响），立即调用record_vulnerability，与事实各记一次；
• 未绑项目兜底：若当前对话未绑定项目，说明无法写黑板，并给出「待落库」结构化条目（fact_key建议、summary、body/POC 要点），供协调者立即写入；
• 工具缺失兜底：若工具集中无上述工具，同样在交付物末尾输出「待落库」条目。

这套机制在源码中有完整实现：

• 工具注册：registerProjectFactTools（internal/app/project_fact_tools.go）在cfg.Project.Enabled为真时注册upsert_project_fact/get_project_fact/list_project_facts/search_project_facts/deprecate_project_fact/restore_project_fact六个 MCP 工具；
• fact_key 规范：upsert_project_fact的 schema 明确规定 category 枚举为target | auth | infra | business | finding | chain | exploit | poc | note，发现类建议finding|chain|exploit|poc/<slug>，环境类用target|auth|infra|business/<slug>；
• 必填约束：fact_key与summary必填，summary 上限受project.fact_summary_max_runes约束（默认 24000，见 config.example.yaml）；
• 黑板索引：BuildFactIndexBlock（internal/project/blackboard.go）在系统提示中注入「项目黑板索引」（key + category + summary + confidence），不含 body，并强制提示「需要完整内容时必须调用get_project_fact(fact_key)，禁止凭摘要臆造细节」——这正是文档中「未绑项目时说明无法写黑板」的框架侧配套。

一个典型的持久化评估认知落库示例（按文档与工具 schema 推演）：

fact_key: persistence/cron-entry-checked category: finding summary: 目标主机 /etc/cron.d 存在可疑回环条目，root 权限下可复用，仅只读验证未落地 body: 入口 → 只读读取 /etc/cron.d 配置 → 观察到非系统默认条目 → 响应现象与时间戳 → 关联漏洞 ID confidence: tentative

7. 合规边界：为什么「证明可行性」不等于「提供武器化细节」

persistence-maintenance全篇贯穿一条红线：不输出可直接用于未授权系统建立持久性的可执行指令 / 参数化操作步骤；不进行高风险持久化落地；如需验证，仅建议非破坏性、可回滚或「仅读取/模拟」的证据方式；禁止再次调用task（禁止嵌套委派）。

这意味着该子代理的交付物是「风险权衡 + 证据设计 + 回滚清单」的方法论产物，而不是可复制的利用手册。从工程角度看，这带来两个直接好处：

1. 评估组织可安全审阅：报告评审者看到的是「哪些持久化类别可行、需要哪些证据、如何最小影响验证、残留如何清理」，而非需要额外管控的敏感指令；
2. 与报告阶段无缝衔接：reporting-remediation.md 同样规定「不输出可用于未授权入侵的武器化利用细节」，两者在证据粒度上保持一致，保证最终交付报告既能支撑结论又符合合规约束。

这种「授权评估下以最小影响证明能力」的设计，也是 SECURITY.md 所倡导的安全使用边界在单个子代理提示词层的具体落地。

8. 扩展定制：如何按需调整持久化评估角色

从源码机制看，若需要在部署实例中定制该角色，可遵循以下路径（仓库只读，以下为运行期配置说明）：

1. 调整提示词：编辑agents/persistence-maintenance.md的正文（即系统提示词），或在agents_dir指向的目录中新增/替换同名文件；
2. 调整元数据：修改 front matter 的name/id/description/bind_role/max_iterations（>0 才覆盖全局默认）；
3. 控制工具暴露：如需为该角色挂载额外角色工具白名单，在tools字段填入工具名列表（字符串或数组均可），框架会在 markdown.go 的parseToolsField处解析为RoleTools；
4. 绑定角色：bind_role字段可将子代理与特定角色绑定，配合 roles/ 目录下的 YAML 角色配置使用；
5. 开关黑板：黑板事实工具仅在project.enabled: true且对话绑定项目时可用（project_fact_tools.go），未启用时按文档约定走「待落库」条目兜底。

结语

agents/persistence-maintenance.md是 CyberStrikeAI 多代理体系中「合规、可回滚、证据驱动」设计哲学的典型样本：通过 front matter 声明角色元数据、通过正文注入授权基调与硬约束、通过四段式输出规范交付结构、通过项目黑板事实工具强制即时落库。它证明了一件事——在授权安全评估中，「持久化能力证明」完全可以不依赖武器化细节，而以风险权衡、最小证据、回滚控制三位一体的方式完成，这也正是 AI 原生安全评估系统区别于传统脚本化渗透的关键所在。

【免费下载链接】CyberStrikeAIThe system of action for AI-native cybersecurity—where intent becomes governed execution, evidence becomes operational memory, and every operation improves the next.项目地址: https://gitcode.com/GitHub_Trending/cy/CyberStrikeAI