# SECURITY MODEL v0.1 — APPROVED PLANNING BASELINE

**Phase 0 · 3 October 2026 · no security acceptance or implementation permission**  
**Owner adoption: PASS WITH CONDITIONS**, Owner Planning Disposition §§1–2, 3 October 2026. Governing security planning requirements, not proof of implemented controls; tools/settings/access and operational owners remain OPEN.
Sources: Owner §6; Constitution IX/XI–XIV; Technical Direction E/F/H9; Architecture §§8/12–16/20/24; Brand/IA and Design candidates. Controls are proposed requirements; exact tooling/limits/header values remain pending validation.

## Assets, threat assumptions and trust boundaries

Protect accepted inquiries and delivery intent, personal intake data, secrets, draft/private editorial material, approved public claims/assets, release provenance and recovery evidence. Anonymous clients and callback senders are untrusted. A successful provider request is not necessarily acceptance/delivery, and staff/vendor access is privileged even without public accounts.

| Boundary | Allowed flow and trust requirement | Principal failure/threat / proposed control |
|---|---|---|
| Browser → public editorial | Approved release only; no secrets/drafts/private data | Injection/cache leak: structured escaped content, bounded rendering, preview isolation |
| Browser → intake server | Bounded practice-specific input; server is decision authority | Spam/injection/large payload: validate allowlisted fields/types/lengths, bounded body, rate/abuse controls |
| Server → journal | Scoped server-only access; atomic accepted record plus required intent | Lost/duplicate inquiry or private lookup: commit boundary, safe identity/conflict rules, no public journal lookup |
| Server/worker → email/CRM | Minimal authorized handoff by internal identity | Provider failure/duplicate effects: durable intent, bounded retries/idempotency, auditable correlation |
| Provider callback → server | Authenticated class appropriate to selected provider, never trust raw payload | Forgery/replay/duplicates: signature/time/replay/event validation, bounded parsing and idempotent state updates |
| CMS → protected preview/build → public | Identified approved revision, authorized promotion and permitted assets | Draft exposure/unapproved release: protected responses/assets/caches, revision-bound approval |
| Staff/vendor → editorial/journal/secrets | Explicit appointment/scoped access; MFA where available | Excess privilege/credential misuse: least privilege, distinct environments, inventory/revocation/rotation |
| App/telemetry → analytics/logs | Non-private permitted event/diagnostic data only | PII/secret leakage: no payload/contact data, safe correlation/redaction, restricted diagnostic access |
| Dev/validation → production | Deliberate data/credential/location boundary | Test reaching real inbox/journal: synthetic/sandbox destinations and environment separation |

No public accounts, login placeholders, custom authentication, tenants/RBAC/client portal, public inquiry lookup or document uploads are introduced. Staff controls belong to selected approved tooling, not a bespoke V1 admin product.

## Server intake and abuse

Proposed validation: method/content type/encoding, supported practice, exact field allowlist, type/length/control-character handling, safe normalized data, bounded aggregate payload and no file input. Client checks improve usability, never authority. Reject invalid/oversized input before acceptance; generic safe errors with no SQL/provider/internal details.

Use parameterized database access through later validated adapter. Render user data safely in staff/notification contexts; no executable HTML from a free-text field. Do not put private fields into URLs, analytics or ordinary logs.

Shared enforcement must work across concurrency/replica-equivalent requests. Per-process memory cannot be authoritative rate-limit, dedup or retry state. Actual provider, challenge strategy, quotas, timeouts, retention and thresholds are unresolved; H5 must establish legitimate/shared-network usability and unavailable-control policy. No indiscriminate challenge or silent loss; fail/degrade under a reviewed policy.

**CSRF/origin:** anonymous intake is not an authenticated account action, but cross-site submission abuse remains relevant. Propose origin/content-type/fetch-metadata checks appropriate to actual client transport; missing/untrusted headers require a deliberate policy. Origin is not authentication and can be spoofed by non-browser clients; do not rely on CORS/CSRF alone. Any future session-sensitive preview/staff action needs appropriate selected-tool CSRF/session controls, not custom public auth.

## Secrets, environments and access

Secrets server-side only, scoped by use; none in browser bundles/source maps/responses/HTML/CMS/assets/logs/backups/handoff. No real secret inspected in this cut. Later selected credentials through authorized secret handling; least privilege, rotation/revocation/recovery ownership and incident scope.

