HostAgentics Docs

HostAgentics Security

Last updated: 2026-08-06

This document describes the security model of the HostAgentics platform. It is an internal operational document; customer-facing claims about security must be limited to what this document actually supports. No SOC 2 report, ISO 27001 certificate, or comparable third-party audit has been published yet — do not claim one.

1. Threat model

We design against these principal adversaries and failure modes:

| Threat actor / scenario | What we protect | Primary controls |

| --- | --- | --- |

| External attacker (internet) | API, dashboard, runtime domains, secrets | TLS everywhere, authentication (OAuth), authorization checks, rate limiting, signed Relay payloads |

| Cross-tenant attacker (one customer's runtime attacking another) | Tenant isolation | Per-runtime volumes, per-runtime credentials, per-runtime domains, no shared agent memory, no Docker socket, provider-level isolation between services |

| Compromised runtime (a customer workload that is itself breached or malicious) | Control plane and other tenants | Control plane is not in the runtime data path; runtimes get scoped credentials only; egress controls; Relay signatures |

| Prompt-injected or tool-abusing agent (agent runtime coerced by malicious input) | Customer data, external services | SSRF protections for browser automation, least-privilege keys, safe mode, customer-visible audit events |

| Insider (operator with admin access) | Secrets, customer data | Two-person rule for production changes, audit logging, encrypted secrets with key separation, redaction |

| Supply chain (compromised dependency or image) | Platform integrity | Pinned image digests, tested-only version catalog, lockfile-managed dependencies, minimal workspace tokens |

We do not claim protection against every class of attack. Material limitations are disclosed in section 9.

2. Isolation model

  • **Per-runtime secrets.** Customer credentials (API keys, BYOK material, integration tokens) are encrypted at rest with AES-256-GCM using a key derived from `ENCRYPTION_MASTER_KEY` (see `packages/encryption`). Ciphertexts carry a key version; the master key ring supports rotation. Subkeys are derived per context so the raw master key is never used directly as a cipher key.
  • **Per-runtime volumes.** Every runtime has its own persistent volume. Storage is never shared between runtimes, and volumes are attached to exactly one runtime service.
  • **No shared agent memory.** Agent runtimes (OpenClaw, Hermes Agent) each have an isolated memory store. There is no cross-runtime memory sharing, and the platform does not read agent memory.
  • **No Docker socket.** Neither the control plane nor any runtime exposes a Docker socket. The provider abstraction (`packages/provider-core`) has no socket concept; runtimes cannot reach host-level container control.
  • **Safe mode.** Agent runtimes support a safe mode that restricts tool use and outbound actions. Safe mode is a runtime-level capability; the platform enforces the plan's concurrency and browser-session limits regardless of mode.

    • 3. Key handling and BYOK

  • BYOK (bring-your-own-key) material, e.g. model provider API keys, is submitted through the dashboard or API once, encrypted immediately, and **never displayed again in plaintext**. Only masked previews (e.g. `sk-…abcd`) are ever shown.
  • Keys are stored hashed or encrypted depending on use: Relay tokens are stored as hashes (plaintext shown exactly once at issuance); provider-API keys are stored encrypted and decrypted only at the moment they must be injected into a runtime environment.
  • `ENCRYPTION_MASTER_KEY` itself never appears in logs, error messages, or customer-visible responses.
  • Stripe secret keys, the OpenRouter management key, and the infrastructure workspace token live only in the control plane's environment and are never injected into runtimes. The management key creates restricted per-runtime keys instead (`packages/ai-access`).

    • 4. SSRF protection for browser automation

    Agent runtimes can drive a managed browser (browser sessions are a plan entitlement). A compromised or prompt-injected agent could otherwise abuse the browser to reach internal services (SSRF). Controls:

  • Browser automation runs inside the runtime's own network scope, not on the control-plane network; it cannot reach control-plane metadata endpoints or internal services.
  • Outbound destinations are subject to the runtime's egress policy; link-local and provider-internal address spaces are not routable from runtime workloads.
  • Browser sessions are counted and capped per plan (`maxBrowserSessions`); exceeding the cap blocks new sessions rather than silently allowing more.

    • See OWASP's SSRF guidance for the general class of attack: <https://owasp.org/www-community/attacks/Server_Side_Request_Forgery>.

    5. Relay security

    The Relay is the authenticated control-plane↔runtime channel. Every Relay request carries an HMAC-SHA256 signature over `timestamp.nonce.sha256(body)`; payloads must be fresh (≤5 min old, no future timestamps beyond 30s skew), nonces are single-use (replay prevention), and idempotency keys make retries safe. Scoped tokens carry explicit claims (organization, runtime IDs, actions) and are stored hashed. See `packages/relay` and `docs/architecture.md` §6.

    6. Audit logging

  • Sensitive operations are audited: provisioning transitions, plan changes, key submission and rotation, BYOK operations, restore/backup completion, admin actions, and Relay token issuance.
  • Audit events include actor, action, target, timestamp, and outcome; they are append-only in the database and are not modifiable through the API.
  • Audit data is separate from operational logs and is retained per the platform's retention policy (to be published).

    • 7. Admin access

  • Production admin access requires short-lived, scoped credentials; standing long-lived admin credentials are not used.
  • Production-impacting changes (deploys, migrations, emergency restores, secret rotation) follow a two-person rule: a second operator reviews and approves before execution.
  • Admin actions are covered by audit logging (section 6) and reviewed in the postmortem process (`docs/incident-response.md`).

    • 8. Redaction in logs, email, Sentry, and PostHog

  • Log redaction: secrets and key material are redacted at the logging boundary (`packages/observability`). Structured logs never contain plaintext secrets; ciphertext or masked values only.
  • Email redaction: transactional email (Resend) is sent with masked values where a secret would otherwise appear (e.g. setup links, key previews). Support email does not contain plaintext secrets.
  • Sentry: error events are scrubbed before transmission (cookie/authorization headers and known secret patterns); `ENCRYPTION_MASTER_KEY` and provider tokens are on the deny list.
  • PostHog: event properties are filtered; no secret values, no provider identifiers, and no PII beyond what is necessary for product analytics (and only with consent where required).

    • 9. Material limitations (disclosed)

  • No SOC 2 / ISO 27001 certification has been published; security claims are engineering controls, not audited attestations.
  • Encryption protects data at rest in the control plane and backup artifacts; it does not protect data the customer's own workflows send to third-party services.
  • A compromised customer API key still grants access to that customer's runtime within plan limits; we cannot revoke keys we do not hold.
  • Prompt injection cannot be fully prevented by any platform control; mitigations (safe mode, egress policy, audit events) reduce blast radius but do not eliminate it.
  • This document is not legal advice and does not constitute a security guarantee or warranty.

    • 10. Related documents

  • `docs/architecture.md` — where the controls live
  • `docs/incident-response.md` — what happens when a control fails
  • `docs/subprocessors.md` — the only customer-visible document that names the infrastructure provider (legally required)