Security & AI Trust

Kliper handles sensitive compliance evidence — firewall configurations, access control policies, network diagrams, cardholder data flow documentation. The platform enforces a multi-layered security pipeline on every uploaded file and provides clear boundaries around how AI processes your data.

File Integrity — SHA-256 Hashing

Every file uploaded to Kliper is cryptographically hashed using SHA-256 at the moment of upload, before it is written to storage.

How It Works

1. The file buffer is received in memory via the upload endpoint.
2. A SHA-256 hash is computed immediately using Node.js crypto.createHash('sha256').
3. The resulting 64-character lowercase hex digest is stored alongside the file record in the database (hash_sha256 column).
4. The file is then written to self-hosted Supabase Storage.

On-Demand Integrity Verification

At any point after upload, an authorized user can trigger an integrity verification check via the Verify action. The platform:

1. Re-downloads the file from storage.
2. Recomputes the SHA-256 hash of the downloaded content.
3. Compares the recomputed hash against the stored original.
4. Records the result (verified or tampered) along with a timestamp in the file’s metadata.

This guarantees that evidence has not been altered in storage — a critical requirement for audit trail credibility during PCI DSS assessments.

What the Assessor Sees

Malware Scanning — Dual-Engine Pipeline

Every file passes through a dual-engine malware scanning pipeline before it is accepted into the platform. No file reaches an assessor’s workbench without being scanned.

Scan Pipeline

The pipeline runs three checks in sequence, plus two scanners in parallel:

Scan Statuses

Scan Results Storage

Full scan results are persisted in the scan_result JSON column on the file record. Each engine’s individual result is stored:

{
  "engines": [
    {
      "name": "ClamAV",
      "status": "clean",
      "detail": "No threats detected"
    },
    {
      "name": "VirusTotal",
      "status": "clean",
      "detail": "0/72 engines flagged",
      "permalink": "https://www.virustotal.com/gui/file/a3f2b8c1...",
      "detections": 0,
      "totalEngines": 72
    }
  ],
  "scanned_at": "2026-02-28T14:30:00.000Z"
}

Assessors can view per-engine scan results directly in the Attachments Panel of the assessment workbench.

File Type Restrictions

Kliper accepts common evidence file types and blocks anything that could execute code:

Automatic Metadata Extraction

On upload, Kliper automatically extracts metadata from supported file types to provide assessors with a preview before opening the file:

This metadata is stored in the file record and displayed in the Attachments Panel, giving assessors immediate context about uploaded evidence without downloading each file.

Cortex AI — Privacy and Data Handling

Cortex is Kliper’s built-in AI assistant. Its conversational agent and document extraction run on OpenAI (GPT-5 family), as do the autofill, document validation, and file summary features. Before any text is sent to the provider, a PII-redaction layer removes IP addresses, emails, payment card numbers (Luhn-validated), phone numbers, and SSNs — so no cardholder data or personal identifiers reach the model. Enterprise organizations can additionally run Cortex under their own OpenAI agreement (bring-your-own key) or their own self-hosted model endpoint — see Choosing Your AI Provider. A self-hosted platform profile also remains available for deployments with strict data-residency requirements.

What Cortex Can Access

Cortex operates within strict boundaries:

• Assessment context only — Cortex can only see data from the assessment the user is currently working in. It cannot access other assessments, other clients, or other organizations.
• Requirement-scoped — when invoked on a specific testing procedure, Cortex receives only the relevant reporting instructions, the assessor’s existing responses for that requirement, and the names of uploaded evidence files tagged to that requirement.
• No raw file content by default — Cortex receives file names and AI-generated summaries of file content, not the raw file contents. The only exception is the Document Validation feature, which sends extracted text content (up to 30,000 characters) to the AI for criteria-based validation.

What Cortex Cannot Do

• Cannot access data across organizations — tenant isolation is enforced at the API level.
• Cannot store or learn from your data — OpenAI API data is not used to train models (enterprise privacy), and Kliper sends prompts only after PII redaction.
• Cannot make assessment decisions — Cortex generates draft text and validation results. The assessor retains full control over all findings, status selections, and the final report content.
• Cannot modify assessment answers directly — all AI-generated content is presented as suggestions that the assessor must explicitly accept or modify.

Data Flow

AI Transparency

Every AI-generated output in Kliper includes:

• Warnings — if data is missing (e.g., no assessor responses yet, no evidence files uploaded), Cortex explicitly flags what is incomplete rather than fabricating content.
• Placeholders — for data that does not yet exist, Cortex uses [PENDING_RESPONSE] or [TAG] markers instead of generating plausible-sounding but unverified text.
• Model attribution — the AI model used and token counts are recorded for every validation and autofill operation.
• Shows its work — every Cortex reply that consulted your data exposes a “How this answer was produced” trace, listing exactly which requirements, evidence, and knowledge-base sources it read before drafting. Reviewers can verify the AI’s reasoning path, not just its output.

AI-Use Declaration

Kliper gives every assessor a standard AI-use declaration to share with the assessed entity — surfaced in the engagement letter and the client portal, and stated plainly here. It is aligned to the PCI SSC “Integrating AI in PCI Assessments” guidelines:

Session Security

Kliper’s session model follows the NIST SP 800-63B AAL2 profile:

• 8-hour rolling sessions with 1-hour refresh granularity
• 12-hour absolute cap — a session cannot be extended past 12 hours without re-authentication
• 30-minute idle timeout — inactive sessions are logged out

Sessions are cookie-based (HTTP-only, secure) — tokens are never stored in localStorage.

Multi-Tenant Isolation

Kliper enforces strict tenant isolation at every layer:

• Database — every query is scoped to the user’s current organization via the org_id foreign key. There is no mechanism to query across organizations.
• Storage — file paths are prefixed with the organization ID. Signed download URLs are scoped per organization.
• API — the x-organization header is validated on every authenticated request. Requests without a valid organization context are rejected.
• RBAC — roles (Admin, Manager, Assessor, QA, Viewer) with fine-grained permissions per resource type and action.

Audit Trail

Every state change in Kliper is recorded in the audit log:

• Who — user ID, name, email.
• What — action type (created, updated, deleted, reviewed, approved).
• When — ISO 8601 timestamp.
• Where — IP address, user agent string.
• Detail — old value and new value snapshots for data modifications.

Audit logs are immutable and queryable from the Admin Dashboard. They are designed to withstand QSA peer review and PCI Council quality assurance inquiries.