feat: Support NIP-46 Remote Signing aka nsec bunker

[Giszmo]

Exposing private keys to different clients is a dangerous pattern clients should not encourage. If at all feasible, the app should build on remote signers or discourage pasting existing keys or at the very least allow power users to use a remote signing device.

Nostr does not support key rotation or sub-keys, so users end up with their keys being handled by multiple clients on multiple devices and sometimes even online services. Most social clients these days support nip46.

[eriknewton]

+1. The strongest case here is agents: every buzz agent holds its own nsec, and a key an agent can read is one prompt injection away from signing anything. NIP-46 puts the key behind a boundary that can say no. That upgrades signing from attributable to enforceable, which matters more for agent members than for any human client. We hit exactly this building Sanctuary (agent key custody: encrypted at rest, transient decrypt for signing, gated approvals). Glad to compare notes.

[kennethkabogo]

+1. the attributable vs enforceable framing is right. NIP-46 gets you partway there but it leaves one question open: what enforces the no? if the signer is a process on a general-purpose host, the enforcement is still a software promise and a compromised host, poisoned dependency or stolen key can substitute a signer that says yes to everything while presenting a valid NIP-46 interface.

hardware attestation closes this gap cause the key can only ever be exercised inside an enclave whose measured code hash matches an expected value, enforced by the KMS at key-release time and not by the process itself. signer can't be swapped out without breaking attestation, the session log is hash-chained and independently verifiable and key custody is structural. not even the operator can extract the nsec from a running enclave.

we're building this out in VAR with an evidence-bundle spec called APEX that a third party can verify without trusting us. a natural extension for buzz would be a companion NIP (we've been calling it NIP-EA), an optional ["attest", "<bundle-id>", "<pcr0>", "<attestation-endpoint>"] tag on agent events, so verifiers that care about execution integrity can check it independently and verifiers that don't can ignore it.

would be happy to compare notes because it sounds like we're working on adjacent pieces of this, especially with Sanctuary.

[eriknewton]

Agreed on the diagnosis, and I would put the boundary a layer lower.

We enforce at the OS boundary on a general-purpose host: the agent gets its own account, and a kernel packet filter denies that account every destination the operator has not approved. Measurements on an unmodified Hermes agent are here: NousResearch/hermes-agent#4656. Off-list hosts denied 18 of 18, my own account unaffected 30 of 30 in the same window.

That answers a different question than attestation does. Yours establishes that the code holding the key is the code you expect. Mine bounds where a process can talk at all, and needs no enclave.

Honest limit on mine: root is above it. A host compromised to root can disable the filter, and I measured exactly that this week. Enclave-held keys survive that. My wall does not.

Happy to compare notes.

[kennethkabogo]

read #4656 measurement in full. the numbers hold up, and so does the corrected ps. agreed these answer different questions and I'd push the distinction one step further than needs no enclave.

Castle Wall's threat model is a process operating within its own privilege level, like a prompt-injected shell command trying to phone home or exfiltrate over the network. against that, a per-uid kernel egress wall is close to free and your data shows it works, but root doesn't need to beat the wall at all to get the key because it can just read the signing process's memory directly with zero network traffic involved. so "root is above it" isn't only "root can disable the filter." the filter is irrelevant to that path from the start because the key is sitting in ordinary process memory the whole time regardless of what's allowed out on the wire.

that's the specific thing enclave memory isolation changes in kind, not degree. on Nitro, the parent instance's own root cannot read enclave memory. it's enforced by the hypervisor below the guest OS and not by anything running inside it that a privileged attacker could introspect or disable. your wall and an attested signer would be bounding different attacker capabilities. egress control is the right answer to "the agent's own logic tries to leave," and it needs no hardware dependency, which matters cause most agents shouldn't need a TEE just to talk to an LLM API. attestation is the answer to "the thing running isn't the agent's logic anymore." the APEX spec is honest about this same boundary from its own side too - hardware attestation is explicitly out of scope for availability and network-layer attacks. a host can starve or terminate the enclave, it just can't forge what was emitted before that happened.

given that, a serious posture for server-hosted buzz agents probably wants both. Castle-Wall-shaped egress bounding as the default for the common case, enclave-held keys for whoever's running the kind of agent where a root-level host compromise is the threat that actually matters. if a fuller writeup happens here, i'll make sure it cites Castle Wall alongside NIP-OA's own gaps; different failure mode, same underlying question of what a signer can prove versus what it can only promise.