Sprint 10 Engineering Log

Program Context

• Phase: Phase 4
• Sprint: Sprint 10
• Status: Completed
• Primary Architecture Layers: Control Plane (Orchestrator Crypto Engine), Execution Contract Layer

Architectural Intent

Implement the Cryptographic Payload Engine baseline for the Universal Execution Fabric:

• Vault/HSM-backed signing key integration in the control plane
• Compact JWS payload generation for signed execution messages
• Execution Manifest schema formalization for BYOT-safe task dispatch
• Anti-replay controls (nonce + timestamp) to prevent broker/network replay abuse

Implementation Detail

Whitepaper-Aligned High-Level Architecture

Sprint 10 implemented the control-plane cryptographic endorsement path described in docs/WHITEPAPER.md:

1. Orchestrator constructs canonical execution payloads.
2. Payloads are signed via Vault Transit (HSM-equivalent key custody boundary).
3. Signatures are emitted as compact JWS artifacts for downstream verification.
4. Manifest nonce/timestamp replay guards enforce short-lived, single-use dispatch semantics.

Logical Architecture and Data Flow

1. Task context + execution parameters are normalized into ExecutionManifest.
2. Manifest payload is canonicalized (sort_keys=True) for deterministic signing input.
3. VaultTransitSigner requests JWS-compatible signature material from Vault Transit.
4. CompactJWSGenerator assembles base64url(header).base64url(payload).base64url(signature).
5. AntiReplayGuard validates freshness window and tenant-scoped nonce uniqueness before dispatch.

Detailed Engineering Work by Sprint 10 Tasks

1. Vault integration for signing keys
   • Added VaultTransitConfig + VaultTransitSigner for key create/read/sign operations.
   • Enforced HTTPS-by-default, runtime config validation, and Vault error hardening.
2. JWS payload generation in Orchestrator
   • Added compact JWS builder (CompactJWSGenerator) with deterministic header/payload encoding.
   • Normalized Vault signature formats to compact JWS signature segment output.
3. Execution Manifest schema design
   • Added ExecutionTaskContext and ExecutionManifest typed contracts.
   • Enforced strict validation for target_urn, tool_sha256, task context integrity, and manifest versioning.
4. Anti-Replay mechanisms
   • Added manifest nonce field and timestamp usage contract.
   • Added AntiReplayConfig + AntiReplayGuard with max-age, future-skew, and nonce-retention policies.
   • Implemented tenant-scoped nonce keying (tenant_id + nonce) to preserve isolation semantics.

Security and Control Posture

• Cryptographic key custody remains externalized to Vault/HSM boundary; private keys never enter app code.
• Signed payload format is deterministic and tamper-evident at transport boundary.
• Replay suppression blocks duplicated nonce use and stale/future timestamp abuse.
• Manifest schema enforces strict target/tool/task context before signing and dispatch.

QA and Validation Evidence

• Unit suites for Vault signer, JWS generation, manifest schema, and anti-replay completed.
• Focused regression command:
  • ./.venv/bin/python -m pytest -q tests/unit/test_orchestrator_anti_replay.py tests/unit/test_orchestrator_manifest.py tests/unit/test_orchestrator_jws.py tests/unit/test_orchestrator_signing.py
• Result: passing in local dev workflow during sprint closeout.

Risk Register

• Remaining risk: anti-replay store is in-memory only; production durability/distributed replay cache is deferred to later execution-plane work.
• Remaining risk: OPA policy pre-sign authorization hooks are scheduled for Phase 5 and not yet enforced in this sprint.
• Remaining risk: edge-side JWS verification enforcement is scheduled in Sprint 12 runner implementation.

Forward Linkage

Sprint 11 proceeds with Armory implementation (immutable tool registry, ingestion pipeline, and tool-signing supply-chain controls).