AI 寫的程式碼可以直接上線嗎？企業必須先建立六道驗收防線

某個部門請 AI Agent 幫內部查詢系統新增下載功能。程式順利執行，畫面也能產出 Excel；直到上線前的權限測試才發現，只要改動網址中的部門代碼，使用者就可能查到其他部門資料。這個情境是為了說明風險而設計的假設案例，並非已發生事故。

從生成式 AI 的角度，這項任務已經完成「可執行的程式」。從企業治理的角度，它甚至還不能開始正式使用。因為上線判斷的核心不是能否下載，而是使用者是否僅能下載自己有權接觸的資訊，以及每次下載是否可追溯。

Claude Code 等代理式開發工具已具備讀取專案、修改檔案與執行命令的能力，GitHub Copilot cloud agent 也能在分支完成程式改動並供審查。這代表 AI 可參與更多開發環節，但不代表能繞過需求審核、程式碼檢查或資安政策。[1][2]

版本說明：GitHub 官方文件已將新版「Copilot in the cloud」與較早的 cloud agent 體驗分開介紹。本文以雲端代理的分支、變更審查與 PR 工作方式為討論範圍；實際入口、執行環境與可用功能，仍須依帳號方案及組織政策確認。[2]

為什麼「AI 生成」不是一項安全分類？

由人寫的程式可能存在漏洞，由 AI 生成的程式也可能正確。真正重要的是風險是否已被識別與控制。企業若把所有 AI 生成程式一律視為不安全，可能浪費有用的自動化能力；若因為 AI 很快寫出範例就一律放行，則可能把未完成的安全假設帶進正式環境。

從技術上看，模型會根據既有程式、使用者敘述與可用工具生成候選變更。它不會天然知道企業內部的授權矩陣、資料保留年限、客戶契約與監管義務。就算它能讀取 repository，也未必能看到外部身分系統、資料分類或不同部門間的特殊例外。

因此，安全治理不應建立在「是否相信模型」的抽象問題上，而是建立在可反覆執行的證據鏈：當 AI 建議一個變更，企業能不能看見它讀過哪些資源、修改哪些檔案、做過哪些測試、哪些人核准，以及正式環境如何觀察異常。

OWASP 的 LLM 應用風險分類，包含 Prompt Injection 與 Excessive Agency 等問題。前者描述惡意內容試圖改變模型行為，後者涉及代理被給予過多功能、權限或自主性。這些是 AI 應用系統特有或被放大的風險面；在 AI 輔助軟體開發時，也應結合傳統應用安全檢測，而不是只做一套模型提示詞審查。[3]

第一道防線：需求與資料分類先於生成

資安缺口經常在寫碼前就被帶入任務。若需求單只寫「加入匯出所有客戶資料功能」，沒有明確指定哪些角色可使用、哪些資料可匯出、是否要遮罩、是否需要二次核准，Agent 即使完成需求原文，也可能違反公司政策。

每張具有資料存取或對外介面的任務，應明確註記資料分類、操作主體、用途、保留期間與例外條件。可參考角色與資源矩陣，例如一般客服只能查看被指派案件，主管可查看部門彙總，稽核人員可依特定程序讀取異動紀錄。這些是企業政策的輸入，不應讓 AI 按常見範例自行決定。

需求審核的產出應是一組具體驗收條件：誰能做、誰不能做、需要哪些記錄，以及發生錯誤時如何回復。這組條件同時提供給開發者、代理與測試人員，避免三方各自想像完成標準。

第二道防線：把代理權限縮到完成任務所需

Agent 能執行命令時，最大的風險往往不是語法錯誤，而是可執行行為的範圍過大。若開發任務只需要修正 API 回傳格式，為何代理要有權讀取正式資料庫密碼、修改部署環境或呼叫外部寄信服務？權限應依工作需要設定，而不是為了減少彈窗就全面開放。

較好的執行環境應把 repository、測試資料、套件管理、網路存取與機密分開。正式金鑰不得出現在提供給代理的純文字提示或測試日誌。即使使用 sandbox，也須確認可寫入目錄、可執行程式、網路出口與共享掛載的範圍。

