feat(C9): add agent persisted state integrity control (9.4.5)

[RicoKomenda]

Summary

Adds 9.4.5 to C9.4 (Agent and Orchestrator Identity, Signing, and Tamper-Evident Audit) to close a gap where no control currently protects agent state stored between invocations from tampering.

New control:

Verify that agent state persisted between invocations (including memory, task context, goals, and partial results) is integrity-protected (e.g., via cryptographic MACs or signatures), and that the runtime rejects or quarantines state that fails integrity verification before resuming execution.

Level: 2

Why this is needed

Long-running agents commonly persist task state to external storage (Redis, databases, object stores) between invocations. An attacker with write access to that storage, or an attacker who compromises a tool that has write access, can modify the agent's persisted goals, memory, or partial results without any in-flight detection. This is a persistence and privilege escalation vector documented in MITRE ATLAS (AML.T0051 - LLM Plugin Compromise) and in the OWASP Top 10 for Agentic Applications 2026.

Existing C9.4 controls address in-flight action signing (9.4.2) and audit log tamper-evidence (9.4.3), but neither covers stored state between turns. This control plugs that gap with a verifiable requirement: MAC or signature over persisted state, verified before resumption.

Level 2 is appropriate: the threat is real for any multi-turn or long-running agent, but verification requires an integrity mechanism on the state store rather than just infrastructure configuration.

Changes

• 1.0/en/0x10-C09-Orchestration-and-Agentic-Action.md: add 9.4.5
• 1.0/en/0x93-Appendix-D_AI_Security_Controls_Inventory.md: add entry to AD.6