Security and compliance

This page is a factual account of Albumi’s security posture. It describes what is implemented, what is not, and where responsibility lies between Albumi and the customer. No compliance certification is claimed; where specific controls exist, they are described plainly.

Tenant isolation

Every business entity — applications, integrations, data objects, capabilities, IT components, initiatives, organisations, albums, activity, comments, notifications, users, invites — is scoped to a workspace and filtered at the data-access layer by a fail-closed query filter: if a workspace context is missing, reads return empty and writes raise an error. Cross-tenant leakage through a missing context is therefore not a quiet data-leak risk; it is an error that fails loudly at the database boundary.

A small set of tables is global by design: the Account table (the identity a user logs into), the Security Audit Log (which logs events across all accounts), API keys (which are account-scoped, not workspace-scoped), the session store, and encryption key material. These are never returned in workspace queries and are not visible across accounts.

Authentication

Albumi supports two sign-in paths.

OAuth (interactive users)

Google and Microsoft are the two supported identity providers. There is no Albumi-managed password — a user authenticates against their provider and Albumi receives a verified identity assertion. MFA, if enforced, is handled on the provider side: if your Google or Microsoft account requires a second factor, that second factor is in play for Albumi sign-in automatically.

Albumi does not layer its own MFA on top of the OAuth provider. If your organisation’s policy requires application-level MFA independent of the IdP, that gap is present today.

API keys (headless / automation)

Account owners can generate API keys for use with the CLI, MCP server, or direct API calls. Key format: alb_ prefix followed by 30 random hex bytes. Stored as a SHA-256 hash in the database — the plaintext key is shown once, at creation, and cannot be recovered.

Two properties to know:

• Keys are account-scoped, not workspace-scoped. An API key inherits the full workspace access of the account that owns it. If an account has access to three workspaces, a single API key can act in all three.
• No per-key scope restrictions. There is no “read-only” or “entity-type-restricted” key type today. A key is as privileged as the account that holds it.

Key creation and deletion are recorded in the Security Audit Log. Keys can be explicitly revoked (immediate effect) or given an expiry date (30 days, 90 days, 1 year, or never).

Sessions

Interactive sessions are stored server-side in a PostgreSQL table backed by an in-memory cache for low-latency lookup. Default TTL is seven days; each request renews the session through normal cookie refresh.

Sessions are revoked in the following cases:

• Explicit sign-out (the one session being used).
• “Log out of all devices” — revokes all sessions for the account except the current one.
• Member removal from a workspace — all of the removed member’s sessions across every workspace are revoked.

Role changes log an audit event but do not currently force a session refresh; if a member is demoted, their current session may continue with stale claims until it naturally expires or they re-authenticate. Closing that gap is on the roadmap.

Audit and activity logs

Albumi keeps two distinct log streams.

Security Audit Log (account-scoped)

Logs authentication and security-relevant events across the account: sign-in success and failure, sign-out, account creation, provider linking, role changes, member deactivation, API key creation and deletion. Each event captures IP address, User-Agent, OAuth provider, outcome (success / failure / blocked), reason, and arbitrary metadata.

Surfaces in the UI:

• Login history — the signed-in user’s own successful and failed sign-ins with browser and OS parsed from the User-Agent.
• Security alerts — the user’s own failed authentication attempts.
• Admin audit view — Admin-visible list of all events for workspace members, with emails and display names resolved.

There is not yet a unified “who changed what in the workspace” audit dashboard beyond what the entity-level activity log provides.

Activity log (workspace-scoped, per-entity)

Every change to a business entity — creation, edit, status transition, deletion, proposal merge — writes an Activity row against that entity. The activity feed on an entity detail page shows this history, filtered by isMainline so that proposal-internal events do not pollute the public timeline while drafts are in progress; once a proposal is merged, the merge appears in the mainline history with a diff link.

Activity is always attributable: every row records the user who made the change, the change type, and enough metadata to reconstruct the diff.

Data classification

Albumi exposes two kinds of classification on architecture data.

Entity-level flags on Data Objects

DataObject carries three explicit flags:

• piiFlag — the data object contains personally identifiable information.
• pciFlag — the data object falls under PCI-DSS scope.
• classification — one of public, internal, confidential, restricted.

Applications additionally carry gdprRelevant, soxRelevant, and pciDssRelevant flags.

These are metadata today, not enforcement. They drive reporting and the anonymous-share strip pipeline (see below), but they do not automatically gate access — a Viewer with workspace membership can see a restricted data object, the same as any other entity. If you need hard access control by classification, that control must live outside Albumi today. Surfacing classification-driven visibility is on the roadmap.

