Firmloom Privacy Policy

Version: 2026-08-05 Effective date: 2026-08-05 Applies to: the Firmloom Service operated by Creator Alliance Group Pty Ltd (trading as Firmloom).

In plain English (read this first): Firmloom builds an institutional-memory layer over your organization's business content. What we read depends on which suite you connect, and the two are not the same. On Microsoft 365 it is mail, calendar events, Microsoft Teams meeting transcripts, and SharePoint and OneDrive documents. On Google Workspace it is Gmail and Google Drive only — no calendar, no contacts, no meeting transcripts. If you connect a Salesforce org we read, and never write, the records listed in Schedule A. To do all of that we read and store that content and send some of it to AI providers for processing.

The memory we build is independent of your mail client: it survives a person leaving, a thread being archived, and a mailbox going out of scope. It is not independent of the source item. When an item is deleted where it lives — in the mailbox or the drive — and that deletion reaches us on the provider's change feed, we remove our copy of it, and when it was the last copy we also remove the facts we extracted from it. Section 11 sets out exactly what is deleted, by which mechanism, and what survives.

Your organization's administrator controls what we can access, who can see it, and what gets deleted. This policy explains, in full, what we collect, why, who we share it with, how long we keep it, and the rights you have. Each section below opens with a plain-English summary; the summary is an aid to understanding and is not the operative legal text.

1. Who we are and the scope of this policy

In plain English: This policy covers the Firmloom product — the ingestion, indexing, AI processing, and querying of your Connected Sources. It applies to organization customers and to individuals who connect only their own mailbox. Contact us at the addresses at the end if you have questions.

This Privacy Policy describes how Creator Alliance Group Pty Ltd (company number ABN 41 689 817 070), trading as Firmloom, of Suite 302, 13/15 Wentworth Avenue, Sydney NSW 2000, Australia ("Firmloom", "we", "us", "our"), collects, uses, discloses, and protects personal data in connection with the Firmloom service (the "Service").

Firmloom is an institutional-memory layer over a company's own business content. It ingests that content from the source suite the Customer connects, parses, embeds and permission-filters it, and makes it queryable from MCP-compatible AI assistants, a web administration console, and API endpoints. The scope differs by suite, and this policy states it per suite throughout:

• Microsoft 365, ingested via Microsoft Graph — mail, calendar events, Microsoft Teams meeting transcripts, and SharePoint and OneDrive documents.
• Google Workspace, ingested via the Gmail and Google Drive APIs — mail and documents only. Firmloom does not read Google Calendar, Google Contacts, or Google Meet recordings or transcripts, and requests no scope that would let it. See section 5.2 and Schedule A.1 for the status of this suite, which is disclosed here in advance of being offered.

Firmloom is a multi-tenant, business-to-business ("B2B") service; our customers are organizations ranging from a single mailbox to several hundred mailboxes. A solo/delegated tier lets an individual connect only their own mailbox.

This policy applies to:

• Organization customers ("Customers") who authorize Firmloom to access their organization's Connected Sources, and the individuals within those organizations who are granted access to the Service ("Authorized Users");
• Solo/delegated-tier users, who connect only their own mailbox and use the Service for themselves; and
• Third parties whose personal data appears within a Customer's ingested content because they corresponded with the organization (for example clients, vendors, and subcontractors).

This policy does not govern the separate privacy practices of Microsoft, Google, Salesforce, the AI assistants you connect to Firmloom, or any other third party, each of which operates under its own terms and privacy notice.

This policy sits alongside the Firmloom Terms of Use, which incorporates this policy by reference. Where a written data processing agreement ("DPA") is executed between a Customer and Firmloom, that DPA governs the processing of Corpus data and controls to the extent of any conflict with this policy on processing matters.

2. Definitions

In plain English: These are the capitalized terms we use throughout this policy and in the Terms of Use. They mean the same thing in both documents.

The following defined terms are used consistently across this Privacy Policy and the Firmloom Terms of Use:

