Effective May 4, 2026. This policy is written for the current Beacon build and is intended to cover the practical privacy, AI-governance, and data-handling issues this product raises. It is stronger than the previous placeholder, but it is still not a substitute for jurisdiction-specific legal review or a negotiated enterprise DPA.
This policy covers Beacon's web app, trial flow, API routes, durable workflow runs, memory features, and connected chat-bot intake channels where enabled. It applies to personal data contained in account records, submitted prompts, research topics, generated reports, URLs, snippets, logs, and user-provided API credentials.
Beacon is currently a product-operated service, not a no-data relay. That means the service operator and its infrastructure providers process submitted content in order to run research, store memory, enforce limits, and return reports. If you submit data about other people, you are responsible for having a valid legal basis and authority to do so.
This page does not claim that Beacon is already fully certified, fully audited, or fully compliant with every jurisdiction's requirements. It states the current processing model and the controls the product is intended to follow so those controls can be tested and improved.
For signed-in web usage, Beacon processes account identifiers supplied by Clerk, such as user ID and basic session context, in order to authenticate the user and separate one account's briefs, memory, logs, and saved keys from another's.
Beacon processes the topic, objective, focus areas, framework selection, recurrence settings, source channel, and any other content submitted in a brief. That content may itself contain personal data if the user includes it.
Beacon stores report content, summary text, source URLs, snippets, query plans, run status, delta URLs, extracted key facts, and memory history so the next run can reuse prior state instead of starting from zero.
The public trial flow uses a session cookie and IP-based allowance checks to limit abuse and separate trial activity. This means Beacon may process trial session identifiers, basic request metadata, and coarse network identifiers for rate-limiting and service protection.
Beacon records workflow, memory, system, and provider-related log events so the operator can diagnose failures, confirm runs completed, and investigate abuse or instability. Logs may include timestamps, run IDs, user scope, category labels, and error messages.
If you configure your own Groq or SerpAPI credentials, Beacon stores them server-side in encrypted form tied to your account. They are used only to execute your research runs and are not intentionally returned in plaintext through the product UI.
If Slack or similar adapters are enabled, Beacon may process channel, thread, and message metadata necessary to receive a prompt and post status updates. Those integrations currently require additional identity and governance hardening before they should be treated as equivalent to the signed-in web app for confidential workloads.
Beacon uses submitted data to authenticate users, accept briefs, search the web, synthesize reports, show sources, and persist memory. For most user-facing activity, the most likely legal basis is performance of a contract or pre-contract product use initiated by the user.
Beacon uses logs, rate-limit data, and run metadata to keep the service available, prevent abuse, debug failures, and improve reliability. The likely legal basis for this processing is legitimate interests in operating a secure research system.
If a user chooses to save personal provider keys or connect an external channel, Beacon processes that information to honor the user's configuration. Depending on implementation and jurisdiction, the likely basis is consent, contract necessity, or both.
Beacon is not intended to sell personal data or build advertising profiles from research activity. Its processing is supposed to remain tied to research execution, persistence, security, and support.
Beacon uses LLMs from Groq for planning and writing and uses SerpAPI for retrieval. Outputs are generated from retrieved web results plus model reasoning. They can be incomplete, stale, biased, or wrong, and they should not be treated as a sole basis for legal, medical, financial, employment, safety, or other high-stakes decisions.
Beacon is intended as an assistive research tool. It is not meant to make binding decisions about a person's rights, eligibility, employment, health, credit, or legal position without meaningful human review. Users remain responsible for review, verification, and downstream use.
Do not submit special-category personal data, health data, biometric data, government identifiers, trade secrets, or confidential third-party material unless you have a clear legal basis, an internal approval path, and a deployment setup that is explicitly approved for that class of data.
Beacon is designed to keep source URLs and memory history so findings can be reviewed rather than accepted blindly. That supports provenance and contestability, but it does not eliminate model error. Human review and source checking remain required.
Topic memory in Upstash currently has a 30-day TTL. That means saved memory is intended to expire about 30 days after it is written unless a later run refreshes it.
Persisted brief records currently have a 30-day TTL. They are intended to remain available for account history and rerun context during that window.
User-supplied Groq and SerpAPI keys currently have a 90-day TTL in storage unless the user deletes them sooner.
Operational logs are currently retained as a rolling capped list rather than a clean legal retention schedule. In practice, recent entries are preserved until overwritten by newer ones. This area should be tightened if the product is moved into a more formal compliance posture.
Trial allowance state is tied to a trial session identifier and IP-based limit window. Users should treat the trial surface as lower-assurance than an authenticated private account.
If GDPR, UK GDPR, or similar rules apply, users may have rights to request access to their personal data, correction of inaccurate data, deletion, restriction, objection, and export of the data associated with their use of Beacon, subject to legal exceptions.
At a minimum, the product should allow users to delete saved API keys, remove memory entries, and close their account-facing access paths. For broader privacy requests, contact the service operator through the support flow so the relevant account, memory, brief, and log records can be reviewed.
Where processing depends on consent, users should be able to withdraw that consent by disconnecting the optional feature or requesting deletion of the related stored data. Withdrawal does not retroactively invalidate prior lawful processing.
Users covered by GDPR or similar frameworks may also have the right to complain to their local supervisory authority if they believe their data has been processed unlawfully.
Beacon currently separates authenticated web data by Clerk user ID, encrypts saved user API keys before storing them in Redis, rate-limits trial and API activity, and keeps memory, brief, and log stores namespaced by user scope.
Beacon does not yet represent a complete enterprise privacy or AI-governance program. The operator should still validate vendor DPAs, transfer terms, security headers, log governance, incident response, deletion workflows, and non-web identity controls before representing the service as fully compliance-ready.
This page is intended to close the major disclosure gap that would otherwise make the app look legally under-specified. It should help Beacon present a more credible baseline for GDPR-style transparency, AI governance, and responsible-use review, but it should not be used as a final claim of legal sufficiency without counsel review.