Phoretic Security
Continuous security monitoring for fleets of embedded Linux devices, built around a small open-source agent and a backend that pays attention.
phoretic.net · alex@cluonflux.com
what
The average consumer IoT device — your router, your IP camera, the thing your neighbor calls "the cloud thermostat" — ships with software that has been frozen since the factory and quietly compounding security debt ever since. The manufacturers behind these devices are not, for the most part, careless. They're stuck between enterprise security products priced for people with security operations centers, and rolling their own from parts.
Phoretic fills the gap with a lightweight agent that runs inside the device, paired with a backend that aggregates behavioral telemetry across the manufacturer's whole fleet and surfaces the things worth a human's attention. Insurance-tier pricing, open-source agent code, removable by firmware update. We're an observer, not a passenger with a key to the kitchen.
The name phoretic is an adjective meaning "hitching a ride" — the relationship between a mite and a bee, where one organism travels on another without harming it. Accurate enough that we kept it.
how
Two pieces, talking over a tamper-evident telemetry chain:
┌──────────────────────────┐ ┌──────────────────────────┐
│ Device (embedded Linux) │ │ Backend (multitenant) │
│ │ │ │
│ ┌──────────────────┐ │ │ ┌──────────────────┐ │
│ │ phoretic-agent │───┼─────────┼──▶│ ingestion │ │
│ │ (open source, │ │ TLS │ │ ▼ │ │
│ │ memory-budget │ │ tamper- │ │ fleet analysis │ │
│ │ constrained) │◀──┼─evident─┼───│ ▼ │ │
│ └──────────────────┘ │ chain │ │ detection rules │ │
│ │ │ │ ▼ │ │
│ observes via procfs, │ │ │ console + alerts│ │
│ netlink, fanotify, eBPF │ │ └──────────────────┘ │
│ where available; falls │ │ │
│ back to polling where │ │ per-manufacturer │
│ it isn't │ │ tenant isolation │
└──────────────────────────┘ └──────────────────────────┘
The agent observes facts about the device — what's running, what's mounted, what files have changed, what's listening on a port, what's talking to whom — and ships those facts upstream. The backend handles judgment: clustering similar devices into anonymous classes, learning what "healthy" looks like across the fleet, generating compact deterministic detection rules, and surfacing residue that doesn't fit the baseline. The agent doesn't decide what's bad. The backend does.
The split matters because of where the leverage lives. Per device, mostly nothing happens — a healthy router looks like every other healthy router, and that's the point. The signal is in the residue, and the residue only becomes legible at fleet scale, across many devices observed the same way. The agent ships honest, structured facts; the backend turns ten thousand devices' worth of nearly-identical observations into one device's worth of "this one is different, here's why, here's what to do."
when
Three forcing functions have arrived close enough together that the industry hasn't fully digested any of them. They are worth naming, because they shape why a thing you build today is more useful than the thing you would have shipped three years ago.
The EU Cyber Resilience Act. Mandatory vulnerability reporting begins September 2026; full enforcement, including penalties of up to €15 million, lands December 2027. CRA is extraterritorial — it applies to anyone placing products on the EU market, regardless of where they're designed or built. The September 2026 reporting obligation applies to products already in the field, not just new launches. A manufacturer who has shipped a million devices into Europe and has no idea what those devices are currently doing is, as of September, a manufacturer with a problem.
The FCC ban on foreign-produced routers. As of March 2026, new router designs involving any stage of design, development, manufacturing, or assembly outside the United States are banned by default from the US market — not subject to additional requirements, banned, unless the manufacturer obtains a case-by-case exemption. Virtually every router manufacturer on Earth is affected, because the global router industry runs on international supply chains. A manufacturer applying for the exemption with fleet security monitoring already in place has a materially stronger case than one without.
The insurance carriers. Cyber underwriters are quietly pricing IoT-derived loss into their books, which means manufacturer liability premiums are starting to vary with the security posture of the manufacturer's fleet. The carriers are not yet asking for monitoring data directly. Give it a couple of renewal cycles.
None of these is a market we serve by selling them paperwork. Compliance paperwork is fine, and the consultants who supply it are not going anywhere. The point of monitoring is that it survives the audit being over. A manufacturer who installs us to satisfy a regulator and then discovers that some non-trivial fraction of their deployed fleet has been compromised is not going to turn the monitoring off when the auditor leaves.
who
You've spent meaningful time understanding how Linux systems are attacked, not just how they're defended. You've written exploit code or reverse-engineered firmware. You know procfs, netlink, eBPF, and cross-compilation toolchains as tools you've used and abused, not abstractions you've read about. You write Rust or C fluently and have opinions about the difference between this works and this works and I can explain why it's correct.
You'll own the agent: the binary that runs in someone's home on hardware nobody can SSH into, with a memory budget measured in single megabytes. If you push a bad update, there is no rollback button — you have to have already built the system that rolls itself back. The code is open source, so every manufacturer's firmware team and every attacker on the planet will read it. You need to be comfortable with both audiences.
Enterprise endpoint security backgrounds are not the right fit. The detection model is behavioral and deterministic, not signature-based or ML-driven. We need someone who's already operated inside these constraints, not someone who needs to learn them.
You are a native Mandarin speaker with existing relationships in the consumer electronics manufacturing ecosystem, particularly in the Pearl River Delta. You've worked in or sold into this world — perhaps at a component distributor, a product design house, an ODM, or a mid-market OEM. You read rooms, not stack traces. You know how purchasing decisions actually get made at a mid-market device company, and it's not through an RFP process.
You can walk into a factory and have a credible conversation about firmware build processes, supply chain timelines, and export compliance — and then close a deal that same week. You'd own the commercial strategy and the customer relationships outright. Not a hire dressed up as a cofounder; a cofounder with equal equity and the title to match.
Not looking for a Western tech executive who "has contacts in Asia." The PRD ecosystem operates on trust, face-to-face relationships, and cultural context that cannot be bridged by business trips and interpreters. We need someone from this world, not someone who visits it.
Alex Cruise. Canadian. Senior sysadmin roots, backend infrastructure background, the kind of person who has opinions about storage I/O patterns and compression algorithms at the block level. Has operated multitenant data pipelines at scale and understands the feedback loop between architecture decisions and the cloud bill. Wrote 150 pages of founding documents — the whitepaper, the technical roadmap, two FAQs, this website — partly to attract cofounders, partly to stress-test whether the idea survived contact with its own details.
Owns the backend: ingestion, multitenant storage, the rule generation pipeline that turns fleet-wide behavioral data into per-device-profile detection rules, the cost engineering that makes the pricing model not a lie. Strength is at the intersection of systems thinking and cost discipline. Weakness is being a better architect than a closer.
If you read all of this and thought "I know someone who could do the platform role better than him" — that's a useful conversation, too. The company matters more than the seat.
next
If any of the open roles sounds like you — or like someone you know, including for the one that's nominally filled — write to alex@cluonflux.com. The 45-page whitepaper, the technical roadmap, and the customer/investor FAQs are available for serious inquiries. We'd rather share too much context than too little.
For design partnerships: if you're a device manufacturer who wants to see what we can see, we'll buy your product off the shelf, instrument it, and show you what it looks like through our backend. Often the first time a manufacturer sees this level of visibility into what their own device does after it leaves the factory.