End-to-End Encryption for Wearable AI: Privacy by Default

A wearable that can hear your life is only safe if privacy is real, not marketed. Nexting's answer is to keep your data with you: in bring-your-own-agent modes — Claude Code, Codex, and MyOpenClaw — end-to-end encryption is on by default, your agent runs on your own device, the keys stay with you, and the Nexting cloud relays ciphertext rather than readable session content. The honest exception is managed Nexting Pro, a separate hosted mode that requires cloud-side processing, so it is not end-to-end encrypted. This article explains both, in plain language.

An always-on microphone is a promise, not a feature

Start with the uncomfortable truth at the center of this entire product category. A wearable AI device earns its place by being available the instant you have a thought — which means it has to be listening, or ready to listen, far more of the time than a phone you pull out of your pocket. The convenience and the risk are the same fact viewed from two angles. The moment a device can capture the texture of your day — the hallway conversation, the number you read aloud, the half-formed idea you mutter while walking — it becomes one of the most intimate sensors you own. More intimate than your browser history, which only knows what you typed. More intimate than your phone's GPS, which only knows where your body went.

That intimacy is exactly why the privacy question cannot be an afterthought bolted onto a finished gadget. It is the foundation the product either has or does not have. If you cannot trust where the audio goes, who can read the transcript, and what happens to it next month, then every clever capability built on top is built on sand. The feature is not “it hears you.” The feature is “it hears you and you still feel safe.” Everything in this article is about how to make the second clause true and where, honestly, it stops being true.

The industry has not exactly earned the benefit of the doubt here. Privacy researchers and lawyers have spent the last two years warning that always-listening wearables shift the privacy burden onto bystanders who have little ability to detect, interpret, or meaningfully respond to being recorded, and that earlier visual-AI wearables already drew public backlash precisely because they could capture data and route it to cloud systems for automated or human review. Buyers are right to be skeptical. Skepticism is the correct starting posture, and a serious product should welcome it rather than wave it away.

What “privacy” actually has to mean here

Privacy is one of those words that gets used to mean four different things at once, which is how marketing departments hide behind it. For an always-on wearable, it is worth being precise. There are at least four distinct questions, and a device can answer some well and others badly:

• Capture — when is the microphone actually active, and do you and the people around you know?
• Transit — once captured, where does that data travel, and can anyone read it along the way?
• Processing — where is the data turned into an answer, and does the place that does the work get to keep a plaintext copy?
• Retention and use — after the moment passes, what is stored, for how long, who can see it, and is it ever used to train models, sold, or shared?

Most “privacy-first” marketing answers only the easy one — transit — by mentioning that traffic is encrypted in transit with TLS, the same padlock your bank uses. That is necessary and meaningless on its own, because encryption in transit protects data from outsiders on the network while leaving the company's own servers free to read everything the moment it arrives. The hard questions are processing and retention. The whole game is whether the party doing the AI work, and the party storing your history, can read your life in plaintext. End-to-end encryption is the tool that answers those hard questions, and the rest of this piece is about applying it honestly.

The threat model: who could see your data, and where it could leak

You cannot reason about privacy without naming the adversaries. “Is it secure?” is unanswerable; “secure against whom?” is answerable. A wearable AI system that touches the network has several distinct places where readable data could be exposed, and a different actor sits at each one. Listing them plainly is the only way to see which ones a given design actually closes.

• The network in between — coffee-shop Wi-Fi, your ISP, a hostile network operator. They see traffic flowing between your device and a server.
• The vendor's own cloud — the company that makes the device. If their servers process or store your data in plaintext, then their employees, their logs, their backups, and their internal tools can in principle see it. This is the big one, and the one most marketing quietly skips.
• The AI model provider — if a third-party model in someone else's data center does the actual inference, that provider receives your prompts and the surrounding context.
• A future breach — data that exists in readable form somewhere can be stolen later. The safest byte is the one that was never stored in plaintext at all.
• Legal compulsion — subpoenas, warrants, and government requests. A company can only hand over what it can actually read. This is the entire point of designing so that there is nothing readable to hand over.
• Bystanders' exposure — the people around you who never consented to a microphone. This is a real and separate harm, and no amount of server-side encryption fixes it; it is addressed by capture discipline and disclosure, not cryptography.

