client-encryption-boundary-audit

Audit whether client plaintext is encrypted before upload, persistence, logs, or telemetry.

2|Updated May 6, 2026
One-click install
npx skills add https://github.com/bpcakes/jig-skills --skill client-encryption-boundary-audit-bpcakes
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: client-encryption-boundary-audit
Source: https://github.com/bpcakes/jig-skills/tree/main/plugins/jig-privacy-audit/skills/client-encryption-boundary-audit
Command: npx skills add https://github.com/bpcakes/jig-skills --skill client-encryption-boundary-audit-bpcakes

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Products claiming client-side encryption, E2EE, or zero knowledge can silently leak protected plaintext through serializers, sync queues, logs, telemetry, or local storage. This Skill traces each user-content flow to verify encryption actually happens before data crosses the client boundary. ## Core Features & Use Cases - Boundary Order Tracing: Follows protected fields from plaintext source through encryption, serialization, and submission points with file and line evidence. - Plaintext Sink Detection: Searches logs, telemetry, local databases, caches, search indexes, queues, and third-party SDKs for unencrypted protected content. - Structured Findings: Produces severity-graded findings (CLIENT-ENC-001 style) using a JSON schema and a report template with flow boundary matrices. - Use Case: While reviewing an encrypted notes app, trace the autosave and background sync paths and discover the offline queue persists plaintext before encrypting at send time, reported as a high-severity finding with retest steps. ## Quick Start Audit this repository's create, edit, and sync flows to verify protected note content is encrypted before it reaches serializers, upload clients, local storage, logs, or telemetry, and report findings with file locations.

Frequently Asked Questions about client-encryption-boundary-audit

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I audit client-side encryption claims in an app?

Trace each protected field from its plaintext source through the encryption point, serialization point, and submission or storage sink, recording file and line evidence. Verify encryption precedes serialization and upload, then check logs, telemetry, queues, and local storage for plaintext leaks.

How to verify zero-knowledge claims with static code review?

Static review traces source-to-sink paths and inspects existing tests, marking reachability as confirmed, likely, or unknown. Runtime verification gaps are recorded as limitations; dynamic sentinel capture is only run when testing is part of the authorized task.

Does TLS encryption satisfy a client-side encryption claim?

No. TLS protects transport only and does not stop the service from receiving plaintext if the application sends it. Client-side encryption requires the plaintext to become an authenticated ciphertext envelope before reaching serializers, API clients, or local sinks.

What counts as a plaintext leak in an encrypted app?

Protected content or metadata appearing in API payloads, logs, telemetry, crash reports, local databases, caches, search indexes, or background queues before encryption is a candidate finding. Encoding like base64, gzip, or protobuf is not encryption.

What are the limitations of a client encryption boundary audit?

The audit does not prove primitive correctness, key safety, malicious-update resistance, or endpoint security. Untested platforms, feature flags, minified bundles, and unavailable capture bodies are recorded as limitations, and missing tests are coverage gaps rather than defects.