Firmloom — Security Overview

Creator Alliance Group Pty Ltd · ABN 41 689 817 070 · Updated 2026-08-05 · Full detail at /trust

Firmloom builds durable, permissioned institutional memory from your business communications. This one-pager summarizes our security posture. Every claim here is defensible today; roadmap items are marked as such.

The one rule: no tool, cache, summary, or timeline ever returns a fact whose source message the requester isn't allowed to see. It's enforced by a permission-test suite that runs in CI — a red permission test blocks deploy.

Source suites — read this before the rest

Microsoft 365 today: mail, calendar, Teams meeting transcripts, SharePoint and OneDrive documents; one organization-wide admin consent, or an individual connecting their own mailbox. Google Workspace is not yet available (our application has not completed Google's OAuth verification) and, when it is, it is Gmail and Google Drive only — no calendar, no contacts, no meeting transcripts, no mail side panel, no manager-hierarchy sync, and no organization-wide connection: each person connects their own mailbox and can disconnect it themselves. Every claim below naming Microsoft 365 is a Microsoft 365 claim.

Hosting & residency

US-hosted (Neon Postgres, AWS S3, Replit compute, Anthropic, Voyage AI — all US). Your data-at-source stays in your source suite's own region (your Microsoft region, or your Google Workspace region); the ingested copies are US. International transfers covered by SCC- equivalent commitments; DPA available on request. AU/EU in-region hosting is roadmap, not shipped.

Subprocessors

Microsoft (source & identity for Microsoft 365, your region), Google (source & identity for Google Workspace — not yet available; your Workspace region), Salesforce (source platform, only where you connect an org; your Salesforce org's region), Anthropic (AI extraction, US), Voyage AI (embeddings & reranking, US), Replit (hosting/compute, US), Neon (Postgres, US), AWS S3 (blob storage, US), Sentry (error monitoring, no mail content, US), Resend (transactional email — reauth nudges, alerts and digests, US). New subprocessors added by notice. What reaches Anthropic and Voyage AI is your own suite's content — on Google Workspace that is Gmail and Drive text and no calendar or meeting content. Search queries are answered from the local index and are not sent to an LLM (query text does reach Voyage's reranker).

Data handling

We do not train AI models on your data and do not sell personal data — a contractual commitment with our AI providers. Encryption: TLS in transit, provider encryption at rest, AES-256-GCM for stored refresh tokens, hashed MCP tokens. Attachments are scanned with ClamAV where the deployment provides a loaded signature database; where it does not, they are stored marked as not scanned rather than recorded clean. Prompt-injection hardening (fenced data blocks, static system prompts, read-only MCP surface).

Access model (ten CI-tested invariants)

Tenant isolation via mandatory tenant_id scoping — the layer in force on every deployment — with Postgres row-level security defined and forced on every tenant table as an independent second layer, which binds where the deployment connects under a non-owner database role. Results are always a subset of the requester's access; sensitive content (HR/legal/payroll) is excluded from every scope; hierarchy is strictly downward; every MCP call is audit-logged before it returns; derived outputs never widen access. All sixteen invariants (BUILD_SPEC §6) are tested over a fixture org in CI; a red permission test blocks deploy.

Microsoft Graph permissions

Org mode: Mail.Read, MailboxSettings.Read, User.Read.All, GroupMember.Read.All, Organization.Read.All — narrowed by an Exchange Application Access Policy the customer configures in Microsoft 365 and Microsoft enforces; Firmloom offers a verification check rather than gating sync on it. Individual mode: openid, profile, email, offline_access, Mail.Read, MailboxSettings.Read, User.Read, Calendars.Read, Contacts.Read, Sites.Read.All, Files.Read.All. Delegated permissions never exceed the signed-in person's own access, and SharePoint/OneDrive stay unread until specific sites or drives are selected.

Google OAuth scopes (not yet available)

Per person: openid, .../userinfo.email, .../userinfo.profile, .../auth/gmail.readonly, .../auth/drive.readonly. Admin connection only: .../auth/admin.directory.user.readonly, .../auth/admin.directory.group.readonly, .../auth/admin.directory.group.member.readonly. All read — no Gmail or Drive write scope of any kind is requested. drive.readonly returns each file's own sharing list, which is what lets Firmloom refuse to show a document to someone Drive does not already grant. There is no organization-wide connection: Google's equivalent is a domain-wide delegation key that can impersonate every user and that Google gives no way to restrict to a group, so Firmloom does not use it and holds no such key. An admin's directory connection connects no mailbox; a rollout takes a connect link per person.

Salesforce (optional, read-only)

Nothing is read from Salesforce unless an administrator connects an org. The grant is exactly two OAuth scopes — api and refresh_token — and no write scope is requested. Eight standard objects are read, and only these fields: Account (Id, Name, Website, ParentId, SystemModstamp); Contact (Id, FirstName, LastName, Name, Email, AccountId, ReportsToId, Title, SystemModstamp); User (Id, Name, Email, IsActive, SystemModstamp); Opportunity (Id, Name, AccountId, Amount, StageName, IsClosed, IsWon, CloseDate, SystemModstamp); OpportunityContactRole (Id, OpportunityId, ContactId, Role, IsPrimary, SystemModstamp); OpportunityHistory (Id, OpportunityId, StageName, Amount, CreatedDate, SystemModstamp); Task and Event (Id, WhoId, WhatId, Subject, ActivityDate, SystemModstamp). CRM-derived facts are labelled as asserted by the CRM rather than observed in communications, follow CRM norms rather than mailbox grain but are still gated on the seat already having a visible window onto the account, and carry no mail source. Disconnecting purges the staged CRM records; the offboarding purge counts them on the certificate.

Retention, erasure & purge certificate

The memory is independent of your mail client but not of the source item: when the source's change feed reports a message or file deleted, we remove our copy, and when it was the last copy we erase the item and the facts extracted from it. Ingestion window defaults to 12 months (24 available, configurable) and bounds how far back we read; the separate rolling-window auto-purge that erases content once it ages past the window is off by default, so while it is off that content is retained. Folder exclusions apply retroactively to mail already ingested. Per-tenant legal hold suspends every purge. Targeted erasure by message/conversation/participant (GDPR right-to-erasure). Offboarding deletes all rows + blobs within a 72-hour target and issues an Ed25519-signed, customer- verifiable purge certificate — verifiable with the public key alone (signing key is never the session secret). Backups: the managed database keeps point-in-time recovery history, so a deletion remains recoverable from that history for a period; a restore that would reinstate erased or purged data has the erasure or purge re-applied before service resumes.

SOC 2 & penetration testing

Audit-ready security evidence trail from day one; SOC 2 certification is on our roadmap (we do not claim certification we don't hold). Codebase hardened through repeated internal adversarial security review; third-party penetration test is on our roadmap.

Employees

Sensitive content is invisible to everyone, including managers; hierarchy access is strictly downward and blocked until the employer completes a mandatory, recorded employee-disclosure step. See /trust#employees.

Contact admin@creatoralliancegroup.com for a DPA, a completed security questionnaire, or residency specifics.