Network boundary — what enters and exits your host
Inbound (once)
H7_LICENSE_KEY
(Ed25519 token, issuance only)
Your Host
h7-sensor · h7-brain
Outbound
∅ — nothing
(zero runtime callbacks)
Zero Phone Home
✓ Proof by log — h7-brain emits zero network syscalls at runtime
Run the following command while h7-brain is active and processing a live detection. A third-party risk committee running this during a proof-of-concept will see zero network activity — the license token was validated once at startup via Ed25519 (local computation only, no callback).
# Run this while h7-brain is active and processing a breach.# Expected result: zero network syscalls from h7-brain. $ sudo strace -e trace=network -p $(pgrep h7-brain) 2>&1 | head -20 # If the process is doing what we claim, you will see:strace: Process XXXXX attached# ...and nothing else. No connect(), no sendto(), no socket() calls.# The license was validated at startup via Ed25519 (offline).# All subsequent operation is local to your host.
✓ Packet-level confirmation — tcpdump during a live attack
Capture traffic at the network interface level while triggering a breach scenario. You will observe agent behavioral drift events, a signed .cal certificate emitted — and zero outbound packets from h7-brain.
# Alternatively, capture all traffic from h7-brain's PID namespace:$ sudo tcpdump -i any -p --pid=$(pgrep h7-brain) -c 100 # Or filter by process name at the interface level:$ sudo tcpdump -i any host $(hostname) and not src localhost -n # Trigger an attack scenario in another terminal:# $ make attack-vercel (in your h7-demo-kit directory)# Expected: .cal certificate emitted, ZERO packets captured for h7-brain.
Offline verification
✓ Verify a .cal certificate with the network physically disconnected
The only dependency for verifying a .cal certificate is the Ed25519 public key — a 113-byte PEM file you can store anywhere. No internet connection, no certificate authority, no SaaS callback. Disconnect your network and run verification: it works identically.
# Step 1: download a .cal certificate from a demo run$ ls run/alerts/*.cal | head -1run/alerts/alert-000001.cal # Step 2: disconnect your network interface$ sudo ip link set eth0 down # or disable WiFi physically # Step 3: verify the certificate — works with only the public key$ ./scripts/verify-loop.sh run/alerts/ run/keys/h7-cert-issuer.pub run/baseline.json [verify] alert-000001.cal[verify] signature: VALID ✓[verify] baseline_sha256: bound ✓[verify] No network required. ✓ # Step 4: restore network — H7 never needed it for verification
✓ Tamper detection — one bit invalidates the entire chain
The Ed25519 signature covers the entire canonical JSON body of the .cal certificate. A single flipped bit — in any field — breaks the signature and returns INVALIDE. This is the property that makes .cal certificates admissible as non-repudiable forensic evidence.
# Flip one byte in the .cal certificate$ python3 -c "d = bytearray(open('run/alerts/alert-000001.cal','rb').read())d[42] ^= 0xFFopen('/tmp/tampered.cal','wb').write(d)" # Attempt to verify the tampered file$ h7 cal verify /tmp/tampered.cal --public-key run/keys/h7-cert-issuer.pub [verify] signature: INVALIDE ✗# A single bit flip breaks the Ed25519 signature chain.# No attacker can forge a valid .cal without the private key.
Key transparency
The public keys used to sign .cal certificates and license tokens are published here with their SHA-256 fingerprints. Any party — your auditor, your internal SOC, a Notified Body — can independently verify any artifact using only these public keys. The private keys never leave our infrastructure.
h7-cert-issuer.pub
Signs AlertCert .cal incident certificates
Shipped inside h7-demo-kit / run/keys/. In production deployments, you receive this key at onboarding and store it for permanent offline verification.
h7-license-validator-k1.pub
Signs Ed25519 license tokens (kid: k1)
Bundled in the h7-brain Docker image at /etc/h7/h7-license-validator-k1.pub. Verified locally at startup — no network call.
Key rotation: if a private key is ever compromised, Pulsaride issues a signed Certificate Revocation List (CRL) and rotates to a new kid. Old tokens remain verifiable against their original key fingerprint for audit purposes; new tokens use the rotated key. No update to your h7-brain deployment is required.
Procurement checklist
Answers to the questions every third-party risk committee asks before approving a security vendor.
Does h7-brain send telemetry to Pulsaride servers?
No. After initial license token issuance, h7-brain makes zero outbound network connections. Verifiable with strace (see above).
Where is agent behavioral data stored?
Exclusively on your host — in /var/lib/pulsaride-h7/ and /var/lib/h7/alerts/. No data leaves your infrastructure.
What data does the license token contain?
email, company, tier, expiry, max_namespaces, and key ID. All signed with Ed25519. No telemetry, no hardware fingerprint, no unique host identifier.
Can Pulsaride revoke access remotely?
No. Revocation works via a signed CRL file you deploy to your host (offline operation). There is no remote kill switch.
Does verification require internet access?
Never. Verification uses only the Ed25519 public key — a static file on your system. Demonstrated above with network disconnected.
What is the data residency?
100% on your infrastructure. The product is a Linux binary + Docker image. No cloud control plane, no SaaS dashboard calling home.
Is the software supply chain verifiable?
Yes. The demo kit provides SHA-256 checksums and an Ed25519 release signature for every binary, verified before installation.
EU/GDPR data processor agreement?
Contact contact@pulsaride.com. Pulsaride Solutions SARL (SIREN 993 339 936, Pessac, France) — EU-incorporated, French law.
Responsible disclosure
Found a security issue? Email security@pulsaride.com — PGP key available on request.