Security Model

Break glass lets a vendor operator reach a resource inside your customer’s own cloud account. That’s a powerful capability, so it’s built to be consented, bounded, and auditable: every session is gated by a customer-signed approval the appliance controller verifies before anything is minted, the access it grants is scoped to one resource for one session, and it self-expires. This page documents those guarantees.

​

The core guarantee

No break glass session happens without an explicit approval your customer signs cryptographically. The approval is bound to one specific request, and the appliance controller running in your customer’s account verifies it against a key only your customer controls before it mints a credential or stands up a network path.

​

Trust model

Two parties touch a break glass session, and only one of them is trusted to grant access:

• The vendor control plane coordinates the workflow (it relays the request and the approval, drives the session). It is not trusted to grant access on its own.
• The appliance controller (the Tensor9 component running inside your customer’s account under your customer’s IAM) makes the actual security decision. It re-verifies your customer’s signature against the customer’s pinned public key and only then mints anything.

The consequence: even a fully compromised vendor control plane cannot mint access, widen its privilege, redirect it at a different resource, or extend its duration. None of those is possible without your customer’s signing key, which the control plane never holds. The security decision is made on the appliance controller in your customer’s environment, not in vendor infrastructure.

​

The approval is customer-signed

Break glass uses the same customer-signed approval mechanism as operations: your customer signs with an Ed25519 private key that lives in their own environment and never travels to your control plane, and the appliance controller verifies against a public key your customer has pinned into the controller’s secret store. If your customer has already set up signing for operations, break glass approvals work immediately. The mechanics of that keypair (how it’s generated, where the private key lives, how the public key is pinned, and how to rotate it) are documented in the operations security model. Rather than restate them, this page covers what’s specific to break glass.

​

What the approval binds

A break glass approval is a signature over an explicit, fixed set of request fields, not a blanket grant. The signed set is what defines what your customer is consenting to: Because the signed set is a deliberate allowlist, an approved request can’t be silently redirected at a different resource, escalated in privilege, or extended in duration after your customer signs. Any such change alters the signed bytes and fails verification. The appliance controller re-derives the signed data from its own view of the request and compares; it does not trust values handed to it at mint time. Approvals are also single-use and carry a short validity window, so a captured approval can’t be replayed. When the credential is produced by an operational command, the approval binds the exact command and its inputs, and the appliance controller re-checks that the command it’s about to run is exactly the one your customer approved before it runs anything. See operations security for how command approval and integrity are signed and verified.

​

Least privilege and time-boxing

Two properties bound every session:

• Scoped to one resource, one session. A session reaches exactly the resource your customer approved, using a credential minted for that session alone. It does not grant standing access to anything else.
• Time-boxed. The credential’s lifetime is tied to the duration your customer approved. Your customer’s own environment may shorten it further (for example, a Kubernetes cluster’s maximum token lifetime), but never lengthen it; where that cap is shorter than the session, the credential can expire before the session does.

“Least privilege” here means scoped and time-boxed, not minimal permissions within the resource. The privilege level inside the resource is whatever the approved request specifies: the shipped Kubernetes path, for instance, mints a cluster-admin-tier credential. What’s bounded is that the credential reaches only that one resource, only for that one session, and only at the privilege your customer signed off on.

​

No standing or stored credentials

When break glass mints a credential (the appliance-controller and operational-command sources), it does not leave it lying around:

• Ephemeral. The credential is minted fresh for the session, not a pre-existing standing credential handed over.
• Delivered once, never durably stored. The credential is delivered to the operator exactly once (consumed on read) and is held only transiently until that single fetch; it is never written to logs or persistent storage. Secrets do not appear in error output that leaves the appliance controller.
• Self-expiring. The credential is short-lived on its own clock, so access ends even if teardown is somehow interrupted.
• Explicitly torn down. At session end the appliance controller deletes the minted identity (revoking the credential) and removes any temporary network path. Teardown removes only the session’s own temporary resources.

For an out-of-band session break glass mints no credential, so there is nothing for it to deliver, store, or revoke on the credential plane; it tears down only the temporary network path, if any. Between sessions, nothing privileged that break glass created remains in your customer’s account.

​

Temporary network paths

When a session targets a private resource, break glass stands up a temporary network path through your configured provider and removes it at session end. The path is created with single-use, ephemeral keys and exists only for that session. Network-level access control within your own network remains governed by your network configuration. For Tailscale, that means your tailnet’s ACLs, which you control; scope them to match the access you intend break glass sessions to have. See Network providers for how each provider’s path is configured.

​

Fail-closed

Break glass denies rather than guesses. If the appliance controller can’t verify the approval, it doesn’t mint. If a session’s network path or credential can’t be assembled, the session doesn’t go active. If teardown can’t complete, the failure is surfaced and the credential still self-expires on its own clock. There is no path where a verification or assembly failure quietly results in standing access.

​

Audit

The request, your customer’s signed approval, and teardown are recorded; credential delivery is logged on a best-effort basis. The customer-signed approval is the durable, non-repudiable evidence of consent: an Ed25519 signature over the fixed set of approved fields, preserved on the session record and re-verifiable in principle against the customer’s pinned public key. It is the same approval primitive operations uses, though the turnkey tensor9 ops command audit verify tool is specific to operations commands and does not cover break glass sessions today.

​

Related

• How break glass works: the two-plane model these guarantees apply to.
• Requesting access: the session lifecycle each guarantee attaches to.
• Operations security model: the shared customer-signed approval keypair, signing, and audit mechanics.