[Audit] Chat → Workflow 全链路问题汇总（55001e07a）

[eanz17]

Chat → Workflow 全链路问题汇总

公开 Discussion 版本。本文从五种既有审计中筛选 /api/chat、流式 Chat、通过 Chat 创建/执行/管理 Workflow 的相关问题；不是新的 finding 来源，严重级别、状态、证据和修复建议沿用对应原报告。

基线与口径

• 冻结源码基线：aevatarAI/aevatar feature/integrate@55001e07a。
• 汇总日期：2026-07-29。来源：现有综合 Review、Codebase Audit Suite、Tech Debt Audit、Code Audit、Audit Full，五种方法均已完成 1 个批次。
• Code Audit 为 deep 静态审计：确认 14 条 findings（P1 9、P2 5），逐项验证 180/289 个 HTTP endpoint/action；未覆盖的 109 个端点不应被解释为安全。
• confirmed、OPEN 等状态沿用原报告；Audit Full 和旧 F-* 未逐项提供新版状态字段，本文分别标为“最终报告收录”和“旧报告登记”。
• 多份报告描述同一根因时合并成一行，但保留全部来源 ID；源码位置仅复述原报告已经记录的证据。

结论摘要

当前 /api/chat 链路不只是“接口文档不完整”。入口层存在 standalone 匿名暴露、JWT audience fail-open、跨 scope run 查询与 fork；工具层存在审批旁路、默认远程执行、高影响 NyxID mutation 免审批、宿主级 LLM 凭据跨租户读写和 artifact owner 绕过；Workflow 控制面还可经 generic schedule 向任意 Actor 持久注入事件，同 scope 用户也能横向控制其他 member 的 run。可靠性方面，draft-run、fork/materialization、projection handoff 和 dedup 缺口会让 run 永久停住、不可见或重复执行。应先封闭身份与能力边界，再恢复 durable execution/observation，最后统一 authoring、SDK 与文档。

Code Audit 补充的组合攻击链

1. 进入链路： standalone Host 匿名开放（H-04/SEC-004），或 Mainnet 接受错误 audience token（M-01/CB-SEC-002/SEC-006）。
2. 枚举与取证： SEC-002 可跨 scope 枚举 run，并读取 output/error、审批状态和 scope/team/member/workflow/service 身份。
3. 复制或篡改执行： SEC-003 可复制其他 scope 的 YAML/variables 后 fork；SEC-001 可借 schedule 持久投递伪造的 stop/step-completed 事件，改变变量和分支。
4. 扩展数据访问： 已知 artifact ID 后，SEC-012 的 document/spreadsheet tools 可省略 owner 读取其他 run/scope 文件。
5. 扩大副作用： SEC-013 的 NyxID mutation tools 无人工确认；SEC-010 允许普通 scope 用户读取、替换或删除宿主级 LLM provider key；SEC-014 允许同 scope 横向读取和控制其他 member 的 run。

A. /api/chat 接入、鉴权与协议

优先级	问题与影响	来源 finding ID	代表性源码证据
High / P2	standalone Workflow Host 的 Chat HTTP/WebSocket 无授权保护。 匿名访问者可运行 LLM/Workflow、查询、schedule 和 service management；Code Audit 将默认条件定为 P2，暴露到不可信网络时升 P1。	H-04、SEC-004	Program.cs:20,45；ChatEndpoints.cs:31-45,1150,1173；ChatRunRequestNormalizer.cs:221
High / P1	legacy Workflow 查询与 fork 缺少 scope ownership。 可枚举并读取其他 scope 的 run 内容、审批和资源身份，再复制 YAML、variables、final error 与幂等状态执行副本。	H-05、SEC-002、SEC-003	ChatQueryEndpoints.cs:15,36,227；ChatEndpoints.cs:689；WorkflowForkRunCommandTargetResolver.cs:48,72,244
P1 / P2 / Medium	生产 JWT 缺少 Audience 时 fail-open。 三个非 Development compose 节点也没有 override；同 issuer 的其他 resource token 可能被 Chat/Workflow facade 接受。	SEC-006、CB-SEC-002、M-01	AevatarAuthenticationHostExtensions.cs:70,143,346；appsettings.json:3；docker-compose.mainnet-cluster.yml:54,101,148
P1	公开 quickstart 无法实际使用 /api/chat。 文档给出的 Host、5100 端口和无认证 curl 与实现不符，结果是连接失败或 401/403。	DOC-001	MainnetHostBuilderExtensions.cs:89,493-518；ChatEndpoints.cs:70-75,1026-1048
P1 / P2	Chat/SDK 文档发布失效路由，Host 注释又否认实际 Chat 能力。 `resume	signal`、actor query 会 404，维护者也会在错误 Host 排查。	DOC-002、DOC-010
P1 / Medium / P2	WebSocket、webhook 与 approval callback 缺少一致消息体上限。 Chat 分片可无限扩张 MemoryStream 并在结尾再次复制；公开回调在验签前整包缓冲。	SEC-005、M-04、M-11、DEBT-020	ChatWebSocketProtocol.cs:25,31,48,57；WorkflowWebhookIngressEndpoints.cs:180-184；WorkflowExternalApprovalCallbackEndpoints.cs:662-666

