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 code stays on your servers, backups from every fix stay on your machine, and we never get standing access to your infrastructure. You pair a connector once; after that, every request is authenticated, signed, and checked.
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, target 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 operators. |
| Workspaces and team permissions | Workspace owners and members see only what their role allows — per-member toggles for targets, 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 target. 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. |
| Fail-closed apply | If a patch is not a valid unified diff, nothing is applied — the connector restores its pre-apply backup and reports failure. |
| 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 target 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 target) | When several suspicious errors hit the same target in a short window, the connector for that site pauses entirely until the timer expires or a team member on your workspace releases it. This is separate from single-error quarantine. |
| 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), or Protection mode active on a target (whole site paused).
Quarantine vs protection mode¶
These are different — easy to confuse:
| Quarantine | Protection mode | |
|---|---|---|
| Scope | One error | One target (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 on your workspace can Release from protection mode on the target page (reason required) |
| Workspace admins / team | Can view quarantined errors and use manual fixes on the server; cannot lift quarantine in the dashboard | Can release or manually trigger protection mode for your targets |
Deep dives:
- Prompt injection protection — what you see and what to do
- Quarantined patches — reviewing held fixes
- Protection mode — when a whole target pauses
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 target settings allow auto-apply). |
| Low-confidence confirmation | The dashboard can require an extra acknowledgment before approving a low-confidence fix. |
| 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 targets 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 targets 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 target 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 | Target-level pause and release |
| Custom sanitizer patterns | Redacting your own secret formats |
| Post-apply restart safety | Trust model for automated shell steps |
| Connectors overview | HMAC, backups, fail-closed apply |
| Login throttling | Sign-in rate limits |
| Authenticator two-factor | TOTP setup and policy |
| FAQ — Security | Short Q&A |