上一篇的結論是：AI 看 Log 會誤判，因為它手上只有那一段 Log。把場景換成程式碼，同一個限制會換一種方式出現。

把 AI 放進 Code Review，它像一位眼力很快、但還沒讀過公司規章的新工程師。

有些問題它抓得很好。SQL 查詢直接拼接輸入，可能是 Injection；Debug 模式沒關、權限配置過鬆，是 Security Misconfiguration；登入流程漏掉驗證，可能是 Authentication Failure。這些有個共同點——判斷需要的一切，都寫在眼前這段程式碼裡。

Broken Access Control 不一樣。GET /orders/123 回傳了資料，只證明這支 API 會回資料，不證明眼前這個使用者「應該」看得到。誰擁有 123 這筆訂單、哪些角色可以跨帳號查、客服的權限到哪裡為止——這些都不在函式裡。

分界線就在這裡：這個漏洞，光看這段程式碼判斷得出來嗎？

Li 等人（2025）把這件事量化了。他們指出過去的評測多半只餵給模型孤立的函式或檔案，缺少執行與資料流脈絡，因而低估了 LLM 的能力；他們提出 CORRECT 評估框架，把脈絡補回去之後，表現最好的模型準確率約六成七。

六成七這個數字有兩面。往好處看，補脈絡確實有效——要 AI 判斷權限，就別只丟一個函式過去，把角色定義、資料所有權和呼叫鏈一起給它。往壞處看，那是在脈絡完整、而且評測者知道正確答案的實驗設定下的成績，離「它說沒問題就可以 merge」還有一段距離。

所以看到 AI 說「這段沒有問題」的時候，先分辨一下：

它說的是「沒問題」，還是「在我看得到的範圍內沒問題」？

延伸閱讀

Yue Li et al., Everything You Wanted to Know About LLM-based Vulnerability Detection But Were Afraid to Ask, arXiv:2504.13474, 2025。