continuous.engineering

Appearance

Trust Center ​

This page is for your auditor, not for you: the questions a third-party risk review typically asks about a vendor with infrastructure access, answered directly. It covers continuous.engineering's own security posture, not how the access we're granted maps to your compliance framework (that's Compliance) and not the technical internals of how our tooling works (that's not something we publish, the same way we wouldn't expect to see the internals of your access-control tooling either).

Need something specific for your audit?

If your auditor needs a signed attestation, a specific evidence format, or a call to walk through this directly, contact devops@continuous.engineering; this page is meant to answer the first round of questions, not replace a real conversation when one's needed.

Identity & access: how our own engineers are controlled ​

Every continuous.engineering engineer authenticates against our own centrally-managed identity provider: there are no local accounts, no shared logins, and no credentials an engineer holds that work outside our own system.

  • MFA is mandatory, enforced technically, for every engineer, every session. Not a policy an engineer could opt out of: our identity provider rejects sign-in without it.
  • Access is tiered by role, not all-or-nothing. Engineers are placed in a read / operate / admin tier, and that tier, not individual judgment, determines what a client environment will grant them. See the Role Reference for exactly what each tier can do.
  • Offboarding is immediate and central. When an engineer leaves continuous.engineering, their identity-provider access is revoked once, centrally, and they immediately lose the ability to reach every client environment simultaneously; there is no per-client account to remember to also disable.
  • We hold no standing credentials to any client system. Every credential our engineers use to reach your infrastructure is short-lived or individually revocable and originates from your side of the trust relationship (see Security Model), not ours.

Evidence, per cloud ​

Our AWS identity provider is the single source of truth for engineer identity and MFA: GCP access rides that same authenticated session rather than enforcing its own separate MFA policy, so there's one MFA screenshot, not three.

AWS: MFA required on every sign-in, enforced at the identity provider, not a policy an engineer can opt out of:

AWS MFA enforcement

AWS: the three access tiers, as real groups in our identity provider:

AWS tiered groups

GCP: the same three tiers, federated as three distinct identity providers (GCP has no session-time role choice, so tiering has to live here instead; see the Role Reference for why):

GCP tiered federation

Azure: security defaults (MFA) enabled on our own Entra tenant:

Azure MFA enforcement

Azure: the same three tiers, as groups in our Entra tenant:

Azure tiered groups

Data handling ​

  • We do not copy or export client data out of your environment as a byproduct of granting access. Access lets our engineers work inside your account/project/subscription; it is not a data pipeline.
  • Local caching, disclosed plainly: our connect tooling caches non-sensitive inventory metadata (instance names, IDs, tags, not data contents) locally on the individual engineer's machine, to make repeated connections fast. This cache is per-engineer, never centrally aggregated, and never leaves the engineer's own machine.
  • No credentials are ever written to disk in plaintext beyond what your own cloud's CLI tooling already does on the engineer's machine (the same local credential cache any aws/gcloud/az CLI user has); nothing continuous.engineering-specific persists beyond that.
  • Client account identifiers (account IDs, project IDs, subscription IDs, tenant IDs) are treated as operational data, not secrets, the same way this documentation site itself treats them, but they are never published or shared outside the engagement.

Infrastructure & operational security ​

  • Least privilege is the default posture, not an exception. Every role we request maps to a specific category of work (read-only, operations, data, admin); see the Role Reference for the full breakdown. We do not request broader access than a given engagement requires.
  • Every session is auditable on your side, by design. Because access is granted by you, into your own environment, your own audit log is authoritative: we are not asking you to trust a log we control. See Monitoring.
  • Access is engagement-scoped and time-bound. Nothing is provisioned "just in case" ahead of a signed engagement, and access is expected to be revoked (by you) at the natural end of an engagement; see Revoking access.
Engineer authenticates to CE's own identity provider  (MFA required, every session)
                        |
                        v
        Placed in a tier: read / operate / admin
                        |
                        v
   Tier determines which role is reachable in YOUR account/project/subscription
                        |
                        v
     Session is short-lived (AWS/GCP) or individually revocable (Azure)
                        |
                        v
        Every action logged in YOUR OWN audit log, under the
              individual engineer's identity, not ours

Incident response ​

If continuous.engineering identifies a security incident that could affect a client environment (including suspected compromise of an engineer's identity-provider credentials), clients with active access are notified directly, without waiting for a scheduled check-in. Contact devops@continuous.engineering to establish the notification channel and escalation path for your specific engagement before access is granted, if your compliance program requires this in writing ahead of time.

What we deliberately don't publish here ​

In the interest of not creating a roadmap for attacking our own systems, this page does not include: the internal source of our access-provisioning tooling, exact internal identity-provider tenant/account identifiers, or engineer-identifying detail. None of that is necessary to evaluate the security properties described above, and all of the properties themselves are independently verifiable from your side once access is granted: you don't have to take our word for any of it; your own audit log proves it.

Questions for your audit: devops@continuous.engineering