The Year of AI Applications: Saying 'Yes' While Ignoring Risks? A Comprehensive Open Source Log of Software Development's Journey

marsbit發佈於 2026-06-16更新於 2026-06-16

文章摘要

The Year of AI Applications: Blindly Saying "Yes" While Ignoring Risks? A Software Development Log Goes Fully Open Source. AI-generated code harbors risks hidden within seemingly correct programs, potentially leading to data leaks or asset loss. The open-source project "Narwhal AI Code Risks," from Peking University's Narwhal-Lab, compiles real-world cases, early warning signs, and typical risk pathways. Its goal is to help developers identify potential hazards early and avoid repeating past mistakes. In 2026, code is generated faster than ever but deployed with less scrutiny. The danger often lies not in glaring errors, but in code that appears normal—syntactically correct, passing all checks—yet introduces subtle but critical flaws like non-existent dependencies, excessive permissions, or exposed databases. A stark example is the Moonwell cbETH oracle incident. A configuration file error, where a cryptocurrency price was set to ~$1.12 instead of ~$2,200, slipped through 28 checks and a pull request signed by both AI (Claude, Copilot) and human developers. This "semantic deviation" resulted in a loss of $1.78 million. The risk is that AI can produce functionally valid code that is semantically wrong for the business context. As AI moves beyond simple code completion to modifying configurations, installing dependencies, and operating via autonomous agents, it traverses longer, less traceable paths within software engineering, blurring traditional boundaries and oversight ...

The risks of AI-written code lurk within seemingly correct code, potentially leading to data breaches or asset loss. The open-source Narwhal AI Code Risks project compiles real-world cases, early warning signs, and typical risk pathways to help developers identify hidden dangers early and avoid repeating past mistakes.

In 2026, code is being generated at an ever-increasing pace, yet deployed with less and less scrutiny.

More and more often, user requirements are placed in a dialogue box, AI reads the context, completes functions, pulls dependencies, fixes configurations, and even conveniently generates tests.

Before you know it, a piece of code is already sitting in the repository, awaiting merge.

Users have developed a new habit: let the AI write it first and get it running, then see what needs fixing if there's a problem.

But in the software world, the most dangerous things are often pieces of code that appear utterly ordinary: syntactically correct, interfaces valid, tests passing, comments perfect.

Yet it may still introduce non-existent package names, open overly broad permissions, expose databases... or even allow an Agent capable of directly calling system tools to exfiltrate sensitive data from internal systems under prompt injection.

The real danger is not a flashing red error light. It's when all risk indicators show normal.

Risks from AI-generated code used to be scattered: a case buried in a security blog, a clue recorded in an Issue. When the next team encountered a similar problem, they had to piece together the source of risk from scratch and expend immense time and effort conducting large-scale empirical measurements on the code.

Now, Peking University's Narwhal-Lab has just open-sourced Narwhal AI Code Risks, which organizes these information fragments into three categories for researchers to examine: real incidents, early signals, and typical risk paths.

Paper link: https://github.com/Narwhal-Lab/Narwhal-aicode-risks

When All 28 Checks Pass, the System Still Veers Off Course

The first clue was a merged Pull Request, where the signature field prominently featured Claude Opus 4.6, Copilot, and four human developers. All 28 checks passed: No one spotted the issue.

Then, the liquidation bot took a few minutes and seized collateral worth $1,778,044.83.

The configuration file set the price of cbETH to its conversion ratio with ETH, approximately $1.12, instead of the actual price near $2,200.

A semantic price error slipped through development, review, and merge processes, ultimately turning into real loss in the financial system. This is the most glaring aspect of the Moonwell cbETH oracle configuration incident.

The problem lay in code without syntax errors, and human developers not immediately halting the anomalous process. On the contrary, it looked complete, smooth—a normal engineering delivery.

But it is precisely this undercurrent of normalcy that makes it a quintessential example of a security incident.

The risk of AI Coding lies in the fact that it doesn't always manifest as errors.

Often, it cloaks itself in the guise of a correct answer, quietly entering the engineering pipeline. The code runs, checks pass, PRs get merged, but the business semantics have already deviated from reality.

In low-risk projects, such semantic drift might just mean rework. But in sensitive contexts like finance or enterprise data systems, it directly leads to data leaks, exposed permissions, and asset loss.

When AI participates in writing code, modifying configurations, conducting reviews, or even co-signing and entering PRs, can we be sufficiently certain of how each deviation occurs?

The Green Light Doesn't Illuminate Every Corner

Early AI code assistants mostly remained at the level of local completions. If the syntax was wrong, the compiler would error, unit tests would fail, and the CI pipeline would block it.

