Trust model

This page is for whoever has to approve installing Seylo in a cluster they are responsible for. It states what we can reach and what we cannot, and it is deliberately specific about the worst case.

What Seylo holds

Cloud credentials for agent-managed clusters	None. There is nothing to leak
A network path into your cluster	None. The connection is outbound-only, from you to us
Your Secret values	None. No surface returns one — see how secrets are handled
Shell access to your containers	None. pods/exec and pods/attach exist in no grant our chart can produce
Your workload inventory, manifests and history	Yes — that is the product

How the connection works

The agent runs inside your cluster and dials out. Your cluster accepts nothing inbound: no Service, no Ingress, no NodePort, no container port.

The agent authenticates to Kubernetes with its own ServiceAccount, using the in-cluster configuration. Seylo never holds an AKS, EKS, GKE or OKE credential for that cluster.

This is why no firewall change is needed, and it is why platform teams allow the agent at all.

The worst case, stated plainly

If Seylo’s central server were fully compromised, an attacker would get: the ability to issue commands within the agent’s RBAC, on enrolled clusters. With the default deploy posture that means patching images, applying the managed manifest kinds, editing ConfigMaps, restarting Deployments and creating namespaces.

They would not get:

• any cloud credential — we hold none;
• any Secret value — the refusal is enforced in the agent before serialisation and again on the server, so a compromised server cannot ask for one;
• delete, anywhere — unless you enabled the destructive tier;
• exec or attach — no code path and no RBAC rule exists;
• access to non-managed namespaces, when you install namespace-scoped;
• access to any cluster whose agent you have revoked or uninstalled.

Why that list is short

Because the boundary is Kubernetes RBAC in your cluster, not a policy in our code. You can read the grant yourself — kubectl get clusterrole seylo-agent -o yaml, or kubectl get rolebinding -A | grep seylo-agent — and what it says is what is true.

Defence in depth on top of RBAC

The agent also enforces its own scope. A command naming a namespace outside its watched list is refused before any API call is made. So even a compromised Seylo server cannot widen the blast radius beyond what you configured, whatever it sends.

Credentials, and how they are stored

Two secrets exist in the agent relationship, and neither is stored in plaintext by Seylo:

	Enrollment token	Per-agent credential
Lifetime	~1 hour, single-use	Long-lived
Where the real value lives	Your cluster, in the Secret you installed with	Your cluster, in the agent’s own Secret
What Seylo stores	A hash	A hash

A token cannot be recovered from its hash. The enrollment token is never written to the audit log, and the install page issues it over POST so it never appears in a URL — and therefore never in a reverse proxy’s access log.

Revoking an agent is immediate and is done from the same page that installed it.

Coexisting with Argo, Flux and Helm

A change to an object that Helm, Argo CD, Flux or an operator owns is refused with HTTP 409. The refusal names the controller, quotes the evidence — which annotation, label, ownerReference or field manager proved it — and states the consequence.

Proceeding requires an explicit acknowledgement, which:

• records who acknowledged and when, with the full ownership report attached to the approval, so the approver sees the owner before approving;
• writes a dedicated audit row — also written when a change is blocked at approval time, because an owner appeared after submission;
• is re-checked inside the mutating engine, so an approved-hours-later request or an unattended scheduled deploy cannot slip past a new owner.

Enforcement is server-side at three points — submit, approval, and the engine. The interface only explains the refusal.

An ownership check that cannot be performed — an older agent, or missing RBAC — does not block, but is recorded as a warning. It is never recorded as “nothing owns this”.

What we will not add later

These are design positions, not unimplemented features:

• Container exec. A shell cannot be dry-run, diffed, version-recorded, verified or reviewed, and it reads Secret values trivially.
• Returning Secret values. Including to an administrator, including in an export.
• Inventing a number. An unknown cost or metric is reported as unknown, with the reason. It is never estimated from a similar workload.
• Acting outside an approved envelope. Autonomy exists only inside a signed, bounded, expiring and rate-limited grant that you issue.

What to check before approving an install

1. Read the RBAC that will be created — the install page renders it before you apply anything, and helm template renders it without installing.
2. Verify the image and chart signatures.
3. Decide the posture and scope. deploy plus namespace scoping is the tightest useful combination.
4. Confirm the egress rule you are adding: one host, port 443, outbound.