Heimdall

SECURITY

Security: the mechanism behind each guarantee.

This page was written to be forwarded. Each answer states the mechanism and where it lives in the product.

Talk to engineering

Opens a WhatsApp chat. Prefer email? [email protected]

Where everything lives.

Everything runs in your infrastructure, and your data stays inside your perimeter. The split between the Agent and the API matters inside your company: whoever administers the API has neither the secret values nor the database passwords.

In the Agent and at the edge

  • The value of each secret.
  • The administrative credential of each database and the password of each service user.
  • The history of each database proxy session.
  • The content of network traffic, encrypted end to end between the edge and the Agent.
  • The Terraform state and lock live in your cloud account's bucket.

In the API, which is yours too

  • Organizations, people, roles and policy.
  • The catalog, with Terraform inputs and outputs (a sensitive output is stored as <sensitive>) and the log of each run.
  • The metadata of each secret and who read it.
  • Database schemas and the text of each SQL statement.
  • The metadata of each network flow.
  • The audit trail.
  • The CA that signs Agents and edges, and the OIDC key, encrypted.

  1. Can whoever administers Heimdall read secret values?

    The API refuses to receive the value, with 400 VALUE_NOT_ACCEPTED. The value your team writes lives in the Agent, encrypted under a master key you hold — a variable, a file or AWS KMS — and the Agent only serves a read it managed to record. Whoever administers the API sees the name, the version and who read it.

  2. Does Yops have access to my installation?

    There is no channel from Yops into the installation. During deployment, the Yops team works with whatever access your team grants.

  3. How is data encrypted, and with whose key?

    In the API, each organization has its own data key, wrapped by a master key you hold: local, or an AWS KMS CMK. In the Agent, the master key is yours too.

  4. Who can do what, and who decides?

    Cedar decides on the server; the screen asks and never decides. A refusal at the entry of a route goes into the trail (authz.denied). System policy is immutable, and the actions that would hand over the owner's identity are protected by a forbid rule the engine injects.

  5. Can the audit trail be altered?

    It is append-only: the database refuses UPDATE and DELETE through a trigger.

  6. How is one organization isolated from another?

    Row-level security per organization, enabled and forced in PostgreSQL on every table that belongs to an organization. A test sweeps the schema and fails any table left without it.

  7. How do people sign in?

    With a password and an email second factor (an organization policy, default for the owner), with Google or GitHub, or through the organization's own OIDC IdP, with domain proof by TXT. On a federated domain, password sign-up is refused.

This page describes mechanisms, not certifications.

For a security questionnaire, talk to engineering.

Talk to engineering

Opens a WhatsApp chat. Prefer email? [email protected]

https://heimdall.yops.cloud/en-US/security · Reviewed on October 10, 2026