Seylo
Start free Request a design partnership

Trust

Security

Last updated 2 November 2026

In short. Seylo is built so that the AI never holds your keys and the control plane never holds your secrets. The agent in your cluster opens an outbound connection only, there is no shell or attach, and Kubernetes Secret values are stripped before anything leaves your cluster. This page describes what is in place today — nothing more.

1. Architecture

  • Outbound only. The Seylo agent runs in your cluster and connects out to Seylo over an encrypted WebSocket. You do not open an inbound port to your cluster.
  • No shell, no attach. The Service has no capability to open a shell in your containers, at any setting; the tools that would do it do not exist. By default the agent cannot exec either. A cluster can be opted in, by a chart value you set on the cluster and a switch a Seylo admin turns on, both off by default, to let Nightshift run a fixed list of read-only commands while it troubleshoots, with output redacted in your cluster.
  • Secret values never leave. The agent replaces Secret values with a placeholder before serialising anything, and the server strips them again. They are never returned by any API, written to a log, or exported.
  • Your telemetry stays home. Raw metrics, logs and traces collected by the observability chart are stored in your cluster. Seylo queries them when you ask, and redacts log lines on the way out.
  • More detail in the docs: the trust model and how secrets are handled.
  • Agent-managed clusters need no cloud credentials. If you choose to connect a cluster directly instead, the credentials you provide are encrypted before they are stored (see section 3).

2. Changes go through approval

  • By default every change is a proposal. A person with the approver role applies it.
  • Four roles — viewer, releaser, approver, admin — decide who can propose, approve and administer.
  • Exceptions to approval are bounded, expiring and rate-limited, and can be switched off for the whole organisation at once.
  • Every write is read back from the cluster to confirm it landed as approved.
  • An audit trail records who proposed, approved and changed what. The application only ever appends to it. Manifest history is hash-chained, so an altered version is detectable.

3. Identity and encryption

  • Single sign-on through OIDC (Microsoft Entra ID, Google Workspace, Okta, Auth0, Keycloak or any OIDC provider) or SAML (AWS IAM Identity Center, ADFS or any SAML provider).
  • Multi-factor authentication with an authenticator app, email codes and recovery codes. Sensitive actions ask you to authenticate again.
  • Passwords are at least 12 characters and stored as salted scrypt hashes. Accounts lock after repeated failures, and sign-in attempts are rate-limited per IP address.
  • Sessions use HttpOnly, Secure, SameSite cookies with cross-site request forgery protection. Session tokens are short-lived and refreshed in the background; idle sessions end after 24 hours. You can see and end your active sessions.
  • In transit: connections to the Service use TLS.
  • Stored credentials and secrets — directly connected cluster credentials, authenticator secrets, identity-provider secrets, model API keys, notification-channel secrets and Git tokens — are encrypted with AES-256-GCM before they are written. Notification-channel credentials are write-only: they can be replaced, never read back.
  • Tokens for the agent, enrolment and coding agents are stored only as hashes.

4. Coding agents

  • Each coding-agent token reaches one namespace that an administrator opened to coding agents. Nothing is open by default.
  • Tokens expire after 30 days by default, never more than 90, and allow at most 20 deploys a day.
  • Coding agents and AI assistants can read metrics, logs, traces, dashboards and alerts for their namespace and propose changes. A person approves every change.
  • No coding agent can read a Secret value, reach a second namespace or approve its own change.

5. Organisation isolation and staff access

  • Every organisation’s data is scoped to that organisation in the application, and an automated test suite checks that one organisation cannot reach another’s.
  • Seylo staff can enter an organisation only through an emergency-access path, and every such entry is recorded in that organisation’s audit trail as well as ours.

6. The software you install

Agent releases are signed with Sigstore cosign and published with a software bill of materials and build provenance, so you can verify what you are running before you install it.

7. Hosting

The Service runs on Microsoft Azure behind Cloudflare. See our sub-processors and data-handling pages for what is stored where.

8. Reporting a vulnerability

Email support@seylo.in with “Security report” in the subject. Include the steps to reproduce and the impact you observed. Please give us reasonable time to fix the issue before disclosing it, do not access data that is not yours, and do not degrade the Service while testing. We will acknowledge your report within 3 working days. Our contact details are also published at /.well-known/security.txt.

9. Questionnaires and compliance

Where we stand on SOC 2, ISO 27001, HIPAA and data-protection law is set out on our compliance page. For a security questionnaire, email support@seylo.in.