---
title: "Security & AI Trust"
description: "How Kliper protects evidence integrity, scans for malware, and ensures responsible use of AI."
version: "en"
---
> Documentation Index
> Fetch the complete documentation index at: https://docs.kliper.dev/llms.txt
> Use this file to discover all available pages before exploring further.
# 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.
> **Note**
>
> Integrity verification is non-destructive and read-only. It does not modify the file. The verification timestamp is recorded in the file's metadata for audit purposes.
### What the Assessor Sees
| Field | Value |
|---|---|
| **Stored Hash** | `a3f2b8c1d4e5...` (64-char hex) |
| **Current Hash** | Recomputed on verification |
| **Integrity Status** | `Verified` or `Tampered` |
| **Verified At** | ISO 8601 timestamp |
## 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:
1. **Static Analysis**
Before any scanning, the file undergoes static validation:
- **MIME type check** — blocked types include executables (`.exe`, `.dll`), scripts (`.bat`, `.sh`, `.ps1`), Java archives (`.jar`, `.class`), and 30+ other dangerous MIME types.
- **Extension check** — 40+ blocked extensions including `.exe`, `.dll`, `.bat`, `.cmd`, `.vbs`, `.ps1`, `.msi`, `.scr`, `.lnk`, `.hta`, and more.
- **Magic bytes inspection** — the first bytes of the file are compared against known executable signatures (PE/MZ headers, ELF binaries, Mach-O binaries, Java class files). This catches files that have been renamed with a safe extension but contain executable content.
- **MIME mismatch detection** — warns when the declared MIME type does not match the file's actual content signature.
Files that fail static analysis are immediately rejected with a `422` status and a `quarantined` scan status. They are never written to storage.
2. **ClamAV Antivirus Scan**
The file is written to a secure temporary location and scanned by **ClamAV** (`clamdscan`) with a 30-second timeout. ClamAV is an open-source antivirus engine with regularly updated virus definitions.
- **Clean result** — no threats detected.
- **Infected result** — one or more virus signatures identified. The specific virus names are captured and stored.
- **Error result** — scanner unavailable (logged as a warning). If a required scanner can't complete, the file is held as **`pending`** rather than accepted — a ClamAV failure is not silently treated as clean.
3. **VirusTotal Hash Lookup**
In parallel with ClamAV, the file's SHA-256 hash is checked against the **VirusTotal** database via API. This cross-references the file against 70+ antivirus engines without uploading the file itself — only the hash is sent.
- **Clean result** — `0/N` engines flagged the hash.
- **Infected result** — one or more engines flagged the hash. Detection count, engine names, and threat names are recorded.
- **Not found** — hash not in VirusTotal's database (file has never been scanned globally). This is treated as clean — absence of evidence is not evidence of malice.
### Scan Statuses
| Status | Meaning |
|---|---|
| `clean` | File passed all scan engines with no detections. |
| `quarantined` | File was blocked by static analysis or flagged by one or more scan engines. File is rejected and not stored. |
| `pending` | A scan could not complete (e.g. a scanner was unavailable). The file is **held** in this state — it is not treated as clean. |
### 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:
```json
{
"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:
Accepted file types
- **Documents** — PDF, DOCX, DOC, XLSX, XLS, PPTX, PPT, VSDX
- **Images** — PNG, JPG, JPEG, GIF, BMP, TIFF, SVG, WebP
- **Text** — TXT, CSV, JSON, XML, YAML, LOG, MD, HTML, SQL, CONF, INI
- **Certificates** — PEM, CRT, CER, KEY, PUB, CSR, P12, PFX
- **Archives** — ZIP (inspected for Java archives)
- **Logs** — EVTX (Windows Event Logs)
Blocked file types
- **Executables** — `.exe`, `.dll`, `.com`, `.scr`, `.pif`, `.so`, `.dylib`
- **Scripts** — `.bat`, `.cmd`, `.vbs`, `.vbe`, `.js`, `.jse`, `.ps1`, `.sh`, `.bash`, `.csh`
- **Windows system** — `.msi`, `.msp`, `.mst`, `.cpl`, `.hta`, `.inf`, `.reg`, `.scf`, `.lnk`
- **Java** — `.jar`, `.class`
- **Shell** — `.ws`, `.wsf`, `.wsc`, `.wsh`
## Automatic Metadata Extraction
On upload, Kliper automatically extracts metadata from supported file types to provide assessors with a preview before opening the file:
| File Type | Extracted Metadata |
|---|---|
| **PDF** | Page count, word count, text preview (first 500 chars), document metadata |
| **Word (DOCX/DOC)** | Word count, text preview |
| **Excel (XLSX/XLS)** | Sheet names, row/column counts, header names |
| **PowerPoint (PPTX)** | Slide count, text preview from first slide |
| **Visio (VSDX)** | Page count, text labels extracted from diagram elements |
| **CSV** | Column headers, row count, first 3 rows as preview |
| **Images** | Format, file size |
| **Text/Config files** | Line count, word count, text preview |
| **Certificates (PEM)** | Certificate type (certificate, private key, public key, CSR) |
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](/guides/cortex-ai#choosing-your-ai-provider). A self-hosted platform profile also remains available for deployments with strict data-residency requirements.
> **Note**
>
> Cortex is an **opt-in** capability — an organization admin must enable it. Until then, Cortex run endpoints return a "feature disabled" response.
### 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](https://openai.com/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:
> **Note**
>
> This assessment is conducted with the assistance of Cortex, an AI tool built into Kliper. Cortex helps your assessor work more efficiently — it drafts narratives, summarizes uploaded evidence, and answers PCI DSS questions — always under the assessor's review. **Cortex does not make any compliance decision: your Qualified Security Assessor reviews and approves every finding and determination.** To protect your data, cardholder data and other sensitive information are redacted before any AI processing, and the AI runs on infrastructure that does not use your data for training.
## 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.
Source: https://docs.kliper.dev/security-and-ai-trust/index.mdx