• Service — the Firmloom software, hosted platform, administration console, API endpoints, and MCP interface through which Connected Sources are ingested, indexed, processed, and made queryable.
• Customer — the organization that subscribes to the Service and authorizes Firmloom to access one or more Connected Sources. In the solo/delegated tier, the individual user is the Customer.
• Authorized User — an individual permitted by a Customer to access the Service under the Customer's subscription.
• Connected Source — any third-party platform, API, application, or data system that a Customer authorizes Firmloom to access. The current Connected Sources are the Connected Sources listed in Schedule A.
• Source suite — the productivity platform a Customer connects as the origin of its mail and documents. The suites are Microsoft 365 and Google Workspace, and what Firmloom reads differs between them (section 1 and Schedule A.1).
• Corpus — the content ingested from a Customer's Connected Sources. For a Microsoft 365 Customer that is mail (message bodies, metadata, participants, and attachments), calendar events, Microsoft Teams meeting transcripts, and SharePoint and OneDrive document content. For a Google Workspace Customer it is Gmail message content and Google Drive document content only — no calendar, contacts, or meeting transcript content is ingested for that suite. Where a Salesforce org is connected, the Corpus also includes the records itemized in Schedule A.1.
• Derived Data — data that Firmloom generates from the Corpus, including AI-extracted items, entity and relationship information, summaries, embeddings, and sensitivity classifications.
• AI Provider — a third-party provider of artificial-intelligence services that Firmloom uses to extract, classify, summarize, embed, rerank, or evaluate content. The current AI Providers are listed in Schedule A.
• Subprocessor — a third party that processes personal data on Firmloom's behalf in order to deliver the Service. The current Subprocessors are listed in the table in Schedule A.
• Order Form — the quote, order form, or equivalent document that records a Customer's subscription, plan tier, and commercial terms.
• Personal data / personal information — information relating to an identified or identifiable individual, as those terms are used under applicable data protection law (including the Australian Privacy Act 1988, the EU and UK GDPR, and the CCPA/CPRA).

3. Our two roles: controller and processor

In plain English: For your organization's email content, your organization decides what happens and we act on its instructions — your organization is the "controller" and we are the "processor". For your account, billing, and the audit/usage records we keep to run the Service — and for solo-tier users — we decide, so we are the "controller". This split is what lets a formal data processing agreement slot in later.

Firmloom acts in two distinct capacities, and it is important to distinguish them.

Firmloom as processor. For the Corpus and Derived Data belonging to an organization Customer, the Customer is the controller and Firmloom is the processor. The Customer decides which Connected Sources to authorize, which mailboxes are in scope, who may access the Service, and what is retained or erased. Firmloom processes that data on the Customer's documented instructions in order to provide the Service. Where a DPA is executed, it sets out these processor obligations in detail.

Firmloom as controller. Firmloom is the controller for:

• account and directory data used to authenticate and manage users;
• billing and commercial data;
• audit, security, and usage/telemetry data that we generate to operate, secure, and improve the Service; and
• all personal data of solo/delegated-tier users, for whom Firmloom deals directly with the individual as controller.

We state both roles explicitly so that responsibilities are clear and so that a future DPA can be incorporated without restructuring this policy.

4. What we collect

In plain English: We collect your organization's directory information; the content we ingest from your Connected Sources — mail (including attachments) on either suite, plus calendar events and Microsoft Teams meeting transcripts on Microsoft 365 only; the AI-generated insights we build from it; the login and token data needed to secure access; and usage/audit records. Because we ingest this content, it unavoidably includes personal data about people who are not Firmloom users — the external people your organization corresponds or meets with. We do not collect payment card data or advertising/analytics tracking data.

We collect and process the following categories of data.

4.1 Account and directory data. For a Microsoft 365 Customer: Microsoft Entra (Azure AD) object identifiers, email addresses, display names, an administrator flag, manager relationships (the organizational tree), Azure AD group memberships, and seat status. For a Google Workspace Customer: the Google directory identifier, primary email address and display name of each licensed user, and the membership of the groups an administrator chooses to import, stored as opaque directory identifiers. Firmloom does not read a manager or reporting hierarchy from Google Workspace; on that suite a reporting line exists only where an administrator enters it in Firmloom.

4.2 Mail corpus. Message bodies (both plaintext and the full raw MIME), subjects, participants (from, to, cc, and bcc, including external parties), timestamps, conversation threading, and folder metadata; and attachments, comprising both the raw bytes and text extracted from them (including text recovered by optical character recognition).

Unsent drafts are never read (Microsoft 365). A message that the source marks as not yet sent is excluded when the mailbox is enumerated: Firmloom does not fetch it, store it, index it, or make it searchable, and no part of it is sent to an AI Provider. This is structural, not a setting a Customer or administrator can switch on or off. If a draft is later sent, the sent message is ingested in the ordinary way. The exclusion is applied by Firmloom's mailbox-enumeration layer using an unsent flag that the source suite supplies; Microsoft 365 supplies it. Firmloom will state the equivalent behaviour for Google Workspace in this policy before that suite is offered, rather than assert it in advance.

In plain English: Firmloom reads mail you actually sent and received. It does not read what is still sitting in your Drafts folder — including the messages Outlook auto-saves there while you are typing. Unsent drafts are never fetched, never stored, and never searchable by anyone, including your manager or your administrator. Send the message and it is ingested like any other; leave it unsent and Firmloom never sees it.

