Skip to main content
PentSeal

Trust & security

Last updated: September 26, 2026

PentSeal is a platform for authorized security testing: it verifies that you control a target, records the scope and authorization you sign, runs checks only inside the agreed window, and produces a defensible report. This page describes the data the service processes, where code runs, and the providers we rely on to operate — including what we cannot yet promise while the product is in pilot.

Data we process

Depending on how you use PentSeal, the service processes:

  • Account information such as your email address, name and role
  • Engagement records: targets you add, the scope you define, rules of engagement, and signed authorization records
  • Ownership-verification tokens you publish for DNS or HTTP challenges
  • Scan results and findings, including CVSS/CWE scoring and severity ratings
  • Evidence you attach to findings, and the hash-chained custody record built from it
  • Integration credentials you add (stored write-only, encrypted, and never returned by the API)
  • Audit-trail events: who did what, when, and to which resource, with sensitive fields redacted
  • Messages you send through the contact, demo and lead forms

We do not intentionally collect payment card data (Stripe holds it) or protected health information. Please do not enter data into the pilot that you are not permitted to store with us — see Terms §4.

Where things run

The application runs on Vercel's serverless platform. The security checks PentSeal performs are built-in implementations that execute inside that runtime and make outbound probes — TLS, DNS, HTTP and port checks — to the targets you have authorized. Scans are not routed through third-party scanning engines, and PentSeal will not run checks against a target until ownership is verified and the engagement's authorization record is in place.

Authorized testing is the product

PentSeal exists to keep testing inside its authorization. Concretely: targets must pass an ownership challenge (DNS TXT or HTTP file) before they can be tested; scope, rules of engagement and the testing window are captured and signed as one record; actions are gated on that record at run time; and an append-only audit trail plus a hash-chained evidence custody record let you demonstrate afterward exactly what was authorized, what ran, and what was found. Testing without provable authorization is treated as misuse, per Terms §1.

How we protect data

  • Authentication via session cookies marked HttpOnly and Secure, with rate limiting and lockout backoff on repeated failures
  • Role-based access control (admin, analyst, viewer) enforced server-side, with every request scoped to the caller's tenant
  • Schema validation on API inputs
  • Field-level encryption (AES-256-GCM) for sensitive fields such as contact details, credentials and verification tokens
  • TLS 1.2/1.3 in transit with HSTS; certificates managed and auto-renewed by the hosting platform
  • Structured audit logging with PII redaction
  • Supply-chain controls: dependency pinning, secret scanning, vulnerability scanning and SBOM generation in CI

Multi-factor authentication and SSO are roadmap items, not features of the current build — we would rather say that than imply they exist.

Data residency

Data is stored in the configured region of the managed Redis provider (Upstash). Regional pinning per customer is a roadmap item, not a current guarantee; if residency is a hard requirement for your engagement, ask us about the current deployment region before you commit.

Providers we rely on

The following services process data on our behalf:

ProviderPurposeData categories
VercelApplication hosting, edge network and serverless runtime for PentSeal itselfRequest metadata; ephemeral platform logs (PII redacted)
UpstashManaged Redis — the primary data store: sessions, engagements, assets, findings, evidence records and audit logsAccount data and customer-supplied engagement data; sensitive fields carry an additional application-layer encryption before storage
StripePayment processing when billing is enabledBilling contact and payment details, held by Stripe. Card details never reach PentSeal servers
GitHubSource control and CI/CD for PentSeal's own codebaseSource code and CI logs; no customer engagement data is intended to reach GitHub

Payment processing is handled by Stripe when billing is enabled; card details never reach PentSeal servers. We keep this table limited to providers actually wired into the service and update it as that changes.

Deleting your data

Engagement, asset, finding and evidence data you enter belongs to you. During the pilot there is no self-serve account deletion; request deletion through the contact page and we will remove your workspace's engagement, finding and evidence records from the datastore and confirm when done.

Report a security issue

Found a security vulnerability in PentSeal? Email security@pentseal.com or use the contact page. We review all good-faith reports and will keep you informed of progress. We do not run a paid bug-bounty program at this time.

Status and incidents

Component health and measured availability history are published on the public status page (JSON feed at /api/status). The uptime figures there are recorded by PentSeal probing itself — they are published as measured evidence, not as an independent attestation. If an incident affects your data, we will notify affected pilot customers directly.

Certifications and compliance

PentSeal does not currently hold SOC 2, ISO 27001, or other third-party certifications. The service is offered in pilot, as described in our Terms of Service. Our compliance program is being built against SOC 2 and PCI DSS control frameworks, and we will update this page as it develops.

Pilot terms

Pilot access is provided for evaluation. Features described as “not yet available” in the documentation may change, and there is no service-level agreement during the pilot. The availability target shown on the status page is an internal engineering objective, not a contractual commitment. Check results and exported reports reflect what was tested at the time they ran — they are not a guarantee that a system is secure, and they are not an attestation or certification.