PCI-focused safeguards | Truenote Security

Plain-language context

PCI DSS includes secure-software requirements and broader controls for systems that handle payment data or can affect its security. Truenote's software evidence supports a security review; customer scope, operating effectiveness, and validation remain unresolved. No PCI DSS compliance, certification, Attestation of Compliance, or independent-assessment result is claimed here.

PCI DSS v4.0.1 is the review basis. Requirements with a March 31, 2025 effective date are already effective. The compliance-accepting entity and qualified assessor determine applicability and the accepted validation path. See the PCI SSC document library and applicability guidance, checked October 9, 2026.

Payment-data boundary and scope

Truenote provides cited answers from approved reference material. No approved path for live payment-card data has been recorded. Until Security and the PCI scope owner approve a different assessed path, do not enter or upload primary account numbers (PAN), CVV/CVC, PIN or PIN blocks, full track data, payment screenshots, call transcripts containing payment data, credentials, or live customer personal data.

For the merchant/customer use being considered, sensitive authentication data must not be retained after authorization, even if encrypted. Truenote is not a payment vault or payment-capture channel. See PCI SSC guidance on sensitive authentication data.

Questions and model output

The ask route blocks supported secret, Social Security number, and card-number patterns in the current question and supplied history before its persistence and provider work. Text-provider firewalls add deterministic redaction to the question, and Truenote's OpenRouter guardrail is configured to redact card numbers, Social Security numbers, and contact details on answer and query-rewrite requests. Neither control redacts names or addresses. Generated-answer screening covers a narrower pattern set.

Card-number detection requires 13-to-19-digit Luhn-valid values with space or hyphen separators. Pattern screening does not reliably identify standalone CVV/CVC, names, addresses, all credentials, or encoded and fragmented values. Personal notes, label names, and document titles are stored without these sensitive-content checks. A prohibited-data policy still needs technical enforcement, user training, and incident handling.

Documents and raw bytes

Object storage receives originals before ingestion. An enabled malware scanner receives raw bytes; PDF/image parsing can send them to LandingAI before parsed-content screening. Parsed text is persisted before its screening decision. Quarantining a version does not remove those copies or reverse the disclosure.

Only approved, sanitized source files should enter this path. Every raw-file processor, storage location, and recovery copy needs a scope and retention decision.

Scope and shared responsibility

A PAN prohibition or redactor alone does not establish that Truenote is outside PCI scope. Administrative access, connected systems, endpoints, hosting, providers, and the ability to affect the customer's cardholder data environment also require assessment.

Program and clearance isolation are application authorization controls. They do not prove PCI network segmentation. Provider certifications do not transfer compliance to Truenote or its customer.

Required scope records: data flows and inventories, scope and PAN decision procedure, and third-party responsibility matrix. Scope includes originals, parsed documents, questions and answers, audit/diagnostic records, backups, and provider copies.

Software safeguards and draft procedures

Each item states its evidence scope. A written procedure or template becomes operating evidence only after approval, assigned responsibilities, and authentic execution records.

Secure development lifecycle

A draft Truenote-specific lifecycle defines responsibilities through design, testing, release, and verification. Approved adoption, role-based training, and sampled use remain required.

Operational evidence required · procedure and curriculum

Threat-driven testing

The engineering threat model covers application, AI, provider, access, data, and PCI-impact boundaries. Negative tests exercise denial paths. Named approval and residual-risk treatment remain open.

Verified · repository negative tests

Pre-provider data screening

Supported high-risk question/history patterns are blocked before ask persistence. Deterministic text redaction covers embedding, reranking, answer, and utility calls. Raw files and broader personal-data classes have separate limits.

Verified · portable provider-boundary tests

Model-output screening

Generated text matching supported secret, Social Security number, or card-number patterns is refused. Missing or invalid citations also produce a refusal. Complete personal-data detection is not claimed.

Verified · generation safety tests

Server-side access boundaries

