Managing Partner Control Boundary

A managing partner helps an operator become and stay operational: hosting, DNS, onboarding, runbooks, trust bundle packaging and client coordination. Connectorzzz is the intended example. This page is the boundary between what the partner may do and what stays with the operator. RFC-008 defines the role; this page is the operational checklist.

The boundary

Action	Operator	Managing partner
Hold the root key	yes	never
Hold operator (admin) keys that approve trust changes	yes	never
Hold the NA signing key	yes (recommended)	only with the operator’s written approval (“managed NA key” model), never as the default
Issue, revoke, suspend or replace treaties	yes	no
Issue and revoke membership attestations	yes	no
Publish the revocation feed	yes	no
Publish and activate boundary policies	yes	no
Run the NA process, database and backups	optional	yes, on request
Manage endpoints and DNS	optional	yes, on request
Assemble trust bundles and proof bundles	yes	yes (assist)
Run continuity checks and runbooks (RFC-007)	yes	yes (assist)
Fork, exit, or switch partner	yes	cannot block

How the software enforces it

• Admin actions need an operator key. Every trust-changing route (treaties, attestations, revocations, policies, feed imports) requires a signed admin request from a configured operator key. Keys have tiers; issuing and revoking need a privileged key.

• Operator keys can be revoked at runtime (genesis-mesh admin revoke-operator-key); a revoked key is refused before its signature is checked. An operator can remove a partner’s access without the partner’s cooperation.

• Every admin action is audited with the key id that signed it (genesis-mesh managed audit-export), so the operator can see what the partner did.

• No built-in authority. The software has no Genesis Core or partner key baked in (genesis_mesh/tests/test_operator_independence.py).

What the software cannot enforce

• If a partner runs the NA process and its database, it can technically read the database and the process memory. The split-operation custody model (the partner runs the service; the operator holds the operator keys and approves every treaty and revocation) keeps trust decisions with the operator, but the operator must still trust the partner’s operation of the host. A deployment where the operator also runs the host removes that.

• If a partner holds the NA signing key, it can sign anything the NA can sign. See Operator Exit and Fork for why that key must then be treated as exposed when the relationship ends.

Pilot checklist

• Root and operator keys generated by the operator, on the operator’s machines; the partner never received them.

• Partner access, if any, is a separate operator key with the lowest tier that its tasks need, and the operator knows how to revoke it.

• The NA signing key is in a key store the operator owns (for example the operator’s own Azure Key Vault with managed identity), or the operator approved the managed-key model in writing.

• The operator has a current database backup and evidence export it can restore without the partner.

• The operator has rehearsed Operator Exit and Fork.