Security and privacy

This document is for security officers, data protection officers and employee representatives. It explains what Klipsu Sentinel processes, who can see what, and how it is protected.

Design principles

1. No clipboard plaintext on the server. Clipboard sync is end-to-end encrypted by the devices, and detection runs on the device.
2. Minimum necessary reporting. A finding contains a masked match, masked the way the rule specifies, plus metadata. Sentinel re-checks every masked value and withholds any that does not conform.
3. Evidence only with a reason. The full matched clip stays sealed on the device. It is uploaded only for a written investigation request, and it can be read only with a passphrase Sentinel never stores.
4. Everything is accountable. Administrative actions are written to a tamper-evident audit log.
5. Your infrastructure. Sentinel runs on your servers with your database and makes no outbound connections except the integrations you configure.

Data flows

A step-by-step walkthrough is in How it works.

What the organisation can and cannot see

Data	Visible to the organisation?
Clipboard history synced between an employee's devices	No. Encrypted with a key derived from the employee's recovery phrase; only their devices hold it.
Content of copied text that matched no rule	No. Never leaves the device.
Findings: rule, severity, masked match, source application, content type and length, device, person, time, actions taken	Yes, to console roles. With pseudonymisation on, analysts see a pseudonym instead of the name and email.
Sealed evidence: the matched clip (up to the rule's size limit)	Only after a written request, upload by the device and opening with the evidence passphrase; each step is audited. It is deleted from the device after the rule's retention period.
Device information: name, platform, OS and app version, last check-in, IP address of the last request, policy version, capture state	Yes.
Enrollment: email address, display name, group	Yes.
Images and files in sync	No. Stored encrypted; Sentinel cannot read them. Detection covers text.

Cryptography

Purpose	Mechanism
Transport	TLS 1.2+ (your certificates)
Clipboard sync (device side)	AES-256-GCM with the employee's vault key (derived with Argon2id from a 24-word recovery phrase); Sentinel stores ciphertext only
Device authentication	Per-device Ed25519 key; every request is signed over method, path, timestamp and body, with a 5-minute window and replay protection
Policy integrity	Policy bundles signed with Ed25519; devices pin the organisation's signing key at enrollment and reject unsigned, tampered or rolled-back bundles
Sealed evidence	HPKE (RFC 9180): X25519, HKDF-SHA256, AES-256-GCM, bound to the evidence id and device id. The private key is encrypted with a key derived from the evidence passphrase (Argon2id); the passphrase is never stored.
Secrets at rest on the server	Signing keys, two-factor secrets, integration secrets and internal keys are encrypted with AES-256-GCM under the key-encryption key (key file), with purpose-bound subkeys (HKDF-SHA256). The key file can be rotated.
Admin passwords	Argon2id (64 MiB, 3 iterations); 12–256 characters, common passwords rejected; lockout after 5 failures
Two-factor authentication	TOTP (RFC 6238), replay-protected; can be required for all admins
Sessions	Random 256-bit tokens stored as SHA-256 hashes; HttpOnly, Secure, SameSite=Strict cookies; CSRF tokens; idle and absolute timeouts; a new token after the second factor
Audit log	Each entry is chained with HMAC-SHA256 to the previous one; the chain is verified in the console
Enrollment codes and tokens	High-entropy random values stored as hashes; enrollment links use 130-bit tokens
Media URLs	Short-lived HMAC-signed URLs bound to the person, object and size

Access control and accountability

• Four roles with least privilege (owner, admin, analyst, auditor); see the Signing in and roles.
• Sensitive operations require re-entering the password: license, keys, admin role changes, password and two-factor resets.
• The audit log records actor, IP address, user agent, action, target and details for sign-ins (including failures and lockouts), rule and settings changes, enrollment and revocation, triage, evidence requests, uploads and openings (with purpose), key and license operations. Auditors can verify and export it but cannot change anything.
• Integration payloads exclude masked matches unless the integration is explicitly configured to include them.

Retention and deletion

Data	Default	Configurable
Findings	365 days	yes
Alerts	730 days	yes
Audit log	7 years	yes (the chain stays verifiable after purges)
Evidence requests and uploaded sealed evidence	30 days	yes
Sealed evidence on devices	per rule (e.g. 14 days)	per rule
Integration delivery records	30 days	yes
Deleted sync items (tombstones)	30 days	yes
Sessions, enrollment links, nonces, pairing sessions	until expiry	fixed

Revoking a device stops its access immediately. Sync data remains until the person is removed.

Threat model and limitations

Protected against

• Compromise of the Sentinel server or database alone: an attacker gets ciphertext for sync data, masked findings and sealed evidence. Evidence cannot be opened without the passphrase; server-side secrets need the key file.
• Stolen or leaked admin passwords (two-factor authentication, lockout, audit).
• A malicious network or proxy tampering with policies (signed bundles, pinned keys) or replaying device requests.
• Quiet changes to the audit history (hash chain verification).

Not protected against, by design

• A user who modifies or replaces the Klipsu app can suppress findings. Sentinel is a visibility and prevention tool for the common path, not a containment guarantee against a determined insider.
• Content an employee retypes, photographs or copies outside Klipsu (for example when capture is paused, if you allow pausing).
• Detection quality depends on the rules; review false negatives and false positives with the test bench.
• Someone who holds both the evidence passphrase and console access can read requested evidence; that is the purpose of the role, and it is audited. Use split custody for the passphrase.

GDPR and works council notes

These notes help your own assessment; they are not legal advice.

• Roles: your organisation is the controller for the data Sentinel processes on your infrastructure. Lygon Software does not receive this data.
• Data minimisation: detection on the device, masked findings, evidence only on documented request.
• Transparency: managed devices show a notice (configurable text) and can notify employees about evidence requests. A template for your employee notice is in Employee notice template.
• Purpose limitation and access: role-based access, pseudonymisation for analysts, re-authentication for sensitive actions, audit log.
• Retention: configurable per data type (see Retention and deletion).
• DPIA inputs: this document, the rule list (exportable from the console) and the retention settings.
• Employee participation: many jurisdictions require consultation before monitoring tools are introduced. The rule list, masking and evidence process can be agreed with employee representatives before rollout.

Next steps

• Employee notice template
• Keys and secrets
• Audit log