Third-party correspondent data — please read. Because Firmloom ingests mail, calendar events, and meeting transcripts, the Corpus inevitably contains personal data of third parties who are not Firmloom users — external correspondents and meeting participants such as an organization's clients, vendors, and subcontractors. We process this data as processor on the Customer's behalf. The Customer, as controller, is responsible for having a lawful basis to connect the sources and for meeting any notice obligations to the individuals concerned.

4.3 Calendar events (Microsoft 365 only). For calendar as a Connected Source, we ingest event data from Microsoft Graph, comprising: subject, event body text, start and end times, whether the event is an online meeting and its join URL, the organizer's email address, and the attendee list (attendee email, display name, and response status). Access to a calendar event is scoped by its attendees. This category does not exist for a Google Workspace Customer — Firmloom requests no Google Calendar scope and ingests no Google calendar data.

4.4 Microsoft Teams meeting transcripts (Microsoft 365 only). For Teams meeting transcripts as a Connected Source, we ingest, for meetings organized within the Customer's tenant: the online-meeting reference resolved from the calendar join URL, transcript metadata (creation time and meeting duration), and the transcript content itself (retrieved as WebVTT text). Transcripts are speaker-attributed, and speakers are resolved to entities. Access to a transcript is scoped by the meeting's attendees. This category does not exist for a Google Workspace Customer — Firmloom requests no Google Meet scope and ingests no Google meeting recordings or transcripts.

4.5 Derived data. Data that Firmloom generates from the Corpus, including: AI-extracted decisions, commitments, and risks (each recorded with the exact source quote); an entity registry of people, companies, and projects (with aliases); a relationship graph; community summaries; 1024-dimension vector embeddings; and sensitivity classifications (for example HR, legal, personal and performance categories; and, on Microsoft 365 only, Microsoft Information Protection label categories — Firmloom reads no equivalent Google Drive label).

4.6 Authentication and session data. OIDC session cookies; MCP tokens (stored only as a SHA-256 hash with a secret pepper, never in plaintext); delegated OAuth refresh tokens (encrypted at rest with AES-256-GCM); and MCP session records.

4.7 Usage and audit data. An immutable audit log of every query — recording the actor, the tool used, the query text, the source message identifiers returned, and latency; a scope-change log; large-language-model token usage per Customer; coverage metrics; and error and trace telemetry captured through our monitoring provider.

4.8 What we do not collect. In the current Service:

• No payment card data. Firmloom does not process or store payment card details; billing is by manual invoicing.
• No marketing analytics or tracking cookies. Firmloom uses only functional session cookies (see section 13). We do not use advertising or analytics trackers.

If we later introduce analytics or other data collection, we will update this policy and increment its version before doing so.

5. Where data comes from — Connected Sources and consent

In plain English: All the content we hold comes from the Connected Sources your organization authorizes. How you connect differs by suite, and it is a real difference, not a presentational one. On Microsoft 365 an administrator can authorize the whole organization in one step, or an individual can connect only their own mailbox. On Google Workspace there is no organization-wide option: every person connects their own mailbox and can disconnect it themselves, and Firmloom holds no credential that can open a mailbox on its own. An administrator can separately connect the Google directory, which lets Firmloom see who exists and who is in which group — and connects nobody's mailbox. Your administrator controls the scope, including excluding sensitive mailboxes, and Firmloom automatically excludes content flagged as sensitive.

5.1 The Connected Sources model. Firmloom only holds data that originates from a Connected Source that a Customer has authorized. A Connected Source is any third-party platform, API, application, or data system that a Customer authorizes Firmloom to access. The current Connected Sources are the Connected Sources listed in Schedule A, with the status shown there. Each new Connected Source requires a fresh authorization from the Customer — for example, connecting a new source or expanding Microsoft Graph or Google OAuth permissions requires the Customer to consent again.

5.2 Connection modes and who consents. The legal significance of a connection mode is who consents and to what, and the answer is not the same on the two source suites.

Microsoft 365. Two modes:

• Application mode. A tenant administrator grants organization-wide Microsoft Graph consent (the Mail.Read, MailboxSettings.Read, User.Read.All, GroupMember.Read.All, and Organization.Read.All scopes). The administrator acts on behalf of the organization. An Exchange Application Access Policy, configured by the Customer in Microsoft 365, narrows Firmloom's access to a defined, in-scope group of mailboxes. That narrowing is enforced by Microsoft; Firmloom provides a check the Customer can run to confirm it has taken effect, and does not condition onboarding on it.
• Delegated mode. An individual grants consent through individual OAuth (the openid, profile, email, offline_access, Mail.Read, MailboxSettings.Read, User.Read, Calendars.Read, Contacts.Read, Sites.Read.All, and Files.Read.All scopes) and acts for themselves only. This mode requires no administrator consent and no access to the organization directory. Because the consent is delegated, every one of these scopes is bounded by what that individual's own Microsoft 365 account can already access — including Sites.Read.All and Files.Read.All, which reach only the SharePoint sites and OneDrive locations already available to that individual, and from which nothing is ingested until the individual selects a specific site or drive.

