# Security Review

## Findings

### High: rollback authorization is left entirely to the lower layer without a required authorization decision point

The draft says recovery events need authenticated and authorized carriage, but it never states when a receiver is required to evaluate authorization before acting on a `rollback-request`. Two compliant implementations could therefore both authenticate the requester yet differ on whether task-level rollback authority is required. The draft should require an explicit authorization check before any irreversible rollback action is attempted.

### High: replay protection is mentioned but underspecified for interoperable use

The draft says implementations SHOULD provide replay resistance, but `rollback-request` already defines an idempotency token and stable identifiers. That is enough structure to make stronger requirements possible. Without a minimum replay-handling rule, an attacker can reuse stale rollback requests in a way that different implementations will treat inconsistently.

### Medium: failure-event spoofing risk is identified, but the draft does not require correlation between failure and rollback flows

An attacker who can inject a plausible `failure` event may induce unnecessary rollback decisions. The draft should at least require that a `rollback-request` reference a specific task or failure context and that receivers preserve the linkage in the `rollback-result`.

### Medium: partial rollback can leave exploitable inconsistent state, but no minimum disclosure is mandated

The draft correctly notes the risk, yet "residual risk description" is only a SHOULD. For partial-success and irreversible outcomes, a stronger requirement is warranted so downstream agents can react safely.

## Open questions

- Should authorization be expressed as a generic requirement only, or should the document define a task-scope authorization concept for rollback actions?
- Should replay resistance be a MUST for all deployments, or only when rollback has externally visible effects?

## Residual risk

Even with the fixes above, the draft will still depend heavily on lower-layer identity and authorization systems. That is acceptable, but the security section should say so more concretely and bind protocol behavior to those assumptions.