Program and classification filters precede protected retrieval, reranking, generation, and citation lookup. Stored history rechecks current clearance, program, source approval, and lifecycle access. Exchanges lacking complete authorized provenance, including zero-citation refusals, are withheld; affected titles are hidden. Feedback and missing-content flags are restricted to the person who asked the question. Production authorization still needs release-specific verification.

Verified · repository isolation tests

Controlled content activation

File, source, lifecycle, parsing, and role controls constrain activation. Scanner absence/failure quarantines uploads when enabled. A super-user scanner override and senior-role self-activation require governance.

Verified · repository policy tests

Automated security analysis

Hosted CI runs CodeQL, secret scanning, dependency audit, SBOM generation, type checks, builds, and tests. Ordinary CI does not require the strict vulnerability release gate or establish that findings are closed.

Verified · named hosted workflow below

Controlled change records

A draft procedure and templates cover impact, approval, review, testing, deployment, recovery, and verification. Approved authority, a reconciled register, and completed operating samples remain required.

Operational evidence required · change-control adoption

Hash-chained audit logic

Security events are hash-chained by a database function. In production the database refuses edits, deletions, and truncation of these events, and database triggers record document-version creation and lifecycle-state transitions and content-source creation and updates. A worker job writes each committed event to the service log in order and emails the owner on privileged logins, account and role changes, security setting changes, failed-login and denial spikes, and failed audit writes. Ten of eleven alert rules were tested in production on 2026-10-10. A daily copy of the logs is kept outside the hosting provider; a defined retention period is not yet in place.

Verified · 10 of 11 alert rules tested in production

PCI review coverage beyond software development

The existing detailed software-development mapping covers Requirement 6. A complete PCI assessment must also resolve the other applicable requirement families. This checklist describes evidence to obtain; it does not mark a requirement satisfied or determine applicability.

Assessment topics and required evidence
PCI DSS area	Evidence required for the assessed scope
1 · Network controls	Approved boundaries, connections, ingress/egress rules, administrative paths, and any segmentation test evidence. Application scoping alone is insufficient.
2 · Secure configuration	Inventories and hardened baselines for services, database, storage, endpoints, and management accounts; configuration and default-account review.
3 · Stored account data	Approved data prohibition or assessed storage paths; retention, discovery, deletion, backups, encryption, and key-management evidence where applicable.
4 · Data in transit	Protection of applicable data paths, certificates, protocols, and trust decisions. Public HTTPS proves only the observed public connection.
5 · Malware protection	Applicable malware controls, enabled configuration, updates, monitoring, exception approvals, and operating results. An upload test signature alone is insufficient.
6 · Secure software and changes	Approved development and training, current vulnerability triage and patch records, independent code review, controlled releases, and applicable web/payment-page protection.
7 · Least privilege	Approved roles, account provisioning and removal, periodic access review, and application/database/platform privilege tests.
8 · Identity and authentication	Unique identities, applicable MFA, account and credential lifecycle, emergency access, idle reauthentication, and revocation evidence.
9 · Physical security	Applicable hosting-provider physical assurance, customer endpoint controls, and media handling, with responsibilities assigned.
10 · Logging and monitoring	Required event coverage, protected and independently retained logs, time synchronization, review/alerts, access restrictions, and failure response.
11 · Security testing	Applicable internal/external scans and ASV evidence, application/network penetration tests, segmentation validation, payment-page change detection, remediation, and retest.
12 · Security governance	Scope confirmation, approved policies, named responsibilities, risk analyses where required, training, third-party agreements and monitoring, and exercised incident response.

Specific applicability decisions include automated public-facing web protection (6.4.2), payment-page script authorization/integrity/inventory (6.4.3), and payment-page change detection (11.6.1). CSP and origin checks alone do not establish those controls. Record an assessed justification for every exclusion; do not infer an exclusion from the application's intended use.

For applicable access, 8.2.8 requires reauthentication after 15 minutes of inactivity. Truenote currently has a seven-day application session lifetime without an enforced application idle timeout. The assessor must confirm whether a verified endpoint/session control satisfies the requirement or application changes are required. See PCI SSC idle-session guidance.

