Security by Construction

Make the framework's natural API protect its users. Apply this principle to framework-owned APIs, capabilities and execution; applications own their payload schemas, business semantics and policies. Preserve the documented behavior of the mechanisms through which applications supply those choices. Review the actual data flow and authority of each operation; Haskell types and pure code help express guarantees, but the guarantees still depend on construction, decoding and execution. For parsing, type and API details, consult Boundary Discipline and NeoHaskell best practices when needed.

1. Trace trust and authority. Identify the caller, protected data or capability, external inputs, and the service/interpreter that can act on them. Follow every reachable entrypoint, including generated handlers and cross-service dispatch. Distinguish authenticated identity, permission to act, and visibility of returned data or metadata. Passing a RequestContext is not itself authorization proof; verify how authority is established and enforced. Make framework-granted authority for background dispatch explicit; historical actor metadata alone must not grant authority to a new operation. Invoke application policy hooks according to their documented contract.
2. Own the guarantee. Parse raw representations into domain types at the owning boundary. Inspect constructors, decoders and conversions before trusting a newtype's invariant. Keep operation-specific authorization, tenant/resource scoping and atomic checks where the protected operation runs. Preserve established invariants inside pure code rather than adding repeated guards to callers. Preserve event-store ordering, append preconditions, event identity and delivery contracts through framework serialization and reconstruction. Make decode failures and incomplete reconstruction explicit at the owning API. Prefer framework-owned safe defaults over asking every downstream user to remember another check or setting.
3. Protect secrets through every output path. Reuse Redacted and owned crypto APIs where applicable; inspect logging, formatting, exceptions, diagnostic labels and serialization as well as Show. A wrapper's safe display does not make unwrapping or every encoder safe. Derived instances are acceptable when their actual behavior preserves the required protection. Use established verification and cryptographic randomness for access-bearing secrets, without inventing cryptographic protocols or imposing secret-handling machinery on public identifiers and ordinary retry jitter. Keep public errors useful without exposing credentials or private internals.
4. Constrain effectful boundaries. Use the storage owner's parameterized statement/codec APIs for external values. Handle dynamic identifiers with their actual safe construction/quoting rules; a typed wrapper alone does not sanitize them. Follow input through any process, filesystem, network or outbound-request boundary the change reaches. Specify which framework execution paths reconstruct state and which may invoke external effects, including what retries can repeat after partial success. Expose delivery guarantees and relevant retry context so application integrations can handle duplicates. Check query/tenant isolation and authorization of counts or other metadata. For changed dependencies, generators or build fetches, inspect provenance and the repository's actual pin/integrity mechanism rather than assuming a lockfile or a type guarantees trust.
5. Bound attacker-controlled work. Put input size, scan/replay work, queue/admission, retry and resource-lifetime controls at the subsystem that owns the cost. A small returned page does not bound a full-store scan; a process-local limiter does not establish a deployment-wide limit. Preserve cancellation, cleanup and isolation under rejection or failure. Coordinate with Design for Throughput, keeping security checks and durability guarantees in the efficient path.

For each design concern or review finding, state the reachable input, affected guarantee, concrete impact and proportionate remedy. Distinguish an observed defect from a design risk or an unknown; do not invent an attacker path or a compliance obligation. Distinguish guarantees enforced by the framework from backend capabilities and application/operator responsibilities; state the configuration and failure/recovery assumptions that limit each claimed guarantee. Reuse existing contract suites, including the event-store specifications; extend relevant negative cases, isolation checks or properties only where the changed guarantee needs evidence. Keep sensitive investigation details and evidence under ignored .agents-state/; publish only material appropriate to the task's authorized audience. This principle adds design and review guidance, not a separate approval pipeline or mandatory review-record format.