proposal: merge duplicate parameter-binding requirement from C9.7.2 into C9.2.2

[RicoKomenda]

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.

[ottosulin]

Good catch on the duplication! I think your assessment is correct: C9.2.2 and C9.7.2 were describing the same control mechanism just from two different angles.

I think this proposal combines the properties correctly into one requirement. The "explicit user intent confirmation" aspect from old C9.7.2 is not lost because C9.2.1 already mandates "explicit human-in-loop approval" for privileged/irreversible actions.

Regarding compound requirements: the merged text has three verifiable properties: (1) present exact parameters, (2) integrity-protect & bind, (3) expire quickly. These are tightly coupled and they all describe properties of a single approval event. An auditor would in practice check one mechanism, not three separate systems. So this is acceptable coupling.

A suggestion for minor rewording:

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.

The change:

• "expire quickly" -> "expire after a short time window" (slightly more testable/auditable than word "quickly" which is more subjective, whereas "short time window" implies a configurable TTL an auditor can check exists.
• Also removed the double phrasing at the end ("approve one thing, execute another" + "stale or substituted approvals" was redundant; one explanation suffices).

[jmanico]

This looks like 4 different requirements:

1. Verify that approval requests display canonicalized and complete action parameters (diff, command, recipient, amount, scope) without truncation or transformation.
2. Verify that approvals are cryptographically bound (e.g., signed or MACed) to the exact action parameters, requester identity, and execution context.
3. Verify that approvals include a unique nonce and are single-use to prevent replay or substitution.
4. Verify that approvals expire within a defined maximum time-to-live (TTL) and are rejected after expiration.

[jmanico]

This looks like maybe three requirements.

1. Verify that post-execution checks confirm the intended outcome.
2. Verify that post-execution checks detect unintended side effects.
3. Verify that any mismatch between intended outcome and actual results triggers containment and, where supported, compensating actions.

I'm not sure what the best level of reduction is, but breaking these up into smaller requirements make them more actionable and easier to test!

[ottosulin]

I would add to the end ".. if retrieved from a remote source"

Prompt templates can be included in the source code, no need to check in that case.