Google Workspace — delegated only, and there is no organization-wide alternative. On this suite Firmloom supports one way to reach a person's mail and documents: that person authorizes it themselves, through Google's individual OAuth consent, and can withdraw it themselves. There is no mode in which one administrator's consent opens other people's mailboxes.

• Per-user delegated connection. Each individual grants the openid, https://www.googleapis.com/auth/userinfo.email, https://www.googleapis.com/auth/userinfo.profile, https://www.googleapis.com/auth/gmail.readonly and https://www.googleapis.com/auth/drive.readonly scopes, and acts for themselves only. Every one of these is a read scope. Firmloom requests no Gmail or Drive scope that can send, reply to, modify, label, insert or delete anything, and no scope that changes a mailbox setting. As the consent is delegated, each scope is bounded by what that individual's own Google account can already open. drive.readonly returns each file's own sharing list as well as its content, and Firmloom uses that list to refuse to show a document to anyone the source does not already grant access to.
• Administrator directory connection — and what it is not. Separately, an administrator may connect the Workspace directory, granting https://www.googleapis.com/auth/admin.directory.user.readonly, https://www.googleapis.com/auth/admin.directory.group.readonly and https://www.googleapis.com/auth/admin.directory.group.member.readonly. These are read-only, are requested only on an administrator's connection and never on an ordinary user's, and let Firmloom know which mailboxes exist and resolve which people are in a group that a document was shared with. Connecting the directory connects no mailbox and grants no access to anyone's mail or files.
• No domain-wide credential. Google offers an organization-wide mechanism — a service account with domain-wide delegation — and Firmloom does not use it and holds no such key. That mechanism is a single credential that can impersonate every user in a domain, Google provides no way to restrict it to a group or organizational unit, and there is therefore no way for a Customer to verify that it has been restricted. Firmloom's per-user model is the deliberate alternative: each mailbox Firmloom can read belongs to someone who individually consented, each credential is individually revocable, and revoking one person's connection revokes nothing else. The cost is that a Google rollout requires each person to connect; Firmloom states that plainly rather than implying an administrator can complete it alone.

5.3 Administrator scope controls and exclusions. In application mode, the Customer's administrator controls the scope of ingestion. The Service excludes sensitive mailboxes and content by design — for example, mailboxes such as those beginning hr@, legal@, or payroll@ are excluded by default — and a sensitive-content exclusion engine keeps content classified as sensitive out of all query scopes, including hierarchy-based access. Customers are responsible for keeping their scope configuration and exclusions accurate.

5.4 Calendar and Teams transcript access (Microsoft 365 only). Calendar and Teams meeting transcripts are read from Microsoft Graph under the Customer's organization-wide consent. Reading Teams meeting transcripts requires the additional application permissions OnlineMeetings.Read.All and OnlineMeetingTranscript.Read.All. As with mail, a Teams application access policy configured by the Customer in Microsoft 365 narrows the transcripts Firmloom is able to read; that exclusion is enforced by Microsoft, which withholds the transcript, rather than by a separate check inside Firmloom. Firmloom provides a verification check the Customer can run to confirm the policy is in effect. Transcripts are only available for meetings organized within the Customer's tenant.

6. How we use data

In plain English: We use your data to run the Service: to ingest and index mail, to generate AI insights, to answer queries with the right permissions applied, to keep an audit trail, to secure and operate the platform, and to bill. We do not train AI models on your data, and the AI Providers we use are engaged under terms that do not permit training on our API traffic.

We use the data described above only to provide, secure, operate, and improve the Service, and to meet legal obligations. Specifically:

• Ingestion and indexing — retrieving mail from Connected Sources, parsing it, and building the searchable index (vector embeddings plus full-text search).
• AI extraction and summarization — using AI Providers to extract decisions, commitments, and risks, to classify content, and to generate summaries (see section 7).
• Retrieval and permissioning — answering queries with permission filters applied so that results never exceed the requesting user's access.
• Audit and security — recording an immutable audit trail of activity and detecting anomalies.
• Service operations — monitoring reliability and performance and diagnosing errors.
• Billing — calculating seat and mailbox usage for invoicing.

No training on your data. Firmloom does not train AI models on Customer data. The AI Providers we use are engaged under agreements that do not permit training on our API traffic; this is a contractual commitment we rely on for the AI Providers listed in Schedule A. We do not sell personal data.

