Security & Privacy

Last updated: 2026-10-25

Jobsite is AI-native. Your data stays yours. Every AI response — whether you're asking about a job's RFI backlog, a crew's cert status, or a change-order trend — flows through the same permission engine as a manual page view. The AI only knows what the asking user is already allowed to see. That is not a policy aspiration; it is a structural property of how the product is built.

This page states what we commit to, names the mechanism that backs each commitment, and is honest about what is on the roadmap but not yet shipped. It is reviewed and updated whenever a commitment changes, a subprocessor changes, or a year passes — whichever comes first.

Last reviewed: 2026-09-24

Our commitments

1. Customer data is never used to train any foundation model.

Jobsite calls three AI providers through their enterprise / API tiers: Anthropic (Claude — LLM backbone for Ask Jobsite, document drafts, and AI intake wizards), OpenAI (Whisper + TTS — audio transcription and voice capture — and image editing for AI illustrations on quotes), and Google Cloud Vertex AI (long-PDF analysis on training research documents). Each provider's contract explicitly prohibits using customer-submitted inputs and outputs to train foundation models. We re-verify this annually; the last sweep ran 2026-05-13.

How: The verbatim no-training clauses from each provider's commercial or enterprise terms are captured below in the Subprocessors section, which also names every other vendor that can reach customer data and states what each one receives. We never use consumer-facing products (ChatGPT web, Claude.ai, Gemini web) in production — only API keys governed by the enterprise agreements cited here.

2. Each customer's data is isolated at the database row level.

Every table that holds project data carries a company_id column. A Postgres policy on every one of those tables enforces that any authenticated query — from the app, from an AI tool call, or from a direct API request — returns only rows where company_id matches the caller's verified identity. There is no path through which a query from one company can return data belonging to another company. This is enforced at the database layer, not just in application code, so an application bug that forgets to filter by company still returns zero rows.

How: Postgres Row-Level Security (RLS), with a auth_company_id() helper function baked into every policy. The isolation is verified automatically on every deployment via Supabase's security advisor sweep (which flags any table missing an RLS policy) and audited in our compliance audit engine, which surfaces policy gaps as findings.

3. AI responses respect the caller's permissions.

Ask Jobsite retrieves data through structured tool calls — not vector search over an unfiltered index. Each tool call is a typed Postgres function that runs under the caller's identity. The AI model never receives raw table rows; it receives the post-permission result set, exactly as if the user had opened that page in the UI. A user who cannot see sub pricing in the dashboard cannot cause Ask Jobsite to surface sub pricing either.

How: The tool-call architecture routes every AI read through the same RLS + permission-gate layer as a manual UI action. See the per-role visibility matrix below for concrete examples of what each role can and cannot reach through Ask Jobsite.

4. Customers retain ownership of all project data.

Your project data — jobs, drawings, RFIs, submittals, daily logs, certifications, incidents, change orders, pay apps, documents, and everything attached to them — belongs to you. Jobsite stores it on your behalf. We do not claim any rights to use, analyze, or re-sell it beyond operating the service. You can export its records or request deletion at any time. We keep your data after you cancel, so it is still there if you come back, and we do not delete it on a timer: when you ask us to delete it, we do so within 30 days of your request.

How: Ownership is established in our Terms of Service. A signed-in company admin can generate a JSON export from Dashboard → Company → Security. It arrives as a download link that works for 24 hours and opens only for a signed-in admin of your company: each click re-checks that you may export, and anyone else who gets the link sees nothing. It holds your company profile and these 23 record tables: workers, jobs, worksites, certifications, training completions, incidents (not their OSHA 300 and 301 recordkeeping fields), inspections (the result and question counts, not each answer), safety observations, toolbox talks, daily logs, RFIs, submittals, change orders, contracts, pay apps, budgets, time entries, company document records and worker document records (each file's name, size and type, not the file itself), customers, proposals, selection categories and selection options. Anything not on that list is left out — for example photos, drawings, uploaded files, signatures (signed dates are included), generated OSHA and safety documents, JHAs, line items (budget, contract, change-order, pay-app and proposal lines), punch lists, schedules, OSHA 300A hours, equipment, estimates, bids and your directory of other companies. Those stay available in the app, and a full export of all your records and files is on the roadmap (see What's next). A self-service hard-deletion path with auditable receipts is on the roadmap too. Today, deletion requests are honored within 30 days via privacy@jobsitecerts.com; sample data exercises the full deletion pattern so the deletion path is tested before it is needed.

