Legal, Compliance & Risk¶

Not legal advice. This is an engineering/business risk map built from primary sources (statutes, court opinions, actual ToS pages), current as of July 2026. Three positions below are flagged litigation-risk, not safe harbor — validate with counsel before any user-facing claim.

The one-table summary¶

Domain	Our strongest position	The line that forfeits it
Platform ToS	No safe harbor exists — all four ATS/platforms ban applicant-side automation, including extensions/overlays	Any automated form-fill/submit is a per-terms breach; mitigation is degree of harm & detectability, not compliance
CFAA	Client-side, user-authenticated ≠ "intrusion" → CFAA is weak against us	The real risk is breach of contract, not CFAA (hiQ paid $500k on contract)
FCRA (verification)	Pure passive conduit of issuer-signed, consumer-held, consumer-presented credentials	Operator does any verification/scoring, or markets as screening → becomes a CRA
Privacy	Local-first = not a controller/"business"; E2EE ciphertext arguably not personal data in our hands (post-SRB 2025)	Any vendor-accessible key, or any cleartext server-side feature
Security	Local-first = no server attack surface; zero-knowledge exceeds cloud-vault norms	SOC 2 Type II becomes a hard gate at enterprise sale
Automation ethics	Consented, rate-limited, human-in-loop, quality-first	Mass-blast: banned, detected, ~2% yield, reputational harm

1. Platform Terms of Service¶

Every major platform's terms prohibit bots, scrapers, browser add-ons, and automated access — including the user's own authenticated activity. These are contract terms; breach means account termination (harming our own users) and a breach-of-contract claim against us. There is no applicant-side "assistive automation" carve-out in any of them.

LinkedIn (User Agreement, "Don'ts"): bans "software, devices, scripts, robots or any other means… (such as crawlers, browser plugins and add-ons…) to scrape or copy the Services" (#2); bans "bots or other unauthorized automated methods to access the Services" (#13); bans circumventing access controls (#3) and account sharing (#1). The Help Center adds a ban on extensions that "modify the appearance of" LinkedIn — so an on-page overlay is prohibited even without scraping.
Workday (Site Terms, §2): bans data-mining/robots/scraping and — broadest clause — "develop or use any applications that interact with our Sites without our prior written consent."
iCIMS: bans "any robot, spider or other automatic device, process, or means to access the Website."
Greenhouse (candidate agreement, §3): bans "automated means, including spiders, robots, crawlers" to access the Services.

Consequence for design: automating form-fill/submit through these platforms is a per-terms violation regardless of consent or rate-limiting. Our mitigation is not "become compliant" (impossible while automating) — it is minimize harm and detectability (human-in-the-loop, human pace, per-user auth, no scraping-for-resale) and move to real partnerships/APIs long-term (Stage 5).

2. CFAA — client-side authenticated automation vs. server-side scraping¶

Good news for a client-side, user-authenticated tool: post-2021 CFAA law narrowed sharply, and the remaining real risk is contract, not the CFAA.

Van Buren v. United States, 593 U.S. 374 (2021) (opinion): adopted the narrow "gates-up-or-down" reading. Liability turns on technological access boundaries, not purpose or terms. Violating a site's use policy is not by itself a CFAA crime. (Footnote 8 left open whether "gates" include contract limits — why scraping law still turns on breaching a technical barrier.)
hiQ Labs v. LinkedIn (9th Cir. 2022): scraping public data (no login) doesn't violate the CFAA — a public site "has erected no gates." But LinkedIn won on breach of contract, and hiQ settled Dec 2022 for $500,000 + permanent injunction + data destruction. The contract sank hiQ, not the CFAA.
Meta v. Bright Data (N.D. Cal. Jan 2024): scraping public data didn't violate the CFAA; Bright Data escaped the contract claim only because it scraped logged-off. That escape hatch is unavailable to an authenticated auto-apply tool — the whole point is acting inside the logged-in session.

Net for WorkWingman: operating inside the user's own authenticated session is not intrusion, so the CFAA theory is weak. Our operative exposure is breach of contract (§1's automation clauses). Reframe mitigation from "is this a crime" (no) to "how do we avoid/limit contract breach and account bans."

3. Verification / trust layer — FCRA surface¶

The trigger: WorkWingman becomes a Consumer Reporting Agency (15 U.S.C. § 1681a(f)) the moment it regularly, for a fee, assembles or evaluates employment/education info in order to furnish it to an employer for a hiring decision. Employment/education verification is squarely consumer-report content (§ 1681a(d)(1)(B)). Consumer consent does not avoid CRA status — Truework, Certn, and Checkr all get consent and are all CRAs.

Obligations that attach if in scope (all settled law): permissible purpose (§ 1681b), standalone disclosure + written authorization (§ 1681b(b)(2)(A)), pre-adverse & adverse-action notices (§ 1681b(b)(3), § 1681m), maximum-possible-accuracy procedures (§ 1681e(b)), 30-day dispute reinvestigation (§ 1681i), retention limits (§ 1681c), and statutory damages of $100–$1,000/violation for willful noncompliance (§ 1681n) — a major class-action category.

