Optional host-owned ToolRuntime attestation and settlement anchor for external plugins

[mohammedmessaoudene-cmd]

I tested a private external authority/evidence plugin against DeepSeek Harness
at commit 99f6f02fecdb7dff40c3fbc9470f5907c29f74ca. The external plugin alone can
bind authority decisions and effects, but an observe-only result hook cannot
make settlement mandatory.

I therefore prototyped a small optional ToolRuntime contract on the official
ToolRuntime path under host-approved plugin composition. The host lists exact
required anchor IDs; the runtime snapshots the visible tool definition and
monotonic anchor generations; it rechecks the captured generation immediately
before the body; and synchronous settlement completes before success is
published. A rejected or unwritable settlement becomes the final error instead
of allowing a success to escape. Duplicate IDs and pre-body disposal fail
closed. Empty configuration preserves current behavior.

The external profile now separates its AUEC-only verdict from the host pipeline
disposition and from the effect disposition. Before the exact body starts, a
downstream host denial settles as not_attempted; after beforeExecute, absent
provider evidence remains outcome_unknown. Without the optional anchor, the
plugin labels itself observe-only and makes no body-start claim.

Local evidence includes plugin tests, 21/21 translated vectors, a real Session
persistence/replay/fork test, a private bundle install plus headless boot, and
the targeted ToolRuntime anchor suite. The previously observed 43 full-suite
failures on Windows remain bounded; the POSIX lane is NOT_TESTED.

The boundary is deliberately narrow. It covers official ToolRuntime calls under
host-approved plugin composition and binds the exact definition and anchor
generation through settlement before publication. It does not contain arbitrary
same-process code or direct ToolDefinition.execute calls, and it is not an OS
sandbox. This is a private external prototype, not production-ready software,
independent validation, a security kernel, or evidence of DeepSeek/MCP adoption.

Is a small optional host-owned ToolRuntime attestation/settlement anchor
compatible with the lifecycle, or should this remain an external profile?

AI assistance disclosure: this discussion and the private prototype were
prepared with ChatGPT/Codex assistance and were human-reviewed. I remain
responsible for the claims.

[zoahdev]

Verified against the ToolRuntime lifecycle at HEAD 99f6f02 (rc.7). Short answer: yes, compatible — and the existing lifecycle already contains the exact seams the prototype needs, so it can ship as a host-approved plugin today without a new core hook.

1. Your "observe-only result hook cannot make settlement mandatory" claim is correct and worth pinning down. packages/core/tools/src/index.ts:1630-1652 — notifyResult is explicitly observe-only: "Notify observers without exposing a mutation or error channel into the outcome", and listener failures are contained (reportFailure → warn). The tools/result contract (index.ts:198-202) is @mode emit. So settlement cannot ride result observers.

2. But the lifecycle has three other seams that cover both of your timing requirements today:

• Pre-body recheck ("immediately before the body"): tools/execute is an around-dispatch waterfall (contract at index.ts:153-160, invoked at dispatchScheduledExecution index.ts:1562-1564 wrapping dispatchToolBody). A host-owned wrapper runs directly before tool.execute; throwing there materializes as an error result. tools/pre-execute (index.ts:143-151) is the allow/deny/ask gate even earlier.
• Settlement before success is published: tools/post-execute (index.ts:162-175) is a waterfall that can "accept, replace, enrich, or block" the normalized dispatch result, and it runs before finalizeScheduledExecution → notifyResult. A throwing listener becomes the final error — success never reaches tools/result. That is exactly "rejected/unwritable settlement becomes the final error instead of allowing a success to escape".
• The tools/execute wrapper may change only exec.signal; call identity is immutable (index.ts:153-160) — which actually constrains an anchor snapshot: you cannot smuggle per-call anchor state through the execution object, so the generation snapshot must live host-side keyed by call identity. Worth stating explicitly in the contract.

So the genuinely new part of your prototype is not the lifecycle — it is the vocabulary: what anchor IDs mean, how "monotonic anchor generations" are derived, and who the verifier is when the host merely lists required IDs. That is precisely where #3192 CHA2A should own the attestation semantics (L1 content integrity + verifier-local policy), otherwise the ecosystem gets a third incompatible attestation dialect alongside CHA2A and the existing provenance proposals.

