Privacy Policy

Effective November 3, 2026

1. Who we are

Sarcio is operated by Dayne Mentier, a sole proprietor doing business as Sarcio in New Jersey, USA (“Sarcio”, “we”, “us”). This policy covers the sarcio.io website, the Sarcio dashboard and API, and the bug-report widget and other components our customers install (together, the “Service”). Privacy questions and data requests go to privacy@sarcio.io.

2. Our two roles

• Controller. For the people who visit our website, sign up, and use the dashboard as members of a customer's workspace, we decide how their personal data is used, and this policy applies directly.
• Processor. Our customers install the Sarcio widget and other components on their own websites. When a customer's site sends us a bug report, or a customer gives us access to its repositories and trackers, we process that data on the customer's behalf and under its instructions. The customer is the controller. If you use a site that runs Sarcio, read that site's privacy policy and send your requests to its operator; we will help them respond. A data processing agreement is available on request for Enterprise customers.

3. What we collect

• Account data: your name, email address, workspace name and role. Passwords are stored only as argon2id hashes. Two-factor secrets are encrypted at rest, and recovery codes are stored only as digests. If you sign in with Google or GitHub, we receive your verified email address, name and provider account id. When you create a workspace, we record when you agreed to our Terms of Service and this policy, and which version.
• Billing data: your plan, subscription status and the Stripe customer and subscription ids. Stripe collects and holds your payment details; we never see full card numbers.
• Bug reports submitted through the widget on a customer's site: the description the reporter types, the page URL, the selector and HTML of the element they picked (up to 2 KB), recent console errors and warnings, metadata about recent network requests (method, URL, status and timing, never request or response bodies or authorization headers), the browser's user agent and window size, and an optional screenshot. To limit abuse we count reports per IP address using a one-way digest of the address that expires after a day; the address itself is not stored with the report.
• Sarcio noticed, only on a site whose workspace turns it on: the widget also sends what failed on a page view (the kind of failure, a short sample of up to 300 characters such as an error message or a request URL, the page address, and for a failed request its method and status), never what a visitor typed, page content or cookies. To count distinct visitors we keep, per failure, a bounded set of one-way digests of the visitor's IP address and user agent that change every day; the address itself is not stored. When enough visitors hit the same failure, it becomes a bug report.
• Update checks from the WordPress plugin: when an update it checked went wrong, the plugin sends the plugin or theme updated, the versions before and after, which of the site's key pages looked different (each page's address and a short before and after description), and what it did about it. This becomes a bug report, and the owner's later decision is recorded on it.
• Security checks from the WordPress plugin: when someone asks for a check or the site check runs, the plugin sends the slugs and versions of the site's plugins and themes and its WordPress version so we can look them up in our list of known security holes. We use them to answer and do not keep them. To see whether WordPress.org closed a plugin, we ask WordPress.org about that plugin by name only, never which site asked.
• Speed checks from the WordPress plugin: when someone checks a page's speed, the plugin sends that page's address and we pass it to Google PageSpeed Insights to measure it. We keep the result for ten minutes so a repeat check is quick, and never keep the address.
• Your AI app on your sites: when a member uses an AI app through Sarcio's remote connection, we sign each request and pass it to the WordPress site, then pass back the site's answer. We keep one audit entry per call (member, site, tool and outcome), never what was sent or answered.
• Plugin shapes from connected sites: when a plugin's version changes on a site, the WordPress plugin sends the names and argument shapes of the tools, routes and settings that plugin offers, plus the kinds of error Sarcio's own calls to it ran into. For a plugin Sarcio does not know yet it also sends its route paths with their handler names and one-line descriptions, the schemas of its settings and blocks, and the names of its post types, taxonomies and shortcodes. With Learn from other plugins' screens turned on (it is off by default; Sarcio → Settings → Advanced in WordPress turns it on or off), it also sends, when someone saves in another plugin's screens, what kind of save it was, the address or action it went to, the names of the fields it sent, and short fixed words that stayed the same across two saves (such as “save”). It never sends what anyone typed, content, setting values, passwords or personal data. To count how many sites and accounts agree we keep a one-way code per site and per account, never the site's address or key. When a plugin we do not know is in the WordPress.org directory, we read its public releases from there.
• Plugin knowledge and tool search: twice a day a connected site sends the names and versions of its active plugins and theme, and we send back notes on using them. When the WordPress assistant looks for a tool, the plugin sends the words it searched for and that list. We answer from them and do not store them.
• Plugin feedback: when someone deactivates the WordPress plugin, it may ask why, and answering is optional. An answer sends only the reason chosen, any text typed, the plugin and WordPress versions, the site's language setting and whether the site was connected to Sarcio. It never sends the site's address or anyone's name or email, and we do not save the IP address it came from with the answer.
• Plugin compatibility: when the WordPress plugin finds that another plugin on a connected site no longer offers something Sarcio uses, it tells us that plugin's name and version, the WordPress and Sarcio versions and which check failed. It never sends the site's address, content or anyone's details. The site key it carries only limits how often a site can send, and is not saved with the report.
• Sign-up steps: to see where people stop, we count how many sign-ups reach each step (opening the sign-up or Connect page, starting, verifying the email address, reaching payment, creating the workspace and connecting a site), with only whether it began in the WordPress plugin or on our website, which button led there, and the plan chosen. These counts use no cookies and hold no email address, name, workspace or IP address, so they cannot be traced back to anyone.
• Assistant counts: each day we count how often the WordPress assistant uses each of its actions, and what kinds of request it could not help with (such as a refund or a plugin it does not support), named from a fixed list. These counts hold no words anyone typed, no site and no person.
• Page visits: we count visits to this website and to the sign-up and sign-in pages with Umami, hosted on our own server, with no cookies and no personal data.
• Workspace content: sites and their settings, patches, approvals and who gave them, source files read from connected repositories to draft fixes, and writing instructions.
• Integration credentials and linked accounts: tokens for GitHub, GitLab, Bitbucket and Jira connections, stored envelope-encrypted (AES-256-GCM). The Sarcio GitHub App keeps no long-lived token. When a member links their own Git host or Jira account, we keep its login, display name, avatar and account id, and no token unless the workspace turns on acting links and the member opts in, in which case that token is encrypted too.
• WordPress Connect: when a member connects their Sarcio account from the WordPress plugin, we issue that member an access token and a refresh token for the plugin to use. We store only one-way digests of them, with the member, workspace and expiry; the plugin keeps the tokens themselves, encrypted, in that WordPress site's database. Signing out everywhere revokes them.
• Audit and usage data: an append-only audit log of security-relevant actions with the actor, source IP address and time, and AI usage records (token counts per model call).
• Technical data: our servers keep standard request logs (IP address, user agent, requested URL and time) to operate and secure the Service.

