Back homeTrust · architecture

Trust & security

Trust the math. Verify us, don’t take our word.

This page is written for the person your institution asks to review vendors: what we encrypt, who can see it, how long we keep it, and — most importantly — how you can independently confirm the record we produce, without connecting to any RedInkAI server.

If a claim on this page can’t be independently confirmed by inspecting an exported Authorship Packet or by reading our public code paths, we don’t make it here.

How you verify a packet yourself

No trust in us required. Just a hash function and a text editor.

  1. Export any project as an Authorship Packet from the editor. You get a JSON file with the full event chain and a manifest.
  2. Recompute each event’s SHA-256 hash from the event body plus the previous hash. Compare with the stored hash. Any tool that speaks SHA-256 can do this — Python, Node, a shell one-liner.
  3. If every hash matches and the terminal hash matches the manifest, the chain is intact. If not, you know exactly which event was altered, and when.

The verifier runs entirely on your machine. It does not phone home. It does not need our servers. The record is portable and archival by construction.

Data flow — where your writing goes

Your browserTLS 1.2+RedInkAI APIFastAPIModel inferenceCommercial APIInkTrail hasherSHA-256 chainMongoDB AtlasAES-256 at restBackups90-day expiry

Every write path is dual: content persists in the encrypted datastore, and a hash of the event persists in the InkTrail chain. The chain is what you export in the Authorship Packet; the datastore is what powers the editor for you.

The trust anchor is the math, not the badge

Most vendors ask you to trust their operational controls. We ask you to trust arithmetic. Every AI-assisted event inside a manuscript — the prompt you sent, the response returned, each accept, edit, or dismiss you made against a Redline note — is hashed and cryptographically linked to the previous event.

The result is an Authorship Packet: an ordered chain that a third party can verify offline without connecting to our servers, our database, or anything we control. If a single character of the record is altered, the chain breaks and any reviewer can see it.

This is why we don’t lead with a compliance mark. A badge attests that a firm reviewed our controls at a point in time. A hash chain attests to the record itself, at the moment of writing, verifiable by anyone, forever.

Encryption in transit and at rest

All traffic between your browser and RedInkAI is served over TLS 1.2+. Manuscript content, InkTrail events, and account records live in MongoDB Atlas with AES-256 encryption at rest. Backups inherit the same encryption posture; nothing is written to disk unencrypted at any point in the pipeline.

Passwords are hashed with bcrypt using a per-account salt. Session tokens are short-lived JSON Web Tokens signed with a secret rotated on server restart; they never leave the browser’s local storage boundary.

Who at RedInkAI can read your manuscript

Access to production data is limited to the founder. There is no support team with read access. There is no engineering team with read access. When we need to reproduce a specific bug you have reported, we ask for your permission, in writing, before opening any part of your project.

Redline’s proactive scan runs only when your session is open in an editor tab. Closing the tab stops the model calls; there is no server-side batch that reads your manuscript in the background.

When you enable Trail Lock on a project, the InkTrail becomes append-only from the platform’s side. Even the founder cannot rewrite a locked chain; every audited operation is logged to a separate immutable event stream.

What we retain, and for how long

We retain your manuscripts, InkTrail events, and account metadata for as long as your account is active. If you delete a project, its content is removed from the primary datastore within 30 days and expires from encrypted backups within a further 60 days (90 days total).

If you close your account, everything above happens automatically. We keep a minimal record of the deletion event (account ID, timestamp, requester) for two years to defend against fraudulent recovery attempts. That record contains no manuscript content.

Application logs (request paths, error codes, IP-hash) are retained for 30 days for operational debugging and then rotated out. We do not retain manuscript text in logs.

Deletion, export, and correction requests

You can export any project as a signed Authorship Packet at any time from the editor. You can delete any project from the dashboard; the deletion cascades as described above.

For GDPR / CCPA / UK GDPR data-subject requests (access, portability, rectification, erasure, restriction), write to redinkaistudio@redinkai.com. We acknowledge within 72 hours and complete verified requests within 30 days.

If you are not the account holder but believe your personal data is in a manuscript on our platform (for example, you are named in someone’s memoir draft), write to the same address and we will work with you and the account holder toward a resolution.

We do not train on your writing

Your manuscripts, prompts, Redline notes, and reference materials are never used to train RedInkAI models. We do not sell aggregated writing data. We do not share manuscript content with third parties for advertising, analytics, or benchmarking.

Inference-time calls to model providers are made under their commercial API terms, which specifically exclude training on submitted content. We select vendors that make this contractual, not aspirational.

Incident response

If we detect a security incident affecting your data, we notify affected account holders by email within 72 hours of confirmed impact, disclose the scope in plain language, and publish a post-mortem within 14 days.

Report a suspected vulnerability or incident to security@redinkai.com. We commit to acknowledging security reports within 48 hours. Responsible disclosure is welcomed; we will not pursue legal action against researchers acting in good faith under the guidelines below.

  • Do not access, modify, or delete data belonging to other users.
  • Do not disrupt service (no DoS, no automated scanning at load).
  • Give us a reasonable window to remediate before public disclosure (default: 90 days).
  • Tell us what you found, how to reproduce it, and what impact you assess.

Policies, sub-processors, and the trust posture

Our internal information security policies (access control, data retention, vendor management, incident response, cryptographic standards, business continuity, acceptable use) are version-controlled and reviewed annually. We do not currently hold a SOC 2 attestation; we will pursue one when a specific institutional pilot requires it, and until then we would rather be honest about that than post a badge.

For a copy of any specific policy under NDA, or for a security questionnaire response (SIG Lite, CAIQ), write to redinkaistudio@redinkai.com.

Regulated-industry readiness

RedInkAI is designed with 21 CFR Part 11 readiness in mind — append-only audit trail, deterministic timestamping, cryptographic integrity of the record, and clear user attribution. Pilot deployments in FDA-regulated workflows are handled under a signed Business Associate or Master Services Agreement.

For legal-industry deployments, the Authorship Packet is structured to support work-product declarations and privilege claims when the record is exported and archived by the practice, not by us.

Sub-processors

VendorPurposeData classRegion & safeguards
MongoDB AtlasEncrypted primary datastore for manuscripts, redline notes, and audit trail events.Manuscript content, InkTrail events, account recordsUS, encryption at rest (AES-256)
OpenAIModel inference for guidance responses and Redline notes.Prompt text and surrounding context sent per request; no training on your data (API terms).US, TLS in transit
StripePayment processing for paid tiers and per-manuscript purchases.Card token, billing email, purchase amount. We never see raw card numbers.US/EU, PCI DSS Level 1
ResendTransactional email (account notifications, redline alerts).Email address, message body of the specific notification.US, TLS in transit
EmergentApplication hosting and preview infrastructure.Application logs, hosted runtime.US, TLS in transit

We update this list before adding any new sub-processor. Existing account holders are notified by email when a material change takes effect.

Deeper review, security questionnaire, or a pilot?

Compliance officers can request our full policy set under NDA. Researchers should report vulnerabilities through the security inbox. Anyone else can start with the pilot brief or the transparency statement.

Last updated: February 2026 · This page is versioned in our source; material changes trigger an email to existing account holders.