6.1 Google user data — Limited Use. Firmloom's use of data obtained through Google API scopes, including Gmail and Google Drive, complies with the Limited Use requirements of the Google API Services User Data Policy. Those requirements apply not only to the raw data obtained from the scopes but, in Google's words, to "data aggregated, anonymized, or derived from them" — so everything in this section is stated of the extracted facts, embeddings, summaries and counters Firmloom derives from Gmail and Drive content, and not only of the stored messages and files.

Firmloom affirms each requirement in the terms Google states it:

• Use. Firmloom limits its "use of data to providing or improving user-facing features that are prominent in the requesting application's user interface" — the search, retrieval and extracted memory that are the entire visible product.
• Transfer. Firmloom does not transfer this data except as Google permits: "To provide or improve your appropriate access or user-facing features", and then only to the Subprocessors listed in Schedule A acting on Firmloom's instructions to deliver those features; for security purposes; to comply with applicable laws; or as part of a merger, acquisition, or sale.
• Human access. Firmloom does not "allow humans to read the data" except as Google permits — with the user's affirmative agreement to view specific messages, files or other data, for security purposes, to comply with applicable laws, or where the data is aggregated and used for internal operations. The tables holding message and document content, and the facts extracted from them, carry no read permission for Firmloom's own cross-tenant support role at all. Firmloom has identified three tables of message-derived text that do still carry such a permission, which no shipped Firmloom screen uses, and is removing it; that removal is a precondition of offering the Google Workspace suite rather than something to be completed afterwards. Any read a support operator does make is recorded in an access log.
• Advertising. Firmloom does not transfer or sell this data to advertising platforms, data brokers, or information resellers, and does not use it to serve advertising of any kind. Firmloom serves no advertising at all.
• No model training. Firmloom does not transfer, sell, or use this data to create, train, or improve a machine learning or artificial intelligence model. Firmloom trains and fine-tunes no model on Customer content; the models it uses are provided by the AI Providers in Schedule A under terms that do not permit training on Firmloom's API traffic.

This statement is about Google user data specifically because Google's policy requires it to be. Firmloom applies the same commitments to Microsoft 365 and Salesforce content — sections 6, 7 and 9 state them for all suites.

7. AI processing disclosure

In plain English: To build insights, we send some ingested content to AI Providers. The AI extraction step sees message content, attachment text and document text on either suite, and — on Microsoft 365 only — calendar event content and meeting transcripts. A Google Workspace customer's calendar and meetings are never sent anywhere, because they are never read at all. When you run a search, your query text goes to a reranking provider — but the searches themselves are answered from our own local index and are not sent to large language models. Separately, if you connect an AI assistant such as Claude or ChatGPT to Firmloom, that assistant receives results under your own agreement with that assistant's provider, not under ours.

Firmloom uses AI Providers to make the Corpus useful. The categories of processing are:

• AI extraction, classification, and summarization. Ingested content, together with extracted items presented in fenced data blocks, is sent to our AI extraction provider, in both batch and live processing, to produce Derived Data. What that content is depends on the suite. For a Microsoft 365 Customer: email subject, sender, date and body; attachment text; document text; calendar event content; and Teams meeting transcripts, which are processed with the same extraction discipline as mail. For a Google Workspace Customer: Gmail message subject, sender, date and body; attachment text; and Google Drive document text — and nothing else, because no calendar or meeting content is ingested for that suite.
• Embeddings and reranking. Chunks of text (approximately 800 tokens plus a context prefix) are sent to our embeddings provider to generate vector embeddings — chunks of mail, attachments and documents on either suite, and additionally chunks of calendar events and transcripts on Microsoft 365. At query time, the top candidate chunks and the query text are sent to the reranking provider.

Two points matter for your privacy:

1. User search queries are answered from the local index (vector search plus full-text search) and are not sent to large language models. Query text does, however, reach the reranking provider as described above.
2. Connected AI assistants operate under your own provider terms. Where a Customer connects an AI assistant (such as Claude or ChatGPT) to Firmloom through the MCP interface, that assistant receives tool results under the Customer's own agreement with that assistant's provider — not under this policy. Firmloom's MCP surface is read-only.

The current AI Providers, the data that reaches each, and their locations are set out in the Subprocessor table in Schedule A. Because AI Providers are defined as a category, adding or changing an AI Provider requires only an update to Schedule A and a version note, with notice as described in section 8.

8. Subprocessors and third parties

In plain English: We use a small set of trusted third parties to run the Service — Microsoft, our AI Providers, our hosting and database provider, and our error-monitoring provider. They are listed in Schedule A. If we add or change a Subprocessor, we update Schedule A and give notice.

Firmloom engages Subprocessors to deliver the Service. A Subprocessor is a third party that processes personal data on Firmloom's behalf. The current Subprocessors, the purpose of each, the data that reaches each, and their locations are set out in the table in Schedule A, which forms part of this policy.

