Security

Security is foundational to RealClear. This page says what is in place today, what is planned, and what is not there yet, so that a security reviewer does not have to guess. For our full security, privacy, and compliance picture in one place, see our Trust Center.

Infrastructure

RealClear runs on managed cloud infrastructure for the web app, backend services, workers, and database, in a United States region, with document storage in managed object storage that is not pinned to a region. Provider categories and their data locations are listed on our sub-processor page. Public website and API connections use HTTPS/TLS; internal service-to-service traffic runs on the hosting provider’s private network and is not represented as end-to-end TLS. Managed storage layers encrypt stored data. The public web tier sends a per-request Content Security Policy with nonces and strict-dynamic, cross-origin framing is denied, and content-type sniffing is disabled. Production changes are gated through local security checks and reviewed deployment steps.

Data Handling

We practice minimal data collection. We do not store client documents or uploaded files beyond what is needed to provide the service unless you explicitly save them to your account. Access-request and account data (email addresses, usage metadata) is stored with appropriate access controls and is never sold to third parties.

Property research requests, source records, briefs, and account actions are retained where needed for product delivery, audit logging, security, support, or legal compliance. Tenant-scoped data is separated by organization and verified by an automated cross-tenant test suite, and customer-visible brief claims tie back to source records and the research activity that produced them.

Access Control

RealClear is operated by its founder, who is the only person with production access; supervised AI coding assistants act under the founder’s credentials and never on their own. There are no other staff accounts to review or off-board today. Administrative actions in the product require multi-factor authentication with step-up checks and are recorded in an append-only audit log; database-level operations such as migrations are run by the founder outside the product and are not recorded in that log — some releases carry receipts in the repository (most recently the September 2026 restore drill), but most releases and migrations do not yet. Access is reviewed with each release rather than on a calendar. Customer accounts use argon2id password hashing, single-use sign-in links, lockouts on repeated failures, and multi-factor authentication, which is required for administrators and for every user of a standard or enterprise organization.

Research Security

Research runs on established model providers, which process property research, cited research, structured analysis, memo composition, verification, review, and embeddings. Different research tasks can carry different data-handling terms, so we do not make blanket zero-retention or no-training claims on their behalf; we review vendor terms before integration and limit the data sent to each task. Web content fetched during research is treated as untrusted: citations that carry recognized injection markers are dropped before they are stored, and no model output becomes a customer-visible claim unless it is tied to a source excerpt. Provider spend is bounded by per-organization reservations and caps.

Backups and Resilience

Nightly core and weekly full database backup jobs are configured, but successful execution has varied. A nightly core backup succeeded on 15 October 2026 after an earlier failure window. A core backup was restored into a scratch database on 21 September 2026; a full-database restore has not been proved. We are formalizing release-bound restore validation and can provide the current status on request.

Compliance Roadmap

We would rather state our posture plainly than overstate it:

• SOC 2 Type II — not certified. A SOC 2-aligned policy set, a control-environment description, and an illustrative risk list exist; an audit engagement starts when a customer requires it.
• Penetration testing — no third-party test yet. Security-sensitive changes receive an independent adversarial code review and targeted negative tests before release.
• CCPA / GDPR — data-subject requests are handled through a documented manual process. See our Privacy Policy for your rights and how to exercise them.

Responsible Disclosure

We appreciate the work of security researchers and the broader community in helping keep our platform safe. If you discover a potential vulnerability in RealClear, please report it to arvind@realclear.ai. Postal contact: RealClear Systems Inc., 400 Beale Street, Apt 606, San Francisco, California 94105. The same contact is published at /.well-known/security.txt.

Please include a description of the issue, steps to reproduce, and any relevant screenshots or proof-of-concept. We will review reports and follow up as we investigate. We do not pursue legal action against researchers who act in good faith under this policy.