Please report security issues privately — do not open a public issue for an unpatched vulnerability. Use either private channel:

• Email (preferred): builder@massing.cloud. PGP available on request.
• GitHub: a private security advisory (via the repository's Security → Advisories → Report a vulnerability button).

We aim to acknowledge within a few days and to ship a fix or mitigation promptly. Please include steps to reproduce, affected version/commit, and impact.

The platform ships in two postures:

• Local / desktop / demo (default): single operator, open by design — RBAC is off so local flows just work. Run it on a trusted machine / network.
• Team / cloud (multi-user): turn on access control and set the secrets below. With RBAC on, every request to project, finance, connection, settings, and admin surfaces requires an authenticated identity (a defense-in-depth gate enforces this even if an endpoint lacks its own role check), and each project-scoped route is authorized by the caller's project role.

Set these environment variables for a team/cloud deployment:

The bundled docker-compose.prod.yml sets these (RBAC, require-secret, HSTS, secure cookie, strict CSP, Redis) and ships a redis service; you only supply the secrets in .env (AEC_AUTH_SECRET, POSTGRES_PASSWORD, S3_*).

There is no Alembic — by design. The schema is partly config-driven: each GC-portal module (module.json) registers its own mod_<key> table at startup, so the table set isn't fixed in code. On boot init_db() runs an additive, dbDelta-style sync: create_all (new tables, including the dynamic module tables) → _ensure_columns (ALTER-ADD any model column missing from an existing table) → _ensure_indexes (backfill new indexes). It is additive only — it never drops or retypes a column, so deploying a newer build over an existing Postgres/SQLite DB is safe and automatic. This is covered by test_migrate.py.

Non-additive changes (dropping/renaming/retyping a column, backfilling data, adding a NOT-NULL column with no default) are not handled automatically — run a one-off SQL migration against the DB during the deploy for those. Take a backup first; the additive sync intentionally won't destroy data.

• Identity: signed bearer tokens / httpOnly samesite=lax cookie; the X-User header is never trusted in production. Accounts can be deactivated (token revocation takes effect immediately).
• Authorization: project-scoped RBAC on read/write routes + a global gate that blocks anonymous access to protected prefixes when RBAC is on. Attachment downloads verify project membership (no IDOR).
• Response headers: X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy, a Content-Security-Policy (framing-only by default; opt-in strict resource policy), optional HSTS.
• Direct downloads: model.frag and attachments accept short-lived HMAC-signed URLs as an alternative to a session (for QR share / worker fetch / deep links); the auth cookie is Secure over HTTPS.
• Signed share links (disposition & investor portal): two intentionally-anonymous surfaces, both requiring a valid HMAC-signed URL even when RBAC is off, read-only, scoped to one project + record (no id-swapping), and rate-limited; minting a link requires a project member (viewer):
  • the public listing (GET /projects/{id}/listings/{lid}/public) returns only owner-authored public fields (price, description, beds/baths, tour link — never internal financials like NOI/cap);
  • the investor statement (GET /projects/{id}/investors/{iid}/statement.public.pdf) serves that one investor's capital-account statement PDF for the no-login LP portal.
• Container: the API image runs as a non-root user (appuser, uid 10001).
• Input / data: Pydantic-validated request models; SQLAlchemy parameterized queries; the data-source SQL browser is read-only (single SELECT/WITH, no DDL/DML, row-capped); storage keys are containment-checked (no path traversal) and upload filenames sanitized.
• Abuse limits: request body-size cap, login lockout, optional per-IP rate limiting, bounded compute (e.g. Monte Carlo iterations).
• Supply chain: CI runs pip-audit + npm audit; production npm dependencies carry no known vulnerabilities (build-only tooling is excluded from the shipped app).
• IFC is the source of truth and the in-viewer authoring round-trips through ifcopenshell recipes (not arbitrary code); the optional Bonsai/Blender desktop bridge that can run Python is gated and off by default. The opt-in execute_ifc_code escape hatch is AST-allowlisted, denied any IO through the objects it is handed, and bounded by a wall-clock budget.
• Outbound requests to operator-set URLs (webhooks, bridges) are scheme-validated on the initial URL and on every redirect hop, so a 3xx cannot walk the guard to an internal address.
• Rendered drawings are sanitised before entering the DOM — model-derived SVG is parsed inertly and stripped of script/handlers, so a hostile IFC cannot become stored XSS.

We credit reporters (unless you prefer to remain anonymous) and note fixes in the CHANGELOG.