Today's AI Coding ventures much further, while oversight has lagged behind.

It can read files, modify configurations, install dependencies, generate infrastructure scripts, and plan autonomously across multiple tasks via Agents.

AI is no longer just sitting on the sidelines handing over tools; it's beginning to enter longer chains of the software engineering process.

>The once-clear boundaries in software engineering are being reconnected by AI Agents into longer, harder-to-trace pathways.

Scattered Records Need a Common Logbook

Security incidents rarely start with complete conclusions. Some events have solid evidence and can enter the directory as real cases; some remain at the stage of community screenshots, researcher discussions, or preliminary disclosures, suitable only for continued observation; others are not tied to a single real event but have already formed clear patterns, suitable for proactive scenario planning.

Narwhal AI Code Risks divides the material into three layers: `cases/`, `inferred/`, and `scenarios/`.

`cases/` records real incidents with public sources and evidential chains; `inferred/` stores early signals not yet fully substantiated but worth continuous tracking; `scenarios/` organizes typical scenarios with clear risk paths, not yet bound to a single specific incident.

Without such public records, risks from AI Coding easily become short-term memories on the internet.

Today, everyone remembers a certain package name; tomorrow, they discuss a data exposure incident; after a few months, it's all covered by the next wave of tool hype. When similar problems arise again, teams still blunder like headless flies into waters of unknown risk.

What Narwhal AI Code Risks does is anchor these scattered risk fragments, allowing those who come later to turn to the same page.

Following Seven Index Categories to See Where Risks Come From

The problems brought by AI-generated code are not only in the code itself. They are in dependencies, in permissions, in Agent tool calls, and even more so in the way humans trust AI output.

Currently, Narwhal AI Code Risks categorizes risks into 7 types: Supply Chain, Code-Level Vulnerabilities, Cloud & Infrastructure Configuration, Agent Risks, Vertical Domain Risks, Intellectual Property & Compliance Risks, and Human Factors.

In Supply Chain risks, AI may recommend non-existent dependencies. In Code-Level Vulnerabilities, AI might reintroduce path traversal, missing input validation, or authentication issues into business code. In Cloud & Infrastructure Configuration, AI might grant overly broad permissions, public storage buckets, or exposed ports just to get the code running initially. Agent Risks are even more complex, moving beyond text generation to action execution. AI-generated artifacts are planting hidden dangers in real systems.

The AI Engine Is Firing Up, and the Logbook Is Just Beginning

As AI increasingly steps into the real world, related risk prevention and mitigation should not remain confined to post-mortems or scattered discussions.

The truly important aspect of Narwhal AI Code Risks is transforming risk cases into reusable knowledge.

Developers can use it to identify similar issues; security researchers can treat it as a sample library; tool vendors can extract detection rules and evaluation benchmarks from it; the open-source community can continue to contribute new cases, new evidence, and new risk types.

The AI engine is roaring, and every course deviation should leave its coordinates. Risks never disappear by being ignored, but experience can be recorded and passed on. The real value lies not in discovering a single vulnerability, but in ensuring later voyagers don't have to step into the same trap.

What Narwhal AI Code Risks is doing is providing an open-source logbook for the software world in the Year of AI Applications.

References:

https://github.com/Narwhal-Lab/Narwhal-aicode-risks

This article is from the WeChat public account "New Zhiyuan," author: LRST

相關問答

QWhat is the main purpose of the Narwhal AI Code Risks open-source project mentioned in the article?

AThe main purpose of the Narwhal AI Code Risks open-source project is to systematically collect and categorize real-world risks, early warning signals, and typical risk patterns associated with AI-generated code. It aims to help developers identify hidden dangers early, avoid repeating past mistakes, and build a shared knowledge base for the community to improve safety in AI-assisted software development.

QAccording to the article, what makes AI-generated code particularly dangerous in software development?

AAccording to the article, AI-generated code is particularly dangerous because it often appears correct—with proper syntax, legal interfaces, passing tests, and perfect comments—yet can still introduce critical risks. These risks include adding non-existent package names, granting overly broad permissions, exposing databases, or enabling data exfiltration through prompt injection. The danger lies not in obvious errors but in code that passes all checks while containing flawed business logic or security vulnerabilities.

QWhat was the financial impact of the Moonwell cbETH oracle configuration incident described in the article?

AThe financial impact of the Moonwell cbETH oracle configuration incident was a loss of $1,778,044.83 in collateral. This occurred because the configuration file incorrectly set the price of cbETH to a conversion ratio with ETH, approximately $1.12, instead of its actual market value of nearly $2,200. The error passed through all development, review, and merging processes without detection.