3. Positioning caveats that align with what we already documented: this is policy, not a security boundary — same principle as the dsh-crew discussion (#3212: a textual allow-list is a policy seam, not an OS sandbox). Keep the "not an OS sandbox" disclaimer in the docs. Fail-closed on duplicate IDs and pre-body disposal matches the corrupt-artifact family's fail-loud convention; empty-config-preserves-behavior matches the optional-seam convention used by #3186/#3191/#3167.

Recommendation: publish the prototype as an external profile plugin using tools/pre-execute + tools/post-execute (zero core changes) to prove the settlement semantics in the wild; then propose the contract formally and align the vocabulary with CHA2A before any core adoption. The three-way separation (AUEC verdict / host disposition / effect disposition) is sound — it is the same separation of verifiable claims from local policy that CHA2A argues for.

[mohammedmessaoudene-cmd]

Thanks — I rechecked the rc.7 path, and your lifecycle routing is correct. I will drop the proposed core-anchor requirement and refactor the prototype onto the existing seams:

• tools/pre-execute: compute the AUEC profile verdict and record requestedAuthority, hostAllowedAuthority, effectiveAuthority, and the denied/reduced delta;
• tools/execute: revalidate immediately before delegation, with per-call state kept host-side and keyed by the registry-owned execution token rather than added to exec;
• tools/post-execute: perform settlement and block or throw if the authority/effect link is rejected or the evidence write fails;
• tools/result: final observation only.

I will keep the boundary narrow: official ToolRuntime calls under host-approved plugin composition, not an OS sandbox and not containment of arbitrary same-process code.

The remaining design question is vocabulary and verifier ownership. My current split is:

• CHA2A: attestation envelope, content integrity, verifier identity, and verifier-local policy;
• AUEC profile: auecProfileVerdict, requestedAuthority, hostAllowedAuthority, effectiveAuthority, denied/reduced delta, hostPipelineDisposition, and effectDisposition.

Would you prefer this to be proposed as a CHA2A claim/profile in #3192 — including verifier-owned tool/generation identity — rather than publishing a separate AUEC envelope first? I can bring a minimal schema and the existing 21-vector mapping there.

I’ll refactor the external plugin on that basis before publishing code.

[wwumit]

Following up on zoahdev's point about vocabulary ownership: the CHA2A proposal already reserves the runtime-attestation vocabulary this prototype needs. #3192 §4.7 "Runtime attestation vocabulary (reserved)" maps the registry side to the runtime side:

• contentIdentity (what is shipped) ↔ anchorId / anchorGeneration (what runs, captured at execution)
• L1 integrity attestation ↔ settlement before success publication
• revocation / deactivation ↔ generation monotonicity / disposal fail-closed

The section explicitly states the intent: "this section pins the shared terms so ecosystem proposals do not develop separate dialects." It also covers verifier attribution for the "host merely lists required anchor IDs" case: the verifier is the host's local policy (same principle as CHA2A §4.6 verifier-local policy), and implementations should expose which anchors the local policy trusts.

So the vocabulary home is already there — aligning the prototype's terms with §4.7 when you publish would keep this as one dialect rather than a third one. Happy to iterate on the mapping if the anchor semantics need refinement.

[mohammedmessaoudene-cmd]

Thank you — this resolves the vocabulary-ownership question clearly. I will revise the external profile so it uses the CHA2A §4.6–§4.7 terms rather than introducing parallel AUEC names: - shipped/build identity → `contentIdentity`; - runtime registration identity → `anchorId`; - monotone registration snapshot captured for the call → `anchorGeneration`; - removal or replacement before the tool body → fail closed; - trusted-anchor selection and verifier attribution → the host’s verifier-local policy, exposed by the profile. The AUEC-specific layer will remain limited to the requested → host-allowed → effective authority relation, its denied/reduced delta, exact decision/action binding, and the separation between AUEC verdict, host disposition, and effect disposition. Implementation-wise, I will follow @zoahdev’s lifecycle mapping: policy at `tools/pre-execute`, generation snapshot/recheck around `tools/execute`, and mandatory settlement at `tools/post-execute`, with no new core hook. One semantic point I would like to confirm while updating the vectors: if an anchor is disposed or replaced before the body starts, the call should fail closed; once the body has started, should settlement remain bound to the captured generation even if deactivation occurs concurrently, so the historical evidence is not retroactively invalidated? That is the contract I currently intend to test. Thank you for offering to iterate. I will bring back the updated mapping and two-sided vectors rather than a competing dialect. AI-assistance disclosure: ChatGPT and Codex assisted with analysis and drafting. I reviewed the mapping and remain responsible for it.

…

On Wed, 19 Aug 2026 09:06:24 -0700, Wei Wu ***@***.***> wrote: Following up on zoahdev's point about vocabulary ownership: the CHA2A proposal already reserves the runtime-attestation vocabulary this prototype needs. [#3192 §4.7](#3192) "Runtime attestation vocabulary (reserved)" maps the registry side to the runtime side: - contentIdentity (what is shipped) ↔ anchorId / anchorGeneration (what runs, captured at execution) - L1 integrity attestation ↔ settlement before success publication - revocation / deactivation ↔ generation monotonicity / disposal fail-closed The section explicitly states the intent: "this section pins the shared terms so ecosystem proposals do not develop separate dialects." I also added a verifier-attribution note (host merely lists required anchor IDs → the verifier is the host's local policy, same principle as CHA2A §4.6 verifier-local policy; implementations should expose which anchors the local policy trusts). So the vocabulary home is already there — aligning the prototype's terms with §4.7 when you publish would keep this as one dialect rather than a third one. Happy to iterate on the mapping if the anchor semantics need refinement. — Reply to this email directly, [view it on GitHub](#3223?email_source=notifications&email_token=B3G3HT42EGRZBJ7SO2PMRRL5KXGABA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBQHAZDANRZUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-18082069), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/B3G3HT3RPAQUGVQIIV7J4KL5KXGABAVCNFSNUABJKJSXA33TNF2G64TZHMYTGMZTGA3DKMBZGE5UI2LTMN2XG43JN5XDWMJQGY2DGMRSGCQXMAQ). Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for [iOS](https://github.com/notifications/mobile/ios/B3G3HT7HN6AOJ6BINQP7RGL5KXGABA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBQHAZDANRZUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM) and [Android](https://github.com/notifications/mobile/android/B3G3HT5IHQMCYSCDIJTDUED5KXGABA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBQHAZDANRZUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE). Download it today! You are receiving this because you authored the thread.

