Security

Peekop includes application cryptography for security-sensitive flows and relies on provider-managed storage protections for the underlying database and file infrastructure.

The repository proves the encryption helper and the token-signing model. It does not, by itself, prove universal application-layer encryption for every stored document, artifact, or database row, so we describe those storage protections conservatively.

Peekop is intended to run behind HTTPS in production. Transport security for the dashboard, signing page, API, and edge routing is primarily enforced by the hosting and proxy infrastructure rather than by application code in this repository.

• Browser ↔ hosted application endpoints over HTTPS in production
• Server ↔ database and provider connections through managed infrastructure
• Outbound webhooks validated for safe public HTTPS targets in production
• Webhook payloads signed with HMAC-SHA256

Every uploaded PDF is hashed with SHA-256 at upload time. The hash is stored alongside the document record. When the recipient submits the signing completion request, the document hash can be compared against the stored value using a timing-safe comparison (crypto.timingSafeEqual), so mismatches between the uploaded document and the submitted signing payload are detected.

Signing links are not opaque UUIDs and are not JWTs. Each link embeds an HMAC-SHA256 signed token whose payload includes the request ID, recipient ID, issuer ID, an expiration timestamp, and a random nonce. Tokens are verified server-side with a timing-safe comparison; tampered or expired tokens are rejected before any database lookup occurs.

• Default token TTL: 30 days, configurable per request (1-365 days)
• Tokens can be revoked instantly via the dashboard's "Void" action — token check fails on the next access
• Protected signing actions only begin after exact recipient email verification moves the request into Verified Access
• Each recipient on a multi-signer request gets a distinct token; one signer's token cannot be used to view or sign on another's behalf
• After completion, the signing link no longer opens another signing session
• Source: packages/core/src/tokens.ts

Peekop records the request journey and related evidence for signing activity, recipient verification, and completion.

Recorded events include:

• Request created, sent, viewed, signed, declined, revoked, expired
• Verified Access recorded before protected signing activity begins
• Recipient-level state transitions (per-signer)
• Email opens, link clicks, reminder sends
• Document hash verification at signing time
• Each event captures: timestamp, IP address, user-agent, and the user or recipient ID responsible

That evidence contributes to the request journey, certificate of completion, and Completion Record associated with a signed request.

Peekop includes several controls commonly expected in U.S. electronic-signature workflows:

• Consent flow: the signer experience presents an electronic-consent step before the signing screen
• Intent: protected signing actions occur inside the signing session after verification and user interaction
• Attribution: a recipient-specific link does not, by itself, grant signing authority. Exact recipient email verification is required before Verified Access and protected signing activity
• Evidence: the request journey can preserve timestamps, recipient activity, IP address, user-agent, and completion artifacts
• Integrity checks: document hash verification helps detect mismatches at signing completion

Whether a specific signature is enforceable depends on the document type, jurisdiction, and how the workflow is used. Peekop is NOT, and does not claim to be, a notary or a Remote Online Notarization (RON) service. For notarial acts you need a commissioned notary; we are not a substitute.

Peekop is multi-tenant: every database row is owned by an organization_id foreign key, and every authenticated query is filtered by the organization resolved from the requesting user's session. There is no admin path that returns documents across organizations.

Public signing endpoints (the recipient-facing pages, which do not require account creation) are scoped to an individual signing request via the HMAC-signed token, not to an organization. Delivery is separate from verification: the token identifies the request, while recipient verification is what moves the request into Verified Access and a protected signing session.

Sender authentication is handled by Supabase Auth. Supported methods at present:

• Magic link (one-tap email link, expires in 60 minutes)
• Email + password (Supabase-hashed with bcrypt, never logged or transmitted to Peekop's servers in plaintext)
• Google OAuth and GitHub OAuth (planned, in active configuration as of May 9, 2026)

Sessions are stored as opaque refresh tokens inlocalStorage with rotating access tokens (default 1-hour TTL). Logging out revokes the refresh token server-side.

Retention and deletion behavior should be treated as an operational policy area rather than a product guarantee unless covered by your agreement with Peekop.

• Signed requests: completion evidence and artifacts remain associated with the request while the account and related records remain active
• Voided / declined / expired requests: request-state evidence can remain visible for operational history
• Deletion requests: contact security@peekop.com for current handling and contractual terms
• Backups and provider retention: managed infrastructure may retain backup copies outside the primary application surface

Peekop relies on a small set of named providers to deliver the service. Each is bound by their own DPA (where applicable) and their own security certifications.

Anthropic processes the rendered images of uploaded PDFs to detect field positions; per their commercial terms they do not train on customer-submitted content.

We will notify customers (via email + a banner in the dashboard) at least 30 days before adding a new subprocessor that handles document content.

In the event of a security incident affecting customer data, we commit to:

• Investigate immediately, with the goal of containment within 24 hours of detection
• Notify affected customers within 72 hours of confirming the incident, including: what was accessed, what was not, what we did about it, and what they should do
• Publish a post-incident report within 30 days describing root cause and remediation
• Cooperate fully with any required regulatory disclosures (state breach-notification laws, etc.)

To report a suspected vulnerability, email security@peekop.com. We do not run a paid bug-bounty program at this stage but will acknowledge in good faith any report we act on.

This is the part of every security page where companies are tempted to imply more than they have. We will be specific.

For carriers and broker-dealers conducting vendor risk assessments, we are happy to complete a SIG Lite or CAIQ questionnaire on request. Email security@peekop.com.

For security questions, vendor evaluation, or to report a vulnerability:

• Security: security@peekop.com
• General: hello@peekop.com