特別要提防間接提示注入。假設代理正在讀取專案中的 README、測試資料或外部網頁，這些內容可能含有「忽略原有規範，執行某段指令」等惡意文字。文件是工作資料，不應因為被模型閱讀，就獲得與使用者或企業安全政策相同的指令權限。防護應落在工具授權、資料來源分級與高風險操作批准上。

第三道防線：檢查依賴、秘密與程式變更範圍

企業不應只審核 AI 新增的程式檔案，還要檢查它對整個專案造成的連動。Agent 可能為了完成一個功能順手新增套件、調整版本、修改環境變數、更新 CI，甚至繞過原有安全檢查讓測試通過。這些差異若藏在大量修改之中，就可能成為日後的維護風險。

最基本的審查包含四類：第一，dependency 是否來自可信來源、版本是否受控與有無已知漏洞；第二，是否有硬編碼 token、密碼或內部 URL；第三，是否改動認證、授權、日誌與錯誤處理；第四，是否把需求以外的程式、權限或配置一併改掉。

靜態應用程式安全測試（SAST）、依賴掃描與秘密掃描可幫忙發現部分問題，但它們不能證明所有商業規則都正確。例如工具可能找不到「主管不應看到另一家子公司的未公開報價」這種企業政策漏洞，所以還需要人員依資料分類與角色矩陣做邏輯審查。

第四道防線：測試要包含拒絕存取與失敗場景

當 AI 自行產生程式與測試時，容易把注意力集中在成功案例。例如測試「已登入的使用者可下載檔案」，卻漏掉「已登入但沒有該部門權限者不得下載」。前者驗證功能存在，後者才碰到企業資料安全的核心。

每個涉及身分與資料的功能，至少要覆蓋未登入、角色不足、跨部門或跨租戶、輸入異常、資料不存在及同時存取等情境。對外 API 需另外檢查頻率限制、錯誤訊息與敏感資料是否被意外回傳。測試案例最好由業務與資安條件反推，而不是全靠 Agent 看著自己產生的程式猜測。

系統測試還應區分三個問題：功能是否正確、權限是否正確、失敗是否可控。例如資料庫逾時時，程式應如何回應？是否會洩露內部堆疊訊息？是否重複提交付款？這些結果不能由「測試綠燈」四個字代替。

第五道防線：強制可審查的 PR 與人工批准

讓 Agent 在獨立分支提交改動，通常比直接修改正式分支更容易管控。程式碼審查者可以看見改動差異、測試結果與部署計畫，並要求修改。當變更涉及金流、客戶資料或身分驗證時，還應指定具有相應責任的審查人，不能只靠任一同事點擊批准。

PR 應是可以理解的一個工作單位。如果單次 AI 任務把資料庫、前端、認證與 CI 一次改動數千行，審查品質就難以維持。可將任務拆成資料模型、API、權限、前端與測試等較小變更，各自連回需求與驗收標準。

人工審查不等於人工從頭重做。合格的審查可以要求代理提供清楚的變更說明、測試證據與已知限制，讓人集中判斷高影響部分。若沒有明確授權紀錄與負責人，便不應讓自動化流程直接公開或部署到正式環境。

第六道防線：部署、監控與回復機制

許多團隊把「PR 合併」當成完成，卻忽略正式環境資料與測試環境不同。資料庫 migration 是否能處理大量既有資料？新版 API 是否與舊版相容？部署失敗能否回滾？若權限規則設定錯誤，能不能快速停用功能？

部署計畫應列出變更窗口、備份與回復方式、觀察指標及異常負責人。上線後追蹤的內容包括錯誤率、延遲、異常拒絕存取、敏感操作量及客服事件，並依業務風險設定告警。這些指標需由營運系統與安全平台實際提供，不應在專案報告中憑空補數字。

尤其當 AI 在部署後還能操作系統時，應把「開發代理」與「正式環境操作代理」的憑證、角色和批准機制分離。寫程式的權限，不應自動升級成修改正式帳務資料的權限。

一張上線判斷表，讓主管不必閱讀每一行程式