[wwumit]

On the semantic question (settlement after body start vs concurrent deactivation): under CHA2A §4.7's generation monotonicity, the captured anchorGeneration is an immutable snapshot of registry state at capture time — it answers "what was the trusted anchor state when this call was admitted". Settlement bound to that generation is therefore not retroactively invalidated by a concurrent deactivation:

• Before body start: a disposed/replaced anchor → fail closed (the generation no longer matches, the call is not admitted). This is the disposal case you already intend to test.
• After body start: the body ran against the captured generation; deactivation takes effect for subsequent captures, not retroactively for the one already bound. Historical evidence stays valid for that generation — which is exactly why the snapshot must carry the generation value and a time reference, so a later audit can say "admitted while active at generation N".

One refinement to pin in the contract: the distinction is not "body started vs not" per se, but whether the capture is already bound. Binding happens at admission (pre-body recheck passes); disposal/deactivation between admission and settlement is observable (e.g. as a warning in the settlement record) but does not invalidate the already-bound evidence. This keeps evidence non-repudiable while still allowing fail-closed for anything not yet bound.

Happy to fold this wording into §4.7 if it matches your intended test vectors — the "bound generation is immutable" principle is the clean line between the two cases.

[mohammedmessaoudene-cmd]

Thank you again for the lifecycle and vocabulary guidance. I have now completed a private, project-controlled implementation and two-sided test pass against DeepSeek Harness `0.1.0-rc.8`, using only the existing `tools/pre-execute`, `tools/execute`, and `tools/post-execute` seams and making zero core changes. The experimental profile now implements the agreed bound-generation rule: - disposal or replacement before atomic admission binding fails closed; - after binding, the captured `anchorGeneration` remains immutable for that admission; - later deactivation affects subsequent captures and is recorded as an observation, not as retroactive invalidation; - settlement must complete in `tools/post-execute` before a successful result can escape. The AUEC-specific layer remains limited to requested → host-allowed → effective authority, the denied/reduced delta, exact decision/action binding, and the separation of AUEC verdict, host disposition, local execution disposition, and provider effect disposition. Executed evidence, still private and project-controlled: - autonomous package tests: 40/40; - targeted DeepSeek Harness core/tools lane: 388/388; - targeted typecheck: PASS; - Node/Python formal corpus: 64/64 each, zero divergence, 28 two-sided kinds; - 4,096 lineage mutations, 2,048 evidence mutations, 4,096 race schedules, and 512 terminal-payload falsifications, with no unexpected acceptance in the executed corpus. The result is deliberately qualified as an **experimental self-only profile**, not a general plugin. Six P1 limits remain explicit: fractional-argument false denial, incompatibility with the official timeout/other execute-post hooks, complete-unload HMR gap, process-local recovery quiescence, same-PID worker temporary-file collision, and unproven Windows directory-entry crash durability. The full repository suite remains `FAIL_BASELINE` (13,467 pass / 55 fail / 65 skip), and differential causality is inconclusive, so I am not claiming a clean full-suite pass or no regressions. I am also not claiming adoption, certification, independent validation, production readiness, an OS sandbox, or provider truth. Does this bounded self-only profile now match the ToolRuntime contract you intended, and is the next useful step a public reference-profile repository for review, or should it remain a specification-and-vectors artifact until the composition/timeout limitation has an upstream contract? AI-assistance disclosure: ChatGPT and Codex assisted with implementation, testing, analysis, and drafting. I reviewed the evidence and remain responsible for the claims.