5. Every AI answer shows where it came from.

Jobsite never hands you a number or a finding you can't check. Ask Jobsite shows the exact records it pulled. The compliance audit links every finding straight to the cert, incident, or worker it flagged. And every AI-assisted cert issuance or revocation writes a record you can look back on. No black boxes.

How: A standardized “AI-drafted from sources X, Y, Z” citation chip visible on every AI surface — daily log narratives, document drafts, RFI drafts, change order narratives — is on the roadmap. Today's surfaces follow the “AI drafts; humans approve” discipline: no AI surface produces an official record without a named human signer or reviewer taking ownership.

6. No cross-customer retrieval occurs.

Today, Jobsite has no vector store. Ask Jobsite retrieves data through Postgres tool calls that are automatically scoped to the caller's company by RLS. This means cross-customer retrieval is impossible by construction, not merely by policy — there is no code path that assembles context from more than one tenant's data.

How: When Jobsite adds vector search for project documents and drawings in a future release, the binding rule is: embeddings stay in our own Supabase Postgres instance, partitioned per tenant; retrieval queries always carry the caller's identity and results are filtered before reaching the model context; no third-party vector database that lacks an equivalent no-training + per-tenant isolation contract will be used.

7. AI access is bounded by the user's own permissions.

An employee who asks Ask Jobsite a question cannot see more than they can see in the UI. A trade foreman asking about another trade's bid gets “I don't see that on the Jobs you're on.” A subcontractor asking about a competitor's pricing gets nothing. There is no “AI power mode” that grants elevated access — every AI read and every AI write passes through the same permission slice check, the same audit-log row, and the same server action a human UI action would use.

How: Structural guarantee — same tool-call architecture and RLS layer as commitment #3. Worth naming separately because the architectural framing (“AI respects permissions”) and the employee-misuse framing (“employees cannot use AI to bypass what they can see”) reach different buyers in a procurement conversation.

Subprocessors

These are the vendors that store or process customer or prospect data on our behalf — the Tier 1 vendors under our Vendor and Third-Party Risk Management Policy, which requires that each of them appear here. Each entry says what we use the vendor for and what it actually receives, because a list of names on its own is not something you can check. Separately, a handful of third-party scripts run in your browser rather than on our servers; those are listed at the end, under code that runs in your browser, so this page is a complete answer to “who else touches this?” rather than only a complete answer about our servers. Development tooling that never touches customer data — source control, CI — is not in either list.

Supabase (database, authentication, file storage)

What we use it for: Supabase is the platform Jobsite runs on. It is not a service we send a copy of your data to — it is where your data lives: the Postgres database, the authentication system, and the storage buckets that hold your files.

What it receives: everything you put into Jobsite. Every job, worker, certification, drawing, RFI, submittal, incident, daily log, photo, and financial record is a row in that database, and every file you upload is an object in its storage. Sign-in identities — email address, phone number, session — are held by its authentication service.

Controls that apply: the row-level isolation described in commitment #2 is enforced inside this database, not in front of it. Files sit in private buckets and are reachable only through time-limited signed URLs. Storage is encrypted at rest under the provider's own control environment, and the database is backed up daily with seven-day point-in-time recovery.

Vercel (application hosting)

What we use it for: Vercel runs the application. Every page render and every API request executes there.

What it receives: all request traffic, necessarily — the URL requested, the request headers, the originating IP address, and the request and response bodies as they pass through. Whatever the application reads out of the database to render a page is in that response while it is being served. Vercel's runtime logs hold request-level detail for one day at our plan's default; we do not extend that window, and our own security-event record is kept separately so an investigation does not depend on it.

Also in the browser: Vercel's own analytics and page-speed scripts run on every page and report browser performance timings (load and responsiveness measurements). They are given the route pattern — /share/photos/[token] — never the address itself, so a share link whose address is the credential that opens it is not reported to them. They send no form input, no file content, and no project record.

Resend (email delivery)

What we use it for: every email Jobsite sends, and every email sent to a Job's own project address.

