Note: English is not the author’s native language; this English version may contain grammatical or semantic inaccuracies. In case of any discrepancy, the Chinese version is authoritative.
Lucifiel Security Research
Responsible Disclosure / AI + Crypto / Web3 Security
Donut AI 漏洞披露Donut AI Vulnerability Disclosure
本文为 Donut AI 相关产品的漏洞披露，范围包括 Donut Browser 钱包交易链路与 D0 AI Agent 自动化交易系统中发现的安全问题，并完整记录与项目方的沟通披露过程，以及对其漏洞响应与安全治理的观察。本文属于负责任披露流程，一切测试与披露过程均合法合规。
This is a security disclosure for Donut AI’s products, covering issues found in the Donut Browser wallet-transaction path and the D0 AI-Agent automated-trading system, together with a full record of the disclosure communications with the vendor and observations on its vulnerability response and security governance. It follows a responsible-disclosure process; all testing and disclosure were lawful and compliant.
Severity is assigned by real-world impact on fund safety, account privileges, control-plane capability, execution-environment control, and attack-chain reachability.
一分钟速览One-Minute Overview
谁：独立安全研究员、数字循真创始人 Lucifiel，自 2025-12 起是 Donut 的用户与 beta 测试者。Who: Lucifiel — independent security researcher and founder of 数字循真 (a Runtime Semantic Intelligence platform); a Donut user and beta tester since 2025-12.
授权：Donut 官方两届 Bug Hunt（2026-02 的 1.0、2026-03 的 2.0）及后续线上沟通框架内。Authorization: within Donut’s two official Bug Hunts (1.0 in 2026-02, 2.0 in 2026-03) and the subsequent online-communication framework.
发现：Donut Browser 与 D0 两套系统共 49 个问题（Critical 10 / High 19 / Medium 16 / Low 4）。核心两条：Findings: 49 issues across the two systems — Donut Browser and D0 (Critical 10 / High 19 / Medium 16 / Low 4). Two core chains:
① Donut Browser 自动签名盗币链：后端在用户无签名确认下即可自动签名并广播交易，且可通过诱导点击远程触发（自有账户已实证，11 笔链上交易 Solscan 可查）；跨用户转账请求在平台侧可被构造放行，最终由第三方托管 Turnkey 拦截、未实际转走他人资金。① Donut Browser auto-signing fund-theft chain: the backend can auto-sign and broadcast transactions with no user signature confirmation, and this can be triggered remotely by a single induced click (proven on the researcher’s own account — 11 on-chain transactions verifiable on Solscan); cross-user transfer requests can be constructed and passed on the platform side, ultimately blocked by the third-party custodian Turnkey — no other user’s funds were actually moved.
② D0 远程命令执行：在研究员自有 Pod 内取得 RCE（已实证）。② D0 remote code execution: RCE achieved inside the researcher’s own Pod (proven).
流程：经三次线上会议 + 脱敏报告 + PPT + PoC 视频 + 书面通知告知厂商，给出超 90 天修复窗口，产品负责人当场确认披露流程。Process: the vendor was notified through three online meetings + a redacted report + slides + a PoC video + written notice, and given a remediation window of over 90 days; the product lead confirmed the disclosure process on the spot.
结果（截至 2026-06 复测）：Outcome (as of the 2026-06 retest):
修复状态：49 项中仅 11 项完全修复，9 项部分修复，29 项仍未修复（含多个核心 Critical）。Remediation status: of the 49 items, only 11 are fully fixed, 9 partially fixed, and 29 still unfixed (including several core Criticals).
处理口径：系统级研究（49 漏洞 / 攻击链 / RCE）被项目方按常规社区奖励口径处理，未获任何单独评估或专项赏金，也未在任何公开渠道（官网致谢、安全名人堂、漏洞披露致谢等）获得正式认可（仅 Discord 社区有非正式感谢）；两届 Bug Hunt 活动各 100 USDC、共 200 USDC，是研究者参赛、按活动规则赢得的常规活动奖金（其中 Bug Hunt 2.0 的 100 USDC 凭独立提交的 13 个漏洞赢得），与本次系统级研究无关；研究者早在 2026-03-18 即书面要求将参赛活动奖金与系统级研究分开评估、反对把后者并入常规社区奖励口径。How it was handled: this system-level research (49 vulnerabilities / attack chains / RCE) was treated by the vendor as a routine community-reward matter — no separate assessment or dedicated bounty, and no formal recognition on any public channel (website credits, security hall of fame, disclosure acknowledgements, etc.); only informal thanks in the Discord community. The two Bug Hunts paid 100 USDC each (200 USDC total) — ordinary event prizes the researcher won by competing (the Bug Hunt 2.0 prize was earned with 13 separately submitted vulnerabilities), unrelated to this system-level research; as early as 2026-03-18 the researcher asked in writing that the contest prizes and the system-level research be assessed separately, objecting to folding the latter into the routine community-reward track.
最终回应：研究员发出最终通知后，项目方未就诉求继续沟通，转以法务立场回复、声明保留追责权利，并作出多条不实指控（均与会议及书面记录不符，正文已逐条对照；会议原始语音与书面记录均已完整封存、脱敏收录，欢迎机构监督核实）。Final response: after the researcher’s final notice, the vendor stopped engaging on the substance and switched to a legal-posture reply — asserting a reservation of the right to pursue claims and making several false allegations (all inconsistent with the meeting and written records, rebutted point by point below; the original meeting audio and written records are fully preserved and redacted-archived, and independent verification is welcome).
技术支持：数字循真平台研判框架（攻击链建模与风险研判）。Tooling: the analysis framework of the 数字循真 platform (attack-chain modeling and risk assessment).
本文：完整脱敏、零 PoC、零可复用武器的负责任披露记录。This document: a fully redacted, zero-PoC, zero-reusable-weapon responsible-disclosure record.
The author is a security researcher. In June 2025, drawn by Donut’s project narrative, the researcher began following the product and joined its official Discord community; in December 2025 the researcher took part in official product interviews and beta testing. After Donut launched its official security events (Bug Hunt), the researcher moved into systematic security research on it and took part in both Bug Hunts.
Within the two events and the subsequent communication framework, the researcher found a total of 49 security issues across the two systems, Donut Browser and D0 — chiefly around wallet-transaction authorization, user isolation, asset-ownership checks, control-plane access, and runtime-environment isolation — including attack chains that can affect user fund safety (evidenced by 11 on-chain transactions) and remote code execution on the D0 platform. The researcher’s ask was open and consistent from the start: as early as the first meeting the researcher clearly expressed a wish to join Donut — in his own words, “如果有可能，我也比较想参与到这边来” / “很想参与进来” noting he had already raised the idea with [the COO]; in early Telegram messages he again stressed that “个人更在意的是长期合作”; and at the third meeting he made clear he hoped to join the team full-time.
On the bounty, the researcher consistently said the amount was negotiable and repeatedly asked the vendor to price it themselves by impact and industry standards; only about three months later, at the third meeting — which the vendor itself initiated — did the researcher give a self-assessed range and explain the basis for it, again asking the vendor to price by industry standards. Throughout, the pricing was always a negotiable suggestion; the researcher never threatened disclosure as leverage, and this was not “强买强卖”.
The researcher acted under a responsible-disclosure process from the outset and explained that process in full at the first meeting: notifying the vendor of the risks via online meetings, a redacted report, slides, a PoC video, and written notice, with a remediation window of over 90 days, confirmed on the spot by the product lead; and making clear that, once the window closed, the redacted research would be published as usual regardless of whether the issues were fixed. This publication plan was set from the very first communication and is a standard step of responsible disclosure.
The advice below is based on objective facts: as of the June 2026 retest, of the 49 issues catalogued here only 11 are fully fixed, 9 partially fixed, and 29 still unfixed (including several core Criticals), and at the time of publication no third-party security audit or remediation-retest report from Donut has been seen. The following are general crypto-asset protection measures applicable to any early-stage product involving custodial wallets, auto-signing, and automated execution — not aimed at any specific party; whether to adopt them is your own call.
如果你正在使用 Donut Browser、D0 或相关钱包 / AI Agent 功能，可按以下顺序处理风险。
If you use Donut Browser, D0, or related wallet / AI-Agent features, you can address the risks in the following order.
Control asset exposure first, then handle accounts, credentials, and files. If you notice abnormal transactions or access, immediately move high-value assets out and keep the transaction hashes, screenshots, and a timeline.
钱包与链上资产Wallets & on-chain assets
01避免在 Donut 托管钱包中长期存放大额资产，按需充值、用完即提。Avoid keeping large balances in a Donut custodial wallet for long; deposit as needed and withdraw when done.
02保持 Donut 登录态时，避免点击来源不明的链接或访问不可信页面，敏感操作完成后及时退出登录，以降低被诱导触发交易的窗口。While logged in to Donut, avoid clicking links from unknown sources or visiting untrusted pages, and log out promptly after sensitive operations, to shrink the window for an induced transaction.
03持续监控该托管钱包地址的链上交易记录；发现异常后立即将资产提走，并保留交易哈希、截图和时间线。Continuously monitor that custodial wallet address’s on-chain activity; if anything looks abnormal, move the assets out at once and keep the transaction hashes, screenshots, and a timeline.
账户与敏感信息Accounts & sensitive information
04不要在 D0 / AI Agent 环境中处理私钥、助记词、交易所 API Key、内部文档或商业机密。Do not handle private keys, seed phrases, exchange API keys, internal documents, or trade secrets inside a D0 / AI-Agent environment.
05如果曾上传敏感配置、脚本或文件，建议立即轮换相关凭据，并检查下游系统访问日志。If you have uploaded sensitive configs, scripts, or files, rotate the related credentials immediately and review downstream system access logs.
06在 Donut 公布第三方安全审计与修复复测结果前，宜按早期、高风险的实验性产品对待，自行控制风险敞口。Until Donut publishes a third-party security audit and remediation-retest results, treat it as an early-stage, high-risk experimental product and control your own risk exposure.
授权与测试边界Authorization & Testing Boundaries
本次披露基于授权测试、后续复测、公开沟通和安全研究记录整理而成。为避免误解，授权与测试边界如下。
This disclosure is compiled from authorized testing, subsequent retesting, public communications, and security-research records. To avoid misunderstanding, the authorization and testing boundaries are as follows.
授权测试边界：Donut Browser 阶段发生在 Donut 官方 Bug Hunt 活动及后续线上沟通框架内，相关风险已在会议和书面沟通中告知 Donut。Authorized-testing boundary: the Donut Browser phase took place within Donut’s official Bug Hunt events and the subsequent online-communication framework; the relevant risks were disclosed to Donut in meetings and written communications.
非破坏性验证边界：研究过程中没有转移任何第三方用户资金，也没有破坏第三方用户数据或服务可用性。Non-destructive-verification boundary: no third-party user funds were moved during the research, and no third-party user data or service availability was harmed.
资金验证边界：链上交易验证使用研究员自有测试账户完成，用于证明交易构建与执行链路存在服务端权限边界缺陷。Fund-verification boundary: on-chain transaction verification was performed with the researcher’s own test accounts, to prove a server-side privilege-boundary flaw in the transaction build-and-execute path.
第三方拦截边界：在跨用户钱包归属校验测试中，研究员使用自己的账号构造他人钱包交易请求，Donut 后端 / API 层仍会构建、提交并推进请求，最终由 Turnkey 返回 AUTH001 拦截资金转出。Third-party-interception boundary: in the cross-user wallet-ownership-check test, the researcher used his own account to construct a transaction request for another wallet; Donut’s backend / API layer still built, submitted, and advanced the request, which was ultimately stopped from moving funds by Turnkey returning AUTH001.
租户与容器边界：D0 阶段的命令执行和数据读取验证限定在研究员自有租户 / Pod 内，未在未授权情况下横向攻击其他用户 Pod；D0 阶段的具体发现未单独预先提交，与 Donut Browser 一并纳入本次公开披露。Tenant & container boundary: the command-execution and data-reading verification in the D0 phase was confined to the researcher’s own tenant / Pod; no other users’ Pods were laterally attacked without authorization. The specific D0 findings were not separately pre-submitted and are included in this public disclosure together with Donut Browser.
敏感信息处理边界：披露内容仅包含与事实证明有关的脱敏证据、验证结论和公开依据，不包含可直接复用的访问凭据、私钥或攻击脚本。Sensitive-information boundary: the disclosure contains only redacted evidence, verification conclusions, and public-basis material relevant to proving the facts — no directly reusable access credentials, private keys, or attack scripts.
披露目的边界：本文用于记录安全研究事实、用户风险、沟通过程和公开依据，不构成攻击指引、投资建议或法律意见。Purpose boundary: this document records security-research facts, user risk, the communication process, and the basis for publication; it is not an attack guide, investment advice, or legal advice.
Donut is one of the most talked-about AI × Crypto newcomers of the past year, billing itself as “the world’s first agentic crypto browser for traders.” Its developer, Donut Labs (headquartered in New York), closed two rounds totaling US$22 million within about six months of founding (a US$7M Pre-seed in 2025-05 + a US$15M Seed in 2025-11), with a marquee investor lineup — top firms such as HongShan (Sequoia China), BITKRAFT, Hack VC, Makers Fund, Sky9 Capital, Matrix Partners, and Altos Ventures, plus backing from chains like Solana, Sui, and Monad and core teams from Jupiter, Drift, and Manifold Trading. Per Donut’s official funding announcement, the company drew 160,000+ waitlist users in its first quarter — extremely high market interest.
On the product side, Donut’s vision is an “AI-native crypto browser”: Donut Browser is the browser + wallet entry point, and D0 is a user-facing AI-Agent platform. Its core selling point is letting autonomous agents directly take over the wallet, signing, and on-chain fund execution — in the CEO’s (ex-ByteDance) own words, “it can trade for you even while you sleep.” That also implies a security bar far above an ordinary app. It is precisely on such a well-funded, top-tier-backed project — whose core selling point is “AI managing money automatically” — that this research found 49 security issues across its two systems, Donut Browser and D0 (including the auto-signing fund-theft chain and own-Pod RCE).
资金可被无授权转走最坏情况下，钱包中的资金可在用户毫不知情、未做任何确认的前提下被转走。Funds can be moved without authorization. In the worst case, wallet funds can be moved out with the user entirely unaware and without any confirmation.
资产与交易隐私尽失余额、持仓、成本与交易历史可被他人读取，资产状况和交易策略形同对外公开。Asset and trading privacy is lost. Balances, holdings, cost basis, and trade history can be read by others, effectively making one’s asset profile and trading strategy public.
更易成为定向目标高价值账户可被批量识别和筛选，钓鱼、定向攻击与交易操纵的成功率随之上升。Easier to be targeted. High-value accounts can be identified and filtered in bulk, raising the success rate of phishing, targeted attacks, and trade manipulation.
资金安全不在自己手里拦下越权转账的最后一道防线落在第三方签名服务上，而非 Donut 自身；该防线一旦变化或未覆盖某类交易，风险即刻显现。Fund safety is out of your hands. The last line of defense against unauthorized transfers rests on a third-party signing service, not Donut itself; if that line changes or fails to cover some transaction type, the risk surfaces at once.
普通上网行为即可触发风险无需用户主动操作——在登录态下被诱导访问页面或点击链接，就可能成为资金损失的入口。Ordinary browsing can trigger it. The risk needs no deliberate action by the user — being induced to visit a page or click a link while logged in can become the entry point to fund loss.
D0
对账户与敏感资料的影响Impact on accounts and sensitive data
托付给 Agent 的资料可能外泄放入 D0 / Agent 环境的 API Key、脚本、内部文档与商业信息，存在被读取和滥用的风险。Data entrusted to the Agent may leak. API keys, scripts, internal documents, and business information placed in the D0 / Agent environment risk being read and misused.
自动化交易任务不再可信Agent 的配置与运行流程可被影响，托付给它的自动化交易与策略未必按预期、安全地执行。Automated trading tasks can no longer be trusted. The Agent’s configuration and runtime flow can be influenced, so the automated trades and strategies entrusted to it may not execute as intended or safely.
账户可被以用户身份滥用运行环境中的会话凭据可被读取，攻击者据此能以用户身份访问后端，账户与资金边界连带受影响。The account can be abused under the user’s identity. Session credentials in the runtime environment can be read, letting an attacker access the backend as the user, which in turn affects account and fund boundaries.
模型"安全"不等于系统安全风险不止于"模型被越狱"；即便模型层足够保守，运行环境一旦失守，账户、交易与数据仍会受冲击。Model “safety” ≠ system safety. The risk goes beyond “jailbreaking the model”; even if the model layer is conservative enough, once the runtime environment is breached, accounts, trades, and data are still hit.
Below are the redacted logical attack-chain paths, showing how the risks combine and how security boundaries fail — the browser side and the D0 side each have a path that can lead to user funds. Items marked “Potential · not actually breached” are escalation paths the researcher did not actually execute.
远程可触发的服务端自动签名盗币Remotely triggerable server-side auto-signing fund theft
攻击者通过钓鱼入口、恶意页面或被控子域，诱导用户在登录 Donut 的状态下访问一次页面或点击一次链接——子域通配符 CORS 与携带凭证的组合放大了这一远程触发面。An attacker uses a phishing entry point, malicious page, or controlled subdomain to induce a logged-in Donut user to visit a page or click a link once — the combination of subdomain-wildcard CORS and credentialed requests widens this remote trigger surface.
浏览器在用户未做任何签名或授权确认的情况下，携带会话向 Donut 交易接口发起请求。With no signature or authorization confirmation from the user, the browser carries the session to call Donut’s transaction API.
Donut 后端在缺少“用户确认”与“钱包归属校验”两道边界的情况下，直接构建并自动签名交易：自有钱包 / 自有资金范围内交易成功上链（已实证，11 笔 Solscan 可查）；引用他人钱包的跨用户交易，后端同样照常构建并推进，最终仅被第三方托管服务 Turnkey 以 AUTH001 在签名阶段拦下。Lacking both the “user confirmation” and “wallet-ownership check” boundaries, the Donut backend directly builds and auto-signs the transaction: within the researcher’s own wallet / own funds, transactions confirmed on-chain (proven — 11 verifiable on Solscan); for cross-user transactions referencing someone else’s wallet, the backend likewise builds and advances them as usual, stopped only by the third-party custodian Turnkey at the signing stage via AUTH001.
真正阻断他人资金转出的是 Turnkey，而非 Donut 自身的权限模型；这道外部防线一旦变化或某类交易不覆盖，跨用户盗币即直接成立。What actually blocks moving others’ funds is Turnkey, not Donut’s own privilege model; if that external line changes or fails to cover some transaction type, cross-user theft becomes directly viable.
Impact: a single induced click while logged in is enough to create the conditions for funds to be silently moved; the last line of fund safety has been outsourced to a third-party signing service.
仅凭研究员自己的会话，通过钱包、资产、持仓、交易历史等接口，读取非当前账号所属钱包的数据（IDOR，已实证）。With only the researcher’s own session, the wallet, asset, holdings, and trade-history APIs read data for wallets not owned by the current account (IDOR, proven).
接口缺少充分的速率限制与访问审计，可批量枚举、筛选高价值钱包与活跃交易策略。The APIs lack adequate rate limiting and access auditing, allowing bulk enumeration and filtering of high-value wallets and active trading strategies.
结合余额探测、跨用户限价单操作等问题，形成对特定目标的精准画像。Combined with balance probing and cross-user limit-order operations, this builds a precise profile of a specific target.
Impact: even without moving assets directly, leaking asset and trading profiles markedly raises the success rate of phishing, targeted attacks, and trade manipulation, and itself constitutes harm to user privacy and account security.
从登录态到 RCE，再到伪造 / 触达交易From login to RCE, then to forging / reaching transactions
进入控制面（已验证）：普通 D0 登录态 → 环境接口返回控制面连接材料（公网入口、端口、Gateway Token）→ 连入底层控制面（页面显示 OpenClaw logo）→ 读取 Agent 与运行时配置。Enter the control plane (verified): ordinary D0 login → the environment API returns control-plane connection material (public entry point, port, Gateway Token) → connect into the underlying control plane (the page shows the OpenClaw logo) → read Agent and runtime configuration.
取得 RCE（已验证）：借控制面读取 / 修改配置、向 Agent 工作区写入文件 → 将 beforeRun / heartbeat 等执行机制组合为命令执行路径 → 在研究员自有 Pod 内完成非破坏性 RCE。Achieve RCE (verified): via the control plane, read / modify config and write files into the Agent workspace → combine execution mechanisms such as beforeRun / heartbeat into a command-execution path → complete a non-destructive RCE inside the researcher’s own Pod.
身份接管（已验证）：RCE 后读出 Session Token，已验证可“以用户身份”获得后端接口的正常响应。Identity takeover (verified): after RCE, read out the Session Token; verified to obtain normal backend-API responses “as the user.”
通向资金：借控制面 / 执行机制伪造并触发 Agent 交易，已在自有环境实测验证；以窃取的用户身份直接执行资金交易，路径已确证可行，但出于白帽边界未实际执行。Toward funds: forging and triggering Agent transactions via the control plane / execution mechanisms, tested in the researcher’s own environment; directly executing fund transactions under the stolen user identity is a confirmed-viable path, but was not actually executed, out of white-hat boundaries.
Impact: the D0 execution environment leads straight to user funds — forming, together with the browser-side fund path (Chain 1), two independent paths to user assets; the AI model layer’s safety limits are entirely ineffective against this chain.
D0 / Chain 4潜在 · 未实际突破Potential · not actually breached
起点是自有 Pod 内已验证的 RCE。The starting point is the verified RCE inside the researcher’s own Pod.
潜在路径：从自有 Pod 尝试容器逃逸 → 接管宿主 / 整台服务器 → 进而触及其他用户的 Pod、资金与权限。Potential path: attempt container escape from the own Pod → take over the host / entire server → then reach other users’ Pods, funds, and privileges.
边界声明：研究员未进行这一步——未尝试容器逃逸，未对任何其他用户 Pod 做未授权访问。本链仅为潜在风险说明，未实际突破（对应 D0-12「Pod 间隔离需进一步授权验证」）。Boundary statement: the researcher did not take this step — no container-escape attempt and no unauthorized access to any other user’s Pod. This chain is a potential-risk description only, not actually breached (corresponding to D0-12 “Pod isolation needs further authorized verification”).
影响（潜在）：若 Pod 间隔离不足，单个被攻陷的 Agent Pod 可升级为对整个 D0 平台与全体用户资产的威胁——这正是执行环境隔离必须作为硬边界的原因。
Impact (potential): if Pod isolation is insufficient, a single compromised Agent Pod could escalate into a threat to the entire D0 platform and all users’ assets — exactly why execution-environment isolation must be a hard boundary.
The recording below is the impact demo submitted to the vendor in 2026-03 together with the redacted report; this is a version re-redacted for public release. It serves only to prove the vulnerability’s real effect: a genuine on-chain transaction initiated and executed directly without any user confirmation, signature prompt, or transaction preview, and verifiable on a block explorer.
脱敏影响演示 · 约 80 秒 · 无音轨 · 画面中所有钱包地址、交易哈希等标识均已打码Redacted impact demo · ~80 s · no audio · all wallet addresses, transaction hashes, and other identifiers in the footage are masked
To be clear: this recording shows the effect only — no attack code, endpoint addresses, or any reusable exploitation steps, consistent with the whole document: zero PoC, zero reusable weapons. The internal workings of the tooling used, the backend APIs involved, and the request construction are not in the recording and not made public; they were provided only to the vendor in the redacted report for reproduction and remediation.
This timeline explains the notification, communication, remediation windows, written disclosure plan, and public-disclosure point; it is not a full technical-reproduction timeline. At the first meeting on 2026-03-11, the researcher laid out the full disclosure-process framework and the product lead confirmed it on the spot (“OK 可以的，对对”); at the second meeting on 2026-06-04, the vendor again confirmed that “披露独立、可按自己节奏进行.”
0–7 天：与项目方确定前期修复方式与对外披露流程；0–7 days: agree with the vendor on the initial remediation approach and the external disclosure process;
7–30 天：研究者协助团队修复；7–30 days: the researcher assists the team with remediation;
30–90 天：视修复情况协商是否、以及如何对外披露；30–90 days: depending on remediation progress, negotiate whether and how to disclose publicly;
90 天后：窗口届满，研究者有权披露——即使届时仍未修复。After 90 days: the window closes and the researcher has the right to disclose — even if it is still unfixed.
2025-06［接触］因项目叙事关注 Donut 并加入官方 Discord 社区。[Contact] Began following Donut for its project narrative and joined the official Discord community.
2025-12［接触］作为 Donut 用户参与官方产品访谈并收到访谈奖励，随后参与 beta 测试。[Contact] As a Donut user, took part in official product interviews (and received an interview reward), then joined beta testing.
2026-02-02［授权活动 · Bug Hunt 1.0］参加 Donut Labs 第一次 Discord Bug Hunt：提交 8 个 bug 与安全报告。[Authorized event · Bug Hunt 1.0] Joined Donut Labs’ first Discord Bug Hunt: submitted 8 bugs and a security report.
2026-02-22［社区活动奖金］Bug Hunt 1.0 参赛奖金 100 USDC 到账（凭活动提交的漏洞赢得）。[Community-event prize] Bug Hunt 1.0 contest prize of 100 USDC paid out (won with the vulnerabilities submitted for the event).
2026-03-07［授权活动 · Bug Hunt 2.0］参与第二次 Bug Hunt：提交 13 个常规漏洞。[Authorized event · Bug Hunt 2.0] Joined the second Bug Hunt: submitted 13 routine vulnerabilities.
2026-03-11［通知 · Critical］第二轮 Bug Hunt 期间挖掘到最高危（Critical）漏洞，拉起第一次线上会议：演示 Donut Browser 资金安全攻击链、说明漏洞等级；完整陈述披露流程框架，产品负责人当场确认；会后提交脱敏报告、PPT 与 PoC 演示视频，并说明沟通窗口、修复协调窗口与窗口期后独立披露安排。[Notification · Critical] During Bug Hunt 2.0, discovered the highest-severity (Critical) vulnerabilities and called the first online meeting: demonstrated the Donut Browser fund-safety attack chain and explained the severity; laid out the full disclosure-process framework, confirmed on the spot by the product lead; afterward submitted the redacted report, slides, and PoC video, and explained the communication window, the remediation-coordination window, and the post-window independent-disclosure arrangement.
2026-03-18［7 天窗口届满 · T+7］前 7 天沟通窗口最后一天：书面正式进入负责任披露流程；项目方将系统级研究并入“常规社区奖励”口径（原话“是常规社区奖励”，见 tg164），研究者当日即书面反对、要求对系统级安全事件单独评估（见 tg163）；基于 90 天窗口，明确通知计划于 2026-06-09 公开披露。[7-day window closes · T+7] Last day of the initial 7-day communication window: formally entered the responsible-disclosure process in writing; the vendor folded the system-level research into the “routine community-reward” track (in its words “是常规社区奖励,” see tg164), and the researcher objected in writing that same day, asking for a separate assessment of the system-level security incident (see tg163); based on the 90-day window, gave notice that public disclosure was planned for 2026-06-09.
2026-03-21提交 9 个 CVE 申请。详见 CVE 记录。Filed 9 CVE requests. See CVE Records.
2026-03-28［社区活动奖金］Bug Hunt 2.0 参赛奖金 100 USDC 到账（凭活动提交的 13 个漏洞赢得；两届合计 200 USDC，均与系统级研究无关）。[Community-event prize] Bug Hunt 2.0 contest prize of 100 USDC paid out (won with the 13 vulnerabilities submitted for the event; 200 USDC across both events, both unrelated to the system-level research).
2026-04 ~ 05［修复 / 观察窗口］研究者保持待命配合，等待修复进展与明确处理方案；期间项目方未就修复实际对接。[Remediation / observation window] The researcher stayed on standby to assist, awaiting remediation progress and a clear handling plan; during this period the vendor did not actually engage on remediation.
2026-05独立完成 D0 阶段研究，验证控制面凭据泄露、配置修改、RCE 与容器数据提取链路。Independently completed the D0-phase research, verifying control-plane credential leakage, config modification, RCE, and the container data-extraction path.
2026-06-02［复测 + T-7 提醒］完成最终非破坏性复测（49 项中完全修复 11、部分修复 9、仍未修复 29，多个核心 Critical 未修复）；提醒距既定公开披露日（06-09）仅一周，预留 48 小时沟通窗口。[Retest + T-7 reminder] Completed the final non-destructive retest (of 49 items: 11 fully fixed, 9 partially fixed, 29 still unfixed, including several core Criticals); reminded that the set public-disclosure date (06-09) was only a week away, leaving a 48-hour communication window.
2026-06-03［重新接洽］在 2026-03-18 降级答复、其后约 2.5 个月无实质推进的情况下，项目方（技术负责人）于披露截止提醒（06-02）次日才主动接洽、提出长期合作。[Re-engagement] After the 2026-03-18 downgrade reply and ~2.5 months with no substantive progress, the vendor (tech lead) reached out only the day after the disclosure-deadline reminder (06-02), proposing a long-term partnership.
2026-06-04［第二次会议］技术细节复核与合作意向；项目方再次确认“披露独立、可按自己节奏进行”。[Second meeting] Review of technical details and partnership intent; the vendor again confirmed “披露独立、可按自己节奏进行.”
2026-06-05［第三次会议］与[法务 / 财务 / 人力负责人]讨论合作方式与漏洞赏金；未获得明确答复。[Third meeting] Discussed partnership terms and the vulnerability bounty with [the legal / finance / HR leads]; no clear answer was given.
2026-06-08［配合］主动表示可提供完整漏洞清单供评估，并表示若合作推进、愿配合（乃至延后）披露节奏。[Cooperation] Proactively offered the full vulnerability list for assessment, and said that if the partnership advanced he would accommodate (even postpone) the disclosure schedule.
2026-06-10［最终通知］在多日无明确回复后，研究者发出最终通知，将公开披露日延至 2026-06-15（再次预留沟通窗口）。[Final notice] After several days with no clear reply, the researcher issued a final notice, postponing the public-disclosure date to 2026-06-15 (again leaving a communication window).
2026-06-10［项目方无端指控］项目方一方未就诉求继续沟通，转以法务对抗姿态回复，作出“以漏洞施压敲诈”“未收到任何完整攻击链 / RCE 证明”“曾承诺不公开沟通过程”等与会议及书面记录不符的指控（逐条事实对照见下方对照表）。[Vendor’s baseless allegations] The vendor side stopped engaging on the substance and switched to an adversarial legal posture, making allegations inconsistent with the meeting and written records — “以漏洞施压敲诈,” “未收到任何完整攻击链 / RCE 证明,” “曾承诺不公开沟通过程,” etc. (point-by-point rebuttal in the table below).
2026-06-15［窗口届满］披露窗口届满，按既定负责任披露流程公开本研究。[Window closes] The disclosure window closes; this research is published per the established responsible-disclosure process.
项目方最终回复（2026-06-10）：法务对抗姿态与不实指控Vendor’s final reply (2026-06-10): adversarial legal posture and false allegations
On the day the researcher issued the final notice (postponing public disclosure to 06-15 and again leaving a communication window), the vendor replied. To avoid any “selective editing,” the full original reply is reproduced below first (redacted only, unabridged; original at Telegram records · 2026-06-10), followed by a point-by-point pairing of its false allegations with the real evidence.
从一开始，你的核心诉求就很明确——利用漏洞作为筹码施压，目的无非是获取奖金，并借此争取一个高薪岗位。这个套路太常见了。在上次会议中，我们已经明确表态：与你的合作和漏洞披露之间没有任何绑定关系，你完全可以按照自己的节奏去走披露流程。你在会议记录中也亲口承诺过，仅披露技术细节，不会公开双方的沟通过程。现在看来，这个承诺你打算不认了也 ok
Below, the five false allegations above are set side by side with the real evidence, point by point. Each piece of evidence links to the corresponding meeting records, Telegram records, or on-chain / retest evidence.
项目方不实指控Vendor’s false allegation
真实证据节选（全程录音封存，欢迎机构进行监督）Real evidence (excerpts; full audio preserved, institutional oversight welcome)
① “你在会议记录中也亲口承诺过，仅披露技术细节，不会公开双方的沟通过程。”
第二次会议（2026-06-04）录音及文字记录：研究者从未承诺“不公开沟通过程”。会议中，项目方（[技术负责人]）先提出“披露这一块跟这个是比较独立的，你可以按照自己的节奏去披露，然后内容的话就一定要保持、保证公平客观，包括沟通过程”——即项目方明确将沟通过程纳入了可披露内容的范围，仅要求保持公平客观，而非禁止公开。研究者据此回应“只做技术层面的披露，不会掺杂个人情绪化的内容”，即按负责任披露流程进行、不掺杂个人主观想法，而非承诺“不公开沟通过程”。项目方随后再次确认“按之前的节奏去披露就 OK 了”。该指控所称的“承诺”，与项目方自身在会议中的上述原话不符。Second meeting (2026-06-04), audio and transcript: The researcher never promised “not to publish the communication process.” In the meeting, the vendor ([tech lead]) first said, “披露这一块跟这个是比较独立的，你可以按照自己的节奏去披露，然后内容的话就一定要保持、保证公平客观，包括沟通过程” — i.e., the vendor expressly placed the communication process within the scope of disclosable content, requiring only that it stay fair and objective, not forbidding publication. The researcher replied accordingly, “只做技术层面的披露，不会掺杂个人情绪化的内容” — i.e., proceed per responsible disclosure without injecting personal subjective views, not a promise “not to publish the communication process.” The vendor then again confirmed, “按之前的节奏去披露就 OK 了.” The “promise” alleged here contradicts the vendor’s own words above in the meeting.
③ “从一开始，你的核心诉求就很明确——利用漏洞作为筹码施压，目的无非是获取奖金，并借此争取一个高薪岗位。……看穿了敲诈和强买强卖就不要再演戏了。”
早在 2026-01-31 首次提交安全报告当天，研究者即在同一条消息中无偿交付报告，并公开写明“目前正在寻找合适的职业机会”、并主动表示在团队尚无专职安全人员时可提供建议与协助（Telegram · 2026-01-31）：求职意向与漏洞报告自始一并、公开摆明，而非事后以漏洞作筹码。其后的首次会议上，研究者先完整演示了攻击链（含真实链上 PoC），之后才软性提出“如果团队有漏洞赏金方面的计划，我个人希望可以争取到一些奖励”、并表达想加入——先无偿交付价值、再软性提赏金，与“拿漏洞施压”在顺序与性质上都相反；其间同时提出长期合作，诉求自始公开、一致；明确拒绝自行定价（原话“金额这块我不太好定的，这有违安全研究的原则，会有威胁的倾向在里面”，见 Telegram · 2026-03-11），请项目方按漏洞影响自行评估。项目方技术负责人本人也在第二次会议前的 Telegram 中明确“专项赏金按劳分配是应该的”、并称“很缺这一块的人才”（见 Telegram 记录）；研究者其后据漏洞影响给出可协商的报价区间并说明依据，正是对方所认同的“按劳分配”，与“敲诈、强买强卖”的指控自相矛盾。全程坚持负责任披露，从未提前公开或以公开相要挟。On 2026-01-31, the very day of the first security-report submission, the researcher delivered the report free of charge in the same message and openly stated “目前正在寻找合适的职业机会,” and proactively offered, should the team not yet have dedicated security staff, advice and assistance (Telegram · 2026-01-31): the job interest and the vulnerability report were laid out openly together from the start, not used as leverage after the fact. At the first meeting the researcher first fully demonstrated the attack chain (including a live on-chain PoC), and only afterwards softly said “如果团队有漏洞赏金方面的计划，我个人希望可以争取到一些奖励，” and expressed a wish to join — delivering value for free first and only then softly mentioning a bounty, the opposite in both order and nature of “利用漏洞作为筹码施压”; a long-term partnership was raised at the same time, and the ask was open and consistent from the outset. The researcher explicitly declined to set a price himself (in his words, “金额这块我不太好定的，这有违安全研究的原则，会有威胁的倾向在里面” see Telegram · 2026-03-11), asking the vendor to assess by impact. The vendor’s own tech lead, in Telegram before the second meeting, clearly said “专项赏金按劳分配是应该的” and that they “很缺这一块的人才” (see Telegram records); the researcher then gave a negotiable price range by impact with a stated basis — exactly the “按劳分配” the other side endorsed, contradicting the “敲诈和强买强卖” allegation. Responsible disclosure was maintained throughout, with no early publication and no threat of publication as leverage.
④ “你仍然开出 10 万美元以上的完全不合理的奖金报酬外加高薪职位的条件。”
研究者对整套 49 漏洞 + 3–4 条攻击链的行业自评为 50–100 万美元（参照 HackerOne / Web3 同级标准），考虑到初创阶段主动大幅下调至 15–20 万美元，并明确“可以沟通商量”（见 第三次会议）。该数字为协商起点；赏金与全职薪资是分开讨论的两件事。尤需厘清：研究者并非主动“开出”条件——在第三次会议上，是研究者先反过来询问团队的预期，由团队（[法务 / 财务 / 人力负责人]）明确要求研究者先报价（原话“你希望的价格是多少”）后，研究者才给出 15–20 万美元的可协商区间（见第三次会议）；而“专项赏金按劳分配是应该的”本就是项目方技术负责人自己认可的原则（见 Telegram）。应团队要求给出、且符合对方自身认可原则的协商起点，与“开出不合理条件”“敲诈”在性质上正相反。The researcher’s industry self-assessment for the full set of 49 vulnerabilities + 3–4 attack chains was US$500k–1M (benchmarked against HackerOne / comparable Web3 standards); given the startup stage, he proactively cut it sharply to US$150k–200k and made clear it was “可以沟通商量” (see the third meeting). That figure was a negotiating starting point; the bounty and a full-time salary were two separately discussed matters. To be precise, the researcher did not unilaterally “set conditions”: at the third meeting it was the researcher who first asked the team about their expectation, and the team ([legal / finance / HR lead]) explicitly asked the researcher to name a price first (verbatim “你希望的价格是多少”) before the researcher gave the negotiable range of US$150k–200k (see the third meeting); and “专项赏金按劳分配是应该的” was a principle the vendor’s own tech lead had endorsed (see Telegram). A negotiating starting point given at the team’s own request, consistent with a principle the other side itself endorsed, is the opposite in nature of imposing unreasonable conditions or “敲诈”.
⑤ “你目前的披露流程和施压索要不合理报酬的行为方式，完全不符合白帽安全研究者的行业规范。”
全程遵循负责任披露（参照 ISO/IEC 29147、30111、CERT/CC）：会议 + 书面多次通知、给足超 90 天窗口、两次额外预留沟通窗口、公开内容零 PoC / 零可复用武器（见披露时间线）。通过负责任披露争取合理赏金或职业机会，是行业通行的正当回报机制。Responsible disclosure was followed throughout (per ISO/IEC 29147, 30111, CERT/CC): meetings + repeated written notices, a full 90-day-plus window, two extra communication windows, and public content with zero PoC / zero reusable weapons (see the disclosure timeline). Pursuing a reasonable bounty or career opportunity through responsible disclosure is a legitimate, industry-standard reward mechanism.
This section records how Donut handled the vulnerability-report materials. The focus is not the reward amount itself, but whether — after the vendor already knew, through meetings and written materials, of the Critical-level fund-safety attack chain, the remediation window, and the public-disclosure plan — it still downgraded such vulnerability materials to routine community-event handling.
During the communications, Donut downgraded a major fund-safety attack chain and the subsequent security reports to routine community-event handling — in the vendor’s own words, “是常规社区奖励” (see Telegram · 2026-03-18, and the third meeting) — rather than running a Critical-level vulnerability-response process with triage, remediation coordination, retest feedback, and a reasonable reward assessment. Notably, at the second meeting the vendor’s product lead said the researcher’s first report was, in his words, “比花了很多钱找的那个专业团队给的报告，有些角度是比较深的” (see the second meeting) — even as the vendor itself judged it this way, the research was still handled under the routine community-reward track above.
Donut took part in the online meetings and received the redacted report, slides, and PoC video. Even so, the communications showed no formal vulnerability-response mechanism commensurate with the fund-safety risk.
After the researcher’s final notice, the vendor stopped engaging on the substance and switched to an adversarial legal posture, making several allegations inconsistent with the meeting and written records; for a point-by-point comparison see the disclosure timeline.
The complete, unedited, redacted-only original communication records are attached on the two pages above: the three online meetings are transcribed from audio, and the Telegram records are arranged in full by real timestamps.
The following questions arise from the attack chains, communication records, and vulnerability-response process disclosed here, and from the gap between Donut’s public security narrative and its actual security posture.
Donut directly handles users’ real funds and can initiate and execute irreversible on-chain transactions. For such a product, basics like user authorization, wallet-ownership checks, and control-plane / runtime-environment isolation should be a non-negotiable bottom line — so why do Donut Browser and D0 still fail at these fundamentals?
Donut’s official docs assure users that “所有交易都需经你批准（All transactions require your approval）” (see official docs · Wallet & Security). But the verified 1-click silent-transaction chain shows a path that bypasses this approval and can initiate and execute a transaction with no authorization or signature confirmation from the user (verified on the researcher’s own account, evidenced by 11 on-chain transactions). When a core user-facing security guarantee can be bypassed, how far can it still be relied on in practice?
Q3
D0 已验证从普通登录态获取控制面连接材料，并进一步组合到配置读取、配置修改、文件写入、自有 Pod RCE 和敏感会话材料读取（详见 D0 证据）。这样的控制面暴露，是否符合 AI Agent 产品应有的安全边界？
D0 was verified to obtain control-plane connection material from an ordinary login, then combine it into config reading, config modification, file writing, own-Pod RCE, and reading of sensitive session material (see D0 evidence). Does such control-plane exposure match the security boundary an AI-Agent product ought to have?
After the researcher submitted major security research, joined the meetings, provided the redacted report, slides, and PoC video, and clearly set a responsible-disclosure window, the vendor still downgraded the Critical-level vulnerabilities to routine community-event handling (vendor’s own words “是常规社区奖励,” see Telegram · 2026-03-18; see also the third meeting). Was this attention and response commensurate with the risk level?
If an independent researcher submits major vulnerability findings under a responsible-disclosure framework only to be downgraded to routine community-event handling, will this make more researchers lose confidence in compliant disclosure?
The cost-and-reward of security research is highly asymmetric between attackers and white-hats: an attacker only needs to find one exploitable path, with no regard for authorization, compliance, or recognition; a white-hat must spend heavily on authorization boundaries, responsible disclosure, and long-running communication, and may end up without even a single public acknowledgement — and may even, while legitimately seeking a reasonable reward within a compliant framework, be recast as “施压” or “敲诈” and then face legal threats. When compliant disclosure long goes without a response commensurate with the risk and researchers leave as a result, does this not weaken the very coordinated-disclosure mechanism the whole industry relies on — while real attackers never need any of these prerequisites?
Q7
Donut 在官方介绍核心产品 D0 时强调“金融操作不可逆，对安全的要求从根本上就不同（the bar for safety is fundamentally different）”（官方 X @DonutAI）。但 D0 恰恰基于一款上线时间很短的开源项目二次开发，本次研究并在其上取得了 RCE 与控制面接管——这与其安全定位、融资规模和市场期待是否相称？相应的潜在安全风险，是否得到了与之匹配的安全投入？
In officially introducing its core product D0, Donut stressed that “金融操作不可逆，对安全的要求从根本上就不同（the bar for safety is fundamentally different）” (official X @DonutAI). Yet D0 is built on top of an open-source project that had been live for only a short time, and this research achieved RCE and control-plane takeover on it — is that commensurate with its security positioning, funding scale, and market expectations? Have the corresponding potential security risks received matching security investment?
安全治理观察Security-Governance Observations
这次事件不只是若干接口漏洞的集合，更暴露了 AI + Crypto 产品在安全治理上的几个共性问题。
This incident is not just a collection of API bugs; it also exposes several common security-governance problems for AI + Crypto products.
First, once an AI Agent connects wallets, trading, signing, strategy execution, and on-chain assets, it is no longer an ordinary chatbot but an automated system with financial-execution capability. Such a system needs an enforced backend authorization model, asset-ownership validation, least privilege, signature confirmation, audit logging, and anomaly interception.
Second, a third-party security policy cannot substitute for the project's own authorization model. Turnkey returning AUTH001 and blocking a high-risk transaction shows that the third-party service acted as an interceptor at the final stage. Donut's own backend still exposes binding-validation problems between users and wallets, orders, and transactions.
Third, a Bug Hunt or community-feedback mechanism cannot substitute for a formal vulnerability-response process. When a project publicly encourages community testing, it should also be ready to handle real Critical-level security incidents, including graded assessment, remediation coordination, disclosure coordination, retest feedback, and reasonable rewards.
Fourth, the control-plane security of an AI-Agent runtime environment should be treated as a core asset boundary. If there is no strong isolation between front-end sessions, the Gateway Token, config modification, file writes, beforeRun, and heartbeat, an attacker may bypass the model-layer safety review and reach the execution layer directly.
Fifth, open-source dependency and secondary development are not themselves a problem. The problem is that a company disclosing US$22M raised across two rounds and presenting D0 as its core AI-Agent product has a core control plane that, on actual access, clearly displays the OpenClaw logo, with the docs link pointing to the OpenClaw official documentation. This fact should be discussed openly: there is a clear gap between D0's external packaging, its in-house-development narrative, the transparency of its key open-source dependency, the security review of its secondary development, and its actual security-engineering capability. What truly warrants attention is not the use of open source, but that, under a high-funding narrative, the core product's dependency on OpenClaw was not adequately disclosed, nor was a security-engineering and vulnerability-response capability commensurate with the funding scale demonstrated.
Sixth, the recognition mechanism for security research is itself part of security governance. A mature responsible-disclosure system usually rewards researchers through dedicated bounties and public acknowledgement (website credits, a security hall of fame, disclosure credits) — both an acknowledgement of the research's value and a foundation for attracting sustained, compliant security research. This system-level research (49 vulns / attack chains / RCE) received neither any separate assessment or dedicated bounty, nor any formal recognition on any public channel (only an informal thank-you in the Discord community). To be clear, submitting security research for free is not uncommon in the industry, and the researcher never made a bounty a precondition for public disclosure; the point of observation here is not “whether it was paid”, but that the vendor itself explicitly stated it has a bug-bounty budget, yet still processed this kind of system-level research under the ordinary community-reward track. How major security research is treated itself reflects a product's security-governance maturity.
The purpose of recording these problems is to let users, media, investors, and the development team see more clearly: the security capability of an AI + Crypto product should not be reflected only in narrative and UI, but in the backend authorization model, runtime-environment isolation, and the vulnerability-response mechanism.
This disclosure conforms to the basic logic of responsible / coordinated disclosure: after finding high-risk issues, the researcher first explained the nature, impact scope, and remediation window to the vendor through an online meeting and written materials; the vendor had the opportunity to be informed, assess, remediate, and communicate within a reasonable time; and after the window expired, the researcher may disclose the risk to users and the public without releasing directly-abusable details.
本次披露的事实基础包括：
The factual basis of this disclosure includes:
Donut Browser 阶段测试发生在 Donut 官方 Bug Hunt 活动及后续线上沟通框架内。The Donut Browser-phase testing took place within Donut's official Bug Hunt events and the subsequent online-communication framework.
2026 年 3 月 11 日，我已通过线上会议向 Donut 演示并说明核心风险。On 2026-03-11, the researcher demonstrated and explained the core risks to Donut in an online meeting.
会后我向 Donut 提交了脱敏报告、PPT 和 PoC 演示材料。After the meeting, the researcher submitted a redacted report, slides, and PoC demonstration material to Donut.
2026 年 3 月 18 日，我以书面方式明确通知计划于 2026 年 6 月 9 日公开披露；6 月重新接洽后，于 6 月 10 日再次书面通知将公开披露日延至 6 月 15 日，又一次预留了沟通窗口。On 2026-03-18, the researcher gave written notice that public disclosure was planned for 2026-06-09; after re-engagement in June, on June 10 the researcher again gave written notice extending the public disclosure date to June 15, once more reserving a communication window.
测试过程中未转移第三方用户资金，D0 的命令执行验证限定在研究员自有租户 / Pod 内。No third-party user funds were moved during testing, and the D0 command-execution verification was confined to the researcher's own tenant / Pod.
披露内容仅展示脱敏后的事实证据、验证结论和公开依据，不提供可直接复用的访问凭据、私钥或攻击脚本。The disclosed content shows only redacted factual evidence, verification conclusions, and the public basis; it provides no directly-reusable access credentials, private keys, or attack scripts.
基于上述事实，本文的公开目的在于告知用户风险、记录安全研究过程、推动项目方和行业重视 AI + Crypto 产品的系统性安全边界。
Based on the facts above, the purpose of this publication is to inform users of the risks, record the security-research process, and push the vendor and the industry to take the systemic security boundaries of AI + Crypto products seriously.
关于作者与团队About the Author & Team
Lucifiel（路西菲尔），独立安全研究员、数字循真创始人。约十年安全攻防与红队经验，长期专注 Web3 安全、AI Agent 安全、业务逻辑安全，以及复杂系统中的权限边界与信任模型问题；本次 Donut AI 安全研究由我独立完成。
Lucifiel, independent security researcher and founder of 数字循真. Around ten years of offensive-security and red-team experience, with a long focus on Web3 security, AI-Agent security, business-logic security, and the privilege-boundary and trust-model problems of complex systems; this Donut AI security research was carried out independently by me.
数字循真是一套运行时语义智能（Runtime Semantic Intelligence）框架。它先将与目标系统相关的流量、产品文档及各类已知信息聚合、清洗，重构出完整的业务运行模型（业务流程图）；继而在该模型上标注潜在风险点，并以状态机跟踪状态迁移、判断风险在真实业务流程中是否成立；再结合团队在网络安全领域的知识与经验所训练的风险模型与 AI，对风险作出明确研判，最终输出带证据与结论的专业报告。它的应用并不局限于安全领域——我们相信未来是 AI 的时代，而由人去逐一监管 AI 的行为既低效也不现实；数字循真要做的，正是让"一个行为是否合理、是否越界"能够被自动且可解释地判断。
数字循真 is a Runtime Semantic Intelligence (RSI) framework. It first aggregates and cleans the traffic, product documentation, and various known information related to the target system, reconstructing a complete business-operation model (a business flowchart); it then annotates potential risk points on that model and uses a state machine to track state transitions and judge whether a risk holds in the real business flow; combined with a risk model and AI trained on the team’s cybersecurity knowledge and experience, it makes a clear determination and finally outputs a professional report with evidence and conclusions. Its application is not limited to security — we believe the future belongs to AI, and having humans police every AI action one by one is both inefficient and unrealistic; what 数字循真 aims to do is make “whether an action is reasonable and whether it crosses a line” something that can be judged automatically and explainably.
The risks this Donut research reveals — the server-side auto-signing fund path, cross-user wallet overreach, asset-profile leakage, and the breakdown of control-plane and agent-tool boundaries — are exactly the kind of business-logic risk that is “locally normal but globally anomalous”: a single action looks fine on its own, yet becomes a global risk once placed in the full business state and flow, and traditional security tools often struggle to find it. We founded 数字循真 precisely to tackle this class of problem systematically; the business attack chains and evidence methods distilled in this research have also become real cases in the 数字循真 risk knowledge base.
欢迎就以下方向与我及数字循真团队交流：
I and the 数字循真 team welcome discussion on the following:
安全测试、安全审计、安全研究等安全服务，以及安全负责人、技术合伙人等职业与长期合作机会。Security services such as security testing, auditing, and research, plus career and long-term opportunities such as Head of Security or technical co-founder.
业务逻辑安全、Web3 安全、AI Agent 安全相关的安全评估、攻击链分析与顾问合作。Security assessment, attack-chain analysis, and advisory engagements in business-logic security, Web3 security, and AI-Agent security.
数字循真正在寻求投资，可就产品试点（PoC）与生态合作洽谈。数字循真 is seeking investment and is open to product pilots (PoC) and ecosystem partnerships.
媒体采访、技术报道、社区分享与行业观察类合作。Media interviews, technical coverage, community talks, and industry-observation collaborations.