--- title: Data security nav: Data security summary: What we can't see, what we can see and why — and what the Beta doesn't do yet. order: 7 --- # Data security The short version: **we can't see what you say to your Agent, what it says back, or what it asks you to approve (the one exception is in the next paragraph).** That content is end-to-end encrypted between your phone and your computer, and only those two can read it. In the Beta you can buy today, that holds for everyone, and for text, pictures, files and voice alike. Our server just passes it along; to us it is unreadable noise. The one exception is the web app: the phone web page comes from our servers, so if we (or someone who broke into our servers) changed it, it could read what's on your phone screen. More under "What the Beta doesn't do yet" below. Below: what we can't see, what we can see, and what the Beta doesn't do yet. ## What we can't see - the messages you send from your phone, and the pictures, files and voice; - the Agent's replies and what it is busy with; - what an approval card says, and whether you approved or denied it; - the 6-digit pairing code, the pairing link, your remote pairing password; - the files on your computer, the Agent's work, its memory, the conversation history and its activity record; - your answers to the workflow design wizard and the files it writes; - the admin password you type and the API keys you paste into a card on your phone. Why we can't: - **The content is encrypted.** When a phone is paired, it and your computer each make keys that never leave them. Every message is encrypted with those keys. Our server only connects the two ends by a number and forwards the encrypted data unchanged. - **Your things stay on your computer.** The conversation history, memory, the activity record, approvals, scheduled tasks and the Agent's work are stored on your computer. When your phone shows them, it fetches them from your computer over the encrypted connection; nothing is kept on our server. Don't want the conversation kept on the computer? Run `agentj config history off`. - **Local speech stays on your devices.** Local ASR runs on your computer and local read-aloud runs on your phone or computer. If you choose cloud ASR (OpenRouter or OpenAI) or cloud TTS (OpenAI or ElevenLabs), your computer sends the audio or text directly to that provider with your own key. Audio between your phone and computer passes through our relay as encrypted data. Telegram is optional and is not end-to-end encrypted; Telegram can read that channel. - **Guests on your Telegram bot stay apart from you.** If you let your Agent J Telegram bot receive guests (off by default), only your paired private chat reaches your main Agent. Every other chat goes to the customer-service bot you chose, with its own session, limits and reviews, and is kept with that bot's conversations on your computer. - **Adding a phone always goes through you.** All three ways need you: confirm on the account page with your passkey or the target computer's remote pairing password; type the phone's 6-digit code and the remote pairing password in that computer's terminal; or confirm on a paired phone. The AI on your computer can't add a phone. The account route trusts the signed control plane, whose compromise could add a phone (see below); disable it with `agentj remote-pair off`. - **Face ID only recognises a phone you already approved.** After pairing you can choose to remember the phone with Face ID (a passkey). The passkey stays on your phone (on an iPhone, in iCloud Keychain); your computer keeps only its public key, next to that phone's pairing record, and we never receive it. Reconnecting later with Face ID — from the Home Screen app or a new private tab on the same phone — only takes over that record: no extra phone, no extra rights. Unpairing the phone on your computer cancels its Face ID record too. iCloud Keychain syncs the passkey to your other Apple devices on the same Apple ID; they can reconnect the same way (again only taking over that record). - **Files the Agent shows you are encrypted too.** Images, audio, video, PDFs, web pages and files the Agent mentions in a reply travel encrypted from your computer straight to your phone; our server sees only how much data and when, never names or content. Only files inside the Agent's working folder are sent; `.env`, private keys, certificates and anything that looks like it holds a secret are never sent. On the phone they live in memory only and are gone when you close the page, unless you download or share them yourself. - **Messages queued offline are encrypted.** What you send without a connection is kept encrypted on the phone and deleted once it has gone out; unpairing clears it too. - **The AI can't reach the approve button.** The Agent runs under your computer account and can read and write your files, so it can do its work; but it is fenced off: it can't see the keys of `agentj`, the list of phones or your passphrase. - **Agent J puts no locks of its own on the Agent.** What it may do, and when it has to ask you, follows the permission rules of your AI coding tool. Agent J only holds the data-safety floor: keys never go into the chat, logs, git or an unencrypted channel; pairing and approvals need your phone's signature; nobody else's data is touched. When an admin password or an API key is needed, you enter it in a card on your phone and the Agent never sees it — see [Admin rights and API keys, from your phone](/docs/phone-admin/). ## What reaches you, and what stays hidden What goes to you yourself is not masked. Agent J decides whether a message goes to you from its destination, not from the Agent's judgement: your paired phones and web pages, your private chat with your own Telegram bot, and the e-mail in slot 0 of your [address book](/docs/contacts/) (plus any address marked as yourself in the e-mail channel). - **Delivered as written**: e-mail addresses, phone numbers, names, postal addresses, file paths, local network addresses, links (query strings included), access codes, one-time codes and report authorization codes. These are meant for you to use; masking them would only get in your way. - **Never in plain text**: real credentials — API keys, tokens, private keys, passwords, seed phrases. E-mail and Telegram are stored on third-party servers, so even mail or messages to yourself leave them out: Agent J takes the credential out of the text, leaves a short note in its place and puts a secret pickup card on your phone, opened with Face ID. On the phone and web page these strings show as ``; to hand you a secret the Agent uses `agentj secret send`, the same pickup card. Everything that goes to anyone else stays strictly redacted, e-mail and phone numbers included: feedback, the plaza, support, friends, customer-service bots, Telegram groups, public web reports, and any mail with even one recipient who is not you. ## Who else sees something Some services handle your content by their nature. That isn't us, but you should know: - **The AI company** (Anthropic, OpenAI, Zhipu, DeepSeek and others): the conversation has to go to the model, so the vendor sees it, including any orders or buyer details in it. It goes straight from your computer to them, under your own account — not through us. How they store data is governed by their privacy policies, for example [Anthropic's privacy policy](https://www.anthropic.com/legal/privacy) and [OpenAI's privacy policy](https://openai.com/policies/privacy-policy/). - **Other services you let the Agent use** — a marketplace, email, an image tool — each see the part they handle. - **Lock-screen alerts** are delivered by Google's, Apple's or Mozilla's push service. They learn that your computer sent this phone an alert at a certain time, but the alert only says "New reply" or "A request is waiting for your approval" — no content. - **The reminder when no remote is online**: when an approval card is waiting and none of your remotes is online, and you've connected Telegram or set up the e-mail channel, Agent J sends one line to your private Telegram chat and your own inbox. It says only how many cards are waiting, never what they ask. Telegram and your mail provider can read that line. - **GitHub** (a website that hosts code): the program on your computer checks GitHub once a day for a newer version, so GitHub sees your computer's IP address, the time and the program's version. To stop it, run `agentj update auto off` on the computer. - **Your cloud provider:** if the Agent runs on a cloud server you rent, anyone who can get into your cloud console can read the files on that server. The server is only as safe as your cloud account. ## What we can see To run accounts, billing and connections, we see the following. None of it is your conversation, but here it all is: | Area | What we see | |---|---| | Account | your email address, the public part of your passkeys, sign-in times | | Agent J account | account ID, team name (if you gave one), members' email addresses | | Agents | the names you gave them; the computer's name (switch off by running `agentj report-hostname off` on the computer); online or not; how many phones, the names the phones gave themselves, when they were paired; the program version on the computer | | Billing | subscription status, number of seats, invoice results. Card numbers stay with Stripe; we never see them | | Seats sent to someone else | status, times, the email address you typed, who opened the link, which computer joined. Of the setup code itself we keep only a fingerprint, never the code | | Connections | which computer connected to our relay server when, its IP address, and the size and timing of each transfer (content is padded to fixed sizes so lengths give little away) | | IP addresses | for abuse protection, scrambled before storing so the original can't be read back, and deleted after 48 hours | | Template downloads | which computer asked for templates and when (deleted after 48 hours) | | Feedback | the reports you agreed to send us — meant for us to read, with sensitive details removed first | | Plaza | the posts and replies you agreed to publish — every account with a paid seat can read them, and so can we | | Support desk | what your Agent asks the support desk (keys, email addresses, phone numbers, user names and paths are removed before it leaves), plus the `agentj doctor` output if it chose to attach it. Not your conversations, files or keys. See [Getting help from the support desk](/docs/support/) | | Official notices | which computers each notice reached, when, and when it was read on a phone; to decide who gets a notice, each computer's Agent J version, which AI coding tool it uses, whether it's online and how many phones it has. Not conversations, email addresses, or the names of computers and phones. See [Official notices](/docs/notices/) | | Plaza skills and workflows | the full text of packages you agreed to share (every account with a paid seat can download them, and we can read them); which computer installed which version of which package; which account liked or reported which package. Not what an installed package does on your computer | ## What the Beta doesn't do yet Some things we can't do yet, or can't yet let you check for yourself: - **The phone page comes from our server.** The encryption happens inside that page. If we — or someone who broke into our servers — changed the page's code, it could see what you see on that page. Our goal is "if the page is changed, you'll know"; the Beta isn't there yet: there is no signed public release record, so you can't independently check that your phone loaded the published version. Tap the "Web app" badge at the top of the page to see this explanation and the current version's fingerprint. - **No native app.** A native app would ship its screens signed and packaged instead of fetched from us each time. That is planned, not available. - **Updates aren't digitally signed yet.** The install guide is protected by three copies agreeing — the one on our site, its published fingerprint and the public copy on GitHub; the program on your computer is installed from one fixed version tag on GitHub, and the install guide carries its fingerprints. All of that is weaker than a signature. The code for the program on your computer, the phone web app and the install guide is public on GitHub; the account dashboard, the relay server and the website aren't public yet. You choose how upgrades happen: by default, when a signed notice about a new version arrives, the Agent upgrades and then tells you; you can switch to being asked first. Urgent security fixes always upgrade right away. - **No third-party audit.** So far we rely on our own automated tests and a security check by two AI models cross-reviewing each other, which is no substitute for an independent security firm. There's no independent third-party audit during the Beta; when one is done, it will be published on the data security page. - **The fence isn't perfect.** The Agent shares your computer's network. If your computer runs local services that trust you — a local SSH server, a browser's debugging port — a command you approved could still use them to get out. Details below. - **Codex "always allow" rules** you saved earlier let matching commands run without asking your phone, by Codex's own design. `agentj doctor` counts them; whether to delete them is your call. We won't call it "absolutely secure", "zero-knowledge" or say "nobody can see your data". The model vendor sees your conversations and we see what's in the table above. That's the honest picture.
Technical details For the curious, and for your AI. Some jargon ahead. **Encryption and pairing** - Phone and computer are end-to-end encrypted: pairing uses a Noise IKpsk2 handshake (a published encryption handshake that lets two devices agree on keys only they know), every later connection Noise IK, and each message is encrypted and authenticated on its own. Session keys exist only at the two ends. Everyone uses this encrypted channel; there is no unencrypted fallback. - The QR code is generated on your computer and holds the computer's public key and a one-time pairing key (single use, 5 minutes). The 6-digit code on the phone is derived from the handshake; you type it on the computer and it must match. Then the remote pairing password (the computer stores only its scrypt hash, a deliberately slow one-way digest that is hard to turn back into the passphrase; 5 wrong tries in a row lock pairing, each lock longer than the last). - The relay server runs on Cloudflare Workers and Durable Objects. It pairs the two ends by channel number and forwards encrypted frames unchanged, each padded to 256 bytes. It stores no frames, logs no content and holds no keys. Your computer only connects outwards and opens no inbound port. - When your computer connects to the relay it shows a seat certificate signed by the account service. It holds only the channel number and an expiry time (at most 3 days), nothing about your account or computer. A computer without a valid seat cannot connect; if the account service is briefly unreachable, the computer keeps working on the certificate it holds until it expires. **Approvals** - At pairing the phone creates a non-exportable signing key (WebCrypto, the browser's built-in cryptography, with Ed25519 signatures). Every approve or deny is signed over "this computer, this phone, the request number, approve or deny, a hash of what you saw". The computer verifies it before acting and writes it to its local approvals.log (hashes only). `agentj approvals --verify` re-checks every entry. Steps approved automatically under the Full access level or "Goal mode: no cards", and a retry that ran because you approved a card left while you were offline, each point back to the signed confirmation on your phone and are checked the same way. Each time Full access is used, the computer re-checks that signature against the phone's current approval key; if it fails (the configuration file was edited by hand, or that phone was unpaired), Standard applies. - Deleting memory, Stop everything, resuming and enabling scheduled tasks from the phone are signed the same way. - Extra high-risk warnings (spending, deleting, sending out, changing passwords or keys, changing prices) are optional and off by default; switch them on in the phone's Settings. Your AI coding tool's own permission rules always apply, and Agent J never answers one of its permission questions for you: those come to your phone. In a shared session, a credential that is only read and not shown (a program reading `.env` by name) no longer raises an approval card; changing one or printing one on the screen still needs your OK on the phone, and the card never carries their contents. `agentj config approvals strict` restores the old rule that asks whenever a credential is touched. **The fence** - In an independent session the Agent runs inside bubblewrap (an open-source process isolation tool) on Linux, the built-in sandbox-exec sandbox on macOS. It keeps your user account and sign-ins, may change your shell and app settings and manage its own background services, but can't see the state folder of agentj, its keys, the phone list or the passphrase; the ssh-agent socket, other terminal sessions (tmux, herdr, screen, zellij and others) and docker / podman are hidden by default. The phone's Settings can allow docker or turn the isolation off. - If the fence can't start (bubblewrap missing, for example), the Agent does not start; it never silently runs unfenced. The phone card names the cause and the fix. **Run this launch without isolation**, confirmed with the owner's passkey, allows that one launch only; the next launch checks the fence again. - The fence is not a file wall: on Linux the whole filesystem is mounted as it is (bubblewrap `--dev-bind / /`). Apart from the hidden places above, any file your user can read or write, the Agent can too. - What remains: the shared network; local control sockets opened after start in folders not on the list; so the Agent can manage its own services, your user service manager and session bus (D-Bus) are bound back in, so it can ask the keyring for secrets over the session bus, and a program it starts through the service manager runs outside the fence; on macOS there is no process isolation, so the Agent can see other processes' command lines and environment for the same user (agentj keeps no secrets in its environment). - Agent J's own browser is meant to be driven by the Agent: that is how it does web work for you. Its debugging port is picked at random at every start and listens on 127.0.0.1 only, and its profile sits inside the hidden agentj folder, so the Agent can't copy the profile's files; but the debugging protocol has no password and the Agent shares your network, so the Agent, or any program running as your user, can use the sites signed in there, cookies included, through that port. A browser you registered yourself (for example one on port 9222) works the same way. Sign in there only to sites you want the Agent to use. - Codex is driven through codex app-server with your own Codex approval and sandbox settings; Agent J adds no policy of its own. When Codex asks for permission, the question comes to your phone. **The five guarantees today** | Guarantee | Status | |---|---| | End-to-end encryption between phone and computer; we hold no session keys | live for text, pictures, files and voice; not yet independently verifiable | | The relay sees only ciphertext and can't reach into your computer | live; not yet independently verifiable | | The code that shows plaintext isn't served by us on the fly | not done (needs a native app) | | Everything that reaches your computer is signed and published; you decide what to install | no signatures or release log yet; you choose how upgrades happen (automatic or ask first; security fixes always right away) | | Credentials and master keys stay on your side | the key card on your phone saves a key, encrypted on the way, straight into a file on your computer; we store none of your keys | The full itemised version (every table, every retention period) is on the [Data security details](/security/) page. Found a security problem? See [Contact](/docs/contact/).
## Automatic sign-in token (0.17.4) So that a phone stays paired after one pairing, your computer gives it an automatic sign-in token. It travels through the encrypted channel and m.agentj.app keeps it as a cookie for that site only: page scripts cannot read it and no other request carries it. When the phone has lost the page's data, our web service uses it only to compute a one-time proof that is valid for this phone's new keys; the token itself never goes back to the page, and your computer does the checking. We neither keep nor log it. To be plain: our web service handles the token at that moment, so a tampered web service could in theory take this phone's place. If that happened, the original phone would immediately show that another one took over; unpairing the phone on your computer cancels the token at once. ## Add a remote for another computer Once the target computer is installed, account-bound and online, find its seat card on your account page and choose Add a remote. Confirm it's you, then scan with the phone; the target computer's terminal isn't needed. Confirm either way: with your passkey (none on this computer? choose Use a phone or tablet in the prompt and confirm on your phone), or with that computer's remote pairing password. After a passkey confirmation, the same session doesn't ask again for ten minutes; the QR expires after five minutes and adds one device. Pending devices can also be reviewed and approved on the seat card. Under More on the seat card, See what the computer is waiting on you for is only for two cases: resuming after Stop everything, or enabling a scheduled task the Agent created. It has nothing to do with seats or billing; an unpaid bill never stops the tasks on your computer. Account-page pairing is on by default. The target computer’s owner can disable it with `agentj remote-pair off`. Offline hosts are never queued; turn them on and try again. Older hosts must run `agentj update apply` or update from a paired phone. Devices record “Added from account page” and other remotes receive a notice. This route trusts the signing control plane. Pairing material is encrypted to an ephemeral browser key and its plaintext is never stored by the backend; the host checks the control plane's signature, not your passkey itself: a compromised signing service could add a phone to this computer, lift Stop everything, enable a scheduled task or rename a remote without any confirmation on the computer. Your existing phones are notified of a new device; `agentj remote-pair off` refuses this route. The remote pairing password is stored only on that computer, as a hash. When you type it on the account page, the browser first encrypts it to a one-time public key that computer just handed out; only that computer can open and check it. Our servers pass on ciphertext they can't read and keep nothing. Five wrong tries in a row lock it on that computer for a while. ## Public customer-service bots (0.17 candidate) Owners manage bots on the paired phone `/bots`, or ask Agent J to use `agentj-bots` for product manuals, fixed price lists and company HTTP APIs. The public `/bots/` URL and website embedding are free. The owner computer must be online. Visitors cannot enter the main conversation or owner approval channel. AI answers can be wrong; owners must review public knowledge and business scope. Chats, knowledge, tool definitions and conversation records stay on the owner computer. Visitor messages use a separate encrypted protocol to that computer. Cloud services hold public names, display metadata, status, rate limits and report metadata only. Chat retention defaults to 30 days and report metadata to 90 days. Reports contain a request ID and category, never chat text. First contact still trusts the website page and public-key binding; a malicious page publisher can replace them. Bots share the main Agent’s current AI app and account plan, including Claude Code, Codex, Gemini, OpenCode and key providers. The owner must confirm provider terms: public use of a personal subscription may be restricted. Optional own-key profiles remain available through the phone secret card. Requests go from the owner computer to the chosen model provider. If that provider is AgentsRelay, requests pass through it; its policy is not to record request or response bodies, a policy assurance rather than technical inability to see them. Jev reviews require the owner’s own OpenRouter account and key, verified through the decisions endpoint before activation. Review costs are paid by that OpenRouter account. Model providers and OpenRouter receive the minimum necessary context under their own data policies. Missing, failed or uncertain reviews stop output; human replies use the same gate. Defaults: 20 visitor messages/day, 100 bot messages/day, and 100 messages plus 100k model tokens/day across the owner bots, including review and tool costs. One enabled bot per seat; concurrency defaults to 4 and cannot exceed 16. Owners can lower limits. Limits or an offline computer stop service politely. Public names contain 3–32 lowercase ASCII letters, numbers or hyphens. Reserved names are unavailable; renamed or removed names freeze for 30 days. Read tools access only owner-approved HTTPS domains and return selected, bounded fields. Authentication secrets are injected at runtime on the host, never sent to the model. Self-reported order numbers or emails bind a visitor session but do not authenticate a customer; company APIs must independently authorize record access. Write tools default off; each enabled write requires paired owner phone approval. Visitor text, knowledge and tool results cannot authorize configuration changes, cross-visitor access or credential disclosure. Shell, arbitrary files and arbitrary URL tools are unavailable. Turnstile runs only in an isolated verification page that cannot read chat content. Anonymous visitor session keys are stored per bot in a separate browser origin and cannot be exported. Browser MessagePorts connect that storage frame directly to the isolated chat frame; parent pages, verification pages and servers receive no key or chat text. After 24 hours without activity a new session starts. Blocking cross-site browser storage also means a new session on reload.