Hold that list in mind, because the value of any privacy claim is exactly which of these boxes it actually checks. A design that encrypts in transit closes only the first box. A design that processes everything in the vendor's cloud leaves boxes two through five wide open. The architecture that follows is an attempt to close as many as possible — and to say out loud which one it cannot.

What end-to-end encryption actually means

End-to-end encryption (E2E) is a specific, testable property, not a vibe. It means that data is encrypted on your device, stays encrypted while it travels and while it sits on any intermediate server, and is only decrypted on the device at the other authorized end. The defining consequence is the one that matters: the service carrying the data — the relay, the cloud, the company — never holds the keys and therefore can never read the plaintext. As the people who popularized it for messaging put it, the server is a dumb pipe that routes ciphertext and handles metadata, but unencrypted content and private keys are never disclosed to it.

The mechanism is asymmetric cryptography. Keys are generated on the client and the private key never leaves it. Content is sealed so that only a holder of the corresponding key can open it. The Signal protocol that set the modern bar for this works exactly this way: identity and ephemeral key pairs are created on each device, and the master secret used to encrypt messages is derived from one party's private key and the other's public key — never assembled anywhere the server can see. The cryptography is decades old, well understood, and not the hard part.

“The test of end-to-end encryption is brutally simple: if the company carrying your data can be compelled to hand over your plaintext, it was never end-to-end encrypted. If there is nothing readable to hand over, it was.”

The hard part is honesty about scope. E2E protects content, not the existence of communication — metadata like who connected, when, and how much data moved is usually still visible to the relay, because routing requires it. And E2E is only as good as the endpoints: if the device at one end is compromised, the encryption in the middle does not save you. None of this makes E2E worthless; it makes it precise. The right question to ask any vendor is not “is it encrypted” — everything is encrypted in transit now — but “can you, the company, read my content on your servers?” If the honest answer is no, that is end-to-end encryption. If the honest answer is “only when we need to,” it is not.

Why “bring your own agent” changes the privacy math

Most AI wearables are voice assistants: you talk, the device ships your words to the vendor's cloud, a model the vendor controls produces an answer, and the answer comes back. In that design the vendor's cloud is structurally in the middle of every thought, because that is where the intelligence lives. Privacy then depends entirely on the vendor's policies, because architecturally they can see everything. The data exhaust is real: prompts and outputs can be logged, retained, and reused, and your protection rests on vendor assurances rather than on the shape of the system.

Nexting is built on a different premise. It is an agent dispatcher, not a chatbot. The intelligence — your Claude Code session, your Codex session, your OpenClaw agent — already runs on hardware you own and control: your Mac, your machine, your account with the model provider you already chose. The wearable's job is to let you raise your hand and dispatch a task to that agent by voice, then watch it work, from anywhere, without pulling out a phone. This is the bring-your-own-agent (BYOA) model, and it is free.

That single architectural choice rewrites the privacy math. When the agent runs on your own device, the heavy, sensitive work — reading your files, executing your task, holding the full context of what you are doing — happens on a machine you control, not in Nexting's data center. The local-AI principle applies in full: if the intelligence never leaves the device, it cannot be harvested, logged, or repurposed by a third party in the way cloud inference can. Nexting's cloud is no longer the brain. It is reduced to what it should be: a relay that connects your wearable to your own agent.

How Nexting does it: E2E on by default in BYOA modes

In the three bring-your-own-agent modes — Claude Code, Codex, and MyOpenClaw — end-to-end encryption is on by default. You do not flip a switch or find a buried setting; it is the standard path. Here is what that means concretely, stated carefully so it is not overclaimed.

Your agent runs on your own device

