Security controls Truenote has today

01

Program and clearance isolation

Server-side filters deny cross-program and above-clearance access before protected content reaches ranking, generation, citations, or document reads. A request for another person's conversation, or feedback on another person's answer, gets the same "not found" response as a record that does not exist.

02

Controlled content activation

Source, file-signature, EICAR, parsed-content, lifecycle, and role checks constrain activation. Missing or failed malware scanning quarantines uploads when scanning is enabled.

EICAR detection is a test-signature check. A super user can disable external scanning; authorized senior managers and super users can activate their own uploads. Independent approval is not universal.

03

Hybrid retrieval boundary

Vector, full-text, typo-tolerant, reranking, and neighbor retrieval preserve authorization and lifecycle limits through the complete pipeline.

04

Zero Data Retention routing policy

Approved answer routes request Zero Data Retention, deny data collection, pin one provider, disable OpenRouter provider fallback for each request, and reject arbitrary routes. Truenote can retry other routes within its approved model chain. Super users can reorder that chain but cannot add or remove a route; changing the approved list takes a code change.

This is a routing policy. Actual provider eligibility, account settings, contracts, and retention require separate evidence. It does not cover every parser, embedding, or reranking service.

05

Pre-provider input firewall

Supported secret, US Social Security number, Luhn-valid 13-to-19-digit card-number (space or hyphen separators), email, structured-phone, and IP-address patterns are redacted at embedding, reranking, answer, and utility-model text boundaries. In answer requests, excerpts from approved documents keep their email addresses, phone numbers, and IP addresses; secrets, Social Security numbers, and card numbers are still redacted.

Names, street addresses, arbitrary credentials, standalone card-verification codes, and obfuscated or contextual personal data are not comprehensively detected. Raw uploaded files follow a separate path.

06

Cite or refuse

Missing, malformed, unknown, and out-of-range citations produce a refusal. Generated text matching the supported secret, Social Security number, or card-number rules is also refused.

A valid citation does not prove every statement is accurate. Output screening has a defined pattern scope; it does not guarantee complete personal-data protection or immunity to prompt injection.

07

Version-bound citation receipts

Ordered source snapshots preserve version and anchor context. Stored history rechecks current program, clearance, source approval, and lifecycle access before returning questions, answers, excerpts, or titles. Exchanges without complete authorized provenance, including zero-citation refusals, are withheld as a whole, so a past answer never appears with some of its sources missing. Refused questions and missing-content flags go to the Content gaps report instead: supervisors see their own team's, managers the whole program's. A title is hidden unless the exchange it was generated from is shown and every other withheld exchange is an uncited refusal; conversations with nothing to show are not listed. Eligible superseded receipts remain readable while their parent document and source stay authorized.

08

Browser request defense

Trusted same-origin mutations pass while foreign, opaque, malformed, cross-site, and sibling-origin requests are rejected. CSP restricts active content. Clients sending neither Origin nor Fetch Metadata headers pass this browser-origin check and still require authentication on protected routes.

09

Redacted diagnostics

Structured error handling removes credentials, complete private keys, Social Security numbers, and payment-card values from covered diagnostic paths.

10

Bounded provider failure

Provider operations use explicit deadlines, retry caps, and abort propagation. The ask path has an overall deadline that cancels outstanding provider calls; a request cut off that way returns the standard refusal. Database steps do not observe this deadline.

11

Hash-chained audit logic

Security events are written through a database function that hash-chains each event to the previous one. In production the database refuses edits, deletions, and truncation of these events, and the application's database account can add events only through that function. API sign-ins and administrative/document changes produce events, and database triggers record document-version creation and lifecycle-state transitions, including background parsing and automatic activation, and content-source creation and updates, in the same transaction. A worker job writes each committed event to the service log in order and checks it against alert rules; ten of eleven rules were tested in production on 2026-10-10 by triggering the event and confirming the alert email.

A daily copy of the logs is kept outside the hosting provider, but one owner administers the database, the hosting account and that copy, and can switch off the append-only protection. Define the retention period and separate who administers the copy before relying on audit integrity against a database administrator.

12

Evaluation integrity

Evaluation tests cover retrieval, reranking, citations, refusals, faithfulness, durable queue recovery, and separate pass rates for held-out questions.

13

Workload limits

Answer requests use PostgreSQL counters per user and program; uploads use per-user counters. Login and selected administrative routes have additional limits.

Some static, history, personal and administrative reads remain without application request limits by an intentional demo-phase decision. Before customer use, the owner must approve application or verified edge abuse coverage and thresholds.

Permitted content

Truenote is intended for approved policies, procedures, and operational reference material. Until a signed data and PCI scope decision permits otherwise, keep payment-card numbers, CVV/CVC, PINs, track data, credentials, and live customer personal data out of questions, history, documents, screenshots, and reports.

Raw-file boundary

Uploads reach object storage before ingestion. An enabled scanner receives raw bytes; PDF and image parsing can send those bytes to LandingAI before parsed-text screening. Parsed text is persisted before its sensitive-content decision. Quarantine restricts activation; it does not undo earlier storage or disclosure.

Provider coverage

OpenAI receives protected embedding text, Cohere receives protected reranking text, and OpenRouter and its selected model provider receive protected generation and utility text. Parser and scanner data handling, account settings, contracts, retention, and subprocessors require separate approval.

Identity and sessions

Code implements Argon2id password hashing, hashed session tokens, production Secure and HttpOnly cookies, account deactivation checks, and session revocation. OIDC with MFA-claim validation is available but intentionally unconfigured during testing. Explicit disabled or break-glass local-login policy remains enforced even when OIDC configuration is unusable, including password-reset and invitation completion; a link refused this way is not used up and still works, before it expires, once access is allowed. Password-reset requests get the same response, sent before the account lookup, whether or not the email has an account. Public demo accounts cannot make shared or administrative changes by default; their personal notes, highlights, and labels stay available within that account. They cannot change or reset their published passwords, and only a super user can edit them, so one visitor cannot lock others out. Passwords set through account creation, reset, and change must be at least 15 characters; demo accounts configured by the operator are exempt. Application sessions have a seven-day absolute lifetime and no enforced idle timeout.

The security owner must approve session controls, MFA, access reviews, and break-glass handling. Public demo access must be isolated or retired before organizational data is introduced.

Retention and deletion

Normal document removal retires it and retains source bytes and evidence. Retention-gated permanent purge is restricted to super users. A deployment setting can permit a retention override. Customer-approved schedules must cover originals, parsed content, questions, answers, diagnostics, security events, provider copies, and backups; document purge alone does not establish complete deletion.

Unscreened personal fields

Personal notes, label names, and document titles are stored without the question or document sensitive-content screening. The prohibited-data policy applies to these fields too; current pattern controls do not enforce it there.

Transport and storage

The reviewed public pages serve over HTTPS with HSTS and a restrictive Content Security Policy. Private-service transport, storage and backup encryption, key access, rotation, and deletion still require platform evidence. Public HTTPS does not establish encryption for every hop or stored copy.