Security Architecture

The CleanShift agent runs as root because server-level security scanning requires access to all user home directories, system configurations, and WordPress database credentials. This is not optional — a non-root agent cannot perform the deep filesystem and database inspection that makes CleanShift effective.

Least-Privilege Design

• The agent only reads files and databases during scanning. Write operations only occur during explicit remediation, which requires a paid tier and explicit opt-in from the operator.
• The agent does not open inbound network ports. All communication is outbound-only via HTTPS/WSS.
• The configuration file is stored at /etc/cleanshift/config.json with 0600 permissions (root-only readable).

The agent performs all scanning locally on your server. Only extracted metadata leaves the machine:

1. Agent scans the filesystem and databases locally.
2. Metadata (hashes, paths, ownership, plugin versions) is extracted.
3. Metadata is transmitted to the CleanShift API via TLS 1.2+ (HTTPS).
4. API matches metadata against the Indicator of Compromise (IoC) database.
5. Results are displayed in the dashboard and returned to the CLI.

Guard Plugin (WordPress mu-plugin)

The Guard mu-plugin operates entirely locallywithin WordPress. All runtime logs are stored in the site's own database and are not transmitted to the CleanShift API unless explicitly triggered by the operator (e.g., sharing a support snapshot).

Before any remediation action, CleanShift creates a timestamped backup of the affected file or database entry. Remediation is never destructive — it is always reversible.

• Backups stored locally at /var/cleanshift/backups/. Release 1 does not promise an automatic 30-day backup purge — operators manage local backup disk use.
• Manual rollback via CLI: cleanshift rollback --scan-id <ID>
• Dry-run mode available before any remediation: cleanshift clean --dry-run
• All remediation actions are logged to /var/log/cleanshift/remediation.log with full before/after audit trail.

There is no legacy installer uninstall binary in Release 1. Stop the agent service and remove the install tree (adjust unit name if your host uses a different service):

What Gets Removed

• ✅ Agent binary / install tree under /opt/wpcleanshift (Release 1 zero-touch /i/TOKEN path)
• ✅ Agent configuration at /opt/wpcleanshift/agent/config/config.yaml
• ✅ Agent cron / systemd unit cleanshift-agent

What Gets Preserved

• ❌ Remediation backups — preserved for safety unless you delete them yourself under the backup directory.
• ❌ Guard mu-plugin — Release 1 does not deploy Guard via zero-touch install; remove any manually deployed wp-content/mu-plugins/ Guard files separately.

Uninstall does not modify WordPress site content, databases, or panel configuration beyond removing what the agent (and any manually deployed Guard files) installed.

• Intelligence updates (signature databases) are verified with SHA-256 cryptographic hashes before being applied. Tampered or corrupted updates are rejected automatically.
• Agent updates are distributed exclusively via the official installer script from get.cleanshift.osg.co.in.
• Remediation playbooks are versioned and auditable — no arbitrary code execution is performed on your server.

• All agent actions are logged locally at /var/log/cleanshift/agent.log.
• All dashboard authentication events are logged server-side.
• Remediation actions include: timestamp, affected file or database entry, action taken, backup location, and operator identity.
• Logs are never transmitted to the CleanShift API unless explicitly shared for support purposes.

• Agent communicates outbound-only — no inbound ports are opened on your server.
• All API communication uses TLS 1.2+ (HTTPS).
• WebSocket connections use WSS with token-based authentication.
• API enforces CORS restrictions, SSRF protection, and rate limiting.
• No third-party tracking or analytics scripts on the CleanShift dashboard.