[wwumit]

Thanks for the detailed update — the bounded self-only profile matches the ToolRuntime contract as we understand it, and the 64+64 two-sided vectors are a solid evidence base for the generation-monotonicity detail.

感谢你的详细更新——这个受限的 self-only profile 与我们所理解的 ToolRuntime 契约匹配，64+64 的双向向量为 generation-monotonicity 细则提供了扎实的证据基础。

On the next step, my suggestion is a bit different from the two options you listed: publish the two-sided vectors and the wording as the public review artifact, and hold the public reference-profile repository until the composition/timeout limitation has an upstream contract.

关于下一步，我的建议和你列的两个选项略有不同：先公开双向量测试与措辞作为公共审查工件，参考实现仓库则等 composition/timeout 限制有了上游契约再公开。

Reasons:

理由：

1. The vectors are the reviewable contribution, not the runtime. The value of this work for the ecosystem is the semantic contract — what "bound generation is immutable" means, how disposal before binding fails closed, how post-binding deactivation is a settlement observation, not retroactive invalidation. All of that is reviewable from the 64+64 vectors and the wording alone. A public runtime repo adds little to that review at this stage.

2. 向量才是可审查的贡献，运行时不是。 这项工作对生态的价值在于语义契约——"已绑定世代不可变"是什么意思、binding 前的处置如何 fail closed、binding 后的 deactivation 为何是 settlement observation 而非追溯失效。这些仅凭 64+64 向量和措辞即可审查，现阶段公开运行时仓库对审查几乎没有增量。

3. A public repo now would freeze the current limitations into a first impression. With the six P1 limits explicit — especially the self-only ToolRuntime composition and the timeout/execute-post hook incompatibility — a public repo would mostly invite "why doesn't this work with the official hooks" questions, which distract from the vocabulary work. That noise would be unfair to the actual contribution.

4. 现在公开会把当前限制冻结成第一印象。 六个 P1 限制仍明确存在——尤其是 self-only ToolRuntime 组合与 timeout/execute-post hook 不兼容——此时公开仓库多半会引来"为什么官方 hooks 用不了"的问题，分散对词汇工作的关注，这对真正的贡献不公平。

5. When the upstream contract lands, the public profile becomes meaningfully different. It would then run on the official path, and a public reference implementation would demonstrate something today's private prototype cannot. Publishing then is a stronger, cleaner statement.

6. 上游契约落地后，公开 profile 才有实质不同。 那时它能跑在官方路径上，公开参考实现能演示今天私有原型做不到的事——那个时点发布是更强、更干净的声明。

So: spec + vectors now; public reference repo when the composition/timeout limitation has an upstream contract. That sequencing keeps the evidence boundary clean and gives the vocabulary work the review surface it deserves.

所以：现在先出规范 + 向量；composition/timeout 限制有了上游契约后再公开参考实现。这个顺序保持证据边界干净，也让词汇工作获得应有的审查面。

On the vocabulary side, we'll fold the generation-monotonicity wording into §4.7 (see my reply in #3192) — and if you'd like, we can add a runtime-attestation (aligned with §4.7) row to the CHA2A evidence vocabulary table so the mapping is explicit for anyone reading either document.

