Security and what the agent never reads

The agent on your server

• •Outbound only. The agent opens no listening port. It sends a heartbeat every 60 seconds over HTTPS to the Opservo API and pulls any work from the response. Nothing connects in. The installer refuses a plain http:// API URL.
• •Signed telemetry. Every heartbeat is HMAC-signed with a secret issued at registration. An unsigned or tampered payload is rejected with 401.
• •Read-only by default. A fresh install observes and reports. It runs nothing on your behalf until someone in your workspace turns on remote actions for that specific server in the dashboard, which needs step-up confirmation and the Growth plan or higher. A fleet-wide agent update never changes that switch. If you want a hard guarantee on a host, set OPSERVO_ENABLE_ACTIONS=false in /etc/infrapilot/config and the agent will ignore commands regardless of the dashboard. Details in Remote actions.
• •Signed updates. The agent only installs a new build whose manifest carries a valid Ed25519 signature from an offline key. A compromised API alone cannot push a different binary.
• •Signed commands. Each remote command is Ed25519-signed by the API over its id, target server, command text and expiry. The agent verifies before running and reports a refusal instead of silently dropping it.
• •Audited. Every command, its output and exit code are stored, together with who dispatched it. Enabling or disabling actions is audited too.
• •Live terminal needs the server’s own consent. An interactive shell from the browser needs a dashboard switch and OPSERVO_ENABLE_SHELL=true in the server’s own config, which is off by default and is meant to be set by the server’s admin over SSH. Opservo blocks remote commands (terminal, chat, fleet runs) that edit the agent’s config or its switches. That check reads the command text, so it stops mistakes and plain attempts; it is not a sandbox against a deliberate root user on a server where you have already switched remote actions on. The agent dials out for each session, each start is signed for one server and one Linux user, the person confirms their identity every time, and the session is recorded except for input typed at a password prompt. See Live terminal.

What the agent never reads

• •It never opens .env files or application secrets. App detection looks at framework files and directory names only; database checks use the database’s own local socket or container credentials exposed by the runtime, never your application config.
• •It does not read your customers’ data. It gathers what is needed to explain and fix a server: services, processes, ports, domains and certificate expiry, resource usage, log patterns and security posture.

What leaves the server, and in what form

• •Log lines are never stored raw. The agent ships normalised entries, and the API keeps only patterns with volatile tokens (ids, timestamps, addresses) replaced, plus counts and an AI summary.
• •SSH and login data is masked on the server. In security findings, usernames keep their first two characters and the rest is starred; IPv4 addresses keep the first two octets and IPv6 the first two groups. The unmasked value never leaves the host.
• •Database queries are stripped of literals before shipping. Slow-query and running-query patterns have every string and number replaced with ?, so WHERE email = 'a@b.com' arrives as WHERE email = ?. Redis slow-log entries keep command names only.

How your data is protected in Opservo

• •Agent secrets, bring-your-own AI keys, cloud credentials and 2FA secrets are encrypted at rest with AES-256-GCM.
• •Every query is scoped to your workspace and re-checked on the server, including inside the AI tools. One workspace can never see another’s servers.
• •Snapshots (the raw heartbeat history) are kept for 30 days; external uptime check results for 30 days. Derived facts such as current services, open findings, alerts, incidents and the audit log are kept while your account is active. Deleting a server removes it; deleting your workspace removes its data.
• •Your data is never used to train third-party models. See the privacy policy.

Your sign-in

• •Sessions are httpOnly cookies, never readable by page scripts, with a CSRF token checked on every change.
• •Optional time-based 2FA with recovery codes, a workspace-wide “require 2FA” policy, five-strike lockout, new-location sign-in emails and one-click sign-out of all other devices. See Team and roles.
• •A mandatory screen lock after idle time, enforced by the API.
• •Optional step-up confirmation (2FA code or password) right before any action that can change a server.

The audit log

Owners and admins can read the workspace audit log on Account → Security. It records sign-in security events, member and role changes, security policy changes, remote actions being enabled or disabled, every dispatched command, SSH key grants, billing changes and cloud connections, each with who did it, when and from which address.