Privacy Policy

1. Account data we collect

Creating an account requires an email address and a password. We store:

• Email address — used to sign in and, if your workspace enables alert email, as the default notification address.
• Password — never in plaintext. We store a scrypt hash of your password (Node's own built-in, memory-hard key-derivation function) plus a random per-account salt. We cannot look up or recover your actual password from what's stored; a login attempt is compared by re-hashing and checking against the stored hash.
• Organization membership and role — which team workspace you belong to, and whether you're its owner or a member.
• Account creation timestamp.

2. Session and cookies

Signing in sets exactly one cookie, named session. It's a random 32-byte opaque token — not a signed JWT, so it carries no personal data by itself, only a lookup key — marked httpOnly (invisible to page JavaScript), SameSite=Lax, and Secure in production. It expires after 30 days, or immediately if you sign out (the matching session row is deleted server-side, which revokes it instantly rather than waiting for expiry).

No consent banner, because there's nothing to consent to yet. We checked directly: there is no Google Analytics, Plausible, PostHog, Mixpanel, advertising pixel, or any other third-party tracking or analytics script anywhere in this codebase. The session cookie is strictly necessary for the product to function (you can't stay signed in without it) and strictly-necessary cookies don't require a consent banner under GDPR/ePrivacy or similar frameworks. If that ever changes — the day a real third-party analytics or advertising script is added — a consent banner needs to be added before that script ships, not after.

3. What your workspace stores about your own usage

This data is shared with everyone else in your organization — OpenBrief is built around team workspaces, not solo silos — but not with anyone outside it, and not with us beyond what's needed to operate the service.

• Watchlist entries — the companies, people, domains, or keywords you choose to track. Treat this as sensitive. Your watchlist is a direct record of your own business intelligence targets: competitors you're watching, prospects you're vetting, vendors you're monitoring, or threats you're tracking. We store it because the product can't function without it, and we never share it outside your organization or sell it.
• Notes — free-text analyst notes attached to a tracked target or theme.
• Brief snapshots — every generated intelligence brief, saved so your team can see how a subject's picture has changed over time, not just its current state.
• Case Files — named bundles of tracked targets assembled into one combined deliverable.
• Key Judgments and their resolutions — generated analytic judgments, and whether a person on your team later marked one correct or incorrect (Track Record calibration).
• Indicators & Warning board entries — the standing indicator scorecard for a tracked subject and its status over time.
• RFIs (Requests for Information) — formal questions your team raises against a subject, and their answers.
• Alert delivery log and contract-opportunity matches — a record of alert emails your workspace's background monitoring attempted (sent or not, and why), and any federal contract-award matches found against your tracked targets.
• Workspace settings — your notification email(s), digest cadence, cover-memo name fields, and, only if you personally add them, your own API credentials for optional sources (ACLED, ReliefWeb, OpenCorporates, Reddit, X). Those credentials are stored server-side and are never sent back to any browser, including your own — the Settings page only ever shows whether one is configured, plus a masked partial value.

4. Public third-party data we pull in

OpenBrief's whole job is monitoring the public record about subjects you track — this data is about the world, not about you, fetched server-side and cached temporarily (5 minutes to 24 hours, depending on the source) so the same query isn't re-fetched on every page load. As of this writing, the real sources are:

• USAspending.gov (federal contract awards) and the Federal Register (regulatory notices)
• OFAC's Specially Designated Nationals sanctions list
• GDELT — both its global news article index and its geolocated Event Database
• News RSS feeds: BBC, NPR, Al Jazeera, DW, France24, The Guardian, and The New York Times, plus Google News search
• SEC EDGAR corporate filings and CourtListener federal court filings/dockets
• USGS earthquake data and NASA's EONET natural-events feed
• CISA's Known Exploited Vulnerabilities catalog
• Mastodon public hashtag timelines, Bluesky public post search, curated Telegram channel previews, and Hacker News
• Anthropic-mediated social discovery — Anthropic's own server-side web-search tool, scoped to Reddit, X, Instagram, TikTok, Bluesky, YouTube, and Threads. OpenBrief itself never contacts those platforms directly for this feature; Anthropic runs the search and returns real, cited results.
• Domain/WHOIS lookups and prediction-market odds (Polymarket)
• Optional, key-gated layers that only activate if you (or your organization) supply your own credentials: ACLED conflict/protest data, ReliefWeb humanitarian data, OpenCorporates ownership records, Reddit keyword search, and X's official recent-search API