What it receives — outbound: the recipient's email address, the subject line, and the full body of the message we generate — worker sign-in links, training links, certification notices, team invitations, approval requests, the weekly compliance digest, and monthly report emails together with their PDF attachments. A sign-in or training link contains a single-use credential, so the delivery provider necessarily carries it; that is inherent to sending a link by email rather than something specific to this provider.

Inbound: a Job can be given its own email address. Mail sent to one — including its attachments, such as a subcontractor's certificate or certificate of insurance — arrives through Resend before it reaches us.

Twilio (SMS delivery)

What we use it for: text messages to workers and managers who have opted in.

What it receives: the destination mobile number and the message text, which is capped at 320 characters — sign-in codes, worker sign-in links, training links, certification-expiry reminders, and onboarding confirmations. Replies to those messages, including STOP and START, reach us through Twilio as well. No project record is sent: the short message text is the entire payload.

Stripe (payments and subscription billing)

What we use it for: two separate things — your Jobsite subscription, and Jobsite Pay, the optional path for paying a subcontractor's pay application.

What it receives — subscription: your company name, the billing contact's email address, our internal identifier for your company, the plan, and the counts your plan is priced on — the number of active workers, or billable session-days. A number, not a roster: the workers themselves are not sent.

Jobsite Pay: a payout account per subcontractor and the amount of each transfer. The subcontractor enters its own identity and bank details directly into Stripe's hosted onboarding — those details never pass through Jobsite and we never store them.

What it never receives: no job, drawing, certification, incident, or document. Stripe sees who is billed and how much, not what the work was.

People Data Labs (business-directory lookup)

What we use it for: filling in a company's public business details during onboarding, so a new account is not an empty form — and, separately, finding contact information for our own sales outreach to companies that are not customers.

What it receives: at signup, the web domain taken from the signing-up manager's work email address; personal email domains are excluded before any request is made. In the same onboarding step, that manager's own email address is used for a directory lookup on themselves — the code path accepts only the signed-up manager's address, so it cannot be run against a colleague. For sales research, a prospect company's name, website and city/state — a business we are considering approaching, which by definition is not a customer.

What it never receives: nothing from inside a customer account. No worker, no project data, and no second user's identifiers.

AI providers. We use the following enterprise-tier AI API providers. No-training commitments from each provider's commercial or enterprise terms are captured verbatim below; source URLs and retrieval dates are included so you can verify against the live documents.

Anthropic (Claude API)