The agent that actually does the work lives on your hardware. A small bridge on your machine connects your local Claude Code, Codex, or OpenClaw session to your account. The wearable and your phone are remote controls and viewports for that session. The substance of your work never has to be evaluated inside Nexting's servers, because the evaluation happens where the agent already lives.

The keys stay with you

Encryption keys belong to your endpoints — your devices — not to the Nexting cloud. Because the cloud never holds the keys, it cannot decrypt what passes through it. This is the property that distinguishes real end-to-end encryption from “encrypted in transit, then readable on our servers.” The keys living with you is the whole point.

The cloud relays ciphertext, not readable session content

When you dispatch a task from your wearable and watch the session stream back, the session content moves between your devices as ciphertext. The Nexting relay forwards sealed bytes; it does not store or read your readable session content. It performs the dumb-pipe role — getting encrypted data from one of your endpoints to another — without being able to open it. That is what “relays ciphertext rather than readable session content” means, and we say it that precisely on purpose.

Put the three together and the threat model from earlier collapses in the good direction. The network in between sees ciphertext. The vendor cloud — Nexting — sees ciphertext, so its employees, logs, and backups cannot read your sessions, and a future breach of the relay yields encrypted blobs rather than your work. Legal compulsion against Nexting cannot produce plaintext that Nexting does not possess. The remaining exposure honestly sits with your own endpoints and with the model provider you chose to run your agent on — which is exactly where a privacy-conscious person would want the trust boundary to be, because you picked those.

A single dispatch, traced end to end

Abstractions are easy to nod along to and hard to trust. So let us trace one ordinary action through the system, step by step, and name what is readable and what is sealed at each hop. Imagine you are walking to lunch and you say into your PIN: “Have the agent run the test suite on the billing service and tell me if anything breaks.” Here is the journey of those words in a BYOA mode with end-to-end encryption on.

First, capture. The wearable picks up your sentence. This is the one moment your raw voice exists in the open, on a device on your own body. Before it travels anywhere, it is sealed with keys that belong to your endpoints. From this instant forward, the content is ciphertext to everything except your own authorized devices.

Second, the relay. The sealed instruction travels over the network — coffee-shop Wi-Fi, cellular, whatever you are on — to the Nexting cloud. The network operator sees encrypted bytes. The Nexting relay receives encrypted bytes. It knows that one of your devices is sending something to another of your devices, and it knows the size and timing of that something, because routing requires that much. It does not know that you asked about the billing service, or that a test suite is involved, or anything about the substance. It forwards the sealed payload toward your machine.

Third, your own device. The bridge running on your Mac receives the ciphertext, and because the keys live there, it can open it. Now — on hardware you control, not in anyone's data center — the instruction becomes readable, and your local Claude Code or Codex agent goes to work: it reads your repository, runs the tests, and observes the results. The full sensitive context of your project never left your machine to make this happen. The intelligence operated where it already lived.

Fourth, the return trip. The agent's output — the streaming log, the pass/fail summary, the line where something broke — is sealed on your machine and relayed back the same way. The cloud again carries ciphertext; your wearable and phone, holding the keys, decrypt and display it. You glance at your wrist, see that two tests failed in the refund path, and dispatch a follow-up. At no point in that loop did the Nexting cloud hold a readable copy of your code, your test output, or your instructions.

Contrast that with the cloud-only version of the same request, where step three happens inside the vendor's data center. There, your instruction and the surrounding context must be readable at the point of processing, because that is where the model lives. The difference between the two stories is the entire subject of this article, told as a single lunch walk.

Metadata: the honest residue of any relay

We have now said twice that the relay sees metadata even when it cannot see content, and it deserves its own honest treatment rather than a footnote, because metadata is where a lot of privacy theater happens. End-to-end encryption seals the “what.” It generally does not seal the “that” — the fact that a connection occurred, between which of your devices, at what time, carrying roughly how many bytes. A relay that could not see any of that could not route at all. This is true of the most trusted encrypted messengers in the world, and it would be dishonest to imply Nexting has repealed a law of how routing works.

