> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt
> Use this file to discover all available pages before exploring further.
# 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](/fundamentals/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](/fundamentals/operations/security). 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:
| Bound field | What it pins |
| ----------------- | ----------------------------------------------------------------------------------- |
| Resource | The one appliance and resource the session targets |
| Privilege | The access level being requested for that resource |
| Duration | How long the session and its credential may live |
| Network provider | Which path the session may use to reach the resource |
| Credential action | For a command-minted credential, the exact operational command and its exact inputs |
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](/fundamentals/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](/fundamentals/break-glass/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](/fundamentals/operations/security) 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](/fundamentals/break-glass): the
two-plane model these guarantees apply to.
* [Requesting access](/fundamentals/break-glass/lifecycle): the
session lifecycle each guarantee attaches to.
* [Operations security model](/fundamentals/operations/security): the
shared customer-signed approval keypair, signing, and audit mechanics.