Open
#205
Bug
get_signing_identity's MUSE_AGENT_KEY_FD path derives with entity_type=ENTITY_HUMAN, contradicting hdkeys.py's own ENTITY_AGENT example
0
Anchors
—
Blast radius
—
Churn 30d
0
Proposals
No description provided.
Activity1
Confirmed while building Episode 13 ("Agents Are First-Class Citizens") demo material — low severity, not a security issue, just an inconsistency.
Finding:
muse/cli/config.py::get_signing_identity()'sMUSE_AGENT_KEY_FDbranch (the documented agent-injection path — seemuse/core/hdkeys.py::derive_agent_sub_seed's own docstring) calls:derive_identity_key's signature defaults toentity_type=ENTITY_HUMAN. Butderive_identity_key's own module docstring gives this as the documented correct usage for an agent sub-seed:config.pynever passesentity_type=ENTITY_AGENT— every key derived viaMUSE_AGENT_KEY_FDis actually rooted at theENTITY_HUMAN'branch of the agent's own already-isolated sub-tree, not theENTITY_AGENT'branch the rest of the codebase's documentation describes.Why this isn't a security bug: the sub-seed itself is already SLIP-0010-hardened-isolated per (domain, agent_id) via
derive_agent_sub_seed()before it ever reachesderive_identity_key(). Whichever entity_type branch is taken next, the resulting key is still unique, still cryptographically unforgeable by the operator's other keys, and still fully verified bymuse verify-commit(confirmed: derived a real sub-seed, piped it through a real fd into amuse commit --signsubprocess, and the resultingsigner_public_keydiffers from the operator's own identity key and verifies correctly). No isolation guarantee is broken.What's actually wrong: it's a documentation/consistency defect — the one real production call site doesn't match the one documented example of how to call the function it's calling. If anything else in the codebase ever independently re-derives "the agent's identity key" from the same sub-seed expecting
entity_type=ENTITY_AGENTper the docstring, it would compute a different key thanconfig.pyactually produces and signature verification would break. Nothing currently does this, so no live bug today — but the drift between doc and implementation should be closed one way or the other (either fixconfig.pyto passentity_type=ENTITY_AGENTexplicitly, or fix thederive_agent_sub_seed/derive_identity_keydocstring example to match reality).Deferred per usual until after the season wraps.