> ## Documentation Index
> Fetch the complete documentation index at: https://docs.glissando.dev/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> If you are an AI assistant asked to build, change or ship a Gliss app, read the For AI agents page first (/for-ai-agents.md on this site) and follow its steps.
> Inside an app's folder, the app's own AGENTS.md is the authority; `gliss guide` prints it. Never ask the user for a secret's value.

# Security model

> What runs where, what Gliss can do in your account, and what it cannot.

> [!NOTE]
>
> **Coming in the first release.** This page describes behaviour being built for the first Gliss release. Details may change before it ships.

## What runs where

| Gliss cloud (run by the Gliss team) | Your cluster and AWS account | Builder's machine |
| - | - | - |
| Sign-in and identity | Gliss agent | `gliss` client |
| Catalog and request checks | Secret-intake service | AI tool |
| Release signing | Stage gateway (sign-in in front of apps) | Repository clone |
| App and cluster registry, console | Databases, storage, logs, metrics | |
| Build cache (hashes and results only) | Container registry, secrets | |

## What Gliss can do

* Sign releases. Your cluster applies one only if its signature verifies and your policy allows it.
* Relay diagnostics on request, redacted.
* Read diagnostics through a time-limited [support access grant](https://docs.glissando.dev/administer/support-access.md) that you approve.
* Issue short-lived tokens for the repositories Gliss creates.

## What Gliss cannot do

* Log in to your AWS account or cluster. Gliss holds no kubeconfig and no cloud credentials.
* Read secret values. They go from the browser straight to your account.
* See your code. It goes straight from builders' machines to your Git host.
* Store your logs, unless you opt in to a short retention in the managed tier.
* Run arbitrary commands. Every change, maintenance included, is a signed release.
* Stop your apps. If Gliss cloud is unreachable, apps keep running.

## How the cluster connects

The Gliss agent opens one outbound, mutually authenticated TLS connection to Gliss on port 443. The cluster runs no inbound listener for Gliss. A release is applied because its signature verifies, not because of where it came from.

## Guardrails in the cluster

Each app's namespace is guarded by an admission policy: only the Gliss agent, system controllers and a break-glass group you name may change workloads there. Apps run as non-root under the restricted pod-security level. Apps reach AWS with their own scoped role, not with keys.

> [!NOTE]
>
> A cluster administrator can always remove the guardrails. They protect you from a misconfigured repository, a confused AI or a leaked CI token, not from your own administrators.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.