Separate development/synthetic test, protected editorial preview and future production data/credentials/notification destinations. H1 stricter: separate disposable Project and synthetic data/secrets only, no company production CMS/database/domain/artist/client/inquiries. App Storage capability never authorizes production-data exposure to dev; no cross-project/venture coupling.

Inventory who can read secrets **and execute code using them**, publish/edit content, inspect/export inquiries or replay delivery. Owner appoints responsible functions; Governor may exercise only explicit delegation. MFA where available; scoped service identities/tokens, no shared privileged account by assumption. Privilege changes/disclosure remain Owner-reserved at relevant consequence.

## CMS/preview, release and browser protections

Proposed deny-by-default draft/preview exposure, protected preview authentication via selected CMS/tool controls, non-indexing and no public cache of protected responses/assets. Robots/noindex is not access control. Check CDN/cache/media visibility, including assets reachable outside page protection.

Bind approved content revision and app/assets to promoted release. Signed/authenticated build callbacks with replay/duplicate safety and authorized promotion. Failed fetch/build/check cannot replace last working release; revoked/incorrect content needs bounded corrective publication and escalation, not indefinite retention.

Header/CSP **direction only**, exact values pending deployed response/asset tests: minimal source-specific CSP without arbitrary wildcard/eval allowances; framing restrictions; content-type protections; appropriate referrer/permissions policy; HTTPS/HSTS only with actual domain/subdomain consequences reviewed. Apply to success/error paths; do not weaken simply to pass. External media/font/analytics requests must be inventoried and justified.

## Data, logs and analytics

Minimum necessary contact/intake data for approved business/music process. Retention/deletion and legal bases/processors require Owner/legal input; no invented durations. Sensitive unsolicited detail discouraged; no automatic public summary/AI/RAG pipeline.

Logging allowlist: safe event/error class, environment, time, internal correlation, attempt/outcome where justified. Never contact details/free text/token/header dumps. Internal identity is not a bearer credential; rate and access controls prevent enumeration, and no public lookup API exists. Internal IDs stay out of public analytics unless separately approved non-private event design proves suitability.

Analytics is outside the acceptance transaction and contains no names/emails/free text/private project/artist information. Consent/blockers affect measurement completeness; conversion only follows durable acceptance. No cross-venture live data linkage.

## Recovery and incident responsibilities

Require appointed incident lead, publishing/rights lead, secret-rotation owner, journal/recovery owner and responder/backup. Assignment is OPEN, not a factual staffing claim.

Proposed incident sequence: detect/classify → contain under valid authority → preserve minimal secret-free evidence → assess affected records/rights/credentials/releases → notify required authorized/legal functions → scoped recovery/rotation/correction → verify → independent review/closure. Avoid broad copying of private data as “evidence.”

Coordinate application/database recovery; restore accepted records and intents without blind replay, cancel duplicate external effects where possible, investigate ambiguous provider events. Actual backup plan/window/history, approved RPO/RTO and isolated restore/export proof remain H8. No zero-loss or exactly-once guarantee.

First production publish/permanent geography, destructive production work, migrations/material access changes, major interruption and HIGH/CRITICAL residual risk require applicable explicit Owner authority. State consequences/alternatives/backup/safe recovery before irreversible action. This document grants none.

## Security acceptance and residual-risk routing

Required later evidence: input/oversize/injection tests; cross-origin/shared-abuse tests; credential/draft/cache/exposure checks; signature/replay/duplicate callback tests; CSP/header success/error requests; non-private telemetry payload review; access/MFA/rotation inventory; failover/restore/replay exercises; rights correction/withdrawal path.

H1 covers only synthetic runtime surface; H2/H9 preview/access, H3 atomicity/identity, H4 callbacks/delivery, H5 abuse, H6 analytics, H7 location, H8 recovery, H10 export and conditional H11 storage. Passing one never substitutes for integrated security.

AR02/03/04/05/07/09/11/12/13/14/15/16 remain candidate risks. Missing mandatory evidence is not accepted risk or PASS WITH GAPS. Independent review, design reconciliation and Owner-reserved risk disposition remain required; no scan, penetration test or security proof was run here.