What matters is keeping that residue thin and not letting it masquerade as harmless when it is rich. Metadata can be revealing — patterns of when you dispatch, how often, and how much can sketch an outline of a life even without content. The right posture is threefold: minimize what the relay needs, never quietly turn that thin operational metadata into a behavioral profile, and be candid that it exists. Nexting's metadata is the connective tissue of routing your own ciphertext between your own devices, governed by the same data policy as everything else — not trained on, not sold, not shared, deletable. The honest claim is “content is sealed and metadata is minimized and governed,” not the unbelievable “we see literally nothing.”

“Beware anyone who claims their encrypted system sees nothing at all. A relay that routes must know that something is being routed. The honest claim is that the content is sealed and the residue is thin — not that the residue does not exist.”

The model provider is a trust boundary — one you chose

A careful reader will have caught something in the dispatch walkthrough: in BYOA mode the agent runs on your device, but the underlying model it calls may still be a service you connect to — your Claude account, your Codex account, your own OpenClaw setup. So there is a trust boundary at the model provider, and pretending otherwise would be exactly the overclaim we keep refusing to make. When your local agent reasons over a task, it may send context to the model provider you configured, under the agreement you have with that provider.

The crucial distinction is whose relationship that is. In a cloud-only assistant, the vendor inserts itself as a mandatory middleman between you and a model you did not choose, and you inherit the vendor's terms on top of the model provider's. In Nexting's BYOA model, you bring your own agent and your own provider relationship; Nexting is not in that path as a reader. The trust boundary at the model provider is one you selected, can inspect, and can change — including by choosing a provider with terms you like, or by running models locally where your agent supports it. The point of BYOA is not that there are zero trust boundaries; it is that the boundaries that remain are yours rather than imposed, and Nexting is not one of them.

This is also why “bring your own agent” is a privacy feature and not just a cost feature. Portability is protection. If the relationship with the intelligence is yours, you are never hostage to a single vendor's future policy change, price hike, or data practice. You can leave and keep your agent. A privacy guarantee you cannot walk away from is a weaker guarantee than one you can.

Why keeping work on your device helps with compliance, too

For a lot of people the privacy question is not only personal; it is professional. If you are a lawyer, a clinician, a financial professional, or an engineer handling someone else's intellectual property, the data your agent touches may be governed by GDPR, HIPAA, contractual confidentiality, or internal policy. The architecture in this article matters disproportionately for you, and it is worth spelling out why — carefully, because compliance is fact-specific and nothing here is legal advice.

The general principle privacy practitioners keep returning to is simple: data that never leaves the device sidesteps a whole class of obligations, because there is no third-party transfer, no cross-border movement, and no external processing of that content to account for. When the heavy work happens on your own machine, the most sensitive material — the client file, the patient record, the proprietary codebase — stays inside your existing controls rather than fanning out to a new vendor's servers. That does not magically make any workflow compliant, and you still have to reason about your chosen model provider and your own endpoint security. But it shrinks the surface you have to defend, and it keeps the trust boundary somewhere you can actually govern.

This is the same reason large vendors have been loudly pivoting toward on-device processing as a privacy and security strategy: minimizing cloud dependency reduces the attack surface, the logging exposure, and the number of places a breach can reach. Nexting's BYOA design lands in that camp by construction. Pro mode, again, does not — it is hosted, and if your obligations forbid sending content to a hosted assistant, the BYOA path is the one that fits. We would rather tell a regulated buyer which mode to choose than sell them the wrong one.

Residual risks we will not pretend away

An article that only listed strengths would be marketing wearing the costume of honesty. So here, plainly, are the residual risks that remain even in the best-case E2E BYOA configuration. None of them is hidden; all of them are inherent to building something genuinely useful.