B. Chat 执行、工具与数据边界

优先级	问题与影响	来源 finding ID	代表性源码证据
High	Responses 本地工具执行绕过统一审批、凭据策略和执行审计。 模型输出可直接触发文件、网络或远程执行类副作用。	H-01	LlmRunCore.cs:336,355-356；ResponsesSafeToolExecutor.cs:8-17
High	Mainnet 默认把免审批 ssh_exec 加入 workspace 工具集。 提示注入或工具选择偏差可落到远程 shell。	H-02	MainnetHostBuilderExtensions.cs:328-332,374-399；NyxIdSshExecTool.cs:43,49,78
P1	高影响 NyxID mutation tools 默认不要求人工审批。 approve/reject、grant revoke、policy 修改、service 删除/credential rotation 和 provider/OAuth credential 管理可由模型直接调用。	SEC-013	IAgentTool.cs:33；ToolApprovalMiddleware.cs:53；NyxIdApprovalsTool.cs:16,58；NyxIdServicesTool.cs:81
P1	Settings API 可读取和覆盖进程级 LLM 凭据。 普通有效 scope 用户可读取、删除或替换宿主 provider key，响应还原样返回 ApiKey。	SEC-010	SettingsController.cs:20,24；FileAevatarSettingsStore.cs:42,68,85,101,142,580；SettingsService.cs:135,161
P1	零 chunk 流会再发第二次非流式 LLM 请求。 单次 Chat 可能双计费并得到两个答案。	DEBT-028	MEAILLMProvider.cs:177-190
P1 / P2	caller bearer 可发往任意 search backend，read-only tool fan-out 无并发上限。 配置错误可泄露 token，单轮模型输出可放大下游资源消耗。	DEBT-029、DEBT-033	WebSearchTool.cs:51-66；WebApiClient.cs:176-180；StreamingToolExecutor.cs:243-280
P2	Document/spreadsheet extraction 未强制 artifact owner。 已知随机 artifact ID 后可省略 owner，跨 run/scope 读取文件；这是 BOLA，不是路径穿越。	SEC-012	WorkflowDocumentExtractToolSource.cs:54,313,428；WorkflowSpreadsheetExtractToolSource.cs:43,202；FileSystemFileArtifactPort.cs:287,290
Medium / P2	Run stream 可能泄露内部 payload/异常，且隔离键文档互相矛盾。 客户端可能收到未脱敏 protobuf 或异常原文，SDK 也可能订阅错误 stream。	M-05、DEBT-024、DOC-005	EventEnvelopeToWorkflowRunEventMapper.cs:31-53,83-97；ScopeServiceEndpoints.cs:2143-2160,2260-2268

C. 用 Chat 创建、执行和管理 Workflow

