Beacon is materially stronger than its initial hackathon baseline, but this page is intentionally direct about the difference between implemented controls and a finished compliance program.
Authenticated briefs, memory, and logs are scoped by Clerk user ID in the web app so one signed-in account does not see another account's data.
Public trial usage is separated by session cookie and IP-based allowance instead of a single global shared state.
User-supplied Groq and SerpAPI keys can be stored through an authenticated route and are encrypted before being written to Redis.
External MCP clients can authenticate with a dedicated token instead of relying on browser cookies.
Current implementation defines 30-day TTLs for memory and brief records and a 90-day TTL for saved provider keys. That is better than indefinite retention, even though it is not yet a full retention-control suite.
Authenticated users can review memory, briefs, logs, and stored-key status through product surfaces, which supports basic access and deletion workflows.
The key-management API never returns raw saved credentials to the browser after storage; the UI only receives masked status.
Beacon still does not ship a formal security whitepaper, penetration test report, SOC package, or enterprise DPA workflow.
Slack or similar chat-bot channels still need stronger user identity binding if they should inherit the same privacy guarantees as the signed-in web app.
Operational logs are retained as a rolling capped list rather than a formal retention schedule with documented deletion, minimization, and legal-hold controls.
Privacy requests, incident handling, and transfer assessments still depend on product/operator process rather than a fully built in-app governance workflow.
Core secrets:
GROQ_API_KEY
SERPAPI_API_KEY
UPSTASH_REDIS_REST_URL
UPSTASH_REDIS_REST_TOKEN
CLERK_SECRET_KEY
Optional auth tokens:
BEACON_MCP_TOKEN
BEACON_PASSWORD
BEACON_SESSION_TOKEN