Can a user-controlled "verified-claims wallet" stay OUT of scope? Plausible but contested — a litigation-risk position, not a safe harbor. - Supports staying out: first-party/transaction-or-experience exclusion (§ 1681a(d)(2)(A)); consumer-directed disclosure (§ 1681b(a)(2)); if the consumer assembles and discloses and the operator is a pure conduit that never compiles/verifies/scores. - Forfeits it: FTC's "function over form" posture ("just saying you're not a CRA isn't enough" — FTC 2013); operator-side verification/record-pulling (the single biggest in-scope trigger); any trust score/ranking (CFPB Circular 2024-06); marketing it as a screening product. - Architecture: the W3C Verifiable Credentials issuer→holder→verifier model (issuer signs, consumer holds, consumer presents) is the right shape and strengthens the first-party posture — but VC format is not an FCRA exemption. Get specialized FCRA counsel before shipping any verification feature.

Design rule: ship the wallet as a pure passive conduit of issuer-signed, first-party, consumer-presented credentials; operator does no source-pulling, verification, evaluation, or scoring; never market it as a background/eligibility screen.

The local-first architecture is genuinely liability-reducing, and 2025 case law strengthened it.

Resumes are personal data (GDPR Art. 4(1)) and often special-category (Art. 9 — ethnicity, health/disability, religion), needing explicit consent; CCPA treats the same as sensitive personal information.
For data that stays on-device and we never receive, we don't process it at all → neither controller nor processor (GDPR); the user's own use likely falls under the household-activity exemption (Art. 2(2)(c)). CCPA turns on whether we "collect" (receive/access) — if we never receive the resume PI, we don't "collect" it. CCPA is even more favorable to local-first than GDPR.
Zero-knowledge ciphertext in our hands: default rule says encryption is pseudonymisation and stays personal data (Recital 26) — but EDPS v SRB, C-413/23 P (CJEU, 4 Sept 2025) holds identifiability is relative to the holder: a vendor holding only ciphertext, never possessing the user-held key, with no reasonable means to get it, has a strong, now case-law-backed argument the ciphertext is not personal data in its hands. Caveat: still being reconciled with EDPB draft guidance through 2026; the "no reasonable means" claim is factual and must be engineered — any key escrow collapses it.
Breach exposure: GDPR Art. 34(3)(a) and most US state statutes have an encryption safe harbor — a sync-server breach exposing only undecryptable ciphertext likely triggers no individual-notice duty. California's CCPA private right of action ($100–$750/consumer) reaches only "nonencrypted" data, so true E2EE removes that dollar exposure entirely.

Design rule: local-first (no data) is strongest; zero-knowledge E2EE sync is a strong second — but the entire benefit is contingent on true zero-knowledge engineering (no vendor-accessible key). Any cleartext server-side feature (server-side parse/autofill) is a controllership event that pulls full obligations back in. Minimize and separately document the metadata we do collect (account, billing, telemetry).

5. Security posture¶

Buyers and partners expect a zero-knowledge / E2EE architecture where the vendor is cryptographically incapable of reading secrets — an architecture, not a promise. Benchmarks: 1Password (AES-GCM-256, on-device Secret Key that never leaves the client) and Bitwarden (AES-256+HMAC, Argon2id / PBKDF2-SHA256 ≥600k iterations, "cannot access your master password or keys").

State, in vendor terms: (1) AES-256 (GCM) at rest; (2) memory-hard KDF (Argon2id preferred); (3) keys derived/held client-side; (4) an explicit "we cannot decrypt your secrets" claim backed by architecture. Our local-first design is a stronger posture than cloud vaults (no server-side attack surface); an open-source client would make it verifiable. References: OWASP Secrets Management & Cryptographic Storage cheat sheets, NIST SP 800-63B.

SOC 2 Type II (and increasingly ISO 27001) becomes a hard procurement gate the moment we sell to mid-market/enterprise or partner as a credential-handler. It's a "sell-to-enterprise unlock" on the roadmap — not day-one, but plan for it before Stage 2 enterprise deals.

6. Automation ethics / anti-spam¶

Why mass auto-apply dies: it loses on three axes at once — (1) ToS violation → account bans (harming our own users); (2) technically detected & throttled (dwell-time, datacenter-IP flags, rate anomalies); (3) near-zero yield + reputational damage (~90% of employers report more AI spam; ~62% say un-personalized AI resumes are more likely rejected; a bulk-apply pioneer shut its blast feature in 2025 at ~2% interview rate). (Yield stats are directional, from industry/vendor sources.)

Designing tolerable automation (our default): human-in-the-loop at the submit/judgement moment (backstopped by GDPR Art. 22); consent + transparency mid-task (show intent/payload/destination before approval); per-user authenticated sessions, never scraping; built-in rate limits and human-like pacing under platform thresholds; quality over quantity as the core value prop; and auditability of where the human intervened.

Three "not settled law" flags (repeat before any public claim)¶

The FCRA "wallet stays out of scope" theory is a litigation-risk position, not a safe harbor — get FCRA counsel.
The SRB "ciphertext isn't the vendor's personal data" position is strong but still being reconciled with EDPB guidance through 2026.
Client-side authenticated automation avoids the CFAA but not platform contract claims.

Plain-language mirror: ../business-plain/staying-legal-and-safe.md