From 147f11a738b54cea994bd68ef272225c9f94b73b Mon Sep 17 00:00:00 2001 From: Rico Komenda Date: Sun, 22 Mar 2026 22:01:56 +0100 Subject: [PATCH 1/4] proposal: merge duplicate parameter-binding requirement from C9.7.2 into C9.2.2 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit C9.2.2 and C9.7.2 both addressed the same attack — binding approvals to exact action parameters to prevent "approve one thing, execute another" / substituted approvals. The core requirement was duplicated across two sections (C9.2 HITL approval gates, C9.7 intent verification). Resolution: - Enrich C9.2.2 with the unique aspects of C9.7.2 (integrity-protection of the approval itself, expiry) so all three properties live together: present parameters → integrity-protect the approval → bind to params → expire - Remove old C9.7.2 (now covered by C9.2.2) - Renumber C9.7.3 → C9.7.2 and C9.7.4 → C9.7.3 This is a PROPOSAL for discussion — please review whether the merged wording captures the full intent of both original controls before merging. --- 1.0/en/0x10-C09-Orchestration-and-Agentic-Action.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/1.0/en/0x10-C09-Orchestration-and-Agentic-Action.md b/1.0/en/0x10-C09-Orchestration-and-Agentic-Action.md index 1a81f77..f73fd5f 100644 --- a/1.0/en/0x10-C09-Orchestration-and-Agentic-Action.md +++ b/1.0/en/0x10-C09-Orchestration-and-Agentic-Action.md @@ -27,7 +27,7 @@ Require explicit checkpoints for privileged or irreversible outcomes. | # | Description | Level | Role | | :--: | --- | :---: | :--: | | **9.2.1** | **Verify that** privileged or irreversible actions (e.g., code merges/deploys, financial transfers, user access changes, destructive deletes, external notifications) require explicit human-in-loop approval. | 1 | D/V | -| **9.2.2** | **Verify that** approval requests present the exact action parameters (diff/command/recipient/amount/scope) and bind approvals to those parameters to prevent "approve one thing, execute another." | 2 | D/V | +| **9.2.2** | **Verify that** approval requests present the exact action parameters (diff/command/recipient/amount/scope), that the resulting approval is integrity-protected and bound to those parameters, and that approvals expire quickly to prevent stale or substituted approvals ("approve one thing, execute another"). | 2 | D/V | | **9.2.3** | **Verify that** where rollback is feasible, compensating actions are defined and tested (transactional semantics), and failures trigger rollback or safe containment. | 3 | V | --- @@ -93,9 +93,8 @@ Prevent "technically authorized but unintended" actions by binding execution to | # | Description | Level | Role | | :--: | --- | :---: | :--: | | **9.7.1** | **Verify that** pre-execution gates evaluate proposed actions and parameters against hard policy constraints (deny rules, data handling constraints, allow-lists, side-effect budgets) and block execution on any violation. | 1 | D/V | -| **9.7.2** | **Verify that** high-impact actions require explicit user intent confirmation that is integrity-protected and bound to the exact action parameters (and expires quickly) to prevent stale or substituted approvals. | 2 | D/V | -| **9.7.3** | **Verify that** post-condition checks confirm the intended outcome and detect unintended side effects; any mismatch triggers containment (and compensating actions where supported). | 2 | V | -| **9.7.4** | **Verify that** prompt templates and agent policy configurations are integrity-verified at load time against their approved versions (e.g., via hashes or signatures). | 3 | D/V | +| **9.7.2** | **Verify that** post-condition checks confirm the intended outcome and detect unintended side effects; any mismatch triggers containment (and compensating actions where supported). | 2 | V | +| **9.7.3** | **Verify that** prompt templates and agent policy configurations are integrity-verified at load time against their approved versions (e.g., via hashes or signatures). | 3 | D/V | --- From 4907545b6ae5ead1dae87752f857c9638b24db3c Mon Sep 17 00:00:00 2001 From: Rico Komenda Date: Tue, 24 Mar 2026 23:00:46 +0100 Subject: [PATCH 2/4] fix: apply ottosulin's rewording for C9.2.2 approval parameter binding MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - 'expire quickly' → 'expire after a short time window' (more auditable; implies a configurable TTL an auditor can verify exists) - removed redundant double phrasing at end ('approve one thing, execute another' + 'stale or substituted approvals'); one explanation suffices --- 1.0/en/0x10-C09-Orchestration-and-Agentic-Action.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/1.0/en/0x10-C09-Orchestration-and-Agentic-Action.md b/1.0/en/0x10-C09-Orchestration-and-Agentic-Action.md index f73fd5f..8f7d9fb 100644 --- a/1.0/en/0x10-C09-Orchestration-and-Agentic-Action.md +++ b/1.0/en/0x10-C09-Orchestration-and-Agentic-Action.md @@ -27,7 +27,7 @@ Require explicit checkpoints for privileged or irreversible outcomes. | # | Description | Level | Role | | :--: | --- | :---: | :--: | | **9.2.1** | **Verify that** privileged or irreversible actions (e.g., code merges/deploys, financial transfers, user access changes, destructive deletes, external notifications) require explicit human-in-loop approval. | 1 | D/V | -| **9.2.2** | **Verify that** approval requests present the exact action parameters (diff/command/recipient/amount/scope), that the resulting approval is integrity-protected and bound to those parameters, and that approvals expire quickly to prevent stale or substituted approvals ("approve one thing, execute another"). | 2 | D/V | +| **9.2.2** | **Verify that** approval requests present the exact action parameters (diff/command/recipient/amount/scope), that the resulting approval is integrity-protected and bound to those parameters, and that approvals expire after a short time window to prevent stale or substituted approvals. | 2 | D/V | | **9.2.3** | **Verify that** where rollback is feasible, compensating actions are defined and tested (transactional semantics), and failures trigger rollback or safe containment. | 3 | V | --- From 60dc8292b07c52b15a470abb14a57d05da43388d Mon Sep 17 00:00:00 2001 From: Rico Komenda Date: Wed, 25 Mar 2026 08:48:35 +0100 Subject: [PATCH 3/4] fix(C9): split 9.2.2 into 4 controls and 9.7.2 into 3 controls per jmanico review on PR #442 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - 9.2.2 display of canonicalized parameters (was merged with binding, nonce, TTL) - 9.2.3 cryptographic binding of approval to parameters, identity, context - 9.2.4 unique nonce + single-use to prevent replay/substitution - 9.2.5 TTL expiry — approvals rejected after expiration - 9.2.6 rollback / compensating actions (renumbered from 9.2.3) - 9.7.2 post-execution: confirm intended outcome - 9.7.3 post-execution: detect unintended side effects - 9.7.4 mismatch triggers containment + compensating actions - 9.7.5 prompt template integrity (renumbered from 9.7.3) --- 1.0/en/0x10-C09-Orchestration-and-Agentic-Action.md | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/1.0/en/0x10-C09-Orchestration-and-Agentic-Action.md b/1.0/en/0x10-C09-Orchestration-and-Agentic-Action.md index 8f7d9fb..5bca9a8 100644 --- a/1.0/en/0x10-C09-Orchestration-and-Agentic-Action.md +++ b/1.0/en/0x10-C09-Orchestration-and-Agentic-Action.md @@ -27,8 +27,11 @@ Require explicit checkpoints for privileged or irreversible outcomes. | # | Description | Level | Role | | :--: | --- | :---: | :--: | | **9.2.1** | **Verify that** privileged or irreversible actions (e.g., code merges/deploys, financial transfers, user access changes, destructive deletes, external notifications) require explicit human-in-loop approval. | 1 | D/V | -| **9.2.2** | **Verify that** approval requests present the exact action parameters (diff/command/recipient/amount/scope), that the resulting approval is integrity-protected and bound to those parameters, and that approvals expire after a short time window to prevent stale or substituted approvals. | 2 | D/V | -| **9.2.3** | **Verify that** where rollback is feasible, compensating actions are defined and tested (transactional semantics), and failures trigger rollback or safe containment. | 3 | V | +| **9.2.2** | **Verify that** approval requests display canonicalized and complete action parameters (diff, command, recipient, amount, scope) without truncation or transformation. | 2 | D/V | +| **9.2.3** | **Verify that** approvals are cryptographically bound (e.g., signed or MACed) to the exact action parameters, requester identity, and execution context. | 2 | D/V | +| **9.2.4** | **Verify that** approvals include a unique nonce and are single-use to prevent replay or substitution. | 2 | D/V | +| **9.2.5** | **Verify that** approvals expire within a defined maximum time-to-live (TTL) and are rejected after expiration. | 2 | D/V | +| **9.2.6** | **Verify that** where rollback is feasible, compensating actions are defined and tested (transactional semantics), and failures trigger rollback or safe containment. | 3 | V | --- @@ -93,8 +96,10 @@ Prevent "technically authorized but unintended" actions by binding execution to | # | Description | Level | Role | | :--: | --- | :---: | :--: | | **9.7.1** | **Verify that** pre-execution gates evaluate proposed actions and parameters against hard policy constraints (deny rules, data handling constraints, allow-lists, side-effect budgets) and block execution on any violation. | 1 | D/V | -| **9.7.2** | **Verify that** post-condition checks confirm the intended outcome and detect unintended side effects; any mismatch triggers containment (and compensating actions where supported). | 2 | V | -| **9.7.3** | **Verify that** prompt templates and agent policy configurations are integrity-verified at load time against their approved versions (e.g., via hashes or signatures). | 3 | D/V | +| **9.7.2** | **Verify that** post-execution checks confirm the intended outcome was achieved. | 2 | V | +| **9.7.3** | **Verify that** post-execution checks detect unintended side effects. | 2 | V | +| **9.7.4** | **Verify that** any mismatch between intended outcome and actual results triggers containment and, where supported, compensating actions. | 2 | V | +| **9.7.5** | **Verify that** prompt templates and agent policy configurations are integrity-verified at load time against their approved versions (e.g., via hashes or signatures). | 3 | D/V | --- From 3a7c6d6bfcc0316133347289a9362c7fa9f4b883 Mon Sep 17 00:00:00 2001 From: Rico Komenda Date: Thu, 26 Mar 2026 21:23:31 +0100 Subject: [PATCH 4/4] fix(C9): scope 9.7.5 to remote-sourced templates per ottosulin review on PR #442 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Prompt templates included in source code do not require load-time integrity verification against an approved version — only those retrieved from a remote source do. --- 1.0/en/0x10-C09-Orchestration-and-Agentic-Action.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/1.0/en/0x10-C09-Orchestration-and-Agentic-Action.md b/1.0/en/0x10-C09-Orchestration-and-Agentic-Action.md index 5bca9a8..3af74a7 100644 --- a/1.0/en/0x10-C09-Orchestration-and-Agentic-Action.md +++ b/1.0/en/0x10-C09-Orchestration-and-Agentic-Action.md @@ -99,7 +99,7 @@ Prevent "technically authorized but unintended" actions by binding execution to | **9.7.2** | **Verify that** post-execution checks confirm the intended outcome was achieved. | 2 | V | | **9.7.3** | **Verify that** post-execution checks detect unintended side effects. | 2 | V | | **9.7.4** | **Verify that** any mismatch between intended outcome and actual results triggers containment and, where supported, compensating actions. | 2 | V | -| **9.7.5** | **Verify that** prompt templates and agent policy configurations are integrity-verified at load time against their approved versions (e.g., via hashes or signatures). | 3 | D/V | +| **9.7.5** | **Verify that** prompt templates and agent policy configurations retrieved from a remote source are integrity-verified at load time against their approved versions (e.g., via hashes or signatures). | 3 | D/V | ---