add gated outreach preparation

2026-09-03 12:27:15 +02:00
parent c0909132f2
commit 537a2a6f0a
12 changed files with 377 additions and 4 deletions
@@ -110,6 +110,19 @@ Phase 11 is present in the current Compose source with durable saved-filter stor

 Phase 12 is not production-ready until transition and outcome invariants, suppression precedence at every boundary, report reproducibility/timezone semantics, export authorization, retention/deletion, idempotent retry, and cross-tenant isolation are covered by integration tests and operational monitoring.

+## Phase 14 draft-only outreach security controls
+
+- Keep outreach preparation deny-by-default. The current Compose setting `AUTOMATED_OUTREACH_ENABLED=false` is a defense-in-depth control; enforce no-send behavior in server authorization and provider adapters as well. Draft creation, approval, retry, or queue acceptance must never be described as sending.
+- Treat recipient, channel, consent/legal basis, jurisdiction, suppression, evidence freshness, provider approval, and content policy as independent server-side gates. Suppression/do-not-contact is unconditional and must be checked before evidence selection, draft persistence, display/export, approval, queueing, and any future send attempt. Public data, score, pipeline state, verification, or AI confidence is not consent, lawful basis, deliverability, or contact permission.
+- Register providers through an allowlist with purpose/capability, tenant/data-class scope, region/egress and retention terms, timeout/payload limits, per-tenant/global request/message/cost caps, circuit policy, approval owner/expiry, and operational enablement. Fallback must preserve all constraints and be separately approved. Provider outage, quota, timeout, policy denial, circuit-open, or approval expiry fails closed.
+- Store provider credentials only as secret-manager references. Never accept secrets from browser clients or persist them in source, Compose, images, committed `.env`, prompts, responses, logs, audit events, metrics, or error messages. Define rotation, revocation, access review, and a kill switch for suspected misuse or leakage.
+- Bind each draft to tenant/recipient/channel, a bounded redacted content version or hash, cited evidence IDs/source references, the exact evidence snapshot hash, observed/freshness times, policy/provider versions, and gate results. Hashes prove lineage to a snapshot, not truth. Reject missing, stale, conflicting, suppressed, or changed evidence; never fill gaps with invented claims.
+- Require explicit authorized human approval of the exact draft/evidence/policy hash. Approval must re-check tenant scope, suppression, legal/consent state, freshness, provider approval, and permissions; edits or policy/evidence changes invalidate approval. Record actor, time, reason, expiry, rejection, before/after status, and correlation ID in append-only/tamper-evident audit. Approval is not delivery authorization.
+- Require tenant-scoped idempotency keys for future side effects, bound to request fingerprint, draft version, recipient, provider, and policy. Exact replay returns the original bounded result; conflicting reuse is rejected. Apply request/message/cost caps before attempts and across retries, fallbacks, workers, and tenants; do not bypass caps by rotation or unbounded retry.
+- Audit all gate outcomes, suppression decisions, draft versions, citation/hash checks, approvals/rejections/expiry, provider attempts, cap denials, retries, and delivery outcomes with safe per-item results. Redact full content, contact values, prompts, legal notes, and secrets where a stable identifier/fingerprint suffices. Preserve deletion/legal-hold semantics without deleting required suppression/audit history.
+
+Phase 14 is preparation-only in this repository: no draft/send route, provider, consent ledger, legal-policy engine, durable approval workflow, delivery feedback, or secret manager is enabled. Production requires jurisdiction-specific legal review and documented lawful-basis/consent policy, provider contracts/DPA, durable transactional idempotency, suppression synchronization, rate/cost monitoring, bounce/complaint handling, rollback/revocation, incident response, retention/deletion verification, and no-send/cross-tenant/citation/hash integration tests.
+
 ## Known limitations before production

 1. **Password storage:** production passwords must be hashed with Argon2id using a reviewed cost/memory/parallelism policy. Never store plaintext or reversible passwords, and never log bootstrap credentials. Rehash on login when the policy changes.