probectl threat model

This is the system-wide threat model — the security design written from the attacker's side of the table: what probectl protects, who might attack it, and — boundary by boundary — what stops them and what honestly does not yet. It is versioned with the code and should be reviewed on any change to a trust boundary and at each release. Every mitigation cites the code, CI gate, or document that enforces it, so you can verify rather than trust.

Companion docs: agent-whitepaper.md (the agent in depth), incident-response.md (what happens when something breaks), ../hardening.md, ../isolation.md, and the project non-negotiables.

1. What we protect (assets)

2. Trust boundaries

A trust boundary is a line in the architecture where the level of trust changes — whatever crosses it must be authenticated, tenant-scoped, and treated as possibly hostile, because the thing on the other side may lie. The diagram is a map of border crossings: B1–B8 name the checkpoints, and §4 inspects each one.

[tenant user] --TLS/session--> [control plane] <--mTLS+SPIFFE--> [agents]
      |                          |       ^  ^                      (CAP_BPF hosts)
 [provider operator]             |       |  +--TLS/auth-- [OTLP/webhook senders]
  (separate domain,              v       |
   break-glass only)        [bus (Kafka, TLS)]--> [stores: PG(RLS)/CH(row policy)/TSDB]
                                 |
                            [AI adapter] --three-gated TLS--> (optional remote LLM)
                            [MCP server] --tenant-then-RBAC--> callers

B1 tenant↔tenant (inside every shared component) · B2 agent↔control plane · B3 ingest surfaces (bus, OTLP, webhooks) · B4 control plane↔stores · B5 operator/provider plane↔tenant data · B6 AI/MCP↔models and callers · B7 build/release↔deployments · B8 agent↔monitored host · B9 endpoint/DEM agent↔bus (a deliberately distinct, lower trust tier).

3. Attacker profiles

1. External unauthenticated — internet/intranet reach to exposed listeners.
2. Malicious tenant (the defining multi-tenant adversary) — valid credentials, hostile intent, aims at B1.
3. On-path network attacker — can intercept/inject between components.
4. Compromised monitored host — controls traffic the agent observes and the local TLS libraries the L7 probe attaches to.
5. Compromised agent node — has the agent's identity and CAP_BPF.
6. Malicious/compelled provider operator — legitimate provider-plane access, wants silent tenant-data reach (B5).
7. Supply-chain attacker — targets deps, CI, artifacts (B7).
8. Prompt-injection attacker — plants payloads in telemetry that the AI layer will read (B6); needs no credentials at all.

4. STRIDE by boundary — mitigations (evidence) and gaps (register IDs)

STRIDE is the standard checklist of ways a system can be attacked: Spoofing (pretending to be someone else), Tampering (altering data or traffic), Repudiation (denying an action because no trustworthy record exists), Information disclosure (reading what you shouldn't), Denial of service (making it unavailable), and Elevation of privilege (gaining power you weren't granted). Each boundary below lists the STRIDE threats that apply to it and the code or CI gate that answers each one.

B1 — Tenant ↔ tenant (the outermost boundary)

This is the boundary that matters most: a malicious tenant with valid credentials trying to reach another tenant's data. The full storage-layer mechanism is in tenant-isolation.md; the summary by threat:

B2 — Agent ↔ control plane

B9 — Endpoint/DEM agent ↔ bus (a distinct, declared trust tier)

probectl has two agent trust models, and this section exists so the second one is a decision rather than an oversight.

The canary agent (B2) holds an mTLS client certificate with a SPIFFE-style identity; its tenant comes from the certificate, never from the payload, and the control plane re-stamps the identity before publishing to the bus. The endpoint/DEM agent is different: it runs on employee laptops and desktops, asserts its tenant_id from local YAML with no certificate and no SPIFFE, and publishes directly to probectl.endpoint.results.

That is a real reduction in trust, and it is accepted deliberately: DEM's value is coverage of the actual end-user fleet, and requiring per-device certificate enrollment on every laptop is the reason most DEM deployments never reach meaningful coverage. The tier is declared, not hidden, and it is contained by one rule:

The endpoint payload's tenant is never authoritative. Every endpoint lane is a VERIFYING lane: the claimed (tenant, agent) is checked against the agent registry before a single sample is stored, and a claim that does not verify is refused and counted — never stored, never re-attributed.

What this tier does not protect against, stated plainly: an attacker with code execution on an enrolled laptop can emit plausible but false measurements for that laptop's own tenant. Registry verification binds the claim to a registered agent; it does not attest that the numbers are real. Treat DEM samples as fleet-experience telemetry, not as evidence in a dispute.

B3 — Ingest surfaces (bus, OTLP, webhooks)

B4 — Control plane ↔ stores

B5 — Provider/operator plane ↔ tenant data

B6 — AI / MCP

B7 — Supply chain (build → release → deploy)

B8 — Agent ↔ monitored host

5. Known gaps (the honest list — tracked, not hidden)

A threat model that claims no gaps is not honest. These are the open items as of this revision:

6. Review log