Security at PearFare
This page describes how PearFare protects client data. It covers what we do, how we do it, and what we do not claim. 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 and readable on our systems only during its processing window. Outside that window, the volume holding it is encrypted and unmounted, and it cannot be read by another process, another tenant, or anyone holding a stolen credential.
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 are static pages with no cookies and no analytics. There are no open inbound ports and no public-cloud compute, and all processing happens at one facility. Administrative access is by SSH key only, with passwords disabled. Fewer moving parts means fewer ways in.
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 static pages on Cloudflare Pages. No cookies, no analytics. |
| 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 open inbound ports. Origin IP never exposed. |
| Encryption at rest | All disks encrypted. Client data lives on dedicated encrypted volumes. |
| Data availability window | Client volumes are mounted only during processing windows. Unmounted and inaccessible otherwise. |
| Retention | Purge 14 days after delivery, or immediate purge on delivery confirmation (zero-retention option). Scratch space scrubbed between windows. |
| Backups | Client data is never backed up beyond its retention window. System configuration and code are backed up; client data is not. |
| Tenancy | Outside client windows, spare GPU capacity may run third-party containers. Never concurrent with client-data processing on the same host. Containers cannot reach client volumes. |
| 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. No public-cloud instance ever touches your batch. There is no hyperscaler account to misconfigure and no shared hypervisor between your data and the internet.
Static frontends
The marketing site and the client portal are static pages served from Cloudflare Pages. They set no cookies and run no analytics. There is no server-side session to hijack and no application server behind them to exploit.
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, there are no open inbound ports on our network and our origin IP is never exposed.
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.
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 during processing windows and remain unmounted and inaccessible outside them. When your window is closed, your data is not readable by anything running on the machine.
Lifecycle of a batch
- You upload scraped pages through the portal or API.
- The nightly window opens at 22:00 US Central. Your volume is mounted, your batch is processed.
- Validated JSON is delivered by 8:00 AM Central.
- 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 windows.
Backups
We do not back up client data beyond its retention window. After a purge, 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 windows use around the clock. Outside client processing windows, spare GPU capacity may run third-party compute workloads in isolated containers through a GPU marketplace. This keeps owned hardware economical.
Two rules apply without exception:
- 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.
Two clarifications follow. We do not claim that no third parties ever run on our hardware: outside your window, third-party containers do, with your volumes unmounted. We also do not claim to have no subprocessors: Cloudflare provides edge delivery, WAF, DDoS mitigation, and static hosting, and Stripe will process payments when billing goes live. Both are service providers.
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, no stale credentials, and a short, named list of people who can access client data.
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, not correct values. A hostile or garbled input page can still produce wrong values inside a valid shape. For that reason, pilot reports score field-level accuracy on your own pages. This page promises schema validity; your accuracy report measures correctness.
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.
Incidents are contained, assessed, and written up by the engineers who built the system. Notification comes directly from them, with no escalation chain in between.
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.
- We will acknowledge your report within 72 hours. The reply comes from the engineer who will fix the issue.
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. Nightly batch windows carry 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.
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:00.000Z
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
Every question on this page reaches an engineer directly. There is no tiered support queue.
- 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 16, 2026. When our practice changes, the page and its effective date change with it.