Security & trust

ServerGuard runs on the principles that earn trust from sysadmins: human-in-the-loop for anything destructive, an append-only audit log, encrypted SSH keys, and least-privilege access scoped per server. The rest of this page is the technical detail behind each.

SGuard operates only on incident remediation. It doesn't access customer site content or databases outside the active incident context.

Human-in-the-loop for anything dangerous

Every action ServerGuard can run on your server is risk-classified before it is allowed to execute. The classification is fixed. ServerGuard does not decide its own permissions.

Risk level	Examples	Behaviour
Safe	Read-only diagnostics: `journalctl`, `systemctl status`, `ps`, `df`, log fetches, mailq inspection.	Auto-executes. Logged with full output.
Moderate	Service restarts, cache flushes, queue drains, log rotation.	Auto-executes per the policy you set per server. Logged with full output.
Dangerous	Deletes, package reinstalls, credential rotation, firewall rule changes that block traffic.	Never auto-executes. Routed to Telegram or the web dashboard for explicit approval. Token expires in 30 minutes.

Least-privilege onboarding

Before ServerGuard runs a single remediation, the onboarding flow proposes the exact privileges the agent will hold on your box, and you decide whether to grant them.

We connect read-only, inspect the server, and propose the recommended set of automatable actions. Each use case has a toggle so you can switch off anything you don't want autonomous, even on Safe-class actions.
We generate the exact sudoers / wheel rules required to grant the `sguard` user only those actions, nothing more. The proposed rules are shown verbatim before you accept.
We generate the root-level constraints that pin the `sguard` user down: no interactive shell outside the approved command list, scoped SCP, hardened sshd_config entries for the agent user, and audit-log immutability.
You review, edit, and accept. The dashboard then emits a single signed bash script. You, the customer's root user, pipe it to root and apply it.
After you apply the script, ServerGuard re-runs the diagnostic to confirm scope: the agent can do exactly what you approved, and nothing else. The confirmation result is written to the audit log.

How we handle SSH keys

We generate one SSH keypair per server you register. The private key never leaves our infrastructure in plaintext, and never appears in API responses, logs, or error messages.

Encrypted at rest with AES-256-GCM. The encryption key is derived per organisation, so a database breach does not yield a single master plaintext.
Excluded from API responses by schema construction: the response type does not contain the encrypted-key field at all.
Decrypted only in process memory, only for the duration of a single SSH session, then dropped when the connection closes.
Source-level redaction is applied to every command and every command output before it is written to logs or to the audit table.
TOFU (trust-on-first-use) host-key fingerprinting on first connect. The fingerprint is pinned; subsequent connections fail closed if the host key changes.
Rotation: replace a server's keypair from the dashboard at any time.

What we log

Every meaningful action in the system is recorded in an append-only `audit_log` table. There is exactly one write path. Redaction is applied inside it before the row is committed.

Every SSH command executed, with the redacted command string, exit status, duration, and a `truncated` flag for long-running output.
Every ServerGuard diagnosis: model, request ID, input/output token counts, cost, duration.
Every approval and every rejection, with the actor, the channel (Telegram or web), and the timestamp.
Every state change to a server, incident, or organisation membership.
Rows are INSERT-only. The schema does not expose UPDATE or DELETE on this table.

Retention follows your plan tier (Starter 30 days, Pro 90 days, Agency 1 year).

Approval workflow controls

Channels: Telegram + web dashboard on Pro; WhatsApp added on Agency. The exact channel availability per tier follows the pricing page.
Approval requires an explicit affirmative response. There is no "approve by default" or "approve if no response in N minutes" mode.
Approval tokens expire 30 minutes after issue. An expired token cannot be reused; the action must be re-requested.
Admin IP allowlist: IPs you mark as admin will not be auto-blocked by ServerGuard regardless of detected attack patterns. This is the kill-switch against the product locking you out of your own server.
Webhook endpoints (Telegram, WhatsApp, web callbacks) are rate-limited and support an optional source-IP allowlist.

Tenant isolation

ServerGuard is multi-tenant by design. Multiple organisations share the same infrastructure. The data separation is enforced at the query layer, not just the application layer.

Every query that touches tenant data filters by `organisation_id`. There are no exceptions, including admin endpoints.
The repository layer is the only path to the database; route handlers do not issue raw SQL.
Endpoints that could conceivably leak keys have explicit tests that scan the response body for key-shaped content. A failing test blocks merge.

How we operate

Human-in-the-loop for anything destructive. Append-only audit logging. Encrypted SSH keys with per-organisation key derivation. Least-privilege access scoped per server. We don't train AI models on customer incident data, and we don't sell or share log data with third parties.

Sub-processors

We use a small number of vetted infrastructure and AI providers. The full list is available on request.