Anonymous share strip pipeline

Shared pages (/s/{token}) go through a dedicated anonymiser that removes sensitive fields before the response is served. The strip list includes, for every shared page:

• Endpoint and Authentication on Interfaces
• Classification, PiiFlag, PciFlag on Data Objects
• TransformationNotes and middleware UUIDs on Integrations
• WorkspaceId, AcrId, FocusEntityId, DeletedAt, CreatedByUserId, ChangeId on every entity

Every internal UUID is replaced with a stable, per-response short public ID. See Shared pages for the full mechanism.

Data retention and deletion

Albumi distinguishes soft-delete (recoverable) from hard-delete (permanent).

Soft delete

Applied to users, entities, and workspaces. Marking a row as deleted sets a deleted_at timestamp; the row is excluded from queries but retained in the database. Soft-deleted entities preserve history — comments, activity, versions, references — which is why an entity someone created last year still appears in the audit trail even after they leave.

Hard delete

Workspaces are hard-deleted after a 30-day grace period from the soft-delete action. During the grace period the workspace can be restored with all data intact. After 30 days, a background cleanup job permanently removes the workspace and all its data.

Users and individual entities are not hard-deleted on a schedule today; soft-deleted records persist until an explicit cleanup action is taken. “Right to be forgotten” as a self-service user action is not currently implemented; requests for hard deletion of personal data are handled manually — see the contact section below.

Export and portability

Admins can export the full workspace as JSON at any time via Workspace Settings → Export. The file conforms to the published workspace schema and contains every entity, user, and relationship. The same shape can be re-imported to another workspace for migration, backup, or archival purposes.

There is no dedicated “personal data export” for a single user independent of their workspace — the workspace export is the unit of portability.

Encryption

In transit: HTTPS is enforced end-to-end. TLS termination runs on Traefik with Let’s Encrypt-managed certificates; there is no unencrypted HTTP path into the application. Cookies carry the Secure flag.

At rest: handled at the infrastructure layer by the cloud provider’s storage encryption, not enforced at the application level. API key tokens are stored as SHA-256 hashes, which means a database compromise does not leak usable tokens; passwords do not exist in the system (OAuth only), so there is no password database to leak. Application-level encryption of arbitrary fields is not implemented.

Backups: PostgreSQL is backed up via pgBackRest to Cloudflare R2. Backup encryption at the R2 layer is handled by the provider.

Compliance

Albumi claims no formal certification at this time. In particular:

• Not SOC 2 certified.
• Not ISO 27001 certified.
• Not HIPAA-compliant (and not marketed to healthcare).
• Not PCI-DSS certified (the PCI flag on data objects is for your own tracking, not a compliance claim by Albumi).

Legal jurisdiction: Finland. Data processing is cloud-hosted; specific region details are available on request for enterprise discussions.

For regulated environments requiring formal attestations, the gaps above need to be addressed through operational controls on your side, contract-level assurances, or waiting for Albumi’s compliance roadmap to deliver. We can discuss specific needs through [email protected].

Responsibility split

A brief summary of who is responsible for what:

Area	Albumi	Customer
Tenant isolation	Yes — enforced at data-access layer	Verify workspace boundaries match your org structure
Authentication infrastructure	Yes — OAuth, sessions, API key storage	Enforce MFA at IdP (Google / Microsoft) if required
Session revocation	Yes on sign-out, log-out-all, member removal	Act promptly on offboarding; role demotions today don’t force refresh
Audit log of security events	Yes — sign-in, role change, API key lifecycle	Review admin audit view periodically
Classification & PII flags	Yes — fields exist, propagate through export and share strip	Populate flags accurately; today they are metadata, not access control
Data classification enforcement	No — not implemented	Compensating controls outside Albumi if required
Encryption at rest	Cloud provider layer	None — accept the model or do not use Albumi
Backup and restore	Yes — automated, with grace-period restore	Data-critical actions in Albumi are still governed by your processes
Export / portability	Yes — full workspace JSON export	Periodic export for your own archival, if required
GDPR right-to-erasure	Partial — manual, via support request	Submit the request via [email protected]
Formal compliance attestation	No — none today	Treat as unattested until stated otherwise

Reporting a security issue

If you find what you believe is a security vulnerability, email [email protected] with the details. We respond to security reports directly and prioritise investigation. Please do not post vulnerability details publicly until we have had a chance to triage — coordinated disclosure is the norm.