Your Idle Mac Could Be a Private AI Data Center

There is a research paper sitting in a GitHub repo that deserves more attention than it is getting. It is called “Private Distributed Inference on Consumer Hardware,” written by Gajesh Naik at Eigen Labs in April 2026, and it describes a working system that does something the industry has spent years insisting requires $14,000 servers.

The short version: you can run AI inference on a stranger’s Mac, and that stranger cannot see your prompt. Not because they promised not to look, but because there is no software path left through which they could look.

The system is called Darkbloom. It is a public alpha, it has not been security audited, and the company says out loud that you should not run it in production yet. All of that is true and all of that matters. But the architecture underneath is genuinely clever, and the economics have a shape that is worth understanding whether or not you ever sign up.

Let us break it down.

The Problem Nobody Solved

When you send a prompt to a cloud AI service, your privacy rests on a contract. The provider’s privacy policy says they will not read your data. You believe them, or you do not, but either way there is no technical mechanism stopping them.

The enterprise answer to this is a hardware Trusted Execution Environment. Intel TDX, AMD SEV-SNP, and NVIDIA Confidential Computing all encrypt memory so that even the machine’s operator cannot read what is running inside. It works. It also requires server hardware that starts around $14,000.

Meanwhile, per the paper, over 100 million Apple Silicon Macs have shipped since 2020. Many of them have 64 to 256 GB of unified memory and 273 to 819 GB/s of memory bandwidth, which is enough to run models up to 235 billion parameters at usable speeds. And they sit idle most of the day.

The obvious idea is to rent that idle capacity. The non-obvious problem is that Apple Silicon offers third-party developers no hardware TEE at all. The Secure Enclave can generate and sign with keys, but it cannot encrypt main memory or isolate arbitrary code. App Attest, Apple’s binary identity service, returns false for isSupported on macOS entirely. There is no public API for boot measurements.

So you have the hardware, you have the demand, and you have no way to guarantee the machine’s owner cannot read what runs on it. That is the gap the paper closes.

The Core Trick: Take Away the Doors

Apple faced a version of this problem with Private Cloud Compute, the system behind Siri and Apple Intelligence. Their answer was not to encrypt memory. It was to remove every interface through which anyone could observe the computation. No shell, no debugger, no persistent storage.

Darkbloom applies the same philosophy to a harder version of the problem. In Private Cloud Compute, Apple owns the servers. Here, the machine owner is explicitly assumed to be the attacker. They have root. They have physical custody. They may be actively trying to read your prompt.

Four things close the doors:

Everything runs in one process. Traditional inference servers such as Ollama, vLLM, and llama.cpp run the engine as a separate HTTP server. That creates two openings: localhost traffic can be captured with tcpdump (which works even with System Integrity Protection enabled), and the subprocess binary can be swapped for one that logs. Darkbloom embeds the inference engine directly inside a single hardened Swift process using mlx-swift-lm. Model weights, tokenizer, activations, WebSocket client, and encryption keys all live in one address space. There is no subprocess, no local server, no socket, no pipe. Nothing to tap.

Debuggers are denied at the kernel. The process calls PT_DENY_ATTACH at startup, before any sensitive data loads. The macOS kernel then permanently refuses every ptrace request against it, including from root. That kills lldb, dtrace, and Instruments.

Memory-reading APIs are blocked. The binary is code-signed with Hardened Runtime and deliberately without the get-task-allow entitlement, so the kernel denies task_for_pid() and mach_vm_read() from any external process.

System Integrity Protection makes it stick. This is the elegant part, and the paper proves it formally as Theorem 1. SIP state lives in NVRAM. The only tool that changes it is csrutil, and Apple restricts that to the Recovery Mode boot environment. To disable SIP you must reboot. A reboot terminates every running process, including the one holding your prompt in memory. So if SIP is verified as enabled when the process starts, it is mathematically guaranteed to still be enabled for that process’s entire life. The owner cannot lower the drawbridge without burning down the castle.

