Security controls you can verify.

Production infrastructure

The hosted service runs on Google Cloud in the United States. Application instances have no public IP addresses; production traffic reaches them through a Google Cloud HTTPS load balancer with managed certificates and a TLS 1.2 minimum. The Cloud SQL database is private-addressed, requires TLS, and has automated backups, point-in-time recovery, and deletion protection. The public DNS zone is signed with DNSSEC, with a validating chain of trust from the signed .dev parent zone to emisar.dev.

Secrets live in Secret Manager and workload identities receive access only to the secrets and resources they need. Administrative access is restricted through Identity-Aware Proxy and OS Login. VPC flow logs and Cloud Monitoring alerts cover the platform; independent external probes feed on-call alerting and our public status page.

Change control & software delivery

Pull requests run with read-only permissions and no deployment credentials. The same reusable CI workflow is called again from the main-branch delivery workflow, so production receives the commit that passed compilation, tests, dependency-advisory checks, static security analysis, architecture checks, and an image smoke test. GitHub Actions are pinned to exact commits; downloaded tools are version-pinned and checksum-verified.

Delivery scans the tested image for high and critical vulnerabilities, generates a CycloneDX SBOM, and publishes provenance and SBOM attestations. The image is promoted by immutable digest, never rebuilt after testing. Infrastructure changes become a saved HCP Terraform plan: auto-apply is disabled, the plan must still match the current main commit and state, and a person must review it and choose Confirm & Apply. Rollouts keep the previous instances serving until the replacement passes readiness checks.

Subprocessors

A short list, each contractually bound to confidentiality and to processing data only on our instructions:

• Google Cloud Platform — application hosting, networking, managed PostgreSQL, and backups, US region.
• Paddle — payment processing and subscription retention (Paddle Retain, loaded only on the checkout page); we never see or store full card numbers.
• Postmark — transactional email (confirmations, approvals, magic links).
• Mixpanel — marketing & growth analytics; server-side and cookieless, never your runners' data.

We update this list before adding a subprocessor — see the privacy policy for the full detail.

Security review & procurement

Security review material is available now. We complete security questionnaires and can provide supporting material for access control, change management, vulnerability management, monitoring, backup and recovery, retention, and deletion. SOC 2 Type II audit preparation is underway; the independent examination is not complete. We also offer a Data Processing Addendum you can sign (email support@emisar.dev for an executable copy). Production data stays in the United States.

Insurance

Professional-indemnity coverage of USD $1M and general-liability coverage of USD $2M apply to hosted use on Team and Enterprise plans, worldwide including the USA and Canada. A certificate of insurance is available on request.

Availability & SLA

The hosted control plane targets 99.95% monthly uptime on Team and 99.99% on Enterprise, backed by a written SLA in the Enterprise order form. Because runners dial out and the host has the last word, a control-plane outage pauses new dispatches — it never leaves an action half-run or bypasses a gate.

Deployment & licensing

emisar runs as a hosted control plane today. The code that runs on your hosts — the runner, the MCP bridge, and the action packs — is open source under the Apache License 2.0, so you can inspect, build, and keep operating it independently of us. The control plane is source-available under the Business Source License, and each release converts to Apache-2.0 on its change date — the code can't end up locked behind a vendor that disappears. Supported self-hosted and air-gapped deployments are not generally available; if on-prem or air-gap is a hard requirement, contact us — we want to hear about it.

Release integrity

Every runner and MCP-bridge release is built by a public GitHub Actions workflow that publishes SLSA-3 build provenance, signed by Sigstore and bound to the exact tag and workflow that produced it. Before a binary ever runs as sudo on your host, you can prove it came from our source — not a tampered mirror — and that its bytes match what we published:

# provenance — built by our workflow, from our source
$ gh attestation verify emisar-<version>-linux-amd64.tar.gz --owner andrewdryga

# checksums — the bytes match what we published (SHA256SUMS-MCP for the bridge)
$ sha256sum -c SHA256SUMS

A green check names the source repository and the release workflow, so it means the artifact is exactly the one our pipeline produced from a tag you can read. The install script verifies the checksum itself; running these first is the download-then-verify path for a security team that inspects before it trusts.

Reporting a vulnerability

Email security@emisar.dev. We'll acknowledge your report, keep you updated, and credit you if you'd like. Please give us a reasonable window to fix an issue before disclosing it publicly.