数据安全Data security

这一节写给想深究的人和你的 AI，会用到一些术语。

加密与配对

• 手机和电脑之间是端到端加密。配对时，用 Noise IKpsk2 握手（一种公开的加密握手协议，两台设备借它商量出只有彼此知道的钥匙）。之后每次连接用 Noise IK，每条消息单独加密和校验。会话密钥只在两端。所有用户都走这条加密通道，没有不加密的备用通道。
• 二维码由你的电脑生成，里面是电脑的公钥和一次性的配对密钥，5 分钟有效、只能用一次。手机显示的 6 位码由握手结果算出，你在电脑上输入，两边一致才算数；再加上遥控器配对密码（电脑上只存它的 scrypt 哈希：一种故意算得很慢的单向摘要，拿到也很难反推出口令；连续输错 5 次会锁定，锁定时间逐次加倍）。
• 转发服务器运行在 Cloudflare Workers 和 Durable Objects 上，只按通道号配对两端，原样转发加密帧，每帧补齐到 256 字节。它不存帧、不写内容日志、不持有任何密钥。你的电脑只向外连接，不开任何入站端口。
• 电脑连上转发服务器时要出示一张由账号服务签发的席位证书，里面只有通道号和到期时间（最长 3 天），没有账号和电脑的信息。没有有效席位的电脑连不上；账号服务暂时连不上时，电脑用手里的证书继续工作到期满。

批准

• 配对时手机生成一把不可导出的签名密钥（浏览器自带的加密功能 WebCrypto，Ed25519 签名算法）。每次批准或拒绝，手机都对「这台电脑、这部手机、请求编号、批或拒、内容摘要的哈希」签名，电脑核对后才执行，并写进本机的 approvals.log（只记哈希）。agentj approvals --verify 可以逐条重新核对。按「全放行」档位或「设了目标就不弹窗」自动批准的，以及你批准了离线时留下的卡后 Agent 重试执行的，记录里都会指回手机上那次签名确认，同样能核对。电脑每次用到「全放行」都会用那部手机现在的批准密钥重新核对这次签名，核对不过（比如配置文件是手改的，或者那部手机已解绑）就按「中等」处理。
• 删除记忆、全部停下、恢复、启用定时任务这些手机上的操作，也一样要签名。
• 额外的高危提醒（花钱、删除、对外发送、改密码或密钥、改价格）是可选的，默认关闭，可以在手机「设置」里打开。你的 AI 编程工具自己的权限规则一直生效；它要问权限时，问题会送到你手机上，Agent J 绝不替你回答。

共享会话里，只读取凭据而不显示（程序按名字读 .env）不再弹审批卡；改凭据、把凭据显示到屏幕上仍然要你在手机上点头，卡片不带具体内容。agentj config approvals strict 可以换回只要碰到凭据就问的旧规则。

隔离

• 独立会话里，Agent 在 Linux 上用 bubblewrap（一个开源的进程隔离工具）、在 macOS 上用系统自带的 sandbox-exec 沙箱运行。它用你的系统用户和登录，可以改你的 shell 和应用配置、管理它自己的后台服务，但看不到 agentj 的状态目录、密钥、手机名单和口令；ssh-agent 接口、别的终端会话（tmux、herdr、screen、zellij 等）和 docker / podman 默认对它隐藏。手机「设置」里可以允许 docker，也可以关掉隔离。
• 隔离起不来时（比如没装 bubblewrap），Agent 不会启动，不会悄悄裸跑。手机卡片会说明原因和修法；点「本次不隔离运行」并用主人的通行密钥验证，才放行这一次，下次启动照样检查隔离。
• 隔离不是一堵文件墙：Linux 上整个文件系统按原样挂进隔离（bubblewrap 的 --dev-bind / /），除了上面隐藏的几处，你的用户能读写的文件，Agent 也能读写。
• 剩下的风险：共用网络；启动后新开的、不在清单里的本地控制接口遮不住；为了让 Agent 管理自己的后台服务，你的用户服务管理器和会话总线（D-Bus）接回了隔离里，所以它经会话总线能找钥匙串要密钥，经服务管理器启动的程序在隔离之外运行；macOS 上没有进程隔离，Agent 能看到同一用户其他进程的命令行和环境变量（agentj 不在环境变量里放密钥）。
• Agent J 专用浏览器本来就是给 Agent 用的，它靠这个浏览器替你上网办事。这个浏览器的调试端口每次启动随机选，只在 127.0.0.1 上监听；它的资料目录在隐藏的 agentj 文件夹里，Agent 拷不走里面的文件。但调试协议没有密码，Agent 又和你共用网络，所以 Agent（或者任何以你的用户身份运行的程序）能经这个端口使用在里面登录过的网站，包括 cookie。你自己登记的浏览器（比如开在 9222 端口的那个）也一样。只在里面登录你愿意让 Agent 使用的网站。
• Codex：通过 codex app-server 驱动，沿用你自己的 Codex 审批和沙箱设置，Agent J 不另加规则。Codex 要问权限时，问题会送到你手机上。

五项保证的现状

完整的逐项说明（每张表、每个保留期）见 数据安全详细说明。发现安全问题，请看 联系我们。

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

The full itemised version (every table, every retention period) is on the Data security details page. Found a security problem? See Contact.