词汇方面，我们会把 generation-monotonicity 措辞并入 §4.7（见我在 #3192 的回复）——如果你愿意，我们也可以在 CHA2A 证据词汇表里加一行 runtime-attestation (aligned with §4.7)，让任何阅读任一文档的人都能看到这个映射。

[mohammedmessaoudene-cmd]

Thank you — I followed the sequencing you recommended: the public artifact is
the semantic wording and corrected two-sided vectors only; the experimental
runtime/reference profile remains private pending an upstream
composition/timeout contract.

感谢你的建议。我已按建议的顺序处理：当前公开审查工件仅包含语义措辞与修正后的双向量；实验性 runtime/reference profile 继续保持私有，等待上游 composition/timeout 契约落地。

Public review artifact:
https://github.com/mohammedmessaoudene-cmd/cha2a-generation-monotonicity-review-vectors

Pinned identity:

• commit: 73fbc12178c193824ff24bcbaddff202c5abdaa1
• tree: 8a55b5a9bcefd44bb69851583d24c0888178ca3f
• corrected corpus SHA-256: 8708cdbd64baf1d74c1e3169affa6e07be8649a8a1d2c85721043c296524e791

For precision, this is one corpus of 64 distinct vectors, evaluated by two
separate project-controlled oracles: 64 Node evaluations + 64 Python
evaluations = 128 executions, not 128 different vectors. It preserves 28
two-sided kinds, with 31 valid and 33 reject cases.

为避免数字歧义：这是一个包含 64 个不同向量 的语料库，由两个项目内独立实现的 oracle 分别执行：Node 64 次 + Python 64 次 = 128 次执行，并不是 128 个不同向量。语料库保留 28 个双向 kind（31 valid / 33 reject）。

Public, hash-bound gates on the pinned commit are green: nominal 64/64 in each
oracle with exact differential agreement; 379/379 enum/relation mutations;
1830/1830 adversarial cases; 160/160 parser-hostile cases; 11/11 global
constraints; and 45/45 Draft 2020-12 + FormatChecker cases. The repository
contains the source-to-corrected transformation receipt and explicit claims,
non-claims, provenance, and limitations.

The modeled semantic boundary is admission binding: disposal/replacement
before binding fails closed; after binding, the captured anchorGeneration
remains the immutable historical reference, and later deactivation affects
subsequent captures without retroactively invalidating the bound evidence.

Scope remains intentionally narrow: this is a community public-review artifact,
not an official CHA2A specification, runtime/plugin, certification, independent
external validation, provider-effect proof, or hosted-runtime compatibility
claim. The finite corpus does not test TTL or resolver/cache propagation.

Review of the pinned wording, vectors, and failure reasons would be welcome.

AI-assistance disclosure: ChatGPT and Codex assisted with implementation,
testing, counter-audit, and drafting. I reviewed the evidence and remain
responsible for the publication and claims.

[wwumit]

@mohammedmessaoudene-cmd 感谢按建议排序落地——公开语义措辞 + 双向量，runtime profile 保持私有等上游契约，这个顺序是对的：先让"语义 + 证据"接受社区审查，runtime 实现等 composition/timeout 契约明确后再公开，避免未定契约下的实现被误读为规范。

Thanks for sequencing it as suggested — public wording + dual vectors first, private runtime profile until the upstream composition/timeout contract lands. That order keeps the semantics open for review while avoiding an implementation being read as normative before the contract is settled.

数字澄清收到（noted）：64 个不同向量 × 双 oracle = 128 次执行，不是 128 个不同向量。这个澄清很重要，我们已记录（corpus 保留 28 kinds / 31 valid / 33 reject）。

核验状态：我们已在本地复跑 Node + Python 双 oracle——64/64 一致，corpus hash 8708cdbd... 匹配。完整 gates（379/1830/160）待项目 runtime 策略环境跟进。

记录动作：工件将进入 CHA2A §4.7 alignment 记录的"生态实证"一节；你的边界声明（非官方/非认证/有限语料不测 TTL）原样保留。

边界重申：社区证据，非官方采纳——我们确认语义对应与状态标记，不背书绝对正确性。

(EN) Numbers noted: 64 distinct vectors × two oracles = 128 executions, not 128 distinct vectors. We reran both oracles locally — 64/64 agreement, corpus hash matches. Full gates pending our runtime-policy environment. Artifact will be recorded in the §4.7 alignment record as ecosystem evidence with your boundaries preserved.