优先级	问题与影响	来源 finding ID	代表性源码证据
P1	Generic schedule 可向任意 Actor 持久注入消息。 任意 JWT（standalone 可匿名）可指定 Actor 和 raw envelope，停止 run 或伪造 StepCompletedEvent 改变量与分支，并持续重复投递。	SEC-001	ScheduledDispatchEndpoints.cs:442,750,835；WorkflowRunGAgent.cs:1193,2622；WorkflowExecutionKernel.cs:317,377,488
P1	Workflow draft-run 的业务 owner 是 detached Task.Run。 持久化 Started 后进程退出会让 Chat 永远收不到终态回复；重复 start 又被忽略。	F-002、ARCH-006、DEBT-014	ChannelWorkflowDraftRunGAgent.cs:80-119；ChannelWorkflowDraftRunInteractionPort.cs:91-116
P1 / P2	fork、materialization、final snapshot 和临时 Actor 回收没有统一 durable continuation。 fork intent 可因 read model 尚不可见而丢失；accepted run 可能长期不可查询；失败被吞或留下临时 Actor。	DEBT-017、DEBT-018、DEBT-019、CB-LIF-001	WorkflowRunForkCoordinator.cs:32-81；WorkflowRunCommandTarget.cs:306-331；WorkflowRunFinalizeEmitter.cs:55-81
High	极深 inline Workflow YAML 可导致不可恢复的栈溢出。 能通过 Chat/authoring 提交 YAML 的调用者可使 Host 进程终止。	H-09	WorkflowParser.cs:24,110,204；WorkflowValidator.cs:576-585
P1 / P2 / Medium	memberId、workflowId、publishedServiceId 被混用。 Chat tool、HTTP、Studio 可能调用错误 service、查询错误 runs 或编辑错误 draft。	F-004、ARCH-009、DEBT-022、M-09	DefaultMemberPublishedServiceResolver.cs:15-23；ExecutionService.cs:93,108-113；studio/index.tsx:842-897
P1	Member service 路由只校验 scope，不校验 member authority。 同 scope 非 owner 可读取 published service/run/audit，并执行 invoke、resume、signal、stop。	SEC-014	ScopeServiceEndpoints.cs:64,75,85,88,92,829,832,1320,1442；AevatarMemberAccessGuard.cs:123,133
P2	同一 Team/Workflow 有多套调用和 authoring 编排。 HTTP、AI tool、Studio 返回不同 receipt/run/observe 语义；旧 /studio 与 canonical editor 又各自保存、发布、绑定和观察。	F-006、ARCH-010、DEBT-046	ScopeServiceEndpoints.cs:908,1904-1972；AevatarInvocationDispatcher.cs:328-354；useTeamMemberWorkflowStudio.ts:1682-1733,2395-2453
P2	Workflow SDK 稳定查询暴露 JsonElement。 Chat/Workflow 客户端只能依赖运行时属性名判断，契约漂移无法在编译期发现。	DEBT-021	IAevatarWorkflowClient.cs:24-37；AevatarWorkflowClient.cs:138,253

D. 会让 Workflow 管理结果不可信的底层根因

优先级	问题与影响	来源 finding ID
P1 / High	committed fact 到 projection feed 没有 durable handoff。 Workflow 已提交但 current-state/run 查询可永久不可见。	ARCH-001、DATA-001、DEBT-001、H-07
P1	batch state/version 错位、rejected write 仍推进 watermark。 管理界面可显示内容超前/落后或把未写入状态当成功。	ARCH-002、DATA-005、ARCH-003、DATA-004
P1	Kafka 重投幂等只依赖进程内 5 分钟缓存。 Chat/Workflow command 在 commit 后、offset commit 前重启可重复执行。	ARCH-004、DATA-002
P1	projection failure 破坏性保留且 replay 无生产入口。 Workflow 查询缺口不能自动修复，第 65 条失败会删除最旧恢复输入。	ARCH-005、DATA-006

E. 测试、整改与验收

• 关键保障缺口： TEST-001 的主流程只断言 202 accepted；TEST-004 没有浏览器登录 → workflow editor → publish → run → SSE → read model 的真实 E2E；M-15 记录当前全量后端和 Console 基线失败。
• 第一优先：封闭安全边界。 修复 SEC-001 至 SEC-006、SEC-010、SEC-012 至 SEC-014，以及 H-01/H-02；在此之前不要把 standalone Host 暴露到不可信网络，也不要让默认 workspace 承载高影响 mutation tools。
• 第二优先：恢复 durable workflow 语义。 处理 F-002/ARCH-006/DEBT-014、fork/materialization/finalization continuation，以及 projection handoff、watermark 和 durable dedup。
• 第三优先：统一产品契约。 删除 ID fallback 与 legacy routes，统一 HTTP/tool/Studio invocation 和唯一 authoring 入口，提供 typed SDK contract，并修正可执行 quickstart。
• 验收主链： 使用形态不同的 m-alpha / wf-alpha / svc-alpha，从带正确 audience、scope 和 member authority 的请求调用 /api/chat，创建并发布 Workflow，消费真实 stream，等待 committed terminal state 与 read model 同步；覆盖进程重启、重复投递、跨 scope query/fork/artifact、同 scope member 横向访问、schedule raw-envelope 注入、超限输入、tool approval 拒绝和 secret 不回显。