Because Subprocessors and AI Providers are defined by category, with the current instances listed in Schedule A, we can add or change a Subprocessor by updating Schedule A and giving notice, without rewriting this policy. Where a DPA is in place, changes to Subprocessors follow the notice mechanics set out in that DPA. We will provide Customers with reasonable notice of a new or replacement Subprocessor before it begins processing Corpus data.

Beyond Subprocessors, Firmloom may disclose personal data:

• where required by law, regulation, legal process, or an enforceable governmental request;
• to establish, exercise, or defend legal claims;
• to protect the rights, property, or safety of Firmloom, our Customers, or others; and
• in connection with a merger, acquisition, financing, or sale of assets, subject to the recipient being bound by terms consistent with this policy.

9. International data transfers

In plain English: Firmloom is hosted in the United States today, so ingested data is stored and processed there. Your organization's data at its original source stays in your Microsoft region; the copy Firmloom ingests is in the US. Where required, we rely on recognized transfer safeguards. We are moving to Australian data residency, hosted in the Amazon Web Services Asia Pacific (Sydney) region.

The Service is currently hosted in the United States, and our hosting, database, and AI Provider Subprocessors are located in the United States (see Schedule A). Your organization's data at its source remains with your source suite in that provider's own region — your Microsoft region for a Microsoft 365 Customer, or your Google Workspace region for a Google Workspace Customer; the copy that Firmloom ingests, indexes, and stores is located in the United States.

Where personal data is transferred from the European Economic Area, the United Kingdom, or another jurisdiction with transfer-restriction rules to a country that has not received an adequacy decision, we rely on an appropriate transfer mechanism — such as the European Commission's Standard Contractual Clauses (or the UK equivalent), or another lawful safeguard — to protect that data.

We are migrating to Australian data residency in the Amazon Web Services Asia Pacific (Sydney) region — including AI model hosting via Amazon Bedrock — after which the copy that Firmloom ingests, indexes, and stores will be located in Australia. We will update Schedule A and this section, with notice, as that migration completes.

10. Security

In plain English: We protect data in transit and at rest, keep each Customer's data strictly isolated, log every access, encrypt sensitive tokens, scan attachments for malware, and harden the AI processing against manipulation. We keep a security evidence trail. We do not claim any security certification we do not hold.

Firmloom applies the following security measures:

• Encryption in transit using TLS, and encryption at rest provided by our database and object-storage providers.
• Tenant isolation enforced by mandatory tenant_id scoping on every tenant-scoped table, applied by a typed query layer and covered by the permission invariants below. Postgres row-level security is defined and forced on those tables as an independent second layer; it binds only where the deployment connects under a non-owner database role, and Firmloom does not represent that both layers are active on every deployment.
• Permission invariants that are tested in our CI pipeline: every result set is a subset of the requesting user's access; sensitive content is excluded from all scopes, including hierarchy-based access; hierarchy access is strictly downward; and every MCP call is audit-logged before results are returned.
• AES-256-GCM encryption of delegated OAuth refresh tokens, and hashed MCP tokens (never stored in plaintext).
• Attachment malware scanning with ClamAV, where the deployment provides a loaded ClamAV signature database. Where it does not, the pipeline does not record a clean verdict it has no basis for: the attachment is stored marked as not scanned, with the reason, and the degradation is logged. Firmloom does not represent that every attachment has been scanned.
• Prompt-injection hardening, including fenced data blocks, static system prompts, and a read-only MCP surface.
• Rate limiting and anomaly detection.
• Secrets management through an environment secrets manager; secrets are never stored in the code repository.
• A security evidence trail maintained from day one. For the avoidance of doubt, Firmloom does not claim any third-party security certification (such as SOC 2) that it has not obtained.

No method of transmission or storage is completely secure, and we cannot guarantee absolute security; however, we work to protect personal data using the measures above.

11. Retention and deletion

In plain English: Firmloom's memory is independent of your mail client, but it is not independent of the source item. Delete a message where it lives and, once that deletion reaches us, we delete our copy — and when it was the last copy, the facts we extracted from it go too. Beyond that, you control retention: there is an ingestion window that bounds how much history we ever hold, an auto-purge that is off unless you turn it on, and a legal hold that stops all of it. An administrator can erase specific messages, conversations, or a person's data on request. When a Customer leaves, we purge everything within a 72-hour target and issue a signed purge certificate. Database backups are the one place a deletion is not instant — see 11.6.

11.1 What happens when an item is deleted at its source. Firmloom follows the change feed of each connected mailbox and drive. When that feed reports an item as removed — a deletion, or a move into a deleted-items or junk folder — Firmloom removes that mailbox's copy of it. When the copy removed was the last one the Customer held, Firmloom erases the item itself and the data derived from it: its indexed text chunks, the AI-extracted decisions, commitments and risks that cite it, the signals and commercial events computed from it, any proposed action or task brief quoting it, and its stored raw content and attachment blobs. Derived caches that could still quote it are invalidated, and community summaries are stripped of it. A legal hold suspends all of this and nothing is removed while one is in effect.