Requirements before security approval

Readiness remains incomplete. The demo/testing deployment intentionally leaves OIDC identity integration and the malware-scanner endpoint unconfigured; their integrations need end-to-end acceptance before customer use. Security alerting runs in production, but the break-glass alert is untested until SSO is on, and no retention period is defined yet. Public demo login remains configured. Current operating records also leave recovery, provider assurance, scope, and independent testing unresolved.

Approve the boundary and permitted data. Name the application operator, customer PCI owner, and decision authority; inventory data, processors, administrative connections, storage, and recovery copies. Authorize a bounded synthetic trace, reconcile it, and approve the final scope and validation path.
Establish safe operation. Resolve identity/MFA, session and privileged access, demo isolation, scanning and overrides, external audit delivery, encryption, retention, and tested backup/restore. Create an authorized test environment or approve a documented substitute.
Close release-management evidence. Reconcile current scanner results to the historical baseline, assign owners and deadlines, approve each disposition, retain remediation/retest, and pass the strict managed-release gate. Adopt change control and retain a reviewed production-change sample bound to deployed bytes.
Obtain provider and independent assurance. Verify exact provider services, contracts, retention/ZDR, subprocessors, and applicable attestations. Complete authorized application/API, AI, and any applicable network/segmentation tests, then remediate and retest findings.
Retain approval and recurring evidence. Authenticate signed decisions and assessment results, complete training and incident/recovery exercises, assign operating cadences and expiry reviews, and obtain customer security authorization before live organizational use.

Each requirement needs a named accountable person, a dated artifact tied to the environment and release, a binary acceptance result, and a reviewer. Templates, screenshots, structural validators, and passing CI alone cannot supply that evidence. The decision meeting pack and independent-testing plan define the next approval and assurance steps.

Assessment boundary: this page is a readiness and evidence summary. It does not establish PCI DSS compliance, certify software, or replace the customer's assessment. Assessment records must state the services, requirements, environment, and period actually tested, including exclusions and unresolved findings.

Checks that passed

The security workflow for reviewed main commit e63293ca7d9d passed. The results below cover tested repository paths, not a deployed CDE assessment.

Access isolation

Unit tests of the authorization checks used by retrieval, citations, and document reads denied cross-program and above-clearance access.

AI input boundary

Portable tests captured provider payloads and confirmed deterministic redaction before supported provider calls.

Citation and refusal rules

Tests rejected missing, malformed, unknown, and out-of-range citations and refused sensitive model output.

Browser request defense

Tests accepted trusted same-origin mutations and rejected foreign, opaque, malformed, cross-site, and sibling-origin requests.

Audit delivery logic

Tests passed signed delivery, retry scheduling, completion, and dead-letter handling. The lease-fenced and delivery-health database functions were checked by content.

Security delivery pipeline

Hosted checks passed type checking, production build, unit tests, secret scan, dependency audit and SBOM, and CodeQL analysis.

The strict managed-release vulnerability and supplemental branch-enforcement gates were skipped in that ordinary main run. CodeQL job success does not assert zero findings. Current scans must be reconciled to approved dispositions; the historical register remains open.

Open the public software evidence set

These links cover implementation, tests, draft procedures, and workflow records. They are an evidence map, not a complete assessment dossier. Links to main show evolving source; the named workflow above pins the reviewed commit. Restricted operating records and third-party reports require separate review.

Secure development and change management

Processes, design analysis, staff guidance, and release records.

AI and sensitive-data boundaries

Documented behavior, source implementation, and direct boundary tests.

Access, content, and browser controls

Server-side authorization, controlled activation, and browser-request defenses.

Audit and secure delivery

Security-event integrity, durable delivery, hosted analysis, and evidence validation.

Compliance documents

Two tiers: public compliance summaries are open to everyone. Detailed documents, such as the full system security plan and the plan of action and milestones, describe security weaknesses and are available only to authorized reviewers who sign in.