证据边界与未覆盖项

本文没有重新读取或修改源仓库，也没有执行 PoC、生产连接、数据库写入或外部状态变更。Code Audit 已完成 deep 静态审计，但仍有 109/289 个 HTTP endpoint/action 未逐项验证；模型是否服从间接 prompt、生产 issuer 的 audience 清单、外部代理限流和真实多节点故障恢复均未动态验证。高风险路径主要来自完整静态调用链与既有 build/test 结果，发生率、容量阈值和生产补偿能力尚未量化。

[eanz17]

我按 Discussion 的冻结基线 55001e07ac7961f7b793b06a2bc541ad30ea24a0，并对照当前本地 HEAD e53afe559d9dc527dcfe3b2be6cb5a153e32778f，重新走了相关调用链；H-09 另做了隔离进程复现。结论是：核心安全/可靠性 finding 大多真实，但有几处把“机制缺口”写成了尚未证明的最终结果，另有两处把文档、SDK 与实际路由混在了一起。

已确认、且当前 HEAD 仍存在的严重问题

我已按根因去重开票：

• SEC-001：generic schedule 接受 caller-supplied actorId + EventEnvelope；无 owner 时 caller scope 根本不参与 admission，payload 原样持久化并投递。见 #3044。
• SEC-010：Mainnet 映射 /api/settings；普通 authenticated caller 可 GET 完整宿主 LLM ApiKey，PUT 可替换/删除全宿主 provider 集合。见 #3037。
• H-01/H-02/SEC-013：Responses local tool 直接走 ResponsesSafeToolExecutor -> IAgentTool.ExecuteAsync，没有统一执行前 approval/credential-policy/audit gate；Mainnet 同时默认启用 ssh_exec 并设置 BypassSshExecApproval=true，NyxID 聚合 mutation tools 又继承默认 NeverRequire。见 #3038。
• SEC-006/CB-SEC-002/M-01：非 Development 缺 Audience 只告警不 fail closed；Mainnet appsettings 与 3 个 Distributed compose node 都未配置 API Audience。见 #3039。
• SEC-002/SEC-003/SEC-014：legacy workflow query/fork 缺 caller-scope ownership；member-first query/invoke/resume/signal/stop 基本只做 scope guard，只有 retry-compensation 做了 member guard。见 #3040。
• H-09：不是纯静态猜测。临时隔离 xUnit probe 中，100 层 steps.children 正常，500 层使 testhost 直接以 YamlDotNet Stack overflow 中止；probe 随后已删除。见 #3041。
• ARCH-001/DATA-001/DEBT-001/H-07 + rejected-write watermark：event-store commit/snapshot 在前，stream publish 在后，没有 outbox/cursor；源码还明确说明 committed feed 是 live-forward-only。多数 projector 又忽略 ProjectionWriteResult.Gap/Conflict，上层仍把版本记成 successful。见 #3042。
• F-002/ARCH-006/DEBT-014：draft-run 先持久化 Started，再把唯一执行 owner 放进 detached Task.Run；重启后相同 start 被 Started 分支丢弃，无 activation recovery。见 #3043。

确认存在，但没有另开 blocker issue