• Your endpoints are the new weak point. End-to-end encryption moves trust to the ends. If your Mac or your phone is compromised by malware, the encryption in the middle does not save you, because the data is readable at the endpoints by definition. Endpoint hygiene becomes part of your privacy.
• The model provider sees what you send it. As covered above, your chosen provider receives the context your agent sends. That boundary is yours, but it is real.
• Metadata exists. The relay knows that and roughly how much you are communicating between your devices, even though it cannot read the content.
• Pro mode is not E2E. Said for the last time so it is impossible to miss: the managed hosted mode requires cloud-side processing and is therefore not end-to-end encrypted.
• Bystanders cannot be encrypted. The people around you are protected by your discretion and the law, not by cryptography.
• No system is unbreakable forever. Cryptography is strong but not magic; software has bugs. The right response is sound architecture, open code where possible, and not overstating certainty — which is the whole ethic of this piece.

We list these not to scare you but to give you a true picture, because a true picture is the only basis for real trust. A company that names its residual risks is easier to believe about the risks it has actually closed. The strength of the BYOA design is not that it eliminates every risk — nothing does — but that it pushes the remaining ones to places you can see and control rather than hiding them inside a vendor's cloud.

Questions privacy-conscious buyers actually ask

Is my AI assistant private on Nexting?

In the bring-your-own-agent modes — Claude Code, Codex, and MyOpenClaw — yes, in the strong sense: end-to-end encryption is on by default, your agent runs on your own device, the keys stay with you, and the Nexting cloud relays ciphertext rather than readable session content. In the managed Nexting Pro mode, the content is private by policy but not end-to-end encrypted, because hosted processing requires the cloud to read your request. Choose the mode that matches your requirement.

Does Nexting record my whole day?

The product is an agent dispatcher, not an ambient life-recorder. The core interaction is deliberate: you raise your hand and say a sentence to dispatch a task, rather than relying on a default that silently transcribes everything around you. That narrower capture footprint is a privacy property in itself, separate from encryption.

Will my conversations be used to train AI?

No. Nexting does not train models on your data, in either mode. It also does not sell your data and does not share it beyond the model provider you chose in BYOA mode, and you can delete your data anytime.

If the Nexting servers were breached, what would attackers get?

In BYOA mode, ciphertext and thin routing metadata — not your readable sessions, because the relay never holds the keys and the content is sealed in transit and at rest on the relay. This is the structural payoff of end-to-end encryption: the safest data is the data the company cannot read in the first place.

Why should I trust any of this?

Partly because the architecture, not just the promise, does the work in the BYOA modes; partly because the code is partly open, with the firmware on GitHub, so the most important behavior can be inspected rather than taken on faith; and partly because a company willing to tell you exactly what it cannot encrypt — the Pro mode limit, the metadata residue, the endpoint risk — has shown you the shape of its honesty. Trust is earned by what you can check, not by what you are asked to assume.

The honest limit: managed Nexting Pro is not end-to-end encrypted

Now the part most companies bury. Nexting offers a second, separate mode called Nexting Pro — a managed, hosted option for people who do not want to run their own agent and would rather pay for a turnkey assistant powered by managed models. Nexting Pro is convenient precisely because the heavy lifting happens in the cloud. And that convenience has a direct, unavoidable privacy cost: managed Nexting Pro requires cloud-side processing, which means it is not end-to-end encrypted.

We will not dress this up. When a model in the cloud has to read your request to answer it, the data must exist in readable form at the point of processing. That is not a Nexting quirk; it is true of every hosted AI assistant on the market. There is no cryptographic trick that lets a remote model reason over your words while those words remain sealed from the system running the model — not at the price, latency, and capability people expect today. So in Pro mode, the cloud-side processing boundary is real, and we label it rather than hide it.

“If a hosted model has to read your words to answer them, those words exist in plaintext where the model runs. Anyone who tells you their cloud assistant is end-to-end encrypted is selling you something. We would rather lose the sale than make that claim.”

What we can promise in Pro mode is bounded honestly by the data policy in the next section: even where cloud processing happens, Nexting does not train models on your data, does not sell it, does not share it, and lets you delete it. That is a meaningful set of commitments. It is just not the same thing as end-to-end encryption, and we refuse to let the two blur together. If end-to-end privacy is your hard requirement, the BYOA modes are the answer and they are free; Pro is for people who knowingly trade some of that for convenience.