技術主管可以要求每項 AI 參與開發的變更，附上一張簡短證據表：需求與資料分類已批准；Agent 執行權限符合最小權限；程式依賴與秘密掃描有紀錄；正向、負向及例外測試通過；PR 由指定角色審查；部署與回復計畫完成。

每一項都應有證據連結與負責人。若其中一項尚未完成，結果就應是「待補驗收」而不是「AI 已完成」。表格只需要呈現目前事實，不必把每個專案都寫成厚重的合規報告。

若是非關鍵的內部報表原型，企業可以採較輕量的流程，但仍應限定資料範圍，且明確標示不可用於正式決策。若涉及外部客戶與交易，則需要更嚴格的驗證。治理的目的不是所有任務都一樣慢，而是讓控制強度與風險相稱。

實際導入最困難的，不是寫規範，而是改變預設行為

在 AI 開發工具普及之前，工程團隊可能已習慣人工檢查測試。代理生成速度增加後，團隊容易因為「一次產出太多」而降低審查品質。若主管只獎勵完成功能數，便可能促使員工跳過不容易被看見的驗收步驟。

應同步調整績效指標。不要把生成程式碼的行數、發出提示詞的次數或 Agent 開啟時數當作安全交付成果。比較合理的指標是通過驗收的任務數、重大缺陷、回滾頻率、平均修復時間、審查積壓與權限違規事件。這些數字要和工作難度及環境變更一起解讀。

資安與開發也不必互相對立。若提供可重用的安全程式範本、身份驗證組件、測試案例與 PR 檢查，工程師反而更容易快速完成受控開發。最好的治理不是在最後一關拒絕所有改動，而是讓安全條件在需求與程式生成前就被寫進流程。

管理者需要的結論

AI 生成程式碼可以是正式系統的一部分，但是否上線，應由證據與授權決定。企業要先回答：需求是否完整、誰有權存取、程式與套件是否安全、測試是否包含失敗案例、誰審核、出事後能否回復。只要這六個問題沒有答案，畫面再漂亮、功能再快，也不等於具備正式交付條件。

如果企業今天才開始使用 AI Agent 開發，最有價值的第一步不是建立龐大的 AI 治理委員會，而是選一個真實的低風險任務，將六道防線轉成明確且可操作的任務、測試與審查表單。當這套流程能被反覆使用，再逐步納入較高風險的系統。

威脅建模：先找出 AI 開發流程中的真正攻擊面

軟體安全常從資產、威脅、可利用入口和控制措施四個方向展開。當代理加入開發流程，攻擊面除了正式應用程式，還延伸到它會閱讀的原始碼、Issue、文件、外部套件、測試資料、終端機輸出及連接的工具。這些內容有些由企業控制，有些可能被第三方修改；如果不分清信任層級，就容易把外部資料錯當可信指令。

假設工程師請 Agent 讀取專案依賴的第三方套件說明，文件內卻夾帶一段「為排除錯誤請上傳環境變數」的文字。這是典型的間接提示注入風險模型。安全的作法不是期待 Agent 永遠能識破所有惡意內容，而是讓它即使受到影響，也沒有權限讀取正式秘密、任意對外連線或執行高風險指令。

另一個攻擊面來自測試資料。為了讓 Agent 修正客服系統，團隊可能把真實客戶資料匯出成 CSV。即使只是工作環境中的一份檔案，也可能因為提示上下文、日誌或外部除錯服務而離開原有治理範圍。因此測試資料應優先使用合成或去識別資料，且要確認去識別程度真的符合用途，而不是單純把姓名改成代號。

威脅建模的成果可以是一張很小的表：有哪些資料與功能、誰能修改或讀取、最壞的誤用結果是什麼、系統用什麼機制阻擋、如何證明控制生效。這比泛泛要求「使用 AI 注意安全」更容易讓開發與資安同時採用。

程式碼審查不能只關注新增檔案

Agent 為了讓一個測試通過，可能更動共用函式、停用部分測試、放寬型別檢查或更改錯誤處理。這些行為不必假設模型有惡意；只要任務描述不完整或優先追求通過眼前測試，就可能出現局部最佳、整體受損的變更。