5. What we send to third parties, and why

This is the material part: two real, outbound data flows exist today.

• Anthropic (api.anthropic.com). When the product writes an analytic assessment — a Situation Assessment, a Key Judgment, a portfolio brief — or runs social-media discovery search, it sends the name of your tracked subject and the public material already collected about it to Anthropic's API so the model can generate the written analysis or run the constrained search. This is the one deliberate exception to how the rest of the product works: every other feature in OpenBrief is direct collection and computation, no model call, nothing leaves the server. The Anthropic API key used is either the product operator's own, or one your organization configures itself in Settings.
• Resend (api.resend.com). If your workspace has alert email configured, the recipient address(es) you set and the alert's content (which topics are tracked, what changed) are sent to Resend to actually deliver that email.
• Optional source APIs. Only if you personally add your own ACLED, ReliefWeb, OpenCorporates, Reddit, or X credentials in Settings — in that case, your tracked target values are sent to that specific service as a search query, using your own key, under that service's own terms.

We don't sell your data. No advertising network, analytics vendor, or data broker receives any of it — there is no such integration anywhere in this codebase.

6. Data retention

• Session tokens: 30 days from sign-in, or immediately on sign-out.
• Cached public-source data: 5 minutes to 24 hours per source, purely a technical cache, not a profile of you.
• Workspace content (watchlist, notes, briefs, judgments, indicators, RFIs, Case Files): retained for as long as your organization's account is active.
• After account deletion: see Section 7 — your login is disabled immediately; workspace data your organization solely owns is retained for 30 days before removal, in case a deletion was accidental or made under duress.

7. Export or delete your data

Both are real, working features on the Settings page, not a request you have to email in for:

• Export my data downloads a JSON file containing every row your organization owns — watchlist entries, notes, brief snapshots, Case Files, judgments, indicators, RFIs, alert history, contract-opportunity matches, Watch Condition history, and workspace settings.
• Delete my account immediately signs you out of every session and disables your login (your email and password stop working — nobody, including you with the old credentials, can sign back in as you). If you're the sole member of your organization, your workspace's data is marked for deletion and kept for 30 days — in case the deletion was a mistake or made under duress — before a cleanup pass removes it. If you share your organization with teammates, you're removed from it and your login is disabled the same way, but the shared workspace data stays intact for the teammates who remain, since it belongs to the team, not to any one member who leaves.

You can also reach us directly at hello@openbrief.io for a manual export in another format, or to request full deletion of a sole-member organization's data before the 30-day window closes.

8. Security

Passwords are scrypt-hashed with a random per-account salt, never stored or logged in plaintext. Session cookies are httpOnly and, in production, Secure (HTTPS-only). Optional third-party API credentials you add are stored server-side and never returned to a browser in full — only a masked partial value and a configured/not-configured status. No system is perfectly secure, and we can't guarantee against every possible breach, but we don't treat that as a reason not to do the basics correctly.

9. Children's privacy

OpenBrief isn't directed at, or knowingly used by, anyone under 18. If you believe a minor has created an account, contact us and we'll remove it.

10. International use

OpenBrief is operated from, and its data is processed in, the United States. If you access it from elsewhere, you're transferring your data to and having it processed in the US.

11. Why we process your data

We process your account and workspace data — email, organization membership, watchlist entries, notes, and everything else described above — because it's necessary to provide the product you signed up for: without it, we can't authenticate you, show you your own tracked targets, or generate the briefs and alerts you're using this for. That's the plain, factual basis for our processing, not a claim about which specific article of any particular privacy law it satisfies. We are not a law firm, and this page has not yet had a full attorney review for GDPR/CCPA/CPRA sufficiency (lawful-basis wording, an EU representative if one is needed, data-transfer mechanisms for any EU users) — see the reviewed-by banner at the top of this page. If you're an EU, UK, or California resident with questions about your specific rights, contact us (Section 13) and we'll do our best to help while that formal review is pending.

12. Changes to this policy

We'll update this page as the product's real data handling changes — most recently, to keep it accurate to what the code actually does — and update the "Last updated" date above when we do.

13. Contact

Questions about this policy, or a data request outside the Settings page: hello@openbrief.io.