DevOS
Security and threat model
What is protected, what is not, and who can see what.
“Most secure” is a goal, not a claim. This page states only properties that ship and can be checked. The relay sees routing, pairing and push metadata. No independent audit or certification exists yet.
The relay, honestly
Encrypted session path
A session message is sealed on the phone with AES-256-GCM under a key agreed with your computer by X25519. The relay carries the sealed envelope and still sees the routing, pairing and push metadata around it. Your computer opens it and passes it to the agent.
- Sealed end to end
- Metadata the relay can see
- Same machine, SSH or setup step
- Shipped
- Trust boundary
Sealed end to end
- Chat and agent output
- Terminal and file contents
- Screen sharing
- Account keys carried between your Macs
The relay still sees
- Routing between your devices and computers
- Pairing records: hashed device keys, random IDs and names
- Push metadata: token, time, kind, session grouping ID, sealed size
- Timing and sizes of what it forwards
Parts: hover, focus or press one for what it does and what it can see
Read this diagram as text
Layers, top to bottom
- Your phone (seals).
- Phone seals the message, shipped, AES-256-GCM. Chat, terminal, files, screen sharing and account keys are encrypted on the phone before they leave it. Can see: The plain message.
- X25519 key agreement, shipped, from the first message. The phone and the computer agree a key during the join handshake, over any network, when the phone joins with a setup code or an invite. A phone paired by an older version enrolls once on the Mac’s Wi-Fi and, until then, uses HTTPS only. Each connection uses fresh keys. Can see: Both public keys.
Trust boundary below this layer. The sealed envelope leaves the phone. The key does not.
- Relay (carries, cannot open).
- Relay forwards the envelope, shipped, cannot read the contents. The relay forwards the sealed envelope. It stores hashed device keys and pairing records, uses IP addresses in memory for abuse limits, and does not log or store payload content. Can see: Routing; Pairing; Push metadata; Timing and sizes.
- What the relay does see, shipped, routing, pairing, push, timing, sizes. Metadata is real. The relay can tell that a phone and a computer talked, when, and roughly how much. It keeps a random computer ID and name, hashed device keys and who is paired with what. For push it sees the token, the time, the kind (including a join request), a session-grouping identifier and the size of the sealed text. Can see: Routing; Pairing; Push metadata; Timing and sizes.
Trust boundary below this layer. The same envelope arrives untouched. Only your paired devices and your computer can open it.
- Your computer (opens).
- Computer opens it, shipped, the bridge decrypts and checks. The bridge decrypts, checks who is asking and what they may do, then passes the text to the agent. It is the only authority over its own machine. Can see: The plain message.
- Agent, shipped, runs in your folder. Agents run with your user’s power on your computer. End-to-end encryption protects the path, not a compromised computer. Can see: The plain message, and your project.
Connections
- Phone seals the message to Relay forwards the envelope: Sealed end to end (AES-256-GCM)
- Relay forwards the envelope to Computer opens it: Sealed end to end (AES-256-GCM)
- X25519 key agreement to What the relay does see: Metadata the relay can see (pairing metadata)
- Computer opens it to Agent: On the same machine or link
In short
- Sealed end to end: Chat and agent output; Terminal and file contents; Screen sharing; Account keys carried between your Macs.
- The relay still sees: Routing between your devices and computers; Pairing records: hashed device keys, random IDs and names; Push metadata: token, time, kind, session grouping ID, sealed size; Timing and sizes of what it forwards.
Conversations, terminals, files, screen sharing and account keys travel end-to-end encrypted between your phone (or browser) and your computer. The relay passes them along but cannot read them. The cipher suite is X25519 key agreement with AES-256-GCM.
Each computer’s random ID and its name, a random account ID that groups your devices, hashed versions of device keys, and which phones are paired with which computers and whether each is owner, member or guest. Pairing a browser leaves a short-lived message, deleted within 5 minutes. A removed phone leaves a note, kept 30 days, that it may no longer connect. The relay uses IP addresses in memory for abuse limits and does not store them; Cloudflare, as host, processes them. Being a forwarder, it also necessarily observes when connections happen and how large messages are.
Only a phone paired by an older version can be in this state until it enrolls: its app requests go through the relay without the extra layer, protected in transit by HTTPS, and the relay could technically read them. The relay’s code does not log or store their content. Once a phone has enrolled, the Mac refuses any request that skips end-to-end. A phone that joins with the owner’s setup code or an invite has end-to-end keys from the first message, over any network. Only a phone paired by an older version enrolls once, on the Mac’s Wi-Fi.
Your computer encrypts the text of each notification with a key shared only between your iPhone and that computer, so neither the relay nor Apple can read it. They can see the phone’s push token, the time of each notification, its kind (a session needs you, a session is done, or a join request), an identifier that groups notifications by session, and the size of the sealed text. Live Activities on the Lock Screen are not encrypted this way: they carry only counts and a random computer ID.
Plainly: the relay sees routing, pairing and push metadata. End-to-end encryption protects payloads, not the fact that you are connected. Read the threat model.
System architecture
Phones, tablets and a browser reach your computers through a relay on Cloudflare. Agents run on your computers, never on the relay. Session payloads are sealed end to end between your devices and your computers. The relay still sees routing, pairing and push metadata, and Apple delivers the push notification.
- Sealed end to end
- Metadata the relay can see
- Same machine, SSH or setup step
- Planned link
- Shipped
- Planned, dashed with a badge
- Trust boundary
Sealed end to end
- Chat, terminal, files, screen sharing and saved logins
- Notification text, sealed for your phone
The relay still sees
- Routing: which device talks to which computer
- Pairing: random IDs, names and hashed device keys
- Push metadata, and when connections happen and how large they are
Parts: hover, focus or press one for what it does and what it can see
Read this diagram as text
Layers, top to bottom
- Your devices (hold keys).
- iPhone, shipped, DevOS Mobile. Holds its own keys in the system keychain. Starts, follows, answers and reviews agent sessions on your computers. Can see: Everything in your sessions, decrypted on the phone.
- iPad, shipped, same app, portrait and landscape. The iPad app does what the iPhone app does. It holds its own keys and pairs with your computers the same way. Can see: Everything in your sessions, decrypted on the iPad.
- Browser, shipped, web app, paired from a phone. A browser paired from the phone shows the same inbox. It runs nothing itself. Can see: What you open in it.
Trust boundary below this layer. Payload keys stay on your devices and computers. The relay carries sealed envelopes.
- Relay and push (no payload keys).
- Relay on Cloudflare, shipped, forwards sealed envelopes. Forwards end-to-end encrypted traffic and cannot read it. It does keep each computer’s random ID and name, hashed device keys and who is paired with what, and it sees when connections happen and how large they are. Can see: Routing; Pairing records (hashed device keys); Push metadata; Timing and sizes.
- Apple push, shipped, APNs. Notification text is sealed for your phone. Apple and the relay see the push token, the time, the kind of alert, a session-grouping identifier and the size of the sealed text. Can see: Push token; Time and kind; Random conversation ID.
Trust boundary below this layer. The relay hands sealed envelopes to your computer. Only the bridge opens them.
- Your computers (hold keys, run the agents).
- Mac: companion + bridge, shipped, the only part that starts agents. DevOS Companion runs the signed devos bridge. The bridge opens sealed envelopes, checks who is asking, and is the only authority over its own machine. Its API keys sit in the Keychain, readable without a prompt only by the signed bridge. Can see: Your sessions, files and keys on that Mac.
- Linux over SSH, shipped, added through a Mac. Other computers, such as a Linux server, join through a Mac that adds them over SSH. They keep working while that Mac sleeps. Can see: The sessions you run there.
- Sandbox desktops, shipped, a Linux desktop per session. A Linux computer of its own for a session’s agent. It runs apart from the Mac and nothing of the Mac is shared with it. Can see: Only what you put in it.
- Agents, shipped, Claude Code, Codex, Grok, Cursor, Gemini. Run in a project folder on their own logins, with your user’s power on that computer. Listed as options, not partners. End-to-end encryption does not protect a compromised computer. Can see: Whatever your user can reach.
- DevOS ADE, planned, optional runtime, design only. Planned. An optional local workbench that would be reached only through the companion on the same Mac, never directly from the phone. Nothing is built, and it shares no code with the bridge or relay today. Can see: Nothing yet: not built.
Connections
- iPhone to Relay on Cloudflare: Sealed end to end (sealed)
- Browser to Relay on Cloudflare: Sealed end to end (sealed)
- Relay on Cloudflare to Apple push: Metadata the relay can see (push metadata)
- Relay on Cloudflare to Mac: companion + bridge: Sealed end to end (sealed)
- Mac: companion + bridge to Linux over SSH: On the same machine or link (SSH)
- Mac: companion + bridge to Agents: On the same machine or link
- Mac: companion + bridge to DevOS ADE: Planned (via companion)
In short
- Sealed end to end: Chat, terminal, files, screen sharing and saved logins; Notification text, sealed for your phone.
- The relay still sees: Routing: which device talks to which computer; Pairing: random IDs, names and hashed device keys; Push metadata, and when connections happen and how large they are.
Pairing and roles
The Mac shows an owner setup code and the phone scans it. The two agree end-to-end keys from the first message. The relay stores only hashed device keys and who is paired with which Mac. Roles are set per Mac, per device: owner, member and a time-boxed guest, and a Mac can have several owner devices.
- Metadata the relay can see
- Same machine, SSH or setup step
- Shipped
- Trust boundary
The relay stores
- A random computer ID and name
- A random account ID that groups your Macs
- Hashed device keys and who is paired with what
The relay does not hold
- Your email, name or contacts
- The keys that open your sessions
Parts: hover, focus or press one for what it does and what it can see
Read this diagram as text
Layers, top to bottom
- Your Mac and your phone (hold keys).
- 1. Mac shows a setup code, shipped, DevOS Companion. The owner setup code is shown only on your own Mac. Do not use a code from anywhere else. Can see: The code on screen.
- 2. Phone scans it, shipped, or opens an invite. Scanning the code pairs the phone. An invite from an owner is another way in. Can see: The code.
- 3. Keys agreed once, shipped, X25519, in the join. End-to-end encryption is set up from the first message as the computer. After that, frames are sealed with AES-256-GCM. Can see: Only the two devices.
Trust boundary below this layer. The keys are agreed between your two devices. The relay is only told who is paired.
- Relay (no payload keys).
- Relay keeps a record, shipped, hashed device keys only. The relay keeps a random computer ID and name, a random account ID, hashed device keys and who is paired. No email, no name, no contacts. That record is metadata the relay can see. Can see: Hashed device keys; Who is paired with what.
Trust boundary below this layer. Owner is granted only at the Mac, by showing its setup code there. A phone cannot grant itself.
- Roles on that Mac (set per Mac, per device).
- Owner, shipped, first approved phone. The first phone a Mac approves is its owner. Owners keep the sensitive actions and can remove a phone, which signs it out and deletes its pairing on the relay. Can see: Everything on that Mac they are allowed to.
- Co-owners, shipped, more than one owner device. A Mac can have several owner devices. Owner is granted only at the Mac, never by a request from a phone. Can see: Same as an owner.
- Member, shipped, a paired device, not an owner. A paired device without owner powers. Sensitive actions stay with owners. Can see: What owners let members use.
- Guest, shipped, time-boxed: watch. A guest sees only what you name, for a limited time, to watch. Guests who can reply are not available yet. Can see: Only what you name, until it expires.
Connections
- 1. Mac shows a setup code to 2. Phone scans it: On the same machine or link (code)
- 2. Phone scans it to 3. Keys agreed once: On the same machine or link
- 3. Keys agreed once to Relay keeps a record: Metadata the relay can see (who is paired)
In short
- The relay stores: A random computer ID and name; A random account ID that groups your Macs; Hashed device keys and who is paired with what.
- The relay does not hold: Your email, name or contacts; The keys that open your sessions.
Invites, and what the relay could still do
An invite joins through the relay without the same Wi-Fi. The handshake mixes the invite secret into the end-to-end keys and pins the Mac’s key from the link, so the relay cannot finish a join or put its own key in.
- Sealed end to end
- Same machine, SSH or setup step
- Shipped
- Trust boundary
What still needs a person
- The owner makes the invite
- The owner approves a link after matching a four-digit code
- The owner’s own first pairing: a setup code shown on the Mac
What it no longer needs
- The same Wi-Fi
- Scanning anything at the Mac
- The relay seeing the invite secret
Parts: hover, focus or press one for what it does and what it can see
Read this diagram as text
Layers, top to bottom
- The owner (a human step).
- 1. Owner makes an invite, shipped, Invite someone, or devos user add. On the Mac’s desk, under a Mac’s Phones on the owner’s phone, or with devos user add. Pick Member or Guest. A guest sees only chosen projects or sessions until an end date the Mac enforces. Can see: Nothing yet.
- 2. Share a link, or show a QR, shipped, link: by any channel. A link works once and lasts 24 hours; send it by Messages, email or anything else. A QR code is for in person and lasts 10 minutes. Can see: The channel you chose sees the link, so pick one you trust.
- The invited person (any network).
- 3. Opens it in DevOS Mobile, shipped, or the relay’s browser client. The link opens the app. The device makes its own key and joins through the relay. The Mac’s key comes from the link, so the relay cannot put its own in. Can see: The device and the Mac, nobody else.
- 4. Reads back a four-digit code, shipped, link invites only. Both sides show the same four-digit code taken from the handshake. The invited person reads theirs to the owner, in whatever way suits them. Can see: The two devices.
Trust boundary below this layer. Everything after the # in the link stays on the device. The relay is told only a hash of the invite id.
- Relay (carries the sealed join).
- Join passes through the relay, shipped, sealed, not readable. The relay forwards the handshake to the Mac that listed the invite’s hash. Without the secret it cannot finish the handshake or swap a key in. It sees routing, timing and that a join happened. Can see: A hash of the invite id; Routing and timing; That a join was asked for.
- Back on the owner’s side (a human step).
- 5. Owner approves, shipped, after matching the code. The companion and the owner’s phones show: Bo wants to join Studio as a Guest, code 4821. Approve only when the code matches what Bo reads out. Deny cancels the invite. A QR invite admits at once and tells the owner’s phones afterwards. Can see: The owner decides.
- Role and end date, shipped, member, or guest until a date. The new device gets a role. A guest’s end date is enforced on the Mac, which removes the device when it passes. In the first release, guests can watch; guests who can reply are off. Can see: Only what the role allows.
Connections
- 1. Owner makes an invite to 2. Share a link, or show a QR: On the same machine or link
- 2. Share a link, or show a QR to 3. Opens it in DevOS Mobile: On the same machine or link (link or QR)
- 3. Opens it in DevOS Mobile to Join passes through the relay: Sealed end to end (sealed join)
- Join passes through the relay to 5. Owner approves: Sealed end to end (asks the owner)
- 5. Owner approves to Role and end date: On the same machine or link
In short
- What still needs a person: The owner makes the invite; The owner approves a link after matching a four-digit code; The owner’s own first pairing: a setup code shown on the Mac.
- What it no longer needs: The same Wi-Fi; Scanning anything at the Mac; The relay seeing the invite secret.
- A link is a credential until it is used. Whoever can read it before the invited person (an email service or link scanner that opens links first) could try to use it. A link waits for the owner to approve after matching a four-digit code, and any denial cancels it.
- A QR invite admits whoever uses it first, with no approval, by the owner’s choice. Every QR join is told to the owner’s phones and listed for a day: remove any device you did not expect.
- Opened in a browser, the link loads the relay’s join page, and the browser client is the relay’s too. A relay that served altered pages could read the secret. Opened in DevOS Mobile, the link never touches those pages.
- Guests who can reply are off in this release: guests watch.
- The relay sees routing, pairing and push metadata, and that a join happened.
Assets and trust boundaries
Assets: session content (chat, terminal, files, screen), agent credentials and keys, repo contents on your machine, pairing secrets and push tokens.
Components: the phone or browser, the relay (a Cloudflare Worker with a Durable Object), the Mac companion and bridge, the agents, and Apple’s push service.
Boundary: end-to-end encryption runs between your phone or browser and your computer. The relay and Apple sit outside it.
Mitigations that ship
- X25519 key agreement and AES-256-GCM between your devices.
- Only hashed device keys on the relay.
- Secrets in the system keychain where available, under a fixed signing identity, on Macs.
- Owner and member roles; sensitive actions are owner-only.
- .env masking, and a denylist for sensitive folders.
- Developer ID signing and Apple notarization for the companion.
Each line is checked against the product source for the current release. Nothing here has been independently audited.
Adversaries considered
| Adversary | What helps | What remains |
|---|---|---|
| Network eavesdropper | Session payloads are end-to-end encrypted. Requests from a not-yet-enrolled (older-version) phone rely on HTTPS. | Sees that traffic exists, as any network observer does. |
| Curious or compromised relay operator | Cannot read E2E payloads sent by the iPhone and iPad apps. Stores only hashed device keys, though your device key is sent to it to sign in, so it is a login credential. A browser session runs code the relay serves, so a browser trusts the relay. | Sees metadata. Can deny service, drop or delay messages. For phones paired by an older version that have not enrolled, can technically read app requests. |
| Stolen phone | Keys live in the system keychain. The owner can remove a phone from a Mac, which signs it out and deletes its pairing on the relay. | A phone that is unlocked and still paired can act until removed. |
| Another person on your Wi-Fi | Adding a phone needs the owner’s setup code or an invite from the desk. A phone that joins this way has end-to-end keys from the first message. | The setup QR admits the first scanner while a Mac has no owner, for up to 10 minutes: show it only on your own screen. |
| Malicious invite link | The invite lives in the URL fragment, which browsers do not send to the server. The invite landing page runs under a locked-down content security policy. | A link you were tricked into opening and approving. |
| A malicious or confused agent on your Mac | Sensitive folders sit on a denylist. .env-style files are masked and open only for the owner on the Mac’s Wi-Fi or over the E2E link. | Agents run with your user’s power. DevOS does not sandbox your own machine for you. |
| Supply chain of the download | Developer ID signing and Apple notarization for the companion; a published SHA-256 you can check yourself. | A matching hash proves the file is what we published, not that the publisher is trustworthy. Notarization is an Apple malware scan, not an audit. |
Non-goals and residual risks
- Endpoint compromise: if your Mac or your phone is compromised, E2E does not help.
- Metadata: who connects to which computer, and when, is visible to the relay.
- First pairing and the pre-E2E window use HTTPS only.
- Screen sharing needs powerful macOS permissions. Grant them only if you use it.
- No audit, certification or SLA exists. We do not claim any.
Team plane
Planned Visibility rules for teams are being designed and are not part of this model yet. Nothing here applies to them.
Reporting a problem
Report a security problem to support@fightingsmartcyber.com with "Security" in the subject. Do not send keys, tokens or setup codes. There is no bounty and no formal disclosure programme yet.
Words we do not use
We do not call DevOS “zero-trust” or “zero-knowledge”, and we do not say the relay sees nothing. We describe the specific properties above instead, until an independent review supports more.