Network boundary

Scrydon's network model is shaped by one principle: the customer cluster is the trust boundary. Everything inside it is enforced by mTLS and capability checks; everything outside is treated as untrusted.

Inbound

Inbound traffic terminates at Traefik. Three classes of routes:

There are no public endpoints that expose customer data. The /health endpoint returns only platform liveness — it does not leak version, configuration, or tenant data.

See Ingress hardening for the header-stripping and TLS-termination rules.

Outbound

Outbound traffic falls into three buckets:

Nothing else leaves the cluster. No telemetry, no error reporting to Scrydon, no anonymous analytics. AI-assistant (Chat/Cortex) LLM calls are brokered in-platform to the organization's configured vendor — they appear in the Vendor calls row above, not as a separate Scrydon-hosted egress. If your security policy requires a tightly scoped egress allowlist, the two endpoints above plus whatever installed integrations declare are the entire list.

Air-gapped mode

In true air-gapped deployments, you can:

• Operate offline-only: skip the license heartbeat. Operations continue under your contractual licence; phone-home is disabled.
• Lock vendor integrations to self-hosted providers only. No outbound vendor calls happen. If no reachable LLM provider is configured, the AI assistant (Chat/Cortex) has no model to call and will be unavailable; the rest of the platform is unaffected.

See Deployment → Air-gapped for the full procedure.

Egress allowlist

For non-air-gapped deployments, the recommended egress policy is:

ALLOW  license.scrydon.com:443                # required
ALLOW  <endpoints declared by installed integrations>
DENY   *                                       # everything else

The AI assistant's LLM calls go to the organization's configured provider (e.g. api.openai.com) and are covered by the "installed integrations" line above.

The platform never makes outbound calls to anything not in that list. The list is auditable from Settings → Platform → Extensions (each installed integration lists its declared egress endpoints).

Organization egress policy

Settings → Governance → Egress controls destinations reached by sandboxed notebooks and by reviewed workflow integrations that use Scrydon's controlled fetch. In allowlist mode, a destination must match a configured domain (or an enabled Scrydon default) before any connection is opened. A missing, invalid, or temporarily unavailable policy denies the request.

Redirects do not bypass this decision. Scrydon evaluates the new hostname and repeats DNS and address validation before each redirected connection. Policy denials are recorded as egress.blocked audit events without request headers, bodies, credentials, or full URLs.

Vendor-declared domains

An integration declares the destinations its tools contact in its manifest. With Vendor-declared domains enabled (the default), those destinations are permitted without also listing them in your allowlist — so installing an integration does not require you to first discover which hosts it needs.

The domains an integration declares are shown on its setup screen, above the credential fields, so you can see what you are permitting before you connect an account.

Bounds that still apply:

• A domain on your denylist stays blocked. A manifest cannot reverse it.
• Only declared domains are permitted. Anything else is denied as before.
• Private, loopback, link-local, and metadata addresses remain denied.

Consider turning this off if your organization requires every destination to be explicitly approved. You then list each integration's domains yourself, and an integration whose domains are missing will fail to reach them.

Per-tool egress and SSRF protection

Web-fetch and tool-driven outbound calls are subject to a runtime SSRF check:

• The organization domain policy is applied before connecting.
• RFC 1918 (private) addresses are denied.
• Link-local (169.254.0.0/16) is denied.
• IPv6 unique-local (fc00::/7) is denied.
• Loopback is denied.
• Cluster-internal hostnames (*.svc.cluster.local) are denied.

Private-network and loopback access are separate administrator opt-ins. Cloud metadata and link-local destinations remain denied even when either opt-in is enabled.

This applies to the built-in fetch-webpage tool, the API block, reviewed workflow integrations, and vendor tools whose governed runtime permits an outbound fetch.

An integration author can widen the set of domains reachable by their own integration, but only through the declared-domains mechanism above, only for public HTTPS destinations, and only while Vendor-declared domains is enabled. None of the address-level protections in this section can be widened by an integration, and a denylisted domain remains blocked.

Related

• Ingress hardening — the inbound side of the boundary.
• SPIFFE / mTLS — internal mesh authentication.
• Deployment → Air-gapped — full disconnect mode.