Security — pilot controls in place

Separation and storage

• In placeSeparate stacks.The public website and the workspace are separate CloudFormation stacks with their own buckets, roles and CloudFront distributions. Nothing private is deployed into the public site's bucket.
• In placeUploads are validated and scanned before anything is kept.A file lands in a quarantine bucket the browser cannot name, under a policy bound to a server-chosen key, its exact declared length and its SHA-256. It is then re-read for type, size, checksum and file signature, checked structurally — a PDF carrying embedded JavaScript, a launch or open action, an embedded file or an XFA form is refused — and scanned for malware. Only the exact version that passed all of that is promoted; a flagged file is refused and deleted. Scanning runs inside our own AWS account, so drawings are not sent to an outside scanning service.
• In placeInvitations are delivered by the server.The invitation link is emailed from a domain we control with DKIM signing, and is never shown to the architect who created it — so holding the link means control of the mailbox it was sent to, not merely knowing the address. Bounces and complaints suppress the address automatically.
• In placeOperators never hold broad credentials.A production job issues a one-hour set of credentials scoped by policy to exactly one source file version and one output location, with an explicit denial on anything wider. One job's credentials cannot read or write another job's files; that is enforced by AWS and verified against real access-denied responses, not only by our own code.
• In placeRestore and deletion have been rehearsed.A drill restores every table into isolated copies and checks that deleted projects stay deleted, revoked invitations stay revoked, and purged files are not referenced again. Deleting a project removes every stored version, its production jobs, its releases and its exports.
• In placePrivate buckets.The workspace's quarantine, source and artifact buckets block all public access, deny any request that is not over TLS by bucket policy, and are versioned.
• In placeCustomer-managed encryption.Objects are encrypted with a customer-managed KMS key that has automatic rotation enabled. The workspace's DynamoDB tables are encrypted with the same key.
• In placeStandard response headers.Both distributions apply AWS's managed security-headers policy (strict transport security, content-type and frame options, referrer policy).

Sign-in and sessions

• In placeAuthorization code with PKCE.Architects sign in through Amazon Cognito using the authorization-code flow with PKCE; the code verifier is generated and held server-side, and the token exchange is a server-to-server call.
• In placeAdmin-created accounts only.The user pool allows no public sign-up. Team members are invited by their firm's owner, and BMDO creates the first account.
• In placeServer-side sessions.The session cookie carries a random 256-bit token; only its SHA-256 digest is stored. Sessions expire 8 hours after sign-in, absolutely, and the expiry is re-checked on every request. The cookie is HttpOnly, Secure and SameSite=Lax.
• In placeMembership re-checked on every request.The firm a session belongs to is resolved server-side and its membership row is re-read on every call, so removing a member ends their access on their next request.
• In placeCSRF token and Origin check.Every mutating request must carry the session's CSRF token and an Origin header equal to the workspace's origin.

Sharing

• In placePer-recipient grants.An invitation is bound to one recipient email, one project and one release version, with explicit capabilities (view, comment, download) and an expiry of 1 to 90 days. Only a SHA-256 digest of the token is stored; the link is returned once and never stored.
• In placeRevocation on the next request.A revoked grant's status is re-read on every guest request. A wrong email, a revoked or expired grant and a made-up token all receive the same “no longer available” response, so nothing is enumerable.
• In placeTenant scoping.Every project, grant, activity and billing read is scoped to the firm resolved from the session. Another firm's project id is indistinguishable from a missing one.

Logging

• In placeMinimal access logs.The API access log records time, method, path, status, latency and request id. It records no cookies, query strings or bodies, so a session token or sign-in code cannot appear in it.
• In placeNo internals in responses.API responses are marked no-store and never carry internal errors or stack traces.

Payments

• In placeStripe-hosted collection.Card details are entered on Stripe's Checkout and customer-portal pages and never reach BMDO.
• In placeSigned webhooks.Stripe events are verified by HMAC-SHA256 signature with a 5-minute tolerance and a constant-time comparison, then deduplicated by event id.
• In placeSecrets in Parameter Store.Stripe keys live in SSM Parameter Store, encrypted with the stack's key; the application role can read only that path.

Least privilege

• In placeApplication role.May read and write the named DynamoDB tables, read the Stripe parameter path, write its own log group, administer the user pool and use the key. It has no S3 access at all today.
• In placeWorker role.May read the source bucket, write the artifacts bucket and use the key. It has no database access, so a worker cannot read other projects' records or publish a release itself.