Security overview

Audience: a customer's IT or security reviewer.

Purpose: how Beacon protects your company's data, and the questions an IT team asks before approving it. Document upload has its own treatment in sections 1 and 2, because it is the step most teams review first. Everything from section 3 onward describes the platform as a whole.

This is a factual description of how the system works, not a contract and not legal advice. The terms that govern Beacon are our Terms of Service and Privacy Policy. Where a statement here depends on a third-party agreement rather than on our own code, it says so. See section 10 for what we do not yet have.

1. What you are approving

Beacon is an AI platform your HR team uses to get answers with sources on them. It also lets your team upload internal HR documents so those answers can cite your handbook and policies alongside HRMorning's editorial and compliance library. Beacon is operated by ForgeIntent LLC, which does business as HRMorning and Rover Insights.

Uploaded documents are private customer data. They are stored on a different plane from HRMorning's shared editorial content, are isolated per organization at the database level, and are not used to train AI models.

2. Where an uploaded document goes

Your browser ──TLS──> Beacon ──> Amazon S3 (raw file, encrypted)
                                   │
                                   └─> text extraction ─> chunking
                                         └─> embedding (Amazon Bedrock)
                                               └─> Beacon's PostgreSQL (pgvector)

Everything in that path sits inside our AWS and PostgreSQL boundary.

The boundary that matters: document text and embeddings are stored in Beacon's own PostgreSQL database, not in the shared analytics warehouse that holds HRMorning's editorial content and audience data. That separation is deliberate and is enforced in the storage schema itself, not by convention.

3. Encryption

4. Tenant isolation, enforced by the database

This is the part most IT reviewers care about, so it is worth being precise: our isolation is not "the application remembers to filter by customer."

• Tenant tables use PostgreSQL Row-Level Security with FORCE ROW LEVEL SECURITY. Forced means the policy applies even to the table's owner, so there is no privileged in-app path that quietly sees everything.
• Policies compare each row's organization and user against an identity that is set per request, inside the transaction, from the authenticated session. Because it is transaction-scoped, a pooled database connection cannot carry one request's identity into another request.
• The application connects as a non-superuser role specifically so those policies bind. A superuser or service-role connection would bypass RLS, which is exactly why we do not use one on the request path.
• Isolation is covered by an automated test suite that runs real SQL as the restricted role and asserts one tenant cannot read or write another's rows. It runs on every change.

5. Access control inside your organization

• Documents can be uploaded as organization-wide or personal. Personal documents are visible only to the uploading user.
• Retrieval is access-checked at the point of retrieval, not only at upload. A document that a given user should not see cannot be surfaced to them as a citation in an answer.
• Administrative actions are recorded in an audit log.

6. AI model handling, and no training on your content

• All model inference runs on Amazon Bedrock within our AWS account. Beacon holds no direct model-vendor API key.
• Beacon has no pipeline that trains or fine-tunes models on customer content. No code path sends conversations, profile data, or uploaded documents to any training or fine-tuning process.
• Embeddings of your documents are generated on Bedrock and stored in our own database, not shipped to a third party.

Whether the model provider itself uses API inputs or outputs for training is governed by the AWS and Anthropic commercial terms, not by our code. AWS Bedrock does not use inputs or outputs to train models under its service terms. We reference that rather than assert it as our own control, and we can point you to the current AWS documentation on request.

7. Authentication

• Authentication is handled by Clerk, a dedicated identity provider. Beacon does not store passwords.
• Multi-factor authentication is required. Every user enrolls a second factor (authenticator app or SMS) at sign-in.
• Sessions are tied to an organization, and a user acts within one organization at a time.

8. Your data, and getting it out or deleting it

• Export. A user can export their data from within the product.
• Deletion. Account deletion is implemented and removes the user's records across the system, including uploaded documents and their embeddings. Data shared at the organization level is handled so that deleting one user does not destroy another user's organizational context. Deletion takes effect after a 30-day grace period, during which the user can cancel it. Section 7 of our Privacy Policy describes what is kept afterwards.
• Deletion of a specific document is available to its owner and to organization admins.

9. Third parties that process data

Two of those are worth spelling out, because you should not have to infer them from a table cell:

• Conversation summaries. When a conversation ends, Beacon stores a short summary of it so it can recall your earlier work later. If that conversation was about an uploaded document, the summary can describe what was discussed. The document itself, its text and its embeddings stay in the database described in section 2 and are not written here.
• Company context and team email addresses. The company details your team tells Beacon (size, industry, jurisdictions, the tools you already use, what you are trying to solve) and your members' email addresses are stored so Beacon can match you to relevant vendors and to what comparable companies are doing.

These four hold your organization's content. Other service providers, such as our payment, email and analytics providers, process limited personal information to run the service. Section 4 of our Privacy Policy lists all of them.

Our providers' own certifications

These are our providers' certifications, not Beacon's. They describe the platforms we build on, and they are not a claim about Beacon. Section 10 states what Beacon itself holds, and that is the line that matters for your approval.

Read from each provider's published pages on 17 August 2026. A provider being able to support HIPAA under its own agreements does not make Beacon HIPAA-eligible. Section 10 is unchanged on that point.

10. What we do not have yet, stated plainly

An IT reviewer deserves the gaps as clearly as the controls:

• No SOC 2 report, ISO 27001 certification, or completed third-party penetration test at this time.
• Not HIPAA-eligible. No BAA is offered. Do not upload PHI.
• Please do not upload regulated or special-category personal data such as medical records, government identifiers, or payment card data. Beacon does not technically block it, so this is a usage expectation, and one worth naming explicitly in your internal approval.
• Data handling terms: retention and deletion are described in section 7 of our Privacy Policy. If your organization requires a Data Processing Agreement or has a security questionnaire, we will complete it. Just ask.

11. Contact

Security questions, questionnaires, or DPA requests: beacon@hrmorning.com

Changelog

Newest first. The date at the top of this page is the first date in this table.