Practical protection, without the theater.

1. Our security principles

• Approval before action. Bloom is designed to let you review supported applications before they are transmitted.
• Least privilege. Accounts, services, and database operations should receive only the access needed for their role.
• Tenant separation. User-owned records are scoped by user and protected by server-side authorization and database row-level rules.
• Fail visibly. If Bloom cannot safely finish or verify an action, it should stop or report an unconfirmed state instead of silently claiming success.
• Defense in depth. Identity, database, storage, network, application, and operational controls reinforce one another.
• Data minimization. We aim to request, expose, and retain only what is needed for the Service and legitimate operational obligations.

2. Accounts and access controls

Bloom uses managed authentication, verified email flows, and additional anti-abuse checks on public authentication and sensitive account actions. Rate limits help reduce automated abuse. Sensitive server operations require authenticated context and do not rely on a user-supplied account identifier alone.

Administrative credentials and provider secrets are kept out of browser-delivered code. Production configuration is separated from source control and access is intended to be limited to people and services with an operational need. Security-relevant actions are designed to produce auditable state without placing secrets in logs.

3. Data and privacy safeguards

Connections to Bloom’s production websites and APIs use HTTPS. Private resumes, profile images, tailored documents, and other user files are stored in access-controlled buckets rather than public directories. Database row-level security and server-side checks separate user records.

Bloom’s deletion workflow is designed to coordinate records, stored files, authentication, billing, and mailbox resources. Durable barriers prevent ordinary account changes while deletion is underway, and reconciliation records are used when an external provider action needs verification rather than being assumed complete.

Retention and deletion practices are described in the Privacy Policy.

4. Application and billing safety

Application boundaries

Bloom distinguishes preparation, approval, submission, and confirmation. Supported submission flows use bounded retries and deduplication controls intended to reduce duplicate sends. An application that cannot be safely completed or confirmed is not supposed to be marked as successfully submitted.

Truthful materials

Generation is constrained to information in your profile and instructions, but AI output can still be wrong. Your review is an important safety control. Never approve content that is inaccurate, misleading, or not yours to use.

Payment operations

Payment-card details are handled by our payment processor rather than stored directly by Bloom. Billing webhooks are verified, and sensitive refund and cancellation flows use authentication, rate limits, idempotency, and durable provider bindings intended to prevent duplicate or mismatched operations.

5. File, request, and network safety

Supported resume uploads are restricted by type and size and pass through a malware-scanning boundary before processing. File access uses private storage and time-limited or authenticated retrieval paths where supported.

Outbound requests to job and provider systems use destination validation, redirect limits, timeouts, response-size limits, and network restrictions designed to reduce server-side request forgery and resource-exhaustion risk. Browser and worker tasks use bounded concurrency, lease or claim controls, and explicit failure states.

6. Operations, monitoring, and providers

Bloom relies on specialized providers for infrastructure, authentication, storage, payments, email and mailbox delivery, job-system integrations, malware scanning, and AI processing. We evaluate integrations for the data and access they require and use provider-side security features where available. Providers remain responsible for their own systems.

We use health checks, structured failure states, operational logging, dependency checks, and deployment gates to detect problems. Security updates are reviewed and tested before release. We maintain recovery and reconciliation paths for operations that cross external systems, where a network failure can otherwise leave the outcome uncertain.

We do not claim compliance certifications or independent attestations that Bloom has not obtained. If a certification becomes current, we will identify its scope and status precisely.

7. How you can help protect your account

• Use a unique, strong password and protect access to your email account.
• Review sign-in and verification messages and never share a one-time code.
• Confirm the job, employer, recipient, attachments, and every answer before approving an application.
• Treat unexpected requests for money, credentials, identity documents, or off-platform communication as suspicious.
• Sign out on shared devices and contact us promptly if you suspect unauthorized activity.

8. Report a security concern

If you believe you found a vulnerability or account-security issue, email hello@bloomcareers.ai with “Security report” in the subject. Include the affected URL or feature, the date observed, reproducible steps, and potential impact. Please do not include passwords, private keys, full resumes, payment-card data, or another person’s personal information in the initial email.

Act in good faith: do not access, change, retain, or destroy another person’s data; disrupt the Service; use social engineering; demand payment; or publicly disclose an issue before we have had a reasonable opportunity to investigate and remediate it. This contact channel does not create a bug-bounty program or promise payment.

For an active account takeover or immediate safety concern, say so in the subject line. We will review credible reports and respond based on severity and available information.