After all four, the paper enumerates what is left. Reading /dev/mem does not work because the device node does not exist on Apple Silicon. DMA attacks over Thunderbolt hit a per-device IOMMU with default-deny that panics the kernel on unauthorized access. Loading an unsigned kernel extension is blocked by SIP. Modifying kernel code at runtime is blocked by hardware-level Kernel Integrity Protection.

What remains is physically desoldering the LPDDR5x memory chips, which are fused into Apple’s system-on-chip package and would be destroyed in the attempt. That is precisely the same residual threat model Apple accepts for your Siri queries.

Proving the Machine Is Real

Eliminating access paths is only half of it. The coordinator still needs to know that a given Mac actually has these protections turned on, and is not a laptop with SIP disabled lying about it. The paper stacks five independent verification layers, each catching what the others miss.

Layer 1, Secure Enclave signature. On first run, the provider generates a P-256 key inside the Secure Enclave. The private key never leaves the hardware. It signs a status blob containing SIP state, Secure Boot state, chip name, serial number, and the encryption key. This proves a specific piece of hardware is talking.

Layer 2, MDM cross-check. The coordinator queries the machine’s security posture through Apple’s own MDM framework, which answers from the operating system, not from the provider software. There is a nice circularity here: to fake the MDM response you would have to modify system frameworks in /System/Library/, which requires SIP to be disabled. So you cannot simultaneously have SIP off and have MDM report it as on.

Layer 3, Apple Managed Device Attestation. Apple’s own servers issue a signed X.509 certificate chain proving the device is genuine hardware, with the serial number, OS version, SIP status, and Secure Boot level encoded as Apple-assigned OIDs. The chain traces back to Apple’s Enterprise Attestation Root CA. The coordinator also sends a nonce equal to the SHA-256 hash of the machine’s Secure Enclave key, and Apple embeds that hash in the certificate, cryptographically binding the key to the attested hardware.

Layer 4, continuous challenge. Every five minutes the coordinator sends a random nonce. The provider re-checks SIP, Secure Boot, RDMA, and hypervisor status, signs the result, and returns it within 30 seconds. If SIP or Secure Boot ever reports disabled, the provider is untrusted immediately with no grace period.

Layer 5, APNs code identity. This one is a genuine hack, in the good sense. Since App Attest does not exist on macOS, they repurposed Apple’s push notification service as a code-identity oracle. Only a process signed with the correct Developer ID, carrying the correct App ID, and authorized by an Apple-signed provisioning profile can register to receive pushes for their topic. Apple’s AppleMobileFileIntegrity kernel extension enforces all three at launch. So the coordinator pushes an encrypted nonce, and if the process can decrypt and sign it, Apple has effectively vouched that the running binary is the genuine unmodified build. A self-reported binary hash cannot do this, because the entity reporting the hash is the one you do not trust.

Consumers can request a minimum trust tier per request, and the full attestation chain for any provider is published at a public API endpoint for independent verification.

Now the Money

Here is where the user-facing pitch and the paper diverge slightly, and it is worth being precise.

The repo states that per-token rates target roughly half of comparable hosted APIs. Current fallback pricing is $0.05 per million input tokens and $0.20 per million output tokens, with a 0% platform fee during the alpha. That is the 50% figure.

The paper argues for much larger underlying advantages, and the reason is architectural. Cloud providers price by total parameter count. Local inference cost depends only on active parameters per token, because on a bandwidth-bound machine only the weights that actually move across the memory bus cost you anything. Mixture-of-Experts models exploit that gap brutally.

The paper’s cost table, calculated at US average residential electricity of $0.15/kWh against a workstation drawing about 100W under load:

Look at that last row carefully. For a large dense model, running locally costs more than the cloud. H100 clusters push 3.35 TB/s of memory bandwidth against an M4 Max’s 546 GB/s, and for bandwidth-bound decoding that gap is decisive.

