Daemonet/Trust and security/Device quarantine

Security concept · device-revocation foundation

Losing the hardware should not mean losing the identity inside it.

Daemonet Device Quarantine is a staged response for a lost, stolen, or compromised machine: revoke its authority now, preserve narrowly scoped owner-encrypted evidence, and decide whether to recover, retire, or wipe it later.

Concept status: signed device revocation exists today. The privileged recovery agent, evidence channel, attestation, and remote-wipe ceremony remain unshipped design work.

WHAT EXISTSOwner-approved signed device removal converges across healthy peers and tears down the revoked device’s WireGuard, private DNS, synchronization, publication, and authentication authority.WHAT DOES NOT YET EXISTNo released Daemonet recovery agent, remote evidence journal, hardware-attestation workflow, location reporting, or wipe command.

The central principle

Quarantine authority before destroying evidence.

A stolen device creates two separate problems: someone may reach the information or authority stored on it, and the rightful owner no longer knows where it is or what state it is in.

Immediate wipe can protect data, but it can also destroy recovery information, later integrity evidence, and the command channel. Daemonet’s identity model allows the network authority to die independently of the hardware.

01Revoke sessions

Assume credentials exposed to an unlocked device may need replacement.

02Remove trust

Healthy peers reject the old device identity, routes, names, and service authority.

03Seal secrets

A future endpoint agent unmounts, clears, re-encrypts, or destroys selected local authority.

04Enter quarantine

Normal synchronization and administration stop; only a narrow recovery role remains.

05Preserve evidence

Approved device-state observations become encrypted, signed, and hash-chained.

06Assess recovery

The owner distinguishes uncertain observations from verified possession and integrity.

07Recover or wipe

Restoration issues a new identity. Destruction requires stronger deliberate authority.

Explicit state, visible consequence

A device does not jump from trusted to erased.

Each transition is a signed security decision with a different authority threshold. A missed heartbeat or unfamiliar network may raise suspicion; it must not become proof of theft or an excuse for automatic destruction.

01Normalauthorized
02Suspiciousstronger proof requested
03Quarantinedauthority removed
04Recovery pendingphysical and integrity checks
05Restoredfresh device identity
TERMINALRetired

The old identity remains permanently revoked even if the hardware reconnects.

DESTRUCTIVEWipe pending → wiped

A separately authorized policy destroys selected protected material and may permanently end recovery visibility.

Cryptographically authorized commands

The recovery channel is not a remote shell.

A quarantined device accepts only a small, versioned command vocabulary. Every command names the exact device, action, policy, validity window, sequence, previous command, and required signer set.

Restore cannot replay an older command after quarantine. Wipe can require a stronger quorum than containment. No provider receives a universal recovery key merely because it delivers the command.

{
  "version": 1,
  "command_id": "cmd_01J…",
  "device_id": "device:8e92…",
  "action": "enter_quarantine",
  "issued_at": "2026-07-16T04:20:00Z",
  "expires_at": "2026-07-23T04:20:00Z",
  "sequence": 184,
  "policy": {
    "revoke_service_access": true,
    "seal_local_vaults": true,
    "enable_recovery_reporting": true
  },
  "previous_command_hash": "sha256:91b7…",
  "signatures": ["owner:…"]
}
DEVICE ACCEPTS ONLY WHEN
  1. An enrolled owner or recovery authority signed the exact envelope.
  2. The device identifier and permitted action match local policy.
  3. Validity, sequence, prior-command hash, and replay state all pass.
  4. Every required co-signature is present.
  5. The requested operation stays inside the recovery vocabulary.
Example thresholds

One owner key may quarantine. Restore may require physical confirmation. Wipe may require two devices or one device plus a separate recovery key.

The endpoint recovery agent

Security infrastructure—not a rootkit.

The proposed agent is a small privileged service installed during legitimate ownership. Its narrow job is to receive signed commands, change device state, seal local authority, create approved encrypted observations, deliver them, and acknowledge execution.

It must be visible to the legitimate administrator, removable after verified recovery, and incapable of spreading, scanning arbitrary networks, or accepting arbitrary code execution.

ALLOWED ROLE
  • receive exact signed commands
  • seal selected local authority
  • record approved device state
  • encrypt reports to the owner
  • send through approved routes
  • perform a separately authorized wipe
FORBIDDEN ROLE
  • record people or conversations
  • read unrelated user content
  • capture passwords or keystrokes
  • scan or exploit nearby systems
  • hide from the rightful administrator
  • resist valid ownership transfer
Ownership boundary

The agent belongs only on a device the installer owns or is explicitly authorized to administer. Employers may revoke their own persona and data without gaining personal recovery authority. A sale or transfer must permanently remove every prior owner and report destination.

Owner-encrypted evidence

Record the device’s state—not the person holding it.

Each approved event can bind sequence, boot identifier, monotonic and trusted time, event type, encrypted-payload hash, and the previous event hash, then receive a device or hardware-backed signature.

The journal can expose tampering or missing entries. It cannot prove a compromised firmware stack told the truth, turn an approximate IP region into an address, or make a cryptographic record automatically admissible in court.

EVENT HASHHASH(sequence + boot + time + type + ciphertext_hash + previous_hash)DEVICE SIGNATURE
DEVICE STATE