QHow does the Narwhal AI Code Risks project categorize the information it collects?

AThe Narwhal AI Code Risks project categorizes the information it collects into three main layers: `cases/` for documented real incidents with public sources and evidence chains, `inferred/` for early warning signals that are not yet fully confirmed but worth monitoring, and `scenarios/` for typical risk patterns that are clear and replicable but not tied to a single specific event.

QWhat are the seven broad categories of risk identified by the Narwhal AI Code Risks project?

AThe seven broad categories of risk identified by the Narwhal AI Code Risks project are: 1. Supply Chain risks (e.g., recommending non-existent dependencies), 2. Code-level Vulnerabilities, 3. Cloud & Infrastructure Configuration risks, 4. Agent risks (related to autonomous AI actions), 5. Vertical Domain-specific risks, 6. Intellectual Property & Compliance risks, and 7. Human Factors risks.

你可能也喜歡

交易

現貨
合約

熱門文章

什麼是 $S$

理解 SPERO:全面概述 SPERO 簡介 隨著創新領域的不斷演變,web3 技術和加密貨幣項目的出現在塑造數字未來中扮演著關鍵角色。在這個動態領域中,SPERO(標記為 SPERO,$$s$)是一個引起關注的項目。本文旨在收集並呈現有關 SPERO 的詳細信息,以幫助愛好者和投資者理解其基礎、目標和在 web3 和加密領域內的創新。 SPERO,$$s$ 是什麼? SPERO,$$s$ 是加密空間中的一個獨特項目,旨在利用去中心化和區塊鏈技術的原則,創建一個促進參與、實用性和金融包容性的生態系統。該項目旨在以新的方式促進點對點互動,為用戶提供創新的金融解決方案和服務。 SPERO,$$s$ 的核心目標是通過提供增強用戶體驗的工具和平台來賦能個人。這包括使交易方式更加靈活、促進社區驅動的倡議,以及通過去中心化應用程序(dApps)創造金融機會的途徑。SPERO,$$s$ 的基本願景圍繞包容性展開,旨在彌合傳統金融中的差距,同時利用區塊鏈技術的優勢。 誰是 SPERO,$$s$ 的創建者? SPERO,$$s$ 的創建者身份仍然有些模糊,因為公開可用的資源對其創始人提供的詳細背景信息有限。這種缺乏透明度可能源於該項目對去中心化的承諾——這是一種許多 web3 項目所共享的精神,優先考慮集體貢獻而非個人認可。 通過將討論重心放在社區及其共同目標上,SPERO,$$s$ 體現了賦能的本質,而不特別突出某些個體。因此,理解 SPERO 的精神和使命比識別單一創建者更為重要。 誰是 SPERO,$$s$ 的投資者? SPERO,$$s$ 得到了來自風險投資家到天使投資者的多樣化投資者的支持,他們致力於促進加密領域的創新。這些投資者的關注點通常與 SPERO 的使命一致——優先考慮那些承諾社會技術進步、金融包容性和去中心化治理的項目。 這些投資者通常對不僅提供創新產品,還對區塊鏈社區及其生態系統做出積極貢獻的項目感興趣。這些投資者的支持強化了 SPERO,$$s$ 作為快速發展的加密項目領域中的一個重要競爭者。 SPERO,$$s$ 如何運作? SPERO,$$s$ 採用多面向的框架,使其與傳統的加密貨幣項目區別開來。以下是一些突顯其獨特性和創新的關鍵特徵: 去中心化治理:SPERO,$$s$ 整合了去中心化治理模型,賦予用戶積極參與決策過程的權力,關於項目的未來。這種方法促進了社區成員之間的擁有感和責任感。 代幣實用性:SPERO,$$s$ 使用其自己的加密貨幣代幣,旨在在生態系統內部提供多種功能。這些代幣使交易、獎勵和平台上提供的服務得以促進,增強了整體參與度和實用性。 分層架構:SPERO,$$s$ 的技術架構支持模塊化和可擴展性,允許在項目發展過程中無縫整合額外的功能和應用。這種適應性對於在不斷變化的加密環境中保持相關性至關重要。 社區參與:該項目強調社區驅動的倡議,採用激勵合作和反饋的機制。通過培養強大的社區,SPERO,$$s$ 能夠更好地滿足用戶需求並適應市場趨勢。 專注於包容性:通過提供低交易費用和用戶友好的界面,SPERO,$$s$ 旨在吸引多樣化的用戶群體,包括那些以前可能未曾參與加密領域的個體。這種對包容性的承諾與其通過可及性賦能的總體使命相一致。 SPERO,$$s$ 的時間線 理解一個項目的歷史提供了對其發展軌跡和里程碑的關鍵見解。以下是建議的時間線,映射 SPERO,$$s$ 演變中的重要事件: 概念化和構思階段:形成 SPERO,$$s$ 基礎的初步想法被提出,與區塊鏈行業內的去中心化和社區聚焦原則密切相關。 項目白皮書的發布:在概念階段之後,發布了一份全面的白皮書,詳細說明了 SPERO,$$s$ 的願景、目標和技術基礎設施,以吸引社區的興趣和反饋。 社區建設和早期參與:積極進行外展工作,建立早期採用者和潛在投資者的社區,促進圍繞項目目標的討論並獲得支持。 代幣生成事件:SPERO,$$s$ 進行了一次代幣生成事件(TGE),向早期支持者分發其原生代幣,並在生態系統內建立初步流動性。 首次 dApp 上線:與 SPERO,$$s$ 相關的第一個去中心化應用程序(dApp)上線,允許用戶參與平台的核心功能。 持續發展和夥伴關係:對項目產品的持續更新和增強,包括與區塊鏈領域其他參與者的戰略夥伴關係,使 SPERO,$$s$ 成為加密市場中一個具有競爭力和不斷演變的參與者。 結論 SPERO,$$s$ 是 web3 和加密貨幣潛力的見證,能夠徹底改變金融系統並賦能個人。憑藉對去中心化治理、社區參與和創新設計功能的承諾,它為更具包容性的金融環境鋪平了道路。 與任何在快速發展的加密領域中的投資一樣,潛在的投資者和用戶都被鼓勵進行徹底研究,並對 SPERO,$$s$ 的持續發展進行深思熟慮的參與。該項目展示了加密行業的創新精神,邀請人們進一步探索其無數可能性。儘管 SPERO,$$s$ 的旅程仍在展開,但其基礎原則確實可能影響我們在互聯網數字生態系統中如何與技術、金融和彼此互動的未來。

