Security & Trust

RedCrown checks whether an AI feature still meets agreed requirements and shows the evidence behind the decision. This page states plainly how your data and keys are handled on each path through the product. We describe only what is true today. We hold no formal certification (no SOC 2, no ISO 27001) and do not claim any.

Last updated 2026-09-17

Where your data goes, by path

Running an evaluation locally does not by itself upload the results to RedCrown. Using a remote model provider sends the necessary requests to that provider. Uploading results to RedCrown and creating a share link are separate actions. The paragraphs below take each path in turn.

Local scoring and checking

redcrown score and redcrown check read files on your machine and write files on your machine. They open no network connection at all. No provider is called, no key is needed, and RedCrown receives nothing.

Local execution with remote providers

redcrown eval runs the evaluation on your machine and calls the model providers you configured. Your provider key is sent to that provider as the authentication for each request, and the inputs for each case go to that provider. That is what calling a provider means, so the key does leave your machine, to the provider you chose and to no one else. RedCrown receives nothing from a local eval; nothing is uploaded until you run redcrown push.

Hosted evaluation

When the app or the API runs an evaluation for you, RedCrown calls the providers with the key you stored. The key is encrypted at rest (see below), decrypted for the duration of your run, and never returned by any API. The inputs and outputs of that run are stored as the run report in your workspace. RedCrown's own provider keys never serve a customer run.

Capture and replay

The proxy path is a separate advanced workflow on Growth and above. When you point an endpoint at RedCrown's proxy, RedCrown forwards each call to the provider on your key and keeps a capture of it. Captured inputs are stored in a private bucket, encrypted at rest and siloed per workspace, and can be replayed through an evaluation later. Nothing on this path runs on a schedule.

Uploading results

redcrown push is an explicit action. It uploads the report you name and nothing else. By default the per-case receipts go with it, because case-level evidence is what makes a report checkable. --no-receipts strips the per-case inputs, outputs, references, audio, and context before upload, so the hosted run holds the aggregate ranking only.

Publishing a report

Creating a share link is a second explicit action, taken after the run is in your workspace. The disclosure level you choose decides how much of the configuration is shown: full, hashed, or private. It does not hide content: inputs, outputs, and references are visible on a public page, and a public link may be indexed. Choose the disclosure level and the visibility before you create the link, and revoke it when you are done; revocation stops the link but cannot recall a copy someone saved.

Encryption, by data class

• Provider API keys you connect (OpenAI, Anthropic, AWS, Deepgram, and others) are encrypted at rest with authenticated symmetric encryption (Fernet / AES-128-CBC + HMAC) under a key-encryption key held only in the server environment. The write API is write-only: it returns the provider and the last four characters, never the key.
• Stored eval inputs (for the capture and replay flow) are encrypted at rest, under a separate PHI key when one is configured and otherwise under the application key-encryption key, and siloed per workspace. A cross-workspace URI is rejected at the storage boundary, and the storage bucket is private.
• Proof-link tokens are encrypted at rest under the same application key-encryption key as provider keys.
• Stored run reports, which hold the model outputs and the inputs they were run on, sit in the database without that additional application-level layer. The database provider's own at-rest encryption applies to them, but that is the provider's layer, not RedCrown's. Treat a hosted run as you would any other cloud-stored copy of the data.
• Card data never touches RedCrown. Billing runs through Stripe-hosted checkout; the billing webhook is the source of truth.

Shared reports, retention, and revocation

• Share links are revocable. The owner can revoke a share link at any time; a revoked link returns a not-found response and stops rendering. Links can also be created with an expiry. The URLs and the API still say proof; a proof link and a share link are the same object.
• Signed attestations are point-in-time signed facts. They show authenticity, integrity, and provenance (which dataset by hash, which model versions, when, under which methodology version), and they verify offline against RedCrown's published key. They are not a claim that the input data was representative, or that a declared configuration was the one that ran.
• Reviewer links are token-scoped and blinded: a reviewer sees option A against option B without model identities, and a token cannot reach another workspace's data.

Tenant isolation

Every authenticated data route is workspace-scoped. Access is validated against your workspace memberships, and stored data is tagged by workspace, so one tenant's data is never returned to another. Database row-level security is deny-by-default on the sensitive tables.

Certifications, and what they cover

RedCrown holds no SOC 2 report and no ISO 27001 certificate, and no audit is under way. If your procurement needs a report from us, tell us and we will scope it with you.

Our platform providers hold their own attestations, listed in the table below and read from each provider's own trust page on 2026-09-14. Two things about them are worth stating plainly, because the distinction is what an auditor or a reviewer will ask about:

• They cover the provider's platform, not RedCrown. A provider's report stays theirs. We do not present it as ours, and running on audited infrastructure is not the same as being audited.
• The controls a SOC 2 audit of RedCrown would test are ours alone. Access management, change control, logging, and vendor management sit with us, and no provider's report says anything about them.

Subprocessors

RedCrown uses the following platform subprocessors. The model providers you evaluate are connected with your own keys and are under your control.

Enterprise

For regulated teams we discuss self-hosted or VPC deployment, SSO, audit logging, and data residency. Talk to us.

For the contractual terms see the Terms of Service, and for data handling commitments see the Privacy Policy.

Reporting a vulnerability