damage_nsecbunker is DamageBDD's in-tree NIP-46 signing service. It places a policy gate between a client request and the configured vault/crypto backend. The supplied modules include the service, operational helpers, relay adapter, client bridge and BDD step implementations.

The strongest recorded operational evidence is release-build run 20260925132037 on 25 September 2026. The supplied console log records all 12 scenarios passing against an installed package. This documentation uses that dated result; it does not claim a new production run on 5 October.

The server reads configuration from application:get_env(damage, nsecbunker) through its configuration module. It builds a policy, prepares the runtime vault and reports whether it is ready. Bootstrap failures leave it unready and subject to its retry path. A ready status is necessary before requests can be accepted.

Inbound relay traffic passes through damage_nsecbunker_relay and damage_nostr_relay_client to the bunker. The bunker produces a response event; the relay path publishes it. The adapter handles delivery, while policy and cryptographic operations remain in the bunker path.

The supplied live test encrypts its requests through the NIP-44 client helper and validates decrypted responses for the current request. NIP-46 provides the remote-signing message contract; see the upstream specification. The successful restricted-policy suite is not a claim that every optional NIP-46 method is enabled or tested.

The service builds policy from configured client keys, allowed methods, allowed event kinds, timestamp tolerance, event-size limits, required tags and content restrictions. It also carries signing timeout and rate-limit settings. Defaults and effective values depend on the installed configuration and policy module; the live report should be read against that configuration.

For the supplied handoff, the suite exercises ping, get_public_key and allowed kind-30023 signing. It checks rejection of a non-allowlisted method and a kind outside the running policy. Returning a signed article and publishing that article are separate actions. Response events must still travel back to the client even when article publication by the bunker is disabled.

The non-publication assertion is a bounded observation on the checked relay path. It should not be interpreted as proof that no copy of an event could exist anywhere or be published by another authorised holder later.

The release run explicitly checks that aws_secrets_manager is the running secret provider and that the local DETS nsecbunker_vault_passphrase lookup has no entry. Vault readiness and agreement between the vault guard public key and running policy also pass.

This establishes the tested runtime state. It does not independently document the historical deletion of a DETS entry, a subsequent restart with that entry absent, the full IAM policy or the security of every host process. AWS secret retrieval is also not evidence of non-exportable HSM signing.

The operator confirmed that setup requiring temporary Sandbox Administrator access was complete and that the access could be revoked. That is a handoff instruction recorded separately from the BDD result; the run does not prove that revocation actually occurred. The agreed runtime permission was secretsmanager:GetSecretValue scoped to the designated secret ARN.

The latest supplied service exports both status/0 and handoff_status/0. The latter returns readiness, start time, secret provider, bunker public key and the authorised public-key list from active server state.

damage_nsecbunker:status().
Handoff = damage_nsecbunker:handoff_status().
maps:get(ready, Handoff).
maps:get(secret_provider, Handoff).
maps:get(bunker_pubkey_hex, Handoff).
maps:get(authorized_clients, Handoff).

These are local administrative calls, not a new public HTTP API. The ordinary status contains a policy summary; an omitted client list there does not imply an empty allowlist. policy/0 derives a policy from configuration, while handoff_status/0 is the appropriate inspected interface for the active server's public identity and allowlist.

After an authorised configuration change, reload/0 validates and prepares a candidate runtime. Failure returns an error and retains the previous state; an unready server rejects reload through its not-ready branch. Always inspect the returned result and the active handoff state instead of assuming an edited configuration was applied.

The suite also asserts audit correlation and the absence of secret material in its test context. Those checks do not establish that every application log, OS dump or unrelated storage location is secret-free.

Relay scenarios use the node's existing damage_nostr identity. The requested LodgeiT client key is checked separately through the local policy gate. Its successful allowlist probe does not prove possession of that client's private key or exercise Andrew's client end to end. That external smoke test remains a distinct handoff action.

Runtime code hash:

52eb0f56f8d8b62c61ba789fe361f1938a48f274a9592c66fd16eb92ec84f470

• Execution report
• Context proof

The references are transcribed from the supplied successful run log, not independently re-executed or re-fetched for this article. Its transaction reference is th_FMRtRhp8hRDCgVsUmb3mc6n4vniEdvqFCXB3N37dbZPeEXGJ9.

The handoff discussion also names an AWSPENDING-to-AWSCURRENT rotation rehearsal, vault-file backup/restore test and META/010 support note. The live suite above does not establish those items. It likewise does not establish load capacity, exhaustive policy coverage or indefinite relay availability.

The operational next step is to attach each remaining item to its own dated evidence, including the external client's smoke-test result. This preserves a clear distinction between a green runtime suite and completion of the wider handoff checklist.

Source basis: supplied damage_nsecbunker.erl, damage_nsecbunker_ops.erl, damage_nsecbunker_relay.erl, damage_nostr_relay_client.erl and generic_live_nsecbunker_operations(1).feature. Run evidence: Pasted text(20260925-132528).txt.

• Reply subscription, correlation and relay diagnostics
• General DamageBDD Nostr integration
• Current feature documentation and evidence map