The Syself automation has scoped access to your cluster: it provisions nodes, reconciles cluster configuration, and manages the platform. It does not touch or process your data or workloads, and the Syself team, meaning the humans, has no standing access to your cluster. This page states the boundary and shows the parts you can check yourself rather than take on trust. [Security architecture](/docs/hetzner/apalla/security/security-architecture) places this boundary in the whole platform picture.

The automation is the set of controllers that run in the [management cluster](/docs/hetzner/apalla/concepts/foundations/management-and-workload-clusters) (a Syself-operated cluster that creates your control plane and keeps it in the state you configured), plus the provisioner they run in the Hetzner rescue system while a machine is installed. Your workloads run in the workload cluster.

## What the automation does and does not do

| Action                                            | Automation                     | Detail                                                                                                                                   |
| ------------------------------------------------- | ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------- |
| Provision and replace nodes                       | Yes                            | Creates servers, installs the OS image, joins nodes                                                                                      |
| Reconcile cluster objects                         | Yes                            | Cluster API controllers keep the control plane matching your configuration                                                               |
| Reach your API server                             | Yes, through gate tickets      | Short-lived credentials for joining nodes and platform traffic, capped at two hours                                                      |
| Reprovision bare-metal servers                    | Yes, through the rescue system | Boots the server into the Hetzner rescue system through the Robot API and reinstalls from there; it does not log in to the node over SSH |
| Run code inside your workloads                    | No                             | It manages machines and cluster objects; it runs nothing in your pods                                                                    |
| Read or process workload data                     | No                             | Your application traffic and storage never pass through the management plane                                                             |
| Read your application Secrets in normal operation | No                             | No management-plane component lists or reads workload Secrets as part of provisioning or reconciliation                                  |

## Limits you can verify

Each of these is visible in the cluster configuration the platform deploys, so you can check it in a running cluster rather than trust a statement.

- **KubeGate cannot mint credentials.** KubeGate, the proxy that fronts your API server, verifies gate tickets against the cluster CA public certificate. It bind-mounts `/etc/kubernetes/pki` read-only, but it runs unprivileged as UID 65532, never as root, so it cannot read the CA signing key (`ca.key`, mode `0600 root:root`). It can check a ticket, not mint one. See [Restrict API server access](/docs/hetzner/apalla/security/restrict-api-server-access).
- **Gate tickets expire after two hours.** KubeGate rejects any ticket signed for longer than its `maxTicketLifetime` of `2h`, so a leaked ticket has a hard ceiling on its useful life.
- **The etcd encryption key is yours.** When you turn on [encryption at rest](/docs/hetzner/apalla/security/encrypt-etcd), you generate the key and create the Secret that holds the encryption configuration. There is no external or provider-operated KMS in the path.
- **Reprovisioning does not use node SSH.** A bare-metal server is reinstalled by booting it into the Hetzner rescue system, not by logging into the running node on port 100. Machine templates set `noSSHAfterInstallImage: true`, so nothing SSHes into the installed OS. Blocking node SSH does not affect reprovisioning. [Restrict SSH access](/docs/hetzner/apalla/security/restrict-ssh-access) covers that path.

## The full boundary

Syself's access is limited, but it is not zero, and you need to know why before you put the claim in an audit. The management cluster provisions your control plane, so it holds the material that job needs: bootstrap data, machine credentials, and, if you enable etcd encryption, the Secret with your encryption configuration. An operator with access to the management cluster could in principle reach those credentials. The accurate claim is that the automation is scoped to provisioning and management and does not process your data, **not** that Syself can never see anything. [Data at rest and key custody](/docs/hetzner/apalla/security/data-at-rest-and-key-custody) works through where the etcd encryption key lives and what the dedicated management cluster changes about custody.

That scoping is why the verifiable limits above matter: they are the parts of the boundary you can check without trusting a statement. To close the one management-cluster caveat entirely, run the [management cluster in your own account](/docs/hetzner/apalla/security/dedicated-management-cluster), so no control plane and no key ever leaves your boundary.