• SEC-005/M-04/M-11/DEBT-020：WebSocket 聚合 MemoryStream 无消息上限并在结尾 ToArray；callback/webhook 也在验签/处理前整包缓冲。静态路径成立，未做容量压测。
• SEC-012：document_extract / spreadsheet_extract 接受只含 artifact identity 的显式 file_ref；request 的 run/scope 没有绑定进读取，store 只有 caller 实际提供 owner 时才比对。BOLA 定性成立；随机 artifact id 是利用前提，所以我保留 P2。
• DEBT-029/DEBT-033：caller bearer 可进入配置的 search URL；所有 concurrency-safe tool 可同时启动，没有数量 semaphore。机制成立，但真实泄漏取决于配置，资源放大量也未压测。
• M-05：unknown workflow envelope 会生成带原 protobuf payload 的 aevatar.raw.observed；Scope stream 在 response 已开始后也会把普通 ex.Message 发给客户端。泄漏面成立。隔离键文档是否导致实际错订阅，我没有单独做运行时复现。
• DEBT-017/018/019/CB-LIF-001：fork hook 对失败只 log 后返回，materialization-gated reclaim 仍是 detached task，timeout/unknown 会留下 actor，final snapshot query 异常被吞成 unavailable。路径真实；“必然永久丢失”的发生率需要 restart/fault-injection 才能量化。
• F-004/ARCH-009/DEBT-022/M-09：身份混用不是整条都原样存在。Mainnet 最终 DI 使用 StudioAwareMemberPublishedServiceResolver，会先读 member read model；但 missing/empty authority 仍 fallback 到 publishedServiceId = memberId，且 member route caller authority 仍缺失。因此根因部分成立，不能笼统说所有路径仍只做等值映射。
• F-006/ARCH-010/DEBT-046：多套 invocation/authoring surface 的结构性重复真实，但本次没有复现一个可独立描述的错误结果；我把它视为架构债，而不是从代码数量直接推出 P2 bug。
• DEBT-021：SDK public query contract 仍返回 JsonElement，成立。
• ARCH-005/DATA-006：failure state 只保留 64 条并删除最旧 envelope；IProjectionFailureReplayService 有内部实现但仓库没有生产 HTTP/admin 入口。成立。

我不同意或需要收窄的表述

1. H-04/SEC-004 不能写成“standalone Chat HTTP/WebSocket 都可匿名执行”。 standalone Host 的确没有注册 ASP.NET Authentication/FallbackPolicy，WS、generic schedule、query 等路由没有统一 auth。可是当前 POST /api/chat 自己调用 ResolvePostTrustedScope：认证未启用返回 403，未认证返回 401，缺/多 scope claim 也 fail closed。因此 HTTP Chat 不是匿名可执行；WebSocket 没有同等 gate，其他 control/query surface 也仍有问题。应拆开描述。

2. H-01 的“绕过执行审计”太绝对。 local tool 确实绕过统一 middleware，尤其缺少执行前 admission；但执行后会调用 RecordToolCallObservedAsync 记录 tool call/result。准确说法应是“绕过统一执行前 safety/credential/audit gate，只有副作用后的 observed record”。

3. DEBT-028 的“两次请求得到两个答案”不准确。 zero-chunk stream 后确实会再发一次 non-streaming request，存在双请求/潜在双计费；但第一条流没有 chunk，客户端只收到 fallback 的回答，不会同时收到两个答案。

4. ARCH-004/DATA-002：机制确认，结果表述过宽。 Orleans/Local 默认 MemoryCacheDeduplicator 的确只有进程内 5 分钟 TTL，重启清空；但部分 actor 另有持久化 LastCommandId / effect idempotency ledger。因此不能仅凭 transport dedup 就断言所有 Chat/Workflow command 都会重复产生业务副作用；需要逐 actor 的 commit-before-offset-restart fault test。底层防线仍明显不足。

5. DOC-002 应区分“文档坏了”和“SDK 坏了”。 docs/canon/sdk-dotnet.md 仍发布已删除的 /api/workflows/resume|signal，这部分会 404；但当前 SDK 的 ResumeAsync/SignalAsync 实际使用已映射的 scope-first /api/scopes/{scopeId}/services/{serviceId}/runs/{runId}:resume|signal，current-state query 使用的 /api/workflow-actors/{actorId}/current-state 也确实被映射。不能说当前 SDK 这些调用本身都会 404。

6. DOC-001 的最终结论成立，但原因需写清。 README 启动 standalone Workflow Host 后请求 5100；仓库没有对应 launch/application URL 绑定，所以通常先连接失败。即使端口手工绑定，当前 HTTP Chat 的 trusted-scope gate 也会让无认证 curl 返回 401/403。这和“H-04 HTTP Chat 匿名执行”互相矛盾，后者应修正。

其余

• projection “batch state/version 错位”这一子项我没有单独构造 batch PoC；本次确认的是 non-durable handoff、ignored rejected write、watermark 与 failure retention。
• TEST-001/TEST-004 属于覆盖缺口，源码证据成立；M-15 的全量 backend/Console baseline 我本次没有重跑，因此不对当前 HEAD 的全量红绿状态背书。
• 本次没有连接生产、没有写数据库，也没有执行外部副作用；除上述 GitHub issues/comment 外均为只读检查，H-09 只在独立 testhost 中复现。