Status: Phase 1 — enforced. The control status table in §11 says what is implemented and what is not, including the gaps. Nothing here is described as active unless that table agrees.

Ranked by what an attacker would actually want, and by what would hurt the operator most:

1. Cross-tenant operational data — vessel positions, operations schedules and incident reports of another organization. Position data reveals commercial activity; incident data is legally sensitive. This is the highest-value target in the system.
2. Account credentials and sessions — an operator session can change operation status and acknowledge critical alerts.
3. Audit trail integrity — an attacker who can edit AuditLog erases their own presence.
4. Provider secrets — API keys for weather/AIS/LLM providers.
5. Availability of the Command Center — a blank command center during an operation is an operational impact, not merely an outage.

Library: Better Auth (better-auth, 1.6.25 stable). Chosen over Auth.js v5, whose stable channel is still next-auth@4 while v5 remains at 5.0.0-beta.32 — verified on npm, not assumed. Betting the authentication layer on a long-running beta is the kind of dependency risk that is cheap to avoid at Phase 0. See ADR-003.

Never in the token or cookie: role, organization id, permissions. They are read from the database on every request. A cookie that carries role=ADMINISTRATOR is a cookie someone will eventually try to forge, and a user demoted mid-session must lose access immediately.

Every authenticated request resolves exactly one context, server-side:

type TenantContext = {
  userId: string
  organizationId: string
  role: Role
  isDemo: boolean
}

Rules, all of them hard:

• getTenantContext() is the only way to obtain it. It reads the session cookie, loads the active Membership, and throws AuthenticationError if absent.
• No server action or query accepts organizationId as a parameter. If a function needs a tenant, it takes a TenantContext. This makes tenant confusion a type error rather than a code-review outcome.
• Users belonging to several organizations pick an active one; the choice is stored server-side in the session row, not in a client-writable cookie.
• Every data-access helper in lib/db requires a TenantContext in its first parameter and injects organizationId into the where clause. ESLint forbids importing the raw Prisma client outside lib/db.

A single permission matrix in lib/auth/permissions.ts. Permissions are resource:action strings; roles map to permission sets. Checks are always server-side — authorize(ctx, 'operation:update', resource) — and the UI merely reflects them by hiding controls the user cannot use.

Two deliberate shapes in this matrix:

• Operators record reality; managers change the plan. An operator can start, suspend and complete an operation and report an incident — that is their job at 03:00 — but cannot reschedule or cancel one.
• Acknowledging is not resolving. Any operator can take ownership of an alert; declaring it resolved is a supervisory act. That distinction is what makes the alert trail meaningful.

Object-level checks. Role permission is necessary, not sufficient: authorize() also verifies the target record belongs to ctx.organizationId. A valid id from another tenant must return 404, not 403 — a 403 confirms the record exists, which is itself a leak.

• Every server action and route handler parses its input with Zod before anything else. The parsed value is used; the raw input is never touched again.
• Validation lives in features/*/schemas/ and is shared with the client form, so client and server enforce the same contract from one definition. Client validation is UX; server validation is the control.
• Domain invariants that Zod cannot express (status transitions, plannedEnd > plannedStart, risk score consistency) are checked in the domain layer, then again by database constraints.
• Ids are validated as ids and then resolved within the tenant scope — the ownership check is what stops IDOR, not the format check.
• Uploads: extension and MIME allow-list, size cap, randomly generated storage key, never the user-supplied filename on disk, and files served through an authorizing route handler — never from a public bucket path.

Security headers (next.config.ts + middleware): Strict-Transport-Security, X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy denying camera/microphone/geolocation, and a CSP whose only external origins are the basemap tile host and the weather API.

Every mutation writes an AuditLog row inside the same transaction as the change. If the audit write fails, the change rolls back — an audit trail that can silently disagree with the data is worse than none, because it is trusted.

Recorded: actor, organization, action (operation.status_changed), entity type and id, before/after diff (with sensitive fields redacted), IP, user agent, timestamp.

AuditLog is append-only: no update or delete path exists in the application, and the application database role is granted only INSERT and SELECT on that table (Phase 10). Administrators can read the trail; nobody can edit it through the product.

• src/config/env.ts parses process.env with Zod at startup. A missing or malformed variable fails the boot, rather than surfacing as undefined in production three days later.
• .env is git-ignored; .env.example documents every variable with a description and whether it is required. Secret scanning runs in CI on every push.
• Rotation: provider keys are read from the environment only, never persisted in the database, so rotation is a redeploy.

• Tools execute with the caller's TenantContext. The model cannot request a wider scope, because the scope is not part of the tool input.
• Tools are read-only in the first AI release. State-changing tools require a human approval step, designed separately.
• Every tool result is size-capped before entering the prompt, so a large query cannot blow the context window or the bill.
• Prompt injection is assumed: user-supplied text (incident descriptions, notes) may contain instructions. It is passed as data, never concatenated into the system prompt, and the model has no tool capable of writing, so the blast radius of a successful injection is a wrong answer — not a wrong action.
• Per-organization request quotas and cost logging from the first AI call.

SECURITY.md at the repository root points here. Reports go to a private channel, not a public issue. This is a portfolio project with no production users: there is no SLA claim, and the document says so rather than inventing one.

withAudit() runs on forTenant(ctx).$transaction, not on the raw client. The first version used the raw client — the natural place to look for $transaction — which would have made every audited mutation the single write path with no tenant filter, in a codebase whose whole isolation story is that such a path does not exist. Verified: the extension does apply inside the transaction, and a write naming another organization is overruled. Covered by tests/integration/audit.test.ts.

Verified against a running instance, not asserted:

• A wrong password and an unknown e-mail return the same 401 and the same message; the sixth attempt within 15 minutes returns 429.
• /command-center without a session redirects to sign-in. The check is in the layout, not the middleware, because middleware sees a cookie and a cookie is not a session.
• Tenant isolation: another organization cannot read, update or delete a record by id, and a create naming a foreign organizationId is overruled to the caller's own.
• The navigation and the Command Center's module list are both filtered by permission. The first version filtered only the sidebar — an Operator could see that an Administration module existed. Caught by testing the rendered page for each of the four roles rather than trusting the code path.

• Passwords are not checked against a common-password list yet. The 12-character minimum is enforced; the breach-list check named in §2 is not written.
• Rate-limit state is in memory. It resets when the process restarts, and it does not span instances. Fine for one process; needs shared storage before there are several.
• AuditLog is append-only by convention, not by grant. No update or delete path exists in the application, but the database role can still do both. The INSERT/SELECT-only grant is Phase 10.
• No E2E test covers the sign-in flow. The API path was verified by hand against a running server; the browser path — form submit followed by the redirect into the Command Center — is covered only by typecheck, because driving a server action needs a real browser. Playwright is Phase 10, so until then a regression there would be caught by a person, not by CI.