We do not use advertising or third-party analytics trackers, and we do not buy personal data.

4. How we use it, and our legal bases

Where the EU or UK GDPR applies, we rely on these legal bases:

• To provide the Service (create and secure accounts, capture reports, draft and deliver patches, open pull requests, send service email): performance of our contract with you or your organization.
• To bill you and keep accounting records: contract and legal obligation.
• To keep the Service secure (rate limits, account lockout, audit logs, fraud and abuse prevention, debugging): our legitimate interest in protecting the Service and our customers.
• To answer your messages and improve the Service: legitimate interest.
• To comply with the law, keep a record of your agreement and enforce our Terms of Service: legal obligation and legitimate interest.

Bug-report data we process as a processor is handled only to provide the Service to the customer that owns the site; the customer determines its legal basis.

5. AI processing

To triage a report and draft a fix, we send the report description, the selected element, recent console and network lines, and for server and module fixes the relevant source files to an AI model provider through OpenRouter. Screenshots are not sent. The same route writes pull request, commit and ticket text from the patch. Prompts are sent only to generate the output you asked for. Sarcio does not use customer data to train AI models, and where a provider offers the option we configure it not to retain prompts or train on them. AI output is not used to make decisions about individuals.

The WordPress assistant works the same way. Each turn sends the conversation so far (or a summary of its oldest part), the results of the actions the plugin ran, which can include the site's own content, what the plugin tells us about the site (such as its name, address, theme, language and the person's WordPress role), and the list of actions the person may run, to the AI model provider through OpenRouter, and returns the reply to the plugin. Sarcio stores no transcript of it: we keep only the usage record for billing, and the conversations themselves are saved in that WordPress site's own database, for the person who had them.

Files attached to the assistant are kept on that WordPress site for 24 hours, then deleted. To read them, the plugin sends what they hold to Sarcio and the AI model provider with the turn. Sarcio does not store them.

6. Who we share it with

We share personal data only with the service providers below, each to the extent needed for its purpose, and when the law requires it or to protect our rights and users. We do not sell personal data. If the business is sold or merged, personal data would transfer under this policy. Within Sarcio, access to customer workspaces is limited to what support and operating the Service require.