89 人學過發佈於 2024.12.17更新於 2024.12.17

什麼是 $S$

什麼是 AGENT S

Agent S:Web3中自主互動的未來 介紹 在不斷演變的Web3和加密貨幣領域,創新不斷重新定義個人如何與數字平台互動。Agent S是一個開創性的項目,承諾通過其開放的代理框架徹底改變人機互動。Agent S旨在簡化複雜任務,為人工智能(AI)提供變革性的應用,鋪平自主互動的道路。本詳細探索將深入研究該項目的複雜性、其獨特特徵以及對加密貨幣領域的影響。 什麼是Agent S? Agent S是一個突破性的開放代理框架,專門設計用來解決計算機任務自動化中的三個基本挑戰: 獲取特定領域知識:該框架智能地從各種外部知識來源和內部經驗中學習。這種雙重方法使其能夠建立豐富的特定領域知識庫,提升其在任務執行中的表現。 長期任務規劃:Agent S採用經驗增強的分層規劃,這是一種戰略方法,可以有效地分解和執行複雜任務。此特徵顯著提升了其高效和有效地管理多個子任務的能力。 處理動態、不均勻的界面:該項目引入了代理-計算機界面(ACI),這是一種創新的解決方案,增強了代理和用戶之間的互動。利用多模態大型語言模型(MLLMs),Agent S能夠無縫導航和操作各種圖形用戶界面。 通過這些開創性特徵,Agent S提供了一個強大的框架,解決了自動化人機互動中涉及的複雜性,為AI及其他領域的無數應用奠定了基礎。 誰是Agent S的創建者? 儘管Agent S的概念根本上是創新的,但有關其創建者的具體信息仍然難以捉摸。創建者目前尚不清楚,這突顯了該項目的初期階段或戰略選擇將創始成員保密。無論是否匿名,重點仍然在於框架的能力和潛力。 誰是Agent S的投資者? 由於Agent S在加密生態系統中相對較新,關於其投資者和財務支持者的詳細信息並未明確記錄。缺乏對支持該項目的投資基礎或組織的公開見解,引發了對其資金結構和發展路線圖的質疑。了解其支持背景對於評估該項目的可持續性和潛在市場影響至關重要。 Agent S如何運作? Agent S的核心是尖端技術,使其能夠在多種環境中有效運作。其運營模型圍繞幾個關鍵特徵構建: 類人計算機互動:該框架提供先進的AI規劃,力求使與計算機的互動更加直觀。通過模仿人類在任務執行中的行為,承諾提升用戶體驗。 敘事記憶:用於利用高級經驗,Agent S利用敘事記憶來跟蹤任務歷史,從而增強其決策過程。 情節記憶:此特徵為用戶提供逐步指導,使框架能夠在任務展開時提供上下文支持。 支持OpenACI:Agent S能夠在本地運行,使用戶能夠控制其互動和工作流程,與Web3的去中心化理念相一致。 與外部API的輕鬆集成:其多功能性和與各種AI平台的兼容性確保了Agent S能夠無縫融入現有技術生態系統,成為開發者和組織的理想選擇。 這些功能共同促成了Agent S在加密領域的獨特地位,因為它以最小的人類干預自動化複雜的多步任務。隨著項目的發展,其在Web3中的潛在應用可能重新定義數字互動的展開方式。 Agent S的時間線 Agent S的發展和里程碑可以用一個時間線來概括,突顯其重要事件: 2024年9月27日:Agent S的概念在一篇名為《一個像人類一樣使用計算機的開放代理框架》的綜合研究論文中推出,展示了該項目的基礎工作。 2024年10月10日:該研究論文在arXiv上公開,提供了對框架及其基於OSWorld基準的性能評估的深入探索。 2024年10月12日:發布了一個視頻演示,提供了對Agent S能力和特徵的視覺洞察,進一步吸引潛在用戶和投資者。 這些時間線上的標記不僅展示了Agent S的進展,還表明了其對透明度和社區參與的承諾。 有關Agent S的要點 隨著Agent S框架的持續演變,幾個關鍵特徵脫穎而出,強調其創新性和潛力: 創新框架:旨在提供類似人類互動的直觀計算機使用,Agent S為任務自動化帶來了新穎的方法。 自主互動:通過GUI自主與計算機互動的能力標誌著向更智能和高效的計算解決方案邁進了一步。 複雜任務自動化:憑藉其強大的方法論,能夠自動化複雜的多步任務,使過程更快且更少出錯。 持續改進:學習機制使Agent S能夠從過去的經驗中改進,不斷提升其性能和效率。 多功能性:其在OSWorld和WindowsAgentArena等不同操作環境中的適應性確保了它能夠服務於廣泛的應用。 隨著Agent S在Web3和加密領域中的定位,其增強互動能力和自動化過程的潛力標誌著AI技術的一次重大進步。通過其創新框架,Agent S展現了數字互動的未來,為各行各業的用戶承諾提供更無縫和高效的體驗。 結論 Agent S代表了AI與Web3結合的一次大膽飛躍,具有重新定義我們與技術互動方式的能力。儘管仍處於早期階段,但其應用的可能性廣泛且引人入勝。通過其全面的框架解決關鍵挑戰,Agent S旨在將自主互動帶到數字體驗的最前沿。隨著我們深入加密貨幣和去中心化的領域,像Agent S這樣的項目無疑將在塑造技術和人機協作的未來中發揮關鍵作用。

