Security at Patcherly¶
Security and privacy came first - before the AI features, before the dashboards, before the patch pipeline.
Patcherly was designed so a problem on our side never becomes a problem on yours: your source tree stays on your servers by default, connector pre-apply backups stay on your machine, and we never get standing SSH or host access. You pair a connector once; after that, every request is authenticated, signed, and checked. Optional Repo Pull Requests uses a customer-installed GitHub App with write access only to GitHub repositories you grant (not your servers).
The full security stack is on for every workspace from day one - sign-in protection, connector hardening, automatic secret redaction, multi-layer AI prompt-injection defense, quarantine when something looks wrong, and audit trails you can actually read. No upgrade tier unlocks “real” safety; we built it in because automated patching only works when you can trust it.
Below is your guide to how each layer works and what you will see in the dashboard.
Your account and dashboard¶
| Protection | What it does for you |
|---|---|
| Authenticator two-factor (TOTP) | Add a second step at sign-in with Google Authenticator, 1Password, or similar apps. Workspace owners can encourage or require enrollment for the team. |
| Login throttling | Slows down repeated wrong passwords or MFA codes so automated guessing is impractical. |
| Audit logs | A searchable record of error-workflow actions, site automation toggles, and pairing / token issue or revoke in your workspace - filter, export, and review who did what. Interactive sign-ins and MFA stay with Patcherly (contact Support if you need login history). |
| Workspaces and team permissions | Workspace owners and members see only what their role allows - per-member toggles for sites, fixes, rollback, metrics, and related access. Billing stays with the workspace owner. Audit log access is gated separately on multi-seat plans. Sensitive actions may require password confirmation. |
| Data export and deletion | You can request a copy of your data or close your account; deletion follows the timelines in our Privacy Policy. |
Connectors and the API path¶
Connectors are small agents on your servers. They talk to Patcherly over HTTPS using credentials you create once during pairing.
| Protection | What it does for you |
|---|---|
| OAuth device pairing | You approve each connector from the dashboard with a short code - no long-lived passwords embedded in config files. Tokens refresh automatically in the background. See also How connectors authenticate. |
| HMAC request signing | Every write from a connector is signed with a secret tied to that site. Replayed or tampered requests are rejected. |
| Signed fix payloads | Before changing a file, the connector verifies that the patch from Patcherly is authentic and intact. |
| Safe apply checks | If a fix cannot be read or no longer matches your live files, nothing is written and no backup is created - the dashboard shows Failed or Stale patch. |
| Test Mode gate | Synthetic test errors only flow when you explicitly enable a 30-minute window in the dashboard, so stray credentials cannot flood your feed. |
| Backup folder hardening | Connectors write .htaccess + IIS web.config by default; guidance for Nginx/Apache when backups must live near a public webroot. |
Learn more: Connectors overview.
Secrets and log privacy¶
Error logs often contain passwords, API keys, or connection strings. Patcherly treats them as sensitive by default.
| Protection | What it does for you |
|---|---|
| Built-in redaction | Connectors scrub common secret shapes (AWS keys, Stripe keys, GitHub tokens, database URLs, PEM private keys, JWTs, and more) before data leaves your server. |
| Server-side re-scan | Patcherly runs the same built-in patterns again when logs arrive - defence in depth. |
| Custom sanitizer patterns | Add up to 32 of your own regex patterns per site for internal tokens the defaults do not cover. |
| Path exclusions | Exclude whole paths from monitoring or from the patch pipeline when they should never be touched. |
| Context size limits | File and log context sent for AI analysis is capped, so oversized payloads cannot abuse the pipeline. |
AI safety - prompt injection defense¶
Attackers sometimes craft error messages that try to trick the AI into suggesting harmful code (“ignore previous instructions”, fake system markers, and similar). Patcherly assumes all error text is untrusted and runs multiple independent checks.
| Stage | What happens |
|---|---|
| Pattern detection (before AI) | Pattern detection scans log lines and stack traces for instruction overrides, fake role markers, obfuscated payloads, and other injection tells - in many languages. |
| Safe prompt sizing | Very long fields are trimmed to safe limits so padding attacks cannot hide malicious text. |
| AI plausibility check | The model is asked whether the error reads like a genuine failure; it can flag implausible or manipulated input. |
| Quarantine (per error) | When checks fail on one error, that fix is held - status Manual review required. Auto-apply and connector apply are blocked for that error only. Patcherly Staff is immediately notified and can Mark as benign after review. Your workspace can view quarantined errors and apply manual fixes on the server while waiting. |
| Signed analysis responses | Connectors verify HMAC signatures and refuse suspicious results even if something slipped through upstream. |
| Protection mode (whole site) | When several suspicious errors hit the same site in a short window, the connector for that site silences until the timer expires or someone with Manage sites releases it. Separate from single-error quarantine. For planned deploys, use Pause site (4h, Paused badge). |
| Post-fix output scan (built in) | Built in and automatic - after the AI proposes a fix (and inbound checks did not already quarantine), Patcherly regex-scans the patch text for dangerous patterns (shell one-liners, destructive commands, and similar). In normal operation this does not block your fix; if a pattern is serious enough to quarantine, the error is held the same way as inbound detection. You do not turn this on or run it manually. |
In the dashboard: look for Quarantined (prompt injection) on an error (one error held), Protection mode on a site (security silence), or Paused (maintenance silence).
Quarantine vs protection mode¶
These are different - easy to confuse:
| Quarantine | Protection mode | |
|---|---|---|
| Scope | One error | One site (whole site/app) |
| Your site | Keeps running; other errors still flow | Connector pauses - no new errors, no applies |
| Who gets alerted | Patcherly Staff - notified to review each quarantine | Your workspace - email when protection mode starts (if notifications enabled) |
| Who can clear it | Patcherly Staff marks false positives benign (get in touch via the Support options, in the dashboard sidebar) | Anyone with Manage sites can Release protection mode (reason required). For Paused, use Resume site. |
| Workspace admins / team | Can view quarantined errors and use manual fixes on the server; cannot lift quarantine in the dashboard | Can release, Pause, or Activate Protection Mode for your sites |
Deep dives:
- Prompt injection protection - what you see and what to do
- Quarantined patches - reviewing held fixes
- Protection mode - security silence and Pause site
Patch pipeline safety¶
| Protection | What it does for you |
|---|---|
| Pre-apply backup | Connectors snapshot affected files on your server before any change. Rollback restores from that local backup. |
| Manual approval gate | Fixes are not applied until you approve (unless your plan and site settings allow auto-apply). |
| Low-confidence confirmation | The dashboard can require an extra acknowledgment before approving a low-confidence fix. |
| Repo Pull Requests | Optional GitHub App delivery opens a PR (and/or applies live). Distinct from Sign in with GitHub; write access is only to repos you install the App on. |
| Plan and feature checks | Analysis, auto-analysis, and apply respect your plan limits and feature flags - no silent bypass. |
Post-apply restart automation (Python / Node.js / PHP)¶
On supported sites and plans, you may configure shell steps to run after a successful patch (reload a process, clear cache, run a smoke test). This is powerful - and Patcherly wraps it in guardrails:
- Manifests are fetched over signed API responses and verified with a hash before execution.
- Automation is opt-in, plan-gated, and rate-limited per hour.
- Failed runs can auto-disable further attempts until you review them.
- Commands run through safe execution (no shell metacharacters; argv-style invocation).
WordPress sites do not run shell automation - the plugin patches files only.
Details: Post-apply restart safety · App restart automation
Monitoring and transparency¶
- Audit logs - workspace activity including security and workflow events.
- Usage analytics - AI token usage separate from business metrics.
- Data retention - what Patcherly keeps, for how long, and what is pruned by plan.
For contractual detail, see our Privacy Policy, Terms of Service, and Acceptable Use Policy.
Quick answers¶
Will security slow down normal bug fixing?
No. Ordinary application errors pass through the same pipeline as always. Extra checks activate only when patterns or AI signals suggest manipulation.
Can I turn off AI safety entirely?
No. Quarantine and protection mode are part of the service so manipulated error text cannot reach auto-apply. Patcherly Staff can mark false positives benign after review. Open Support from the bottom of the dashboard sidebar if you hit a recurring false positive on a quarantined error.
Where do I start if something looks wrong?
1. Check Quarantined patches or Protection mode.
2. Review Audit logs for the same time window.
3. Open Support from the bottom of the dashboard sidebar (include the error ID or site name when your plan includes direct contact).
All security guides¶
| Guide | Best for |
|---|---|
| Workspaces and team permissions | RBAC toggles, invites, and multi-workspace access |
| Prompt injection protection | Understanding quarantine badges and connector pauses |
| Quarantined patches | Per-error hold and false-positive review |
| Protection mode and Pause site | Site silence for security or maintenance |
| Custom sanitizer patterns | Redacting your own secret formats |
| Post-apply restart safety | Trust model for automated shell steps |
| Connector hardening tests | What we verify on every connector release |
| Connectors overview | Pairing, backups, when a fix cannot be applied safely |
| Login throttling | Sign-in rate limits |
| Authenticator two-factor | TOTP setup and policy |
| FAQ: Security | Short Q&A |