The throughput numbers explain why MoE wins. On an M4 Max, the dense Qwen3.5 27B decodes at 21 tokens per second. The larger Qwen3.5 35B-A3B, which has more total parameters but only 3B active, hits 101 tokens per second. Bigger model, five times faster, because less of it moves per token.

What You Would Actually Earn

The paper does not publish provider payouts, so let us do the arithmetic from the published numbers.

At the fallback rate of $0.20 per million output tokens, a Mac sustaining 100 tokens per second around the clock produces 8.64 million tokens per day, which is about $1.73. Electricity at 100W for 24 hours is 2.4 kWh, or roughly $0.36. Net, call it $1.37 per day at one hundred percent utilization.

Nobody gets one hundred percent utilization. This is a young network with a classic cold-start problem, and third-party coverage during the alpha suggested top earners were making single-digit dollars per day. Treat this as beer money that partially offsets your electric bill, not as a hardware payback plan. One commenter made the sharpest version of the point: if the payback period were really two to four months, Eigen Labs would just buy the Macs themselves.

The far more interesting number for a business is zero. Running a provider node makes your own inference free. Add an X-Darkbloom-Route: self header and requests route only to machines your account owns, end to end encrypted, no charge. There is also a direct mode where the CLI serves an OpenAI-compatible endpoint on your LAN and skips the coordinator entirely, meaning your bytes never leave your network at all.

For a small shop with a spare M-series Mac and an internal tool that needs an LLM, that is the actual value proposition. The rental income is a rounding error next to not paying an API vendor.

Requirements are modest: Apple Silicon M1 or newer, macOS 14 or later, 8 GB of memory minimum with 32 GB or more recommended, 50 GB of free disk, and outbound HTTPS. No port forwarding, because the provider dials out over WebSocket. Install is a single curl command with no sudo required.

The Honest Counterpoint

A fair reading of this paper has to include what it does not claim, and what the project openly admits.

The coordinator sees your plaintext. The repo says this plainly, and it is the single most important caveat. This is not zero-knowledge. The coordinator decrypts your request inside an AMD SEV-SNP Confidential VM in order to route and bill it, then re-encrypts it for the provider. The claim is that plaintext exists only inside hardware-encrypted memory and is never logged or retained. That is a strong claim, but it is a different claim than “nobody can see it.”

It has not been audited. The license page says so in plain language, along with the instruction to use it for testing only and not in production. For a system whose entire value is privacy, an unaudited implementation is a substantial reservation.

You are installing an MDM profile from a third party. To reach the hardware trust tier, you enroll your Mac with Eigen Labs’ MDM server. The paper is genuinely careful here: the AccessRights bitmask is set to 1041, granting only inspect device, query device information, and query security information. The remaining ten capability bits are explicitly unset, so they cannot erase your Mac, lock it, change your passcode, install profiles or apps, or query your network. You can unenroll at any time from System Settings. That is a well-designed minimum-permission model, and it is still more trust than most people extend to a startup.

Timing side channels are unaddressed. The provider cannot see your tokens, but they can see the timing. Packet intervals reveal approximate prompt length, response length, and relative generation difficulty. The paper acknowledges this and does not implement constant-time inference. It notes the limitation is shared with Apple’s Private Cloud Compute.

The whole model rests on a kernel assumption. Theorem 1 holds only if there are no unpatched macOS kernel vulnerabilities that bypass SIP, Hardened Runtime, or Kernel Integrity Protection. A zero-day breaks it. Hardware TEEs do not have this dependency. The paper is upfront that this is inherent to software-enforced boundaries and that they are relying on Apple’s patching record.

RDMA is a real hole with a not-yet-enforced fix. RDMA over Thunderbolt 5, available in macOS 26.2 and later, lets a physically connected Mac read host memory at 80 Gb/s via DMA, going around PT_DENY_ATTACH, Hardened Runtime, and SIP entirely. It is disabled by default and turning it on requires a Recovery OS boot. Hypervisor memory isolation would close it, and the team validated it at 0% performance overhead on an M4 Max, but it is currently telemetry rather than an enforced routing gate.