860 人學過發佈於 2025.01.14更新於 2025.01.14

什麼是 AGENT S

如何購買S

歡迎來到HTX.com!在這裡,購買Sonic (S)變得簡單而便捷。跟隨我們的逐步指南,放心開始您的加密貨幣之旅。第一步:創建您的HTX帳戶使用您的 Email、手機號碼在HTX註冊一個免費帳戶。體驗無憂的註冊過程並解鎖所有平台功能。立即註冊第二步:前往買幣頁面,選擇您的支付方式信用卡/金融卡購買:使用您的Visa或Mastercard即時購買Sonic (S)。餘額購買:使用您HTX帳戶餘額中的資金進行無縫交易。第三方購買:探索諸如Google Pay或Apple Pay等流行支付方式以增加便利性。C2C購買:在HTX平台上直接與其他用戶交易。HTX 場外交易 (OTC) 購買:為大量交易者提供個性化服務和競爭性匯率。第三步:存儲您的Sonic (S)購買Sonic (S)後,將其存儲在您的HTX帳戶中。您也可以透過區塊鏈轉帳將其發送到其他地址或者用於交易其他加密貨幣。第四步:交易Sonic (S)在HTX的現貨市場輕鬆交易Sonic (S)。前往您的帳戶,選擇交易對,執行交易,並即時監控。HTX為初學者和經驗豐富的交易者提供了友好的用戶體驗。

1.8k 人學過發佈於 2025.01.15更新於 2026.06.02

如何購買S

相關討論

歡迎來到 HTX 社群。在這裡,您可以了解最新的平台發展動態並獲得專業的市場意見。 以下是用戶對 S (S)幣價的意見。

活动图片