Security at PearFare
This page describes how PearFare protects client data. It covers how the system is built and run, and where its limits are. Everything here reflects how the system runs as of the effective date. If our practice changes, this page changes with it.
01Security philosophy
The team that built this system is the team that secures it. The architecture described here is the architecture running in production, and no undisclosed downstream vendor holds your data.
Three ideas drive the design.
Single tenant by time. Customer isolation comes from hardware we own and from scheduling. Your data is present in readable form on our systems only while your batches are processing. At all other times, the volume holding it is unmounted and its contents are encrypted at rest, so no process on the host, including any third-party container, has a readable view of it. The volume is mounted again only to process your batches. A stolen API key does not change this: keys can submit batches and read status, nothing more.
Constrained output. Our extractors generate tokens inside your JSON schema, and every record is validated again after generation. These two checks make it impossible to deliver a malformed record. Details in section 7.
Small attack surface. The web frontends run no analytics and no tracking cookies. The marketing site is static pages. The client portal adds a small sign-in service at the Cloudflare edge, and the only cookie we set is its strictly necessary session cookie. Our GPU servers accept no inbound connections from the internet, there is no public-cloud compute, and all client processing happens at one facility. Administrative access is by SSH key only, with passwords disabled.
02At a glance
| Control area | What we do |
|---|---|
| Compute | GPU servers PearFare owns outright, at one privately controlled facility in Wisconsin. No public-cloud compute. |
| Web frontends | Marketing site and client portal are served from Cloudflare Pages; the portal's account service runs at the Cloudflare edge. No analytics; the only cookies are the portal's session cookie and strictly necessary Cloudflare security cookies. |
| Network edge | TLS 1.3 terminates at the Cloudflare edge, behind a managed WAF and DDoS mitigation. |
| Origin exposure | Traffic reaches our servers over a tunnel our servers establish outbound. No inbound ports open to the internet. Origin IP not published in DNS; our hostnames resolve to Cloudflare. |
| Encryption at rest | All disks encrypted. Client data lives on dedicated encrypted volumes. |
| Data availability | Client volumes are mounted only while a batch is processing. Otherwise unmounted, with contents encrypted at rest. |
| Edge staging | Batches uploaded through the portal, and finished result files, are staged in Cloudflare object storage, encrypted at rest, on the way to and from PearFare hardware. Staged copies are removed within 14 days. |
| Retention | Purge 14 days after delivery, or immediate purge on delivery confirmation (zero-retention option). Scratch space scrubbed between batches. |
| Backups | Client data is never written to backups. System configuration and code are backed up; client data is not. |
| Tenancy | When a host is not processing client data, its spare GPU capacity may run third-party containers. Never concurrent with client-data processing on the same host. Containers cannot reach client volumes, which are unmounted and encrypted whenever third-party work could be present on that host. |
| Administrative access | SSH key pairs only. Password authentication disabled at the OS level. No shared accounts. |
| API keys | Batch submission and status reads only. No administrative capability. |
| Payments | No card data stored, ever. Stripe processes payments when billing goes live. |
| Output integrity | Schema-constrained generation plus independent post-hoc validation. Failed pages are flagged and unbilled. |
| Logging | Access and batch logs retained roughly 90 days. |
| Incident notice | Affected clients notified no later than 72 hours after we confirm an incident affecting their data. |
| Vulnerability reports | Email pilot@trypearfare.com with "SECURITY" in the subject. Acknowledged within 72 hours. Safe harbor, no bounty. |
03Infrastructure & network
Owned bare metal, one facility
All client processing runs on GPU servers PearFare owns outright, at a single privately controlled facility in Wisconsin. We do not rent compute, and no public-cloud instance touches your batch. Your workload never runs under a shared hypervisor or on hardware another party controls.
Web frontends
The marketing site is static pages served from Cloudflare Pages, with no analytics and no cookies of its own. The client portal is also served from Cloudflare Pages, with a small account service running at the Cloudflare edge and account records in Cloudflare's edge database. That service stores account, session, and batch status records. Batch files uploaded through the portal, and finished result files awaiting download, are staged in Cloudflare object storage, encrypted at rest, until a PearFare node retrieves the batch and until you download the results. Staged copies are removed within 14 days. Passwords are stored only as salted, key-strengthened hashes with a separate server-held secret mixed in, never in plain text. Sign-in is protected by Cloudflare Turnstile, per-address rate limits, and automatic account lockout, and sessions use a secure, HttpOnly cookie tied to a server-side record we can revoke at any time. Cloudflare may additionally set strictly necessary security cookies, as described in our privacy policy.
The path from you to us
API traffic terminates TLS 1.3 at the Cloudflare edge, where a managed web application firewall and DDoS mitigation sit in front of everything. From the edge, traffic reaches PearFare servers over a tunnel that our servers establish outbound. As a result, our servers accept no inbound connections from the internet, and the origin IP is not published in DNS: the hostnames you connect to resolve to Cloudflare.
Because TLS terminates at the Cloudflare edge, Cloudflare handles API traffic in transit. Cloudflare is a service provider and is listed as one in section 5.
Outbound traffic we originate
Our servers originate outbound traffic of three kinds: the tunnel to the Cloudflare edge described above, routine system traffic such as software updates, and Managed Collection fetches. Under Managed Collection, PearFare retrieves publicly accessible pages at a client's instruction. These fetches are ordinary outbound HTTP requests from PearFare infrastructure, made at controlled request rates. They carry no client credentials, do not authenticate to the sites being fetched, and do not bypass any access control. A page that requires a login or is otherwise not publicly accessible is not collected.
04Data protection & lifecycle
Encryption and the mounted-only rule
Every disk in the facility is encrypted at rest. Client data additionally lives on dedicated encrypted volumes that are mounted only while your batches are processing and remain unmounted otherwise. When your batch is not running, your data sits encrypted on an unmounted volume: no process on the host has a readable view of it, and it becomes readable again only when the volume is mounted to process your next batch.
Lifecycle of a batch
- You upload scraped pages through the portal or API, or we collect them for you from publicly accessible sources you specify (Managed Collection, described in the terms).
- Your batch is processed as it arrives. Your volume is mounted for processing and unmounted when the batch completes.
- Validated JSON is delivered within 12 hours of submission.
- Your data is retained for at most 14 days after delivery, then purged.
- Zero-retention option: confirm delivery and we purge immediately instead of running the 14-day clock.
- Batch scratch space is scrubbed between batches.
Backups
Client data is never written to backups at any point in its lifecycle, so when a purge completes, no copy remains in any backup set, snapshot, or archive tier. This has a trade-off: once your data is purged, we cannot recover it, and re-running a batch means re-submitting it. System configuration and code are backed up so we can rebuild the service. Client data is not in those backups.
What we collect about you as a customer, and why, is covered in our privacy policy.
05Tenancy & isolation
We own more GPU capacity than client processing uses around the clock. When a host is not processing client data, its spare capacity may run third-party compute workloads in isolated containers through a GPU marketplace. This keeps owned hardware economical.
Two rules govern this arrangement:
- Never concurrent. Third-party workloads never run at the same time as client-data processing on the same host.
- Never reachable. Third-party containers cannot reach client volumes. Whenever third-party work could be present, those volumes are unmounted, and the data on them is encrypted at rest. Even in the event of a container escape, no client filesystem is mounted.
To be explicit about scope: third-party containers do run on our hardware, on hosts that are not processing client data and with client volumes unmounted. And we do use service providers: Cloudflare provides edge delivery, WAF, DDoS mitigation, static hosting, and encrypted object storage that stages portal batch uploads and result files, and Stripe will process payments when billing goes live.
Whenever your data is readable on a host, that host is doing client work and nothing else.
06Access control
Administrative access to PearFare systems is by SSH key pairs only. Password authentication is disabled at the operating-system level. This removes password phishing, guessing, reuse, and credential stuffing as attack vectors.
Least privilege is structural: there are no shared accounts, every credential maps to a named person, access to client data is limited to a short, named list of people, and credentials are revoked when no longer needed.
Client API keys are scoped narrowly. A key can submit batches and read batch status. It carries no administrative capability and cannot change retention settings or reach anything beyond the batch interface.
We never store card data. When billing goes live, payments will be processed by Stripe, and card details will be held by Stripe. Commercial terms are in our terms of service.
07Application & model integrity
Extraction output is generated inside your schema. During decoding, the model's next-token choices are constrained to those consistent with the JSON schema you defined. An unclosed brace, a wrong type, or an off-schema field cannot be produced.
Every record is then validated against the schema a second time, after generation, by an independent post-hoc validator. Between constrained generation and post-hoc validation, a malformed record cannot be delivered.
Pages that fail extraction go through a repair pass. If a page still fails validation after repair, it comes back to you flagged, and it is never billed.
Constrained decoding guarantees structure. It does not guarantee that the values inside that structure are correct: a hostile or garbled input page can still produce wrong values in a valid shape. For that reason, pilot reports score field-level accuracy on your own pages.
08Monitoring & logging
Access logs and batch processing logs are retained for roughly 90 days and then deleted. They exist to establish what happened and when. During an incident we use them to reconstruct scope, and in normal operation we use them to verify that batches ran as the portal reports.
We keep the retention period short on purpose. Logs are useful for investigation, and retaining them longer than needed adds risk without adding value.
There is no 24/7 security operations center. Monitoring is automated, and alerts go directly to an engineer rather than through a queue.
09Incident response
Incident response follows a fixed order: we contain the incident, assess its scope, and then notify affected clients.
We will notify affected clients without unreasonable delay, and no later than 72 hours after we confirm an incident affecting their data. Notice will tell you what happened, what data was involved, what we have done about it, and what we recommend you do.
Where an incident involves personal information covered by Wisconsin law, we also comply with Wis. Stat. § 134.98, including its requirement to notify affected individuals within 45 days. Contractual remedies and obligations that sit alongside these commitments are in our terms of service.
The engineers who operate the system handle containment, assessment, and client notification directly.
10Responsible disclosure
If you find a vulnerability in anything PearFare operates, we want to hear about it, and we want reporting to be safe for you.
How to report
- Email pilot@trypearfare.com with "SECURITY" in the subject line.
- Include what you found, where, and steps to reproduce it. A proof of concept helps.
- An engineer will acknowledge your report within 72 hours.
Safe harbor
We will not pursue or support legal action against researchers who act in good faith and within this policy. We consider good-faith security research conducted under this policy to be authorized, and we waive any restriction in our terms of service that would otherwise prohibit it, to the extent the research complies with this policy.
Acting in good faith means:
- Do not access, modify, or destroy data that is not yours. If you hit client data, stop and report immediately.
- Do not degrade the service. Processing runs around the clock and carries real client workloads.
- Stop once you have enough to demonstrate the issue. Do not escalate further to demonstrate broader impact.
- Give us reasonable time to fix the issue before disclosing it publicly.
- Do not demand payment as a condition of disclosure.
No bug bounty
We do not run a bug bounty program, and there is no payment for reports. What we offer is a fast, direct human response, and a fix when the report identifies a real issue.
security.txt
We publish a machine-readable disclosure pointer per RFC 9116 at https://trypearfare.com/.well-known/security.txt. Its contents:
Contact: mailto:pilot@trypearfare.com
Expires: 2027-07-16T00:00:00Z
Preferred-Languages: en
Policy: https://trypearfare.com/security/11Security reviews
Prospective and current clients can review these controls directly. We answer security questionnaires in writing, walk your team through the architecture on a call, and put the commitments that matter to you into the contract.
12Questions & contact
Questions about anything on this page go directly to an engineer.
- Security questions, questionnaires, and architecture reviews: pilot@trypearfare.com
- Vulnerability reports: same address, with "SECURITY" in the subject. See section 10.
- How we handle personal data: privacy policy.
- Contractual commitments, including SLA credits: terms of service.
This page is effective as of July 20, 2026. When our practice changes, the page and its effective date change with it.