APNs attestation needs a logged-in Mac. Push delivery requires an active GUI session, so headless or login-screen Macs cannot become code-attested and are excluded from private text traffic. If you pictured a rack of headless Mac minis, that is a real constraint.

The alpha catalog is small. The paper benchmarks Qwen and MiniMax models, but the network was running Gemma 4 and GPT-OSS during the public alpha. The larger models are the roadmap, not the current menu.

The JAMD Take

The security engineering here is the part that will outlast the business model. “Eliminate every access path” is a design pattern that generalizes well beyond inference, and the paper says so directly: fine-tuning on private data, evaluation on proprietary datasets, and confidential data pipelines could all use the same approach. The APNs code-identity trick in particular is the kind of thing that gets borrowed by other projects within a year.

The economics are more conditional than the headline suggests. Roughly half price is real for the models where MoE architecture and unified memory line up. For large dense models it inverts entirely. Anyone evaluating this should check which side of that line their workload falls on before doing any budgeting.

Our honest recommendation: ignore the rental income and look at self-route and direct mode. If you already own an Apple Silicon Mac that is idle overnight, you can point an OpenAI-compatible SDK at your own hardware, pay nothing per token, and keep the data on your own network. That is a defensible use today, with the alpha caveats fully in view. The distributed marketplace is the interesting bet, but it is still a bet.

If you are weighing private inference options for your own infrastructure and want a second opinion on where the risk actually sits, get in touch with JAMD Technologies. We spend a lot of time on exactly this kind of build-versus-rent question.

The full paper is worth reading if any of the above caught your interest. It is available in the Darkbloom repository on GitHub, and the project itself lives at darkbloom.dev.

Frequently Asked Questions

Can the owner of the Mac really not see my prompt?
Not through any software route the paper identifies. Debuggers are denied at the kernel, memory-reading APIs are blocked, there is no inter-process communication to intercept, and SIP cannot be disabled without a reboot that destroys the process. The remaining attack requires desoldering memory chips from the SoC package, which destroys them. The important caveat is the coordinator, which does decrypt your request in Confidential VM memory to route and bill it.

Does it really cost half as much?
The repo states that per-token rates target roughly half of comparable hosted APIs, with fallback rates of $0.05 per million input tokens and $0.20 per million output tokens. The underlying cost advantage is much larger for Mixture-of-Experts models, up to 32x by the paper’s own table, but it reverses for large dense models where cloud GPUs win on memory bandwidth.

What hardware do I need to earn money on this?
Apple Silicon M1 or newer, macOS 14 or later, at least 8 GB of memory (32 GB or more recommended), 50 GB of free disk, and outbound HTTPS on port 443. No inbound firewall changes are needed. Realistically, more memory means larger models and better routing odds.

How much can I actually earn?
Less than you hope. At the published fallback rate, a machine sustaining 100 tokens per second nonstop for a full day grosses about $1.73 against roughly $0.36 of electricity, and real utilization on a young network is far below that. The stronger financial case is the free self-routed inference on your own machine, not the rental income.

Do I have to let them manage my Mac?
For the hardware trust tier, yes, you install an MDM enrollment profile. The permissions are deliberately minimal: inspect device, query device information, and query security information only. The MDM server cannot erase, lock, install software, change settings, or see your network. You can unenroll from System Settings at any time.

Is it safe to use for production workloads?
The project says no. It is a public alpha, it has not been security audited, interfaces are expected to break, and the license explicitly says to use it for testing only. Treat it as a promising architecture to evaluate rather than infrastructure to depend on.

Can I run this without joining the network at all?
Yes. Direct mode starts an OpenAI-compatible endpoint on your own machine or LAN and bypasses the coordinator entirely. Lowest latency, works offline, and your data never leaves your network.