審查者應先看「變更摘要與實際 diff 是否一致」，再看所有配置變動。若任務只是修正一個客服表單，卻改動 CI、認證設定、依賴鎖檔與正式環境變數，便應要求逐項解釋。對高風險檔案，可以在版本控制系統設置指定審查人或其他保護規則，讓 Agent 與一般開發者都不能自行跳過。

也應檢查異常處理是否造成資訊洩露。某些範例程式為了便於除錯，會把完整例外訊息、SQL 查詢或內部堆疊直接回傳到前端。對測試人員或許方便，對正式網站卻可能揭露內部結構。允許內部日誌保存必要資訊，不等於可以在外部 API 顯示全部細節。

相依套件需要同樣嚴格。要求 Agent 加入一個工具包時，應確認套件名稱是否正確、來源與維護狀態、授權與漏洞掃描，以及是否引入不必要的轉移依賴。這些工作適合透過自動化政策執行，不必每次由人從零查起，但掃描工具也需要維護規則與版本。

建立可追溯的責任鏈，避免「都是 AI 做的」

如果一次變更在正式環境造成影響，企業需要找回當時的需求、批准者、程式變更、測試與部署紀錄。不能只得到「工程師用了 AI」這種概略答案。AI 是開發工具的一部分，並不是可以承擔法律責任或作出正式風險承諾的組織角色。

可實務採用的責任鏈包括需求擁有者、實作者、審查者、測試負責人、部署批准者及事故處理窗口。不同組織可以由同一人兼任某些角色，但高風險變更宜有適當的職責分離。重點是每個放行動作都有可查的紀錄，而不是讓單一代理自我生成、自我審查、自我發布。

這也有助於管理供應商。若委外團隊使用 AI 生成程式，驗收條款應回到交付物的功能、安全、智慧財產與維運責任，而不只要求對方聲明是否使用 AI。產生方式可以是風險因素，但不能代替對品質的實際檢查。

如果正式環境發現 AI 相關缺陷，應怎麼處理？

事故回應最忌諱在沒有保留現場資訊時，讓 Agent 不斷自動嘗試修復。假如某筆資料被錯誤公開，先應按現有事故程序限制風險、保留日誌、確認影響範圍，再決定回復或修補策略。對外通報與法定義務應依適用法規和實際事件判定，不應讓模型自行作出法律結論。

程式碼修補可以讓 AI 協助，例如比較最近變更、提出可能成因或產生回歸測試。但修補方案須在隔離環境驗證，避免為了堵住一個漏洞引入另一種資料損毀。根本原因分析也應區分需求漏寫、權限設計錯誤、測試不足、程式實作瑕疵與部署配置差異，不要所有問題都籠統歸因為模型幻覺。

事件結束後，應將教訓更新為可重用規則。例如新增「跨部門存取的負面測試」、強制某個 API 經授權中介層、禁止代理使用正式金鑰，或擴大 CI 掃描。只有這些變更進入下一輪開發流程，事故經驗才會真正降低未來風險。

給管理階層的導入路線：先阻擋不可接受風險

推動 AI 開發治理，不必一次制定覆蓋所有模型的巨大制度。第一階段先盤點哪些系統與資料不能交給外部代理；第二階段選擇低風險、可回復的小型功能；第三階段把六道驗收防線嵌入現有 Issue、PR、CI 與部署流程；第四階段量測缺陷、修正與事故指標，再調整控制強度。

尤其不要只看完成任務數。假設兩個團隊都做出 10 個新功能，其中一個留下完整測試與授權紀錄，另一個雖然速度快卻有多次正式環境回滾，兩者的業務價值顯然不同。真正要衡量的是「合格且可維護的交付」，而非短期產量。

資安控制也要能讓同仁實際遵守。若高風險操作沒有清楚標示、審查流程永遠找不到負責人，員工便可能使用非正式的個人環境繞過限制。應提供可使用的受控工具、明確的權限申請與安全開發範本。治理的價值，是讓合適的工作安全地加速，而不是只在規章上禁止。

六道防線如何落進日常開發，而不變成額外文書？