What is and isn't encrypted, by mode

Because the previous two sections draw a sharp line, it is worth putting it in a single table you can scan. This is the most important grid in the article. Read it as the literal statement of what each mode does and does not protect.

One row deserves emphasis: metadata. Even in the E2E BYOA modes, the relay necessarily handles routing metadata — which of your devices connected, when, and roughly how much data moved — because that is what makes a relay route. That is the standard, honest limit of end-to-end encryption everywhere, including the messengers people trust most. It is content that is sealed, not the bare fact that a connection happened.

The data policy, stated as promises

Encryption answers “who can read it.” A data policy answers “what do you do with what you can touch.” Both matter, and the second is where most companies hedge with phrases like “we may use your data to improve our services.” Here are Nexting's commitments, written as flat promises across both modes:

• Never trained on. Nexting does not use your data to train models. Your conversations are not fuel for someone else's product.
• Never sold. Your data is not a revenue stream. The PIN costs $129; Pro costs a subscription. The business model is hardware and software you pay for — not your behavior resold to advertisers or brokers.
• Never shared. Nexting does not hand your data to third parties beyond the model provider you yourself chose to run your agent on in BYOA mode.
• Deletable anytime. You can delete your data. The right to remove what exists is not a favor; it is a standing option.

The reason these promises are credible is that the architecture backs them up where it can. In BYOA mode there is little for Nexting to misuse even if it wanted to, because the cloud sees ciphertext — the data policy and the cryptography point the same direction. In Pro mode the policy carries more of the weight, because the cloud does see your request during processing; there the promise is a genuine commitment rather than a structural impossibility, and we mark that difference plainly. A policy that matches the architecture is worth more than a policy that contradicts it, and we have tried to make ours match.

How this compares to cloud-only assistants

It helps to contrast the BYOA approach with the dominant pattern in the category, fairly and factually. Many AI wearables and assistants are cloud-only and locked to a single provider. Humane's Ai Pin launched at $499 plus a $24/month subscription with its intelligence in the cloud. Bee, the $49.99 wristband that records and summarizes your day, runs its processing in the cloud and was acquired by Amazon. Rabbit, Friend, and Plaud likewise center on cloud processing and a vendor-controlled model. These are real products built by real teams, and the contrast is not a moral one — it is architectural.

The architectural difference is exactly the threat-model difference from earlier. In a cloud-only design, the vendor's servers are structurally in the path of your content because that is where the model runs, so privacy reduces to trusting the vendor's policy and the vendor's security. In Nexting's BYOA modes, the model runs on your device, the relay carries ciphertext, and the trust boundary moves to hardware you control and a provider you already picked. You also are not locked in: BYOA means you choose Claude Code, Codex, or OpenClaw, and you keep that relationship if you ever leave Nexting.

To be scrupulous: Nexting's own Pro mode sits on the cloud-only side of that first comparison, by design, and we put it there ourselves a few sections ago. The point of the table is the structural choice available to you, not a claim that Nexting is pure and everyone else is not. The honest framing is that Nexting gives you a free path where the architecture, not just the promise, keeps your content out of the vendor's reach — and a paid path where it does not, clearly labeled.

What cryptography does not fix: bystanders and capture

End-to-end encryption protects the data you choose to capture. It does nothing for the people around you who never chose anything. This is the part of wearable privacy that no server-side architecture addresses, and pretending otherwise would be exactly the kind of overclaim this article is trying to avoid. The legal and ethical literature is blunt: wearable recording shifts the burden onto bystanders who often cannot even tell they are being recorded, and two-party-consent jurisdictions make casual recording of conversations a genuine legal exposure, not just an etiquette problem.

The honest mitigations here are behavioral and design-level, not cryptographic. A wearable should make capture legible — clear about when it is active — and a wearer carries a real responsibility to disclose recording where law or basic courtesy requires it. Nexting's dispatcher model helps at the margin, because it is built around deliberate dispatch — you raise your hand and say a sentence to send a task — rather than around silently transcribing every minute of your ambient life by default. A device oriented to “dispatch a task” has a narrower capture footprint than one whose core promise is “record and summarize your whole day.” But narrower is not zero, and the wearer's judgment remains part of the system. We would rather say that than imply a chip solves a social problem.

