Blossom Security Overview

Version 0.1 — Last updated July 22, 2026

This page describes the current security approach of Polymath HQ, Inc. d/b/a Blossom. It is a plain-language overview, not a certification, audit report, warranty, or expansion of Blossom’s contractual obligations.

1. Our security approach

In short: Blossom uses layered safeguards based on the data, access, and actions involved in each workflow.

Blossom is built to connect to business systems, analyze customer information, and carry out customer-configured tasks. Our security program therefore focuses on limiting access, protecting credentials, separating organizations, recording agent activity, controlling high-impact actions, reviewing vendors, and deleting data on stated timelines.

No system is perfectly secure. We review and improve safeguards as the product, threats, and legal requirements change.

2. Data use and AI

In short: Customer data is used to provide the customer’s service—not to train outside AI models—unless the customer expressly opts into a disclosed AI-model exception for its own account.

Blossom does not use Customer Data to train, develop, or improve AI models made available outside the Customer’s account. AI providers are contractually restricted from using Customer Data to train, develop, or improve their models and are subject to retention restrictions appropriate to the service.

For a high-risk or new model that cannot meet those terms, Blossom requires prior, affirmative, account-specific consent before any Customer Data is sent. The consent identifies the provider, data, purpose, and applicable terms and may be revoked for future use at any time. Refusing or revoking consent may disable that optional model feature without affecting unrelated Services.

3. Access scope and tenant controls

In short: Users authenticate through WorkOS, and organization and team roles limit who can reach data and features.

Blossom uses WorkOS for authentication, identity, sessions, and organization membership. Application controls distinguish organizations, teams, users, and roles such as owner, administrator, and member. Access checks are designed to limit a user to authorized tenant data and functions.

Blossom personnel access to production data is limited according to role and operational need and is subject to confidentiality obligations. Customer administrators control authorized users, roles, integrations, agent instructions, and available approval settings.

4. Encryption and storage

In short: Data is protected in transit with TLS; stored secrets receive additional encryption and restricted key access.

Data transmitted between supported clients and Blossom services is encrypted in transit using TLS. Hosting, database, and file-storage providers supply encryption for stored service data. Secrets stored in Blossom’s vault are encrypted using AES-256-GCM, with access to encryption keys restricted to authorized application paths and personnel.

Because encryption coverage depends on the specific system and data path, this statement does not mean every piece of data is encrypted with the same algorithm or under a single Blossom-managed key.

5. Credentials and connected services

In short: Blossom prefers scoped OAuth access and uses encrypted or managed token storage for credentials it needs to operate connections.

Blossom uses OAuth or delegated access where supported and appropriate and encourages least-privilege scopes. Some connection credentials are stored in Blossom’s encrypted vault. For long-tail integrations, token-holding providers such as Composio or Pipedream may store tokens on Blossom’s behalf. Those vendors appear on the Subprocessor List.

Customers choose and authorize the services they connect and can revoke access through the provider or available Blossom controls. Customers should promptly revoke or rotate credentials after personnel changes, suspected compromise, or the end of a workflow.

6. Agent guardrails and records

In short: Customer configuration and connection controls limit agent scope, and Scout records external calls for auditability.

Agents operate using customer-configured instructions, permissions, recipients, and available approval settings. Scout records external API calls in its audit log. Logging for other agent actions varies by workflow and may depend on information returned by a connected provider; no log can record conduct outside Blossom’s execution path.

Customers can change available configuration and revoke a connection through the provider or supported Blossom controls. Higher-risk workflows should use human approval and review. Blossom’s terms require customers to keep supported disclosure, quiet-hours, suppression, and opt-out controls correctly configured; customers remain responsible for lawful configuration and consent records.

7. Payment-data boundaries

In short: Full card details belong in approved payment flows, not AI prompts, chats, recordings, or transcripts.

Blossom’s terms prohibit customers from placing full payment-card numbers or security codes into general Customer Data or the AI pipeline. Supported payment collection should use a processor-hosted flow or approved DTMF capture so sensitive card details are handled by the payment provider rather than an agent conversation.

8. Data minimization and retention

In short: Workspace data follows the account; raw Scout artifacts expire after 90 days; legal records may last longer.

Workspace data is kept while an account is active and deleted within 30 days after account deletion. Raw Scout audit artifacts, including imported batches, recordings, and transcripts, are automatically purged no later than 90 days after collection, and a user may trigger earlier purge at the end of onboarding. Billing and tax records are retained as long as law requires. Marketing leads and submitted questions are retained until the person requests deletion.

Backup copies may remain for a limited ordinary backup cycle with restricted access and no ordinary use until deletion or overwrite.

9. Vendor risk

In short: Blossom uses vendors to operate the service and applies contractual data-protection terms based on their role.

Blossom reviews vendors based on the data and service involved and requires written confidentiality, security, privacy, and deletion terms where appropriate. AI providers receive specific no-training and retention restrictions. The public Subprocessor List identifies active vendors, purposes, location-verification status, and the change-notice process.

Customer-Connected Services are chosen and contracted for by the customer. Blossom evaluates the security of its own connection path but does not control those third-party services or their independent practices.

10. Incident response

In short: Blossom investigates, contains, remediates, and notifies affected customers when a confirmed incident requires it.

Blossom maintains practices for receiving security alerts, investigating suspected incidents, containing affected access, preserving relevant information, remediating the cause, and restoring service. If Blossom confirms a personal-data breach affecting Customer Personal Data, it will notify affected customers without undue delay and provide available information reasonably needed for their response, as described in the DPA.

Customers should report suspected account compromise or security incidents promptly to legal@blossom.fm.

11. Responsible security research

In short: Good-faith researchers can report issues under Blossom’s safe-harbor disclosure policy.

The Responsible Disclosure Policy explains authorized research, prohibited testing, reporting details, safe harbor, and coordinated disclosure. Blossom does not currently promise a monetary bounty.

12. Changes and contact

In short: Material updates receive 30 days’ notice when practical; security questions go to legal@blossom.fm.

We will give at least 30 days’ advance notice of a material reduction to the public safeguards described here during a paid Service term, unless a faster change is required by law or an urgent security need. For questions or security reports, contact legal@blossom.fm, Attention: Noah Lenz.

13. Current assurance status

In short: Blossom does not claim a security certification today.

Blossom does not currently claim SOC 2, ISO 27001, or another security certification. Blossom is actively building toward third-party attestation.

Changelog

In short: This is the first working-draft version.

Status: Blossom is actively building toward third-party attestation.