sharness.ai / mockups and experiments / edge matrix
The edge matrix: who may talk to whom
A mockup of the design's edge matrix, from Architecture. Click a cell, caller down the side and callee along the top, to see whether the connection is allowed and, when it is not, which layer refuses it first. Deny by default: the app never talks to the KMS; only sharness.net and sharness.llm do, and the KMS never returns a clear key to either.
Status: a mockup of the designed matrix as of 24 Oct 2026; nothing here enforces anything. What was measured: with a session CA and role certificates, app→fs, app→net and net→kms accepted; fs→kms, app→kms and fs→net refused, exactly per the matrix (Evidence §6). The layers below are the design's enforcement map (Policies §5).
Click a cell
For example app → kms, the one edge the whole design is built around refusing.
The layers, in the order they refuse
- Kernel: network namespace or Landlock port rule. A component with no network at all (the KMS, the fs) is in an empty network namespace; a component with some network may only connect to the ports its policy lists. The connection never leaves the caller.
- Kernel:
SO_PEERCREDon a Unix socket. Locally, the callee reads the caller's uid and refuses one that is not the expected role's. An independent check, no crypto involved. - Mutual TLS with the session CA. Both sides verify the chain to the session CA (whose key was destroyed after issuing) and read the peer's role from its certificate's SAN URI; the pair (caller, callee) must be in the edges list. A compromised component cannot pose as another: it has no certificate for that role.
- Schema on the payload. Even on an allowed edge, the request must match the callee's schema and its business rules (op, vault id, host) before anything happens.
Rule of thumb from the design: a business rule is only a Boundary if it is enforced in a different process from the one it constrains. The matrix is that rule, drawn.