Security

What stays, what leaves

RemoteHangar keeps the control plane, the repositories, the session transcripts and the secrets on your server. It does not run the model: every agent turn calls the model provider you configure, and the prompt includes the code the agent works on.

Model traffic can go through your corporate HTTPS proxy. The agent CLI’s own non-essential traffic, such as telemetry, is turned off.

Agent sandbox

Each agent process runs under bubblewrap with the file system mounted read-only, except the bay’s working directory, its own HOME, the whole /home directory (shared by every bay) and shared caches. /tmp is private to the process. NoNewPrivileges blocks sudo and setuid binaries inside the sandbox.

The service runs as an unprivileged system user under a hardened systemd unit with ProtectSystem=strict and ProtectHome=read-only.

Writes outside /home and the bay’s own directories are blocked. Reads are not isolated yet; see the limits below.

Credentials and encryption

A master key is delivered to the service through systemd credentials from a root-only file (mode 0600). Per-subsystem keys are derived from it with HKDF-SHA256.

Git credentials, integration OAuth tokens, remote-server SSH secrets and the internal CA key are stored encrypted with AES-256-GCM. Session tokens are stored as HMAC hashes and API tokens as SHA-256 hashes, never in the clear.

Local passwords are hashed with Argon2id. Repeated failed logins trigger a progressive lockout per user and per IP address.

Sign-in and access

People sign in with local accounts that an admin creates, or with OIDC single sign-on (discovery and PKCE), which you turn on. OIDC creates the account on first sign-in.

There are two roles: admin and user. Session cookies are httpOnly, SameSite=strict and secure in production, and people can see and revoke their own sessions. API tokens carry scopes, expire after 90 days by default and can be revoked at any moment.

Tool calls follow your permission rules: allowed, denied, or sent to a person for approval in the browser or on the phone.

Audit trail

RemoteHangar writes three audit tables to its SQLite database. This is what they record, and nothing more:

• Every tool-permission decision: allowed or denied, and whether a rule, a person or a timeout decided
• Git credential events: created, renamed, deleted, used, tested
• Admin calls to enrolled remote servers

Signed releases and updates

Release manifests are signed with minisign, and the signing key is never on the distribution server. The signature and the checksum of the artifact are checked before installing. If the host cannot run the verifier, the installer only warns; --require-signature makes the check mandatory.

Updates run only inside your maintenance window and only when no agent is busy. The database is snapshotted first; a failed health check rolls back code and schema. You can pin a version or turn automatic updates off.

Known limits

We would rather you read these here than find them in a review.

• Reads are not isolated between bays yet: the sandbox blocks writes outside the bay, not reads. Treat one installation as one trust group, such as one team. Read isolation is planned.
• /home is writable from every bay, so one bay can change files in another bay’s workspace under /home.
• Secrets set in /etc/remote-hangar/config.env, such as the model provider key and the OIDC client secret, are stored in plain text, readable by root and the service group (mode 0640). Bays run as the service user, so agents can likely read them too until read isolation lands.
• Roles are admin and user only; there is no finer-grained access control.
• OIDC has no group or domain allowlist: anyone who can sign in at your identity provider gets a user account. Restrict access at the provider.
• RemoteHangar sends no email, so there are no email invitations or password resets by email.
• Logins, user management and settings changes appear in application logs, not in the audit tables.
• The admin web terminal runs a shell on the host as the service user, outside the sandbox. Only admins can open it.
• Docker inside bays, when enabled, shares the host’s Docker socket, which is root-equivalent on that host. It is off by default.
• CSRF protection runs in report-only mode by default: violations are logged, not blocked.
• Backups are manual (remote-hangar backup); the only automatic snapshot is the one taken before an update.
• RemoteHangar runs on a single server.
• RemoteHangar has not been through a SOC 2 audit or a formal certification.