On open source, and why it matters for trust

Privacy claims are easier to believe when they can be inspected. Nexting's code is partly open — core and partial, with the firmware published on GitHub — and it is worth being exact about that phrasing, because “open source” is another term that gets stretched. Nexting is not fully open source, and saying it were would undercut the entire point of an article about honesty. What is true is that meaningful parts, including the firmware that runs on the hardware against your body, are public and inspectable.

Why does that matter for privacy specifically? Because the most important privacy claims in this piece — the keys stay with you, the relay carries ciphertext — are claims about behavior that can, in principle, be checked against code rather than taken on faith. Open firmware lets the people who care most verify what the device on their collar actually does with a microphone. Transparency is not a substitute for sound architecture, but it is a real check on it, and it is the opposite of asking you to trust a black box. We would rather earn trust through what can be seen than demand it through what cannot.

Practical advice for privacy-conscious buyers

Whether or not you ever buy a Nexting device, here is the checklist worth applying to any always-on AI wearable. The questions are designed to cut through marketing to the architecture underneath, using the threat model from earlier as the lens.

• Ask the only question that matters first. “Can your company read my content on your servers?” If the answer is anything other than a clean no, it is not end-to-end encrypted, regardless of what the homepage says.
• Separate transit from processing. “Encrypted in transit” is table stakes and tells you almost nothing about whether the vendor can read your data once it arrives. Push past the padlock.
• Find out where the model runs. On your device, or in the vendor's cloud? This single fact determines most of your real exposure.
• Read the data policy for the three nevers. Never trained on, never sold, never shared — and check whether deletion is a real, available action.
• Watch for “may use to improve our services.” That phrase is frequently where training-on-your-data hides.
• Check for lock-in. If your data and your assistant are trapped with one vendor, leaving costs you everything. Bring-your-own-agent keeps the relationship yours.
• Match the mode to your requirement. If end-to-end privacy is non-negotiable, choose the E2E path even if a hosted mode is more convenient — and notice when a vendor offers you that choice honestly versus when it pretends there is no trade-off.
• Respect the people around you. No device's encryption covers your bystanders. Disclosure and discretion are on you.

Applied to Nexting, that checklist resolves cleanly. The BYOA modes — Claude Code, Codex, MyOpenClaw — pass the first six because E2E is on by default, the agent runs on your device, the keys stay with you, the relay carries ciphertext, and you bring your own model. Pro mode passes the data-policy questions but fails the encryption question, which is why we keep saying so. The seventh point is the choice itself; the eighth is yours to honor regardless of hardware.

Why we made privacy the default, not the upsell

There is a common pattern in this industry where privacy is a premium tier — pay more and we will collect less. We deliberately did the opposite. The free, bring-your-own-agent path is the one with end-to-end encryption on by default, because the people most likely to be priced out of privacy are exactly the people who deserve it most. Making the most private option also the free option is a statement about what we think the baseline should be: privacy is not a luxury good.

That choice falls out of who built this. Nexting is the work of one person — Eric Shang, a former DJI embedded engineer in Guangdong, building solo — which means there is no growth team optimizing for data collection and no advertising business that needs your attention rendered into a profile. The incentive is to sell you a good device and a clearly-priced service, and to be the kind of company a careful person can actually trust with a microphone. The honest limit on Pro is part of that same posture: a company comfortable telling you what it cannot encrypt is more believable about what it can.

An always-on wearable AI is a genuinely powerful idea, and it only works if you can wear it without surveilling yourself. The architecture in this article — your agent on your device, keys with you, the cloud relaying ciphertext — is how we tried to make that real in the modes where it can be real, and how we tried to be honest in the one mode where it cannot. Privacy by default is not a tagline here. It is the shape of the system, limits and all.