Security posture

Keryx reads a customer's telemetry, sends it to a third-party LLM, and publishes conclusions. Its value proposition is a negative capability, so the interesting failures are the ones where a write becomes possible — and the ones where reading is enough to hurt.

Keryx's only write surface is Git PRs that a human reviews and merges; the cluster changes only through your existing GitOps pipeline.

• Read-only by construction

  The enforcement boundary is a read-only RBAC ServiceAccount and a read-only fine-grained GitHub token. MCP read-only flags are defense in depth, not the guarantee — CVE-2026-46519 hit a Kubernetes MCP server whose read-only flag was enforced at tools/list but not tools/call. A denylist test covers every mounted server's write-capable tools.

• Telemetry is treated as attacker-controlled

  Logs, alert annotations and Kubernetes object fields are written by the workloads under investigation. Tool output reaches the model inside nonce-fenced blocks the system prompt marks instruction-inert; the model never executes strings from telemetry.

• Reading is exporting, and we say so

  Everything Keryx reads leaves the cluster — to your LLM provider on every model call, and to Slack as evidence excerpts. A read-only agent is still an exfiltration channel. Redaction at the Slack boundary is opt-in and off by default; stored evidence stays verbatim, because citations are enforced as substrings of stored output.

• Your model keys stay yours

  BYOK: keys are operator-supplied through Helm values into a Kubernetes Secret, never stored in Keryx's database. A pod refuses to start on missing or malformed key config, and the audit logger never logs key material.

Vulnerability disclosure policy and reporting channels are in SECURITY.md on the GitHub organisation: three-day acknowledgement, ninety-day fix target, injection findings explicitly in scope.