Security

Security is part of every decision we make about the product. We follow the principle of least privilege, default to encryption everywhere, log access for review, and write the product in memory-safe languages on managed infrastructure. We describe the specifics below; if a measure isn't listed here, assume it's on the roadmap rather than in production.

• Application and database hosting on Railway, with PostgreSQL as the system-of-record. The construction-graph workers and the API server run in containers under the same network boundary as the database.
• Construction-graph database backups land in an S3-compatible object store (Railway Buckets) at server-side encryption. The backup bucket holds Postgres dumps only — we do not store user-uploaded files in object storage (avatars and similar are inline data URLs in the database).
• Inbound application traffic terminates at HTTPS with modern TLS. Plain HTTP requests are not served in production.
• Production secrets (API keys, signing keys, database URLs, OAuth client secrets) are stored in the hosting provider's secret store, scoped per environment, and never committed to source.

• In transit — TLS 1.2 or higher with modern cipher suites for every external connection to the website and the product.
• At rest — the Postgres volume is encrypted at the storage layer by the hosting provider. Backups in object storage are encrypted at rest by the storage provider.
• Account passwords are hashed with bcrypt at the default cost before storage; we never store plain-text passwords. Personal-access tokens — long-lived bearer credentials issued only to internal administrators for our own command-line tooling, not exposed to customers — are stored as a SHA-256 hash of the plaintext token, with only a short non-secret prefix kept in the clear for display in the list view.
• Session tokens, single-use magic-link tokens, and password-reset tokens are also stored as SHA-256 hashes of the values issued to the browser. The plaintext only ever lives in the session cookie or in the email link the user receives; a database leak alone cannot be used to impersonate a user or hijack a password reset. The session cookie is HttpOnly, SameSite=Lax, and Secure (sent only over HTTPS) in production.

• Production database and hosting access is restricted to a short list of named individuals (currently the founders). Access is reviewed on every personnel change.
• Customer accounts authenticate with email + password, magic links (short-lived, single-use), or Google OAuth. Passwords have a minimum length; we do not impose periodic-rotation requirements, which research shows weaken security.
• Sessions are scoped to a single browser, expire on the server side, and can be revoked by clearing cookies. Personal-access tokens are scoped per user, can be revoked from the admin area at any time, and the full plaintext token is displayed only once at issuance.
• Authentication endpoints (login, magic-link request, password reset) are rate-limited per-IP and per-email to slow credential-stuffing and email-enumeration attacks.
• An admin allowlist (controlled by the ADMIN_EMAILS environment variable) gates the /api/admin/* endpoints — middleware returns 403 if the session's email is not on the list.

Customer-specific data — Matrix workspaces, custom columns, Signals templates, project notes, CRM-sync records — is scoped to the user (and, where applicable, the organisation) that owns it and is filtered on every read by the authenticated user's id. The product's authentication middleware refuses any request that does not present a valid session.

• Application logs are structured (JSON) and retained according to our hosting provider's default policy.
• Authentication events, reveal-contact events, and administrative actions are written to dedicated database audit tables that are write-only from application code.
• Operational health (request error rate, latency, queue depth) is visible to the engineering team via the hosting provider's metrics; we do not yet have a paging on-call rotation outside of normal business hours.

Every subprocessor we use is enumerated in the Privacy Policy and the DPA. New subprocessors are reviewed for security posture and data-handling commitments before they are added. We update the published list before changing the data flow.

• All code is reviewed before merging to the main branch and runs through automated linting, type checking, and tests on every change.
• Dependencies are tracked through the language ecosystem's lock files (go.mod for the API, package-lock.json for the frontend); we monitor advisories and patch critical vulnerabilities as they surface.
• External HTTP traffic from the product passes through a small set of internal HTTP clients; outbound URL fetches initiated by user input are bounded by SSRF guards (allowlisted schemes, blocked private-IP ranges).
• We treat the OWASP Top Ten as the floor for application-security review — injection, broken authentication, sensitive-data exposure, SSRF — and address those threats as first-class items in code review.

If we become aware of a security incident that compromises personal information, we will investigate, contain, and notify affected customers without undue delay. For incidents that meet the GDPR's notification threshold to a supervisory authority, we will provide notice within 72 hours of becoming aware. Customer notifications will describe what happened, what information was involved, what we have done to address it, and what you can do to protect yourself.

If you believe you have found a security vulnerability in our product or marketing site, please email security@tibly.ai with the steps to reproduce. We read every report. We will not pursue legal action against good-faith researchers who follow these guidelines:

• Do not access, modify, or destroy any customer data.
• Do not run automated scans against the production environment without our prior agreement (we do not currently maintain a separate staging environment that is open to external testing — ask us before scanning).
• Give us a reasonable window to investigate and patch before publishing details (typically 90 days).
• Do not perform tests that degrade service availability or that may impact other customers.