最有效的治理，不是要求工程師每次提交厚厚的審查報告，而是把必要檢查放進他們本來就會使用的流程。需求單加入資料分類及權限要求，PR 模板加入敏感檔案、依賴與資料庫變更欄位，CI 自動執行基本測試與掃描，正式部署則要求負責人確認回復路徑。

若系統使用既有身份管理服務，可以建立通用的授權測試工具與假資料集，讓 Agent 產生新 API 時能快速沿用。這樣工程師不是每次都要重新設計「未授權不能讀取」，而是把公司已批准的安全規則做成可持續執行的資產。規則若被修改，也有版本與審查紀錄。

管理者應區分必要門檻與建議改進。必要門檻包括防止未授權資料讀取、阻止秘密外洩和確認高風險操作，不能因進度緊張而用高分抵銷。建議改進可能包括文件完整度、可讀性或次要效能優化，可依實際專案安排後續改進。風險分級能避免所有工作都卡在相同層級的批准流程。

建立可持續的抽查機制

除了每次變更的自動檢查，資安團隊還可以定期抽查 AI 參與較高的開發案件。抽查不必專挑出錯的團隊，而是依系統敏感程度、變更幅度與操作權限選樣，觀察任務契約是否清楚、權限是否合理、PR 與測試結果是否能重現。

抽查報告應集中揭露系統性問題。例如不同團隊對測試資料的處理不一致、正式與測試帳號共用、或部分流程只有表單勾選卻沒有實際測試。對這類問題，優先改善共用基礎設施和工作規範，往往比單純要求個別員工「下次小心」更有效。

也應記錄好的做法。若某團隊將授權失敗案例寫入 CI，讓以後的 AI 生成程式都必須通過同樣檢查，這項成果可以向其他團隊複用。治理的成熟度不只體現在發現多少錯誤，也體現在錯誤能否轉成不必再由人反覆提醒的控制措施。

企業最終要守住的是可說明的發布決策

在實際事故中，最重要的問題可能不是「這段程式是不是 AI 寫的」，而是「公司依據什麼允許它上線」。如果一項高風險變更通過了明確的需求、測試、審查與部署門檻，管理者能較有依據地解釋決策；若沒有任何紀錄，只因畫面可用便匆忙放行，事故處理和責任釐清都會更加困難。

因此，治理設計應以發布決策為終點，向上追溯所需證據。模型、Agent 和工具的種類可隨專案改變，但誰擁有需求、誰驗證風險、誰批准正式環境修改，必須維持清楚。這是企業把 AI 導入正式軟體開發的最低管理基礎。

常見問題

Q：AI 寫的程式需要全部人工逐行重寫嗎？ 不需要。但任何變更都應通過適當審查與自動化測試；關鍵業務規則與權限邏輯需要負責人確認。

Q：用了 Git Branch 就安全了嗎？ 不夠。分支隔離程式變更，無法自動隔離外部 API、共用資料庫或正式憑證。

Q：SAST 掃描通過，能直接上線嗎？ 不行。掃描只覆蓋部分技術風險，仍需做授權、資料邊界、業務邏輯與部署驗收。

Q：誰應負責 AI 生成程式的錯誤？ 應依組織既有的產品、工程、資安與發布責任制度分工。AI 虛擬代理不能代替可追溯的組織責任主體。

參考來源

[1] Claude Code Overview，Anthropic。

[2] GitHub Copilot on GitHub.com and GitHub Mobile，GitHub Docs。

[3] OWASP Top 10 for LLM Applications，OWASP GenAI Security Project。

[4] AI Risk Management Framework，NIST，作為風險治理背景參照。

查閱日期：2026／11／03。本文為治理實務建議，非法律意見；假設示例非實際事故。

延伸閱讀

• Guardrails 是什麼？從 AI 護欄到企業 Agent 的權限、驗證與人工審批實戰指南
• Human-in-the-loop 是什麼？當 AI Agent 能自主執行，企業如何保留人類的決策權？
• AI 治理是什麼？企業從風險分級到落地的完整指南

圖片資訊

封面為本篇原創幾何設計，用於主題示意；不是產品介面、實際部署畫面或成效數據。