Heroa is a managed runtime substrate. Its threat model starts from the assumption that the code running inside it is untrusted and potentially adversarial. The architecture is shaped accordingly.
Every Heroa task runs in an ephemeral container that is destroyed on completion. Containers do not share memory, filesystem, or network namespaces. A task cannot read files written by another task even if both tasks belong to the same workspace. The execution environment is a minimal read-only rootfs with the task's image layer applied; no writable layer persists after the task ends.
Long-running agents use an explicit persistent-state API; state is written to a workspace-scoped object store, not to the container filesystem, and access is gated by the workspace token. Cross-workspace state access is architecturally impossible.
Heroa's management API accepts traffic on HTTPS only (TLS 1.3 minimum). Container egress is limited to the hosts declared in the task's template definition. Templates undergo a review step before they can be published publicly; private templates are gated to the workspace that owns them. By default, a new template has no egress allowance; allowances must be declared explicitly in the manifest.
The self-host binary and BYOC agent operate the same allowance model. No container egress is enabled by default. The host operator declares the allowances at deploy time and they are enforced at the kernel network layer, not at the application layer.
API keys, secrets, and tokens used by tasks are stored in a workspace-scoped vault. The vault is backed by GCP Secret Manager on the managed plan, or by the KMS adapter of your choice on BYOC and Enterprise plans. Secrets are decrypted only inside the container process memory and are never logged, returned via API, or written to container-layer storage. Heroa staff do not have a path to read cleartext secrets without a formal key-escrow process that the customer explicitly authorizes in writing.
When you run BYOC (Bring Your Own Cloud), you provision the Heroa agent into your AWS or GCP account. The agent runs inside your account boundary, under your IAM roles. Heroa does not have access to your cloud account; the agent phones home to the Heroa control plane only on a narrow webhook-style event channel. The agent binary is signed and its checksum is published; you can verify it before you provision it. Cross-border data flow from a BYOC deployment is zero by construction — the containers run in your account and your region.
The sovereign BC-Canadian tier runs on dedicated single-tenant infrastructure in Cube Global Vancouver colo. No data leaves Canada. The MSA is Canadian-entity, enforceable in BC courts. Personnel with access to the sovereign substrate are Canadian residents. A compliance attestation is available under NDA for Canadian public-sector procurement.
Every task execution produces a structured audit log entry with timestamp, workspace ID, task ID, template name, exit code, and resource usage. Audit logs are append-only and retained per your plan's retention window. SOC 2 Type I is in progress; summary letters are available under NDA.
Security reports go to [email protected]. Critical reports are acknowledged within one business day and triaged within three. In-scope: container isolation breaks, vault exfiltration, cross-workspace data leaks, BYOC agent binary tampering, network egress enforcement bypasses. Out-of-scope: denial-of-service against the marketing site, social engineering. Eligible reports receive acknowledgment under our coordinated-disclosure program.