• Amazon Web Services (EC2): Hosting of the Service and its database, in the us-west-2 region (Oregon, USA).
• Stripe: Subscription billing and payment processing. Card details go to Stripe, never to us.
• Resend: Transactional email: verification, sign-in security, billing and product notices.
• OpenRouter and the AI model provider it routes to (only providers that keep no data, under OpenRouter’s Zero Data Retention setting): Triage of bug reports, drafting of fixes, source edits and change text, and the WordPress assistant’s replies.
• ImprovMX: Forwarding of email sent to sarcio.io addresses.
• GitHub, GitLab, Bitbucket and Atlassian (Jira): Only when you connect them: reading source files, opening pull or merge requests, and mirroring patches into tickets.
• Google and GitHub: Only when a member chooses to sign in with that provider.
• Google PageSpeed Insights: Only when someone asks the WordPress plugin to measure a page’s speed: the address of that public page on the site.
• unpkg (a public content delivery network): Serves the open-source html2canvas library to a reporter’s browser the first time they add a screenshot to a report, so unpkg receives that browser’s request (its IP address and user agent). No report content is sent to it.

7. Cookies and local storage

• Session cookie (sarcio_session): a first-party, HTTP-only cookie scoped to sarcio.io and its workspace subdomains that keeps you signed in, for up to 12 hours.
• Signed-in header (sarcio:session in local storage on this website): your workspace name and URL and your first name, so the header shows you as signed in. It holds no token and is cleared when you sign out.
• The dashboard and widget use session storage for short-lived interface state, such as a dismissed notice or a patch preview.

These are strictly necessary for the Service, so there is no cookie banner. We set no advertising or analytics cookies.

8. How long we keep it

• Bug reports, update-check reports included, are kept for your plan's retention window: 14 days on Free, 30 on Solo and Site, 90 on Team, Freelancer, Agency and Agency Plus, and 365 on Scale. After that, reports that never produced a patch are deleted, and reports that did are stripped of their captured context, screenshot, element HTML and AI triage reply, keeping only the description, URL and status that live patches refer to.
• Sarcio noticed counts are kept while the workspace exists, with at most 50 of the daily visitor digests per failure, and are deleted with it.
• Account and workspace data is kept while the workspace exists. Admins can export it as JSON or delete the workspace from the dashboard, which removes its data at once. Removing a member deletes their account.
• Cancelled workspaces are kept for 90 days after cancellation, during which they can be restored or exported on request to privacy@sarcio.io, and are then permanently deleted.
• Unfinished sign-ups are deleted automatically after they expire.
• Plugin feedback, compatibility reports, sign-up step and assistant counts are kept while they help us improve the Service.
• Request logs are kept for a limited, rotating period of up to 30 days.
• Audit logs are kept for the life of the workspace, and billing records as long as tax and accounting law requires.
• Backups, where kept, are rotated, and data deleted from the Service is removed from them within 30 days after the retention period above ends.

9. Security

We protect data with TLS in transit, envelope encryption for secrets at rest, argon2id password hashing, optional two-factor authentication, role-based access, workspace isolation, rate limiting and an append-only audit log. No system is perfectly secure; our security page describes the controls in detail. Report a vulnerability to security@sarcio.io.

10. International transfers

Sarcio is based in the United States and hosts the Service there, in Amazon Web Services' us-west-2 region (Oregon). Some of our providers process data in other countries. If you are outside the US, your data is transferred to the US. Where the law requires a transfer mechanism, such as under the GDPR, we rely on the European Commission's standard contractual clauses.

11. Your rights

Depending on where you live, you may have the right to access, correct, delete or export your personal data, to object to or restrict certain processing, and to withdraw consent where we rely on it. Many of these you can do yourself in the dashboard (your account, email address and two-factor settings; for admins, export and deletion). For anything else, email privacy@sarcio.io; we may need to verify your identity, and we respond within the time the law requires. If you are in the EU or UK, you can also complain to your data protection authority. If your data reached us through a customer's site or workspace, we will refer your request to that customer.

12. US state privacy rights

Residents of California and other US states with privacy laws may have the right to know what personal data we collect and how we use and disclose it, to access, correct and delete it, and to opt out of its sale, sharing for cross-context behavioral advertising, or profiling. We do not sell or share personal data for advertising and do not profile people. The categories we collect are identifiers and account data, commercial information (plan and billing), internet activity (request logs, bug report context) and any personal data in content you submit, for the purposes in section 4. We will not discriminate against you for exercising your rights. You or an authorized agent can make a request at privacy@sarcio.io.

13. Children

The Service is for businesses and is not directed at children under 16. We do not knowingly collect their personal data; if you believe we have, contact privacy@sarcio.io and we will delete it.

14. Changes to this policy

We will post any update on this page with a new effective date, and notify workspace admins by email or in the dashboard before a material change takes effect.

15. Contact

Dayne Mentier, doing business as Sarcio, New Jersey, USA. Privacy and data requests: privacy@sarcio.io. Security reports: security@sarcio.io. Legal notices: legal@sarcio.io.