What we use it for: LLM backbone — Ask Jobsite natural-language queries, compliance audit finding translation, document generation (owner letters, safety plans, schedule recovery plans, OSHA reports, etc.), AI intake wizards (job and incident creation, JHA drafting), cost-code voice prediction, manpower forecasting, change order drafting, pay app cover letters, report narratives, and a check on each AI illustration on a quote (it compares the customer's photo with the edited one and flags a changed person or structure).

Anthropic may not train models on Customer Content from Services.

As between the parties and to the extent permitted by applicable law, Anthropic agrees that Customer (a) retains all rights to its Inputs, and (b) owns its Outputs. Anthropic disclaims any rights it receives to the Customer Content under these Terms. Subject to Customer's compliance with these Terms, Anthropic hereby assigns to Customer its right, title and interest (if any) in and to Outputs. Anthropic may not train models on Customer Content from Services. “Inputs” means submissions to the Services by Customer or its Users and “Outputs” means responses generated by the Services to Inputs (Inputs and Outputs together are “Customer Content”).

OpenAI (Whisper + TTS)

What we use it for: Audio transcription (Whisper) and text-to-speech (TTS) for voice capture on worker and manager surfaces — dictating daily logs, voice-to-schedule commands, and speak-to-draft document commands.

One path runs from your browser: the live voice conversations (voice onboarding, and asking Jobsite by voice) use OpenAI's realtime API, which browsers can only reach directly. On those surfaces your microphone audio streams from your device to OpenAI over a peer connection our servers set up but do not sit in the middle of. The session credential for it is minted server-side, is short-lived, and is scoped to that one conversation.

  • Source: openai.com/enterprise-privacy
  • Retrieved: 2026-05-13
  • Default posture: Training off by default — we never opt in to model-improvement programs.

We do not train our models on your data by default

You own and control your data

You own your inputs and outputs (where allowed by law)

OpenAI Images (AI illustrations on quotes)

What we use it for: The “See it” preview on a quote or proposal: a person at the contractor picks a photo of the customer's home (one the customer sent with their request, a job-site photo, or one the technician takes on the visit) and the products being quoted, and an AI-edited illustration of the work is made from them. It is labelled “AI illustration” and reaches a customer only after that person attaches it to the quote.

What it receives: the customer's home photo, the product photos from the contractor's catalog, and a text instruction describing the change to make (the product names and attributes, and any note the contractor typed). Sent from our servers to OpenAI's Images API (POST /v1/images/edits). We add no customer name, address or contact details to the request; a note the contractor types is sent as written, and the photo shows whatever is in it.

  • Source: platform.openai.com/docs/guides/your-data
  • Retrieved: 2026-07-17 (our annual contract sweep, which now covers this endpoint; the next sweep re-reads it)
  • Default posture: Training off by default — OpenAI's published terms say data sent to its API is not used to train or improve its models unless the customer explicitly opts in, and we never opt in. The verbatim clause is captured in our security reference and re-verified at each sweep.
  • Retention: OpenAI's published terms say API abuse-monitoring logs, which can contain prompts and responses, are retained for up to 30 days by default, unless longer retention is required by law or reasonably necessary to protect its services or a third party from harm. Eligible customers can have their content excluded from those logs through Zero Data Retention. We have not been granted Zero Data Retention, so the default applies to these photos.

Google Cloud Vertex AI / Gemini API

What we use it for: Long-PDF analysis on training research documents and content library material where the document length exceeds efficient Claude context windows.

As outlined in Section 17 “Training Restriction” in the Service Terms section of Service Specific Terms, Google won't use your data to train or fine-tune any AI/ML models without your prior permission or instruction. This applies to all managed models on Vertex AI, including GA and pre-GA models.

Note: Google's data governance page also describes prompt logging for abuse monitoring under Google Cloud Platform Terms. Jobsite never requests an exception from this standard abuse-monitoring posture; if zero data retention is required for a specific deployment, contact us.

Sentry (error monitoring)

What we use it for: When a page or a background job fails, the error report is forwarded to Sentry so an engineer sees it and can fix it. Sentry is not an AI provider, and it is not a copy of your data — it receives error reports, nothing else.

What it receives: the error type and message, the code stack frames that produced it, the route template the request hit (for example /dashboard/jobs/[jobId]/change-orders — the template, never the concrete URL), the error digest, and the internal record identifiers already present in the failing code path.

What it never receives: the contents of your project records. No job, cert, document, incident, financial, or worker record is sent to Sentry. What identifies a failure is machine values — a record's internal id, a storage key, the name of the query that failed — not the data inside the record. Before anything leaves our servers it passes through a scrubbing layer that removes email addresses, phone numbers, access tokens, session cookies, API keys, and the credential inside any share link. That scrubbing is not a review convention we hope someone remembers: the error forwarder accepts only a payload the scrubber itself produced, so wiring it ahead of the scrubbing does not compile.

  • Browser: we do not run Sentry's browser SDK. Nothing is collected from your device, and no page URL you visit is sent — which matters because a share or sign-in link carries its own access credential in the URL.
  • Scope: production only — and enforced in the code, not by a setting someone has to get right. A preview or development deployment forwards nothing even if it inherits the configuration.
  • Retention: 30 days. Our account is on Sentry's free Developer plan, whose published error-retention window is 30 days. We do not extend it, and we do not archive forwarded errors anywhere else.

Third-party code that runs in your browser

The services above receive data from our servers. These four run as scripts on the page itself, so what they see comes from your browser directly — including the IP address you are browsing from. None of them receives the address of the page you are on: analytics is given the route pattern instead, and the browser is configured to tell a third-party host only which site a request came from, never which page. None of them receives a project record or a file. One of them — the address autocomplete — necessarily receives what you type into that one field, and its entry says so; the rest receive nothing you type anywhere. They are listed here because “our servers do not send it” is not the same statement as “nobody else sees it,” and the second one is what you actually asked. Every external origin any of them may contact is pinned in the application's Content Security Policy, so the set is enforced rather than promised.

  • Google Analytics — visit measurement on our public pages only: the marketing site, pricing, help, the demos and sign-up. It does not load on signed-in pages, the worker app, the sign-in screen or share links. It does not receive the address of the page being viewed. What it receives is the route pattern — /rfi/respond/[token], never the link itself — because many of our links are share links where the address is the credential that opens them. The query string is stripped to marketing-attribution parameters only, and the referring page is reduced to the site it came from. The remaining signals are the standard ones: browser, and approximate location derived from IP.
  • Mapbox — the worksite map and the address autocomplete field. It receives the coordinates being displayed and the text typed into an address search, which is what makes autocomplete work.
  • Cloudflare Turnstile — the bot check on the sign-in and sign-up forms. It is a challenge widget rendered beside the form and returns a pass/fail token; the credentials you type into the form are not sent to it.
  • YouTube and Vimeo — embedded video players. Vimeo hosts the training module videos a worker plays. Product and how-to videos on our public pages use YouTube's no-cookie player domain; the Watch Room uses YouTube's standard player instead, because it measures how much of a safety video a worker actually watched and only the standard player reports that back. Each host sees the request for the video being played, as any embedded video does.

Vercel's analytics and page-speed scripts also run in the browser; they are described in the Vercel entry above, with the rest of what that vendor receives.

What each role can see through Ask Jobsite

The following examples reflect the actual permission gates enforced in the system today. “Cannot see” means the AI returns “I don't have access to that on your account” rather than silently omitting the data — so the boundary is visible to the user asking.

Project manager / company owner (full access)

  • Every job, every worksite, every worker on the company roster.
  • Full cert and compliance posture across all workers and crews.
  • All incidents, JHAs, and safety documentation across all sites.
  • All drawings, RFIs, submittals, and document sets.
  • Full financial view: budgets, contracts, change orders, pay apps, labor by cost code.
  • Subcontractor pre-qualification, bid packages, and marketplace listings.
  • Schedule baselines, variance, and recovery plans across all jobs.

Trade foreman (job-scoped access)

  • Their assigned jobs only — asking about a job they are not on returns “I don't see that on the Jobs you're on.”
  • Their crew's cert and compliance status on their jobs.
  • Their site's drawings, RFIs, daily logs, and incidents.
  • Cannot see: other trades' bids, sub pricing, labor dispute documentation, financial data, or workers on jobs they are not assigned to.

Owner rep / customer portal (reporting views only)

  • Daily log summaries shared by the GC for their jobs.
  • Schedule status and milestone views the GC has enabled for them.
  • Financial dashboards the GC has explicitly shared (e.g., budget-to-actual summaries).
  • Cannot see: internal cost coding, subcontractor pricing, labor dispute documentation, worker PII, or any data the GC has not explicitly shared.

Subcontractor (scope-bounded access)

  • Their own scope of work, their assigned RFIs, their bid submission.
  • Their pre-qualification status on the general contractor's company.
  • Cannot see: other subcontractors' bids, other subs' scope or pricing, any data outside their specific contract scope.

What's next

We ship trust mechanisms before we publish commitments. These items are on the roadmap but not yet shipped — naming them here means customers can ask about the status rather than discovering gaps in a procurement review.

  • Hard-deletion of customer data with auditable receipts. Today, deletion requests are honored within 30 days via email. A self-service, programmatic deletion path with a confirmation receipt is on the near-term path.
  • A full export, files included. Today's export is a JSON file of your company profile and the record tables listed under commitment #4, and nothing else. A full export that packages all your records and files — including what today's export leaves out, such as photos, drawings, uploaded files, signatures, generated OSHA and safety documents, JHAs, line items, punch lists and schedules — is planned; until then those stay available in the app.
  • SSO / SAML. Single sign-on integration for enterprise customers who manage identity centrally.
  • Per-tenant region pinning. Data residency selection for customers with contractual requirements for US-East, US-West, or EU hosting.
  • BAA option for healthcare-adjacent projects. HIPAA business associate agreement for customers managing health-related occupational records.
  • Customer-managed encryption keys (CMEK). Bring your own key for at-rest encryption of project data.
  • Standardized citation chip on every AI surface. A consistent “AI-drafted from sources X, Y, Z” UI element on daily logs, RFI drafts, document generators, and other AI write surfaces — so provenance is visible on every artifact.
  • assisted_by_ai metadata on audit-log rows. Schema-level flag so audit queries can filter AI-assisted vs. human-authored state transitions.

Enterprise tier — talk to us

A small but high-value tier of customers — federal contractors, healthcare, large industrial, defense-adjacent — needs more than the hosted default. Jobsite's enterprise tier (in development) will include private deployment options: dedicated cloud project, customer-managed encryption keys, optional region pinning, and dedicated database with no cross-tenant infrastructure. If your procurement process requires a VPC, CMEK, or private deployment, reach out at sales@jobsitecerts.com to discuss requirements and timing.

Changelog

This page is reviewed when any commitment shifts, when subprocessors change, or annually, whichever comes first. The annual review is scheduled as a recurring task in our site maintenance calendar.

  • 2026-10-26 — Commitment #4: the data export's download link now opens only for a signed-in admin of your company, re-checked on every click, for every export made from today on; it no longer works for anyone holding it. The stored file can no longer be listed, read, replaced or deleted by other members of your company.
  • 2026-10-25 — Google Analytics now runs on our public pages only. It had loaded on every page, signed-in pages and the worker app included; it no longer loads there, on the sign-in screen, or on share links. Vercel's own analytics, which receive the route pattern only, still cover every page.
  • 2026-10-25 — Added OpenAI Images to the subprocessor register: the AI illustrations on quotes send a customer's home photo, the product photos and a text instruction to OpenAI's Images API. The entry states what is sent and OpenAI's published retention terms, including that Zero Data Retention has not been granted to us. The Anthropic entry now names the check that compares each illustration with the customer's photo.
  • 2026-09-24 — Commitment #4 now says exactly what the data export holds: your company profile and 23 named record tables, through a private link that works for 24 hours, and nothing else — no photos, drawings, uploaded files, signatures, generated OSHA or safety documents, JHAs, line items, punch lists or schedules, and incidents without their OSHA recordkeeping fields. The earlier wording described the export as everything in your account, which overstated it; a full export with files is now listed under “What's next.” It also described the download link as authenticated: generating one needs a sign-in, but the link itself works for whoever holds it. The same commitment now states what happens after you cancel: we keep your data so it is there if you come back, and delete it within 30 days when you ask (our Terms and Privacy Policy say the same).
  • 2026-08-31 — Stopped sending page addresses to the analytics services. Many links in this product are share links where the address is the credential that opens them — an inspection response, a certificate, a customer portal. Google Analytics and Vercel's analytics were reporting the address of every page viewed, those included. They now receive the route pattern only (/rfi/respond/[token]), with the query string reduced to marketing-attribution parameters and the referring page reduced to its site. The entries above are updated to say so.
  • 2026-08-31 — Completed the subprocessor register. It previously listed the AI providers and Sentry only; it now names every vendor that can reach customer or prospect data — adding Supabase, Vercel, Resend, Twilio, Stripe, and People Data Labs — and states for each what it actually receives. Added a section naming the third-party code that runs in your browser (Google Analytics, Mapbox, the sign-in bot check, embedded video players), since “our servers do not send it” and “nobody else sees it” are different claims. Noted that live voice conversations stream from your device to OpenAI directly. Sentry's retention line now gives the real number (30 days) rather than deferring to “whatever our plan sets.”
  • 2026-08-31 — Added Sentry to the subprocessor register. Server errors are now forwarded to an external monitoring service so failures are seen and fixed rather than sitting unread in a log that expires. Sentry receives scrubbed error reports only — never project records — and we do not run its browser SDK, so nothing is collected from your device.
  • 2026-08-09 — Shipped the customer-facing data-export flow named under commitment #4: company admins can generate an authenticated JSON export of their company's main record tables from Dashboard → Company → Security. Removed from “What's next.” (Corrected 2026-09-24: this entry first overstated what the export holds.)
  • 2026-05-13 — Initial publication. Seven commitments named; subprocessor list with verbatim no-training clauses for Anthropic, OpenAI, and Google Cloud Vertex AI; per-role visibility matrix; enterprise tier roadmap pointer; full roadmap naming un-shipped items honestly.