Integrity and operation

Boot and shutdown, secure-boot status, failed unlock count, power, disk health, interface state, and hardware or time-source changes.

NETWORK ENVIRONMENT

Narrow observations

The device’s addresses, connected access-point BSSID, gateway, signed public-IP observation, reachability, latency, and an explicit confidence level.

OWNER-ONLY RAW VALUES

Encrypt before delivery

SSID, BSSID, gateway identifiers, IP addresses, and permitted location readings are encrypted directly to the owner or authorized recovery group.

PRIVATE CORRELATION

Keyed fingerprints

An owner-secret HMAC can show that the same network reappeared without exposing the raw identifier to a storage or delivery provider.

OFF BY DEFAULTmicrophone · camera · keystrokes · messages · browser history · opened files · passwords · nearby client scans · biometricsNO SECRET SURVEILLANCE

Offline first, store and forward

A missing device may reconnect weeks later.

The endpoint queues a signed event, encrypts its payload to the owner, retries only through legitimately available owner-approved connectivity, and removes the delivery item only after a receiver signs an acknowledgement.

Multiple drop points can reduce availability risk. A personal Daemon, organization security system, 1Man, another provider, or an encrypted object store can carry ciphertext without becoming identity or evidence authority.

QUARANTINED DEVICEsigned journalowner-encrypted payload
→ approved outbound route →
SELECTED DROP POINTSciphertext deliverypersonal · organization · 1Man · another provider
→ signed receipt →
OWNER DASHBOARDdecrypt and assessobservation with confidence—not certainty
DELIVERY PROVIDER MAY SEErecovery_channel · sequence · ciphertext · ciphertext_hash · device_signatureNO PLAINTEXT REPORT REQUIRED

Recovery and destructive action

The more irreversible the step, the stronger the authority.

Unexpected signals should usually request confirmation. Owner-confirmed wipe is the safest ordinary default. Automatic integrity or location triggers require much stronger engineering, testing, and policy because a false positive can destroy the only surviving data or evidence.

CONTAIN

Immediate authority revocation

Remove the device from trusted services even while it remains offline. Publish a bounded quarantine command for its next permitted contact.

ONE OWNER MAY SUFFICE
RECOVER

Never restore old trust

Verify possession and integrity, reinstall when appropriate, generate a new hardware-backed key, re-enroll, and retire the old identity permanently.

PHYSICAL CHECK + FRESH IDENTITY
WIPE

Destroy deliberately

Choose immediate, delayed, integrity-triggered, location-aware, or explicit-only policy before loss—and understand that evidence visibility may end.

QUORUM OR SECOND CONFIRMATION

Beyond laptops and phones

Quarantine the implementation. Preserve the service identity.

The same authority split applies to an organization laptop, server, contributed node, virtual machine, container, kiosk, or field device. A compromised instance can stop work and remain inspectable while a clean replacement inherits only freshly authorized service authority.

ORGANIZATIONS

Bound the employer role

Revoke corporate identities and data, require quorum for sensitive actions, retain only declared evidence, and preserve employee-private personas.

SERVERS

Isolate suspicious infrastructure

Stop workloads, remove service identities, seal volumes, preserve logs, and retain only a restricted incident-response channel.

COMMUNITY NODES

Stop earning and serving

A suspicious node no longer stores new shards, relays traffic, runs compute, issues proofs, or earns contribution credit.

VIRTUAL WORKLOADS

Freeze the instance

Snapshot, revoke secrets, remove normal networking, move to an isolated analysis segment, and issue a clean replacement identity.

SERVICE CONTINUITY

Identity outlives the host

The stable service can move to a replacement while the compromised machine remains quarantined and unable to impersonate it.

INCIDENT EVIDENCE

Export with limits

Provide signatures, chain validation, commands, acknowledgements, measurements, and confidence notes without promising legal admissibility.

Evidence state

A compelling security design is not a shipped recovery product.

This example extends naturally from Daemonet’s owner-controlled identity model, but each privileged endpoint and destructive action needs platform-specific implementation, external security review, abuse analysis, and destructive failure testing.

IMPLEMENTED FOUNDATION

Signed device revocation

Owner-approved removal converges, tears down the revoked local peer, and removes its authenticated profile, WireGuard, private-DNS, publication, and synchronization authority.

PROTOCOL DESIGN

Quarantine command and journal

Envelope fields, state transitions, recovery quorums, chained evidence, encrypted store-and-forward, and signed receipts still require a formal versioned protocol.

PLATFORM WORK

Privileged recovery agent

Linux, Windows, macOS, mobile, TPM/secure-enclave behavior, full-disk encryption, secure boot, offline queues, and clean removal need separate implementations.

RELEASE GATE

Safety before remote wipe

Ownership transfer, stalking and employer-abuse defenses, false positives, quorum loss, firmware compromise, destructive wipe, restore, and evidence-export canaries must pass.

Hard limits

A powered-off or radio-disabled device may never receive a command. Physical attackers can destroy or replace hardware. Network identifiers can be moved or spoofed. Firmware compromise can undermine software evidence. Quarantine protects network authority first; it is not perfect tracking or a guarantee of hardware recovery.

The device is one representative—not the owner

Quarantine the device. Preserve the evidence. Recover deliberately.