Firmloom also runs a reconciliation pass: where a full re-enumeration of a mailbox no longer returns an in-window message Firmloom holds, that message is treated as gone at source and removed on the same terms.

What survives, stated plainly. Firmloom's memory does not depend on the mail client, and it is not erased by a person leaving, a thread being archived, or a mailbox going out of scope. Records that exist in their own right — the registry of people, companies and projects, and relationship records that still rest on surviving evidence — are not deleted merely because one message mentioning them was. A relationship record whose only evidence was the erased message is deleted with it, and a mention count is reduced.

11.2 Ingestion window and purge controls. The ingestion window bounds how far back Firmloom ever reads and holds mail. The default is 12 months, with 24 months available; the window that applies to a Customer is the one recorded for that Customer and stated in its Order Form, and it is configurable. Content older than the window is not ingested in the first place.

Separately, an optional rolling-window auto-purge continuously erases content that has since aged past the window. It is off by default, and while it is off, content that was in-window when ingested is retained even after it ages past the window, until it is erased by one of the other mechanisms in this section. When it is on, a nightly job erases the aged-out content on the same cascade described in 11.1, and each night's erasure is audit-logged with the cutoff it applied. A per-tenant legal hold blocks purges while it is in effect.

11.2a Retroactive folder exclusions. Where an administrator adds a folder to the exclusion list after its mail has already been ingested, Firmloom does not merely stop reading it: an hourly sweep removes the copies already held from that folder, on the same cascade as 11.1.

11.3 Targeted erasure. An administrator tool supports targeted erasure by message, by conversation, or by participant email address. Erasure cascades to the associated chunks, flagged items, and stored blobs; entity mentions are anonymized; and the erasure is audit-logged. This mechanism supports right-to-erasure requests.

11.4 Tenant offboarding and the purge certificate. On offboarding, Firmloom performs a full purge of the Customer's stored rows and blobs within a 72-hour target and provides a signed, downloadable purge certificate confirming the deletion.

11.5 Retention of controller data. Data for which Firmloom is the controller — account, billing, and audit/telemetry data — is retained for as long as needed to operate the Service and to meet legal, accounting, and security obligations, and is then deleted or de-identified.

11.6 Backups — the one place deletion is not immediate. Firmloom's managed database provider maintains point-in-time recovery history, so for a period after any deletion the data remains recoverable from that history. Firmloom does not restore that history in the ordinary course; it exists for disaster recovery. Firmloom's documented procedure is that where a restore would reinstate data covered by an erasure request or an offboarding purge, the erasure or purge is re-applied to the restored database before the Service is served from it. Firmloom states this rather than let a purge certificate imply that no recoverable copy exists anywhere: the certificate attests to the live database and the object storage it enumerates.

12. Your rights

In plain English: Depending on where you are, you have rights to access, correct, delete, or object to the use of your personal data. Because most of the content we hold belongs to an organization Customer, if your data appears in a Customer's Corpus we will direct you to that Customer, who controls it — and we help them respond. Solo-tier users deal with us directly. You can also complain to a data protection regulator.

Depending on your location and applicable law, you may have rights to access, correct, update, delete, or receive a copy of your personal data; to object to or restrict certain processing; and to withdraw consent.

• GDPR / UK GDPR. If you are in the EEA or the UK, you have the rights of access, rectification, erasure, restriction, objection, and data portability, and the right to lodge a complaint with a supervisory authority.
• Australian Privacy Act (APPs). If you are in Australia, you may request access to, and correction of, your personal information, and may complain to the Office of the Australian Information Commissioner (OAIC).
• California (CCPA/CPRA). For California business Customers, Firmloom generally acts as a service provider, processing personal information on the Customer's behalf and not selling or sharing it. California residents may have rights to know, delete, and correct, and the right not to be discriminated against for exercising those rights; requests concerning data in a Customer's Corpus are routed to that Customer as described below.

Routing of requests (the B2B reality). For organization Customers, the Customer is the controller of the Corpus. If you are an individual whose data appears in a Customer's Corpus — including as an external correspondent — we will generally direct your request to that Customer, and we will assist the Customer as processor in responding. Solo/delegated-tier users deal with Firmloom directly, as we are the controller in that tier.

To exercise a right or ask a question, contact us at admin@creatoralliancegroup.com. We may need to verify your identity before acting. If you are not satisfied with our response, you may escalate to your data protection regulator — the OAIC in Australia, or your local supervisory authority in the EEA or UK.

13. Cookies

