# HoneyMesh company pilot guide

**Draft for authorized evaluations · 29 October 2026**

## Objective

Determine whether HoneyMesh can observe relevant abuse, apply a selective source-IP ban on chosen Linux interfaces, and share an approved ban among trusted nodes **while unbanned users can still reach the protected service**. Evaluate two paths separately:

1. **HoneyMesh identifies activity:** configured traps, scan correlation, or local policy surfaces a source and may create a ban. Measure detection quality and false positives; the existing federation PoC did not test these.
2. **An operator responds:** an analyst confirms a source and creates a ban. Measure local enforcement, propagation to trusted peers, and time to release. The 2.3.6-rc2 AMD64 PoC tested this path in a three-node lab.

## Prerequisites

- Written authorization for the hosts and traffic used in the pilot.
- Named security and Linux owners, change window, escalation contact, and rollback owner.
- Version-matched packages and manuals; verify checksum and architecture. The tested 2.3.6-rc2 package uses a dedicated service user and requires Linux kernel 5.8 or newer for its capability model.
- Selected interfaces and services, baseline network flows, allowlist, peer trust policy, individual certificates, and valid Pro licenses if testing mesh sharing.
- Existing firewall, identity, endpoint, and logging controls remain in place.

## Procedure

### 1. Baseline and observe

Inventory kernel, distribution, architecture, network interfaces, services, and normal traffic. Install on one host, configure only the intended interfaces and traps, and start in observe/test mode. Confirm the dashboard and local events are available. Record baseline CPU, memory, packet rate, and service response.

### 2. Test HoneyMesh identification

Generate approved, repeatable scan and trap traffic from known test sources. Record each expected event, actual event, time to detection, policy outcome, and any legitimate traffic that was misclassified. Do not count a simulation in the website demo as a detection result. Enable enforcement only after reviewing these results and the allowlist.

### 3. Test operator response

Use one authorized source for the ban and a different source as the unbanned control. Confirm both reach the protected service before the change. Issue a manual ban, verify local enforcement, then verify each trusted peer's decision and enforcement state. Check the control source again. Record the source IP, interfaces, protocols, timestamps, node states, and logs. Release the ban and verify access returns.

### 4. Test failure and recovery

Disconnect and reconnect a peer. Exercise certificate and trust failures, license expiry behavior, agent restart, and an accidental shared-IP ban. Confirm the operator can inspect and release a bad ban. Measure service behavior and resource use under representative traffic; do not extrapolate from the three-node lab to production load.

## Pilot scorecard

| Measure | Record |
| --- | --- |
| Detection | Expected vs. observed events, misses, false positives, and time to decision |
| Enforcement | Local and remote ban acceptance, interface coverage, probe outcome, and time to apply |
| Selectivity | The same listeners respond to an unbanned control source before and after the ban |
| Service continuity | Health checks, representative user requests, and error rate remain within agreed pilot thresholds |
| Recovery | Time to release a bad ban; peer outage and reconnect behavior |
| Performance | CPU, memory, service latency, and packet rate before and during enforcement |
| Operations | Install time, upgrades, log access, trust setup, certificate rotation, support response |

Agree on pass/fail thresholds before testing. Keep raw records, configuration versions, and an explanation for any corrected or discarded run. After the pilot, document which hosts and paths are in scope and which are not.

## Existing proof

The [2.3.6-rc2 technical PoC](/proof/HoneyMesh-Technical-Proof-of-Concept-2.3.6-rc2.pdf) and [detailed federation report](/proof/HoneyMesh-Federation-Ban-Test-Report-2.3.6-rc2.pdf) cover manual-ban propagation and selective enforcement across three AMD64 nodes and five IPv4 traffic cases. They do not supply the detection, false-positive, scale, or production performance results this guide asks a company to measure.