Security and data flows

Isolation

• One stack per organisation. No container, database, certificate or credential is shared with another customer's stack.
• Every password, key, token and certificate authority is generated on your server by the install. None is built into an image.
• Internal services have no host port; only the gateway (443, 80) and the manager (1514) are published, plus, on a two-server core, four ports on the private address for the application server.

What leaves your network

Self-hosted

Data	Goes to	When
Stack health (service states, probe results), version, and the agent list (names, addresses, OS, status)	Schildmark Leitstand	Every 5 minutes and after each change
Install progress, step output (passwords masked)	Schildmark Leitstand	During installs
Generated secrets and the stack's CA	Schildmark Leitstand, sealed	Once, when the core or single server finishes its install, so that a second server or a re-install can use them
The first administrator's password	Nowhere: shown in your terminal and kept in FIRST-LOGIN.txt
Alerts, events, vulnerabilities, inventory	Not sent to the control plane
Questions and the data Schildmark Analyst reads	Your LLM endpoint	When Schildmark Analyst or AI features are used
Vendor API calls	AWS, Cloudflare, Microsoft, Sophos	When configured
Vulnerability feed downloads	NVD, Microsoft, Canonical, CISA, the engine's vendor	Regularly; requests, no customer data

The configuration we manage for you (including integration secrets such as an AWS key you give us) is held by the control plane and sent to your server inside a signed job.

Hosted by us

The stack runs on our infrastructure, so all its data is there, isolated per customer. Endpoints send their events to it over TLS. We keep the first administrator's sign-in sealed until we hand it over.

Optional hosted services

With hosted Schildmark Analyst or hosted patching, the alert, inventory and vulnerability data those services read leaves your infrastructure for ours.

• Each customer's hosted services run in their own containers, on networks no other customer's containers are attached to, with no route to the internet except, where a service needs it, through a proxy that allows only named vendor hosts. Containers run without privileges and with memory and CPU limits. Isolation between customers is tested before each release.
• They reach your stack over one connection your stack opens: TLS 1.3, mutual, each side pinning the other's certificate. Each side accepts only the fixed list of services the other may reach; anything else is refused and logged. No inbound port is opened on your side.
• They sign in to your stack with their own least-privilege accounts: Schildmark Analyst can read your data and write only its own; patching writes only its jobs, results and agent records.
• What they store stays in your stack's indexer.
• Hosted Schildmark Analyst sends questions and data to an AI provider through our LLM gateway, per your AI data policy (Standard, BAA only, Off), enforced on every request by the gateway. No BAA-covered provider is in service yet, so BAA only currently refuses every AI request.

Data	Goes to	When
Alerts, inventory, vulnerabilities the hosted service reads	Our environment, your organisation's containers	While hosted Schildmark Analyst or hosted patching works
Questions and the data hosted Schildmark Analyst reads	An AI provider through our LLM gateway, as your AI data policy allows	When Schildmark Analyst is used
Patch traffic of your endpoints	Relayed by your stack to hosted patching	With hosted patching

Credentials

Credential	Where it lives
Service passwords and keys	theseus.env (mode 0600) and runtime/ (directory 0700) on the server
Internal CA and certificates	runtime/pki/; runtime/pki/extra-ca.pem (optional) is a CA you add to the services' trust bundle
Patch job-signing key	runtime/pki/agent/jobs.key; endpoints pin its public half at enrolment
Vendor connector credentials	runtime/connectors/<name>.json
Cloudflare credentials saved in the console	The console database, encrypted
User passwords	Keycloak's database
Enrolment tokens	Only a SHA-256 hash; the token is shown once

Services use least-privilege accounts towards each other: the enrolment service's manager API account can only register, read and delete agents and assign groups; console services use an indexer account without security administration.

Endpoints

• Monitoring agent registration never ships a shared password. The registration port (1515) is not published; agents are registered by the enrolment service through the manager API.
• Package signatures are checked: The engine's repository key (Linux), Authenticode (Windows), Developer ID (macOS).
• The Schildmark Agent connects out only; endpoints open no port. Each request is signed with the machine's own Ed25519 key, created on the machine; only its public half leaves it. Requests must be fresh and their nonce unseen.
• Jobs are signed by your stack's job key, pinned at enrolment. The agent runs a job only if it verifies, names this machine and has not expired. Jobs name one of a fixed set of actions (exact package versions, Windows KBs, Homebrew, reviewed winget and pip helpers, reboot, monitoring agent restart, stop, start, uninstall). There is no shell and no "run command" action.
• Revocation: removing a machine revokes its enrolment; its next request is refused.

Leitstand node

• Outbound HTTPS only; it pins the control plane's TLS key.
• Requests signed with its own Ed25519 key; jobs signed by the control plane and refused when the signature, target node, time or job id is wrong. Each job id runs once.
• A fixed list of jobs, each running ./theseus with fixed arguments; no "run command" job, and no values interpolated into command lines.

Sign-in

Keycloak for the console, Schildmark Analyst and the SIEM dashboard. Password policy: 12 characters minimum, upper case, lower case, digit, special character, not the username or e-mail. Page access per role; changes are recorded in the audit log.

Known limits

• The manager API's certificate is issued by the manager itself and is not yet pinned by the services that call it (on the internal network).
• Internal service-to-service authentication uses static generated keys, one per pair of services.