Rune Gurd docs

Gurd Cloud

Guard Cloud is the Rune Guard service your devices report to, and you can run it on your own infrastructure with the same images the hosted service uses.

What Gurd Cloud does

  • Enrolls devices and receives their coverage status and findings.
  • Publishes signed detection catalogs to devices.
  • Serves the Guard Console API.
  • Stores everything in PostgreSQL. Every row of tenant data belongs to one organization, so one deployment can serve one organization or several.
  • Optionally runs Scan your URL: a free, public scan of what anyone can reach on a host name, for a requester who proved control of it with a DNS TXT record or a /.well-known/ file. It is off unless GUARD_URL_SCAN_ENABLED=1, and its records belong to no organization. On a server with real data, run the fetching in guard-cloud scan-worker, a separate process with its own egress, no database connection and no keys.

By default, devices send metadata only. The device and the server both check finding and status fields against an allowlist, and refuse a finding that carries a path, an argument or any unknown field. See privacy for what the opt-ins add.

Security model

  • Device requests are signed with the device's Ed25519 key and carry a timestamp and a nonce. The server refuses timestamps more than 5 minutes off, replayed nonces, and unknown or revoked devices.
  • Admin keys (rgk_…) and enrollment tokens (rge_…) are 256-bit random secrets, stored only as SHA-256 digests. Tokens are single-use.
  • Catalogs must verify against the server's catalog keys and the device's pinned keys. When --catalog-key was pinned at enrollment, each sync raises the device's rollback floor to the organization's newest catalog, so an older catalog is refused.
  • Findings log integrity. Each record the sensor writes is hash-chained. Once the device has a key, each record is also MACed with a key that ratchets forward. Guard Cloud records gaps, rewrites and bad MACs as integrity events instead of refusing the upload. Before a key is issued, the local user can rewrite unsynced records and recompute every hash, and nothing detects that. After, a local user can still forge records written after they copy the current key, and stopping the sensor shows up only as missing reports.
  • Audit log. Organization changes, tokens, enrollment, revocation and catalog publication are recorded. When an AI agent CLI ran the enrollment, the device record and the enrollment audit entry name it. That comes from the enrolling process's parents, so it is device testimony, not proof.

Tenant isolation

The credential picks the organization: an admin key, Console session or device signature each resolve to exactly one. No organization route takes an organization ID from the request, and another organization's ID gets the same refusal as a random one. Budgets and quotas count per organization or per device.

PostgreSQL row-level security is the second line of defence. Every table with tenant data returns and accepts only the current organization's rows, even if a query misses its own filter. This holds only when Guard Cloud connects with a non-owner, non-superuser role (see Database roles).

Choose a deployment

Path For What runs Data
Try it Evaluation on a laptop or test VM One container: Guard Cloud, the Console and built-in PostgreSQL One Docker volume, no backups
Docker Compose One production server Guard Cloud, the edge (Caddy and the Console), and bundled or external PostgreSQL Encrypted off-server backups, restore drills, upgrades with automatic rollback
Kubernetes A cluster The Helm chart in helm-charts/guard: Guard Cloud, the edge and an Ingress Your PostgreSQL and its backups

Every path can also install without internet access.

No call-home

Self-hosted Guard Cloud never contacts Runeward Labs. It has no telemetry, licence check or update check. Its only outbound connections are ones you configure:

  • your PostgreSQL;
  • ACME (Let's Encrypt) when Caddy obtains a certificate, unless you mount your own;
  • identity providers and SIEM or export destinations you configure through the administrator API (no production connector ships yet);
  • the public MCP registry, only when mcp_reference_key is set.

To run it yourself, see Self-hosting.

Integrations

Export. Guard Cloud sends findings, integrity events and incident changes as signed OCSF events, delivered at least once, to Splunk HEC, Elasticsearch or OpenSearch, Datadog Logs, AWS Security Hub, Amazon S3, syslog, OTLP or any webhook.

Response rules. A rule can react to a new finding: label it, open an incident, notify someone by Slack, Microsoft Teams or email, or file a Jira, ServiceNow or PagerDuty ticket that stays in step with the incident. A Microsoft Sentinel target receives every new finding.

Credentials for these are write-only: Guard never shows them back.

Limits

  • Remote response commands are pulled on the next sync. There is no push.
  • Console accounts don't create or revoke machine administrator keys.
  • Tenant-configurable retention policies are not built.
  • Devices don't use the installed catalog automatically: pass --catalog and --catalog-key explicitly.
  • A managed multi-region service is not available.

Written from docs/guard-cloud.md, docs/self-hosting.md at commit fb79778d02f0. Rune Guard is in early access.