K-8.5 Security and Reliability for a Pool Host or Client

"Small companies get breached through the boring doors." The Field Manual's line covers a Kindling host as well as anyone: a reused password, a phished login, a mailbox with a forwarding rule nobody set. Kindling adds two things. Some of a host's duties are MUSTs with clocks on them. And the content a parser or agent reads is written by strangers. Spec references are to v0.1.1, as of October 4, 2026.

"Nothing here makes you compliant with any specific regulation." Chapter K-4.7 covers the law.

The baseline: do these this week

1. Password manager. "Every password unique, generated, and stored in one password manager." That includes the SMTP credentials your handshake server sends with. The reference server "Sends handshake emails via SMTP (configure via environment variables)." Keep them in the environment or a secrets manager, never in code.

2. Multi-factor authentication, in the Field Manual's order: "email (it resets everything else), password manager, domain registrar, bank and payment processor, code host, cloud hosting, accounting." For a host, email is the handshake mail and the address in curator_contact. The domain registrar controls the domain that serves your well-known file (§10.1). The code host holds your manifests if they live in a Git repository (§3.1). Use "Passkeys or hardware security keys" on all three: they are "Resistant to phishing because they won't work on a fake site."

3. Backups, with the rule that matters most on Kindling: "A backup you haven't restored is a hope."

Figures checked October 2026.

Decline records are the item hosts forget. Lose them and you can no longer honor a no. Put them in every restore test. "Keep at least one backup that your everyday admin account can't delete."

4. Device basics. Full-disk encryption, automatic updates, a short screen lock. "A lost laptop should be annoying. It should not be the end."

Access control

"Least privilege: everyone, including every agent and integration, gets the minimum access for their job, for the minimum time." Keep the Field Manual's access register, with two Kindling additions:

• Co-curators. "Co-curators listed in the manifest are first in line" (§9.3) when a Pool goes dormant. Each needs their own account on whatever holds the manifest and the decline records, so a handover never depends on a shared password.
• Who can edit the manifest. An edit is a curation action (§9.1), and anyone who can edit it can add an entry. An entry without a real consent_proof breaks §5.1. Keep edit rights to the curators named in the manifest's curator field (§3.2).

"Offboarding checklist. When any contractor finishes: revoke accounts, revoke shared vault items, rotate any secret they saw" applies as written. "Same day."

Incident response, with one Kindling scenario

The Field Manual's runbook holds: contain, cut keys, preserve, assess, get help, communicate, review. "Write the runbook before you need it." Add the scenario a host is most likely to meet: a curator's mailbox is compromised and starts sending handshakes.

1. Contain. "Change the password and revoke sessions on the affected account." Do it "from a clean device," and "Check forwarding rules and connected apps; attackers add auto-forwarding."
2. Cut keys. Rotate the SMTP credentials and any token that can edit a manifest.
3. Check the manifest. Compare every entry added since the compromise against its consent_proof (§3.4). An entry with no real handshake response behind it was added silently, which §5.1 forbids. Remove it.
4. Preserve the logs before they roll over. A withdrawal that arrives in the meantime is still processed within 60 seconds (§5.3).
5. Assess and get help. What could the attacker reach? If personal data may be involved, the Field Manual's order holds: "attorney first (breach notification laws exist in every state and deadlines vary; see Vol 13)," then your cyber insurer (Chapter K-4.8).
6. Communicate. Tell the people who received a false handshake what happened, plainly. Links in any handshake your Pool sent worked as designed: nothing was recorded unless they pressed a button (§5.2).
7. Review within a week, and write it up.

Reliability, as the spec states it

Most reliability targets are yours to choose. On Kindling three are set for you:

• Withdrawal within a minute. "Implementations MUST process withdrawal within 60 seconds of receipt." (§5.3) Monitor it like an uptime target: send a withdrawal from an invented profile on a schedule, time it, and alert when it is slow.
• Dormancy notices. After 90 days without a curation action, "the Pool MUST enter dormant status. Pool members MUST see a notice. The well-known file MUST reflect dormancy." (§9.1) Whatever produces those three effects has to keep running when you have stopped.
• Email as the floor. In v0.1, messaging "is delivered as structured email over standard email infrastructure" (§6.1), and any richer transport "MUST preserve email as a fallback through v1.x" (§6.4). Watch bounces and deliverability as closely as server errors.

The Field Manual's incident shape applies to an outage: "contain (roll back), communicate (status page), fix, write it up." Add one thing to the write-up: whether any withdrawal took longer than 60 seconds while you were down, and what you told the person.

The case study the spec gives you

v0.1.1 changed the handshake after a real failure mode. Each link in a handshake email "MUST open a confirmation step." "Only an explicit action on that step, such as a button that sends a POST request, records a decision. A GET request to either link alone MUST NOT record a decision." (§5.2) The reason is one line: "email security scanners open every link in a message."

Any link you email that does something when opened will be opened by a scanner. Make every state-changing action a POST behind a page a person reads. K.1's Field exercise 4 has you sketch that page.

When the page you read is written by a stranger

"A Profile is whatever the owner publishes at a URL." (§2.1) Every page a parser or agent reads is untrusted content. The Field Manual's warning about prompt injection then applies in full: "A model can't reliably tell your instructions apart from instructions hidden in the content it reads." A profile page can carry text written for your agent, not for a person.

The reference discovery agent does not use a model. Its header says it ranks by "a simple lexical relevance score over parsed profile fields," and that "Production implementations should replace rankProfiles with an embedding-based or LLM-driven ranker." The day you do that, the Field Manual's "lethal trifecta" is a design question for you: an agent that has "access to private data," is "exposed to untrusted content," and has "a way to send data out." An agent reading an unlisted or invite-only Pool holds the first. Profile pages give it the second. A client that lets it start a message would give it the third.

Break the trifecta by design, as the Field Manual says, and add the protocol's own limits:

• An agent never adds anyone and never starts a handshake. Inclusion needs the owner's explicit consent (§5.1), recorded on a confirmation page (§5.2).
• An agent never sends a message. A person sends it, after reading what the agent drafted. Messages carry verification levels the recipient will see (§4.5), and they are the person's to send.
• An agent reads only entries with a consent_proof (§3.4), and never surfaces a page with the noindex directive (§2.7).
• Pool content sent to a model vendor leaves your systems. "Know what your AI vendors do with your data," and record it in the AI register (Chapter K-4.7).

"Agents with broad permissions do broad damage when wrong." Cap spend at every provider. "A looping agent calling a paid API overnight is leaving the water running."

Vendor security

Your email provider and your host hold the data in Chapter K-4.7's map. Run the Field Manual's six checks before adopting either. "Confirm you can export and delete your data" matters more than usual, because a Pool has to be able to move hosts without losing its consent proofs or decline records (§3.4, §5.2). K.3 lists the providers' published prices.

Field exercises

1. Run a restore test that brings back one Pool's manifest and its decline records. Done when both are restored into a test environment and you have written down how long it took.
2. Time a withdrawal end to end with an invented profile, then make the timing a scheduled check. Done when the check runs on its own and alerts you when a withdrawal takes longer than 60 seconds.
3. List every link your system emails and what opening it does. Done when none records a decision or changes anything on a GET.
4. Feed your parser an invented profile page that carries an injected instruction. Done when you have recorded what it did, and nothing it did reached a message, a handshake or a manifest.
5. Walk your access register. Done when every person with edit rights to a manifest is named in its curator field, and no agent holds edit rights.

---

Rewritten for the Kindling edition from Chapter 8.5 of The Solo Operator's Field Manual. The full chapter is on solo.joshwolf.net. © 2026 Josh Wolf, licensed under CC BY 4.0. Quotations from the Kindling Protocol Specification v0.1.1: © 2026 TranquilTech and Kindling spec contributors, CC BY 4.0, marked where shortened.