In plain English: Firmloom uses only the functional session cookies needed to keep you logged in. We do not use advertising or analytics tracking cookies today. If that changes, we will update this policy first.

The Service uses only functional session cookies necessary to authenticate users and maintain a logged-in session. Firmloom does not use advertising or analytics tracking cookies. If we introduce analytics or other non-essential cookies in the future, we will update this policy and increment its version before doing so, and will provide any consent mechanism required by applicable law.

14. Employee-visibility transparency

In plain English: Firmloom can be configured so that managers see information from the mailboxes of people who report to them (a downward-only hierarchy). Before this is switched on, your administrator must confirm that employees were informed — the system enforces this. Sensitive categories are excluded from these views by design. The duty to tell employees sits with the Customer.

The Service can be configured to allow hierarchy-based access, under which a manager may access information derived from the mailboxes of individuals who report to them. This access is strictly downward through the organization tree.

Before manager-chain (hierarchy) access is enabled, the Customer's administrator must confirm that the affected employees were informed; this confirmation is enforced by the Service. Sensitive categories of content are excluded from these views by design. This exclusion applies across all Connected Sources: a meeting transcript classified as sensitive — for example a one-to-one meeting flagged as HR or performance — is excluded from every retrieval scope by the same mechanism as sensitive mail. The obligation to inform employees, and to have a lawful basis for this visibility, rests with the Customer as controller. This obligation is also reflected in the Firmloom Terms of Use.

15. Children

In plain English: Firmloom is a business service and is not directed at children.

The Service is a B2B service intended for use by organizations and their Authorized Users. It is not directed at children, and we do not knowingly collect personal data directly from children. Where children's personal data appears within a Customer's Corpus as correspondence content, it is processed as part of the Corpus on the Customer's behalf and is subject to the same controls as other Corpus data.

16. Changes to this policy

In plain English: We may update this policy. For material changes we will give notice and increase the version number; some changes require you to accept the new version before continuing. Minor updates — such as adding a Subprocessor to Schedule A — are made by updating the schedule and giving notice.

We may update this policy from time to time. The version is identified by the Version: string at the top of this document, in YYYY-MM-DD format.

• Material changes are accompanied by notice and a version increase. Where a material change affects the terms governing your use of the Service, continued use and, where applicable, a renewed acceptance may be required, consistent with the versioned-acceptance mechanism used at signup.
• Schedule-only updates — such as adding a new Connected Source, AI Provider, or Subprocessor to Schedule A — are made by updating the schedule and giving notice in accordance with the notice mechanics of any applicable DPA, without a full re-draft.

The change log at the end of this document records the version history.

17. Contact and registered address

In plain English: Here is how to reach us about privacy.

For any question, request, or complaint concerning this policy or your personal data, contact:

• Privacy contact: admin@creatoralliancegroup.com
• Legal contact: admin@creatoralliancegroup.com
• Entity: Creator Alliance Group Pty Ltd (company number ABN 41 689 817 070), trading as Firmloom
• Registered address: Suite 302, 13/15 Wentworth Avenue, Sydney NSW 2000, Australia

This policy is governed by the law of New South Wales, Australia.

Schedule A — Connected Sources and Subprocessors

In plain English: This schedule lists the platforms we connect to and the third parties that help us run the Service. We keep it up to date and give notice when it changes, so we can add new sources, integrations, or AI providers without rewriting the whole policy.

This Schedule A forms part of the Privacy Policy. It is maintained as the current list of Connected Sources, AI Providers, and Subprocessors, and is updated with notice as described in section 8 and section 16.

A.1 Connected Sources

Each new Connected Source requires fresh authorization from the Customer before Firmloom may access it.

On the three Google rows. They are listed as not yet available because that is the truth: no Customer can connect Google Workspace to Firmloom today, and Firmloom's application has not completed Google's OAuth verification. They are disclosed now, in the operative policy, so that the processing Firmloom would carry out on that suite is stated before it happens rather than after — and so that a Google Workspace customer can read what Firmloom would and would not read before deciding anything. When the suite becomes available these rows move to Current with a change-log entry. No Google Calendar, Google Contacts, or Google Meet source appears in this table, and none is planned in this phase.

A.1a Derived data classes

A.2 Subprocessors and AI Providers

Planned or possible additions (disclosed here as "may include", to be added to this table with notice if adopted): Amazon Web Services — further use beyond the blob storage listed above, namely hosting and AI model hosting via Amazon Bedrock in the Asia Pacific (Sydney) region, as part of our migration to Australian data residency (section 9); and a payment processor (for example Stripe) if and when billing is automated.

Change log

The summary boxes marked "In plain English" are provided as aids to understanding and are not the operative terms; the numbered sections and Schedule A are the operative Privacy Policy.