譯者 | 晶顏

審校 | 重樓

代理式人工智能（Agentic AI）具備自主編寫與部署代碼的能力，由此衍生出新的安全風險，因而需要人工監督與強有力的保障機制。

自2022年底ChatGPT及生成式人工智能（GenAI）成為主流以來，其影響力的持續攀升對軟件開發行業產生了直接影響。生成式人工智能工具編寫可執行代碼的能力被視作顯著優勢之一，且此后人工智能一直在持續迭代優化。代理式人工智能的興起是軟件開發領域的下一個重大變革，它能夠自主編寫、調試代碼，并將代碼部署至運行環境，這一特性也要求我們從安全視角對其進行重新審視。

長期以來，網絡安全專業人士始終強調“左移”方法是至關重要的安全支柱，即盡可能在軟件開發生命周期的早期階段集成安全控制措施。然而，隨著人工智能的智能化程度不斷提升，當前我們面臨著在完全由人工智能編寫、無需人類參與的環境中保障軟件安全的新課題。

本文旨在研究這一范式轉變所帶來的新挑戰，以及為應對代理式人工智能環境，必須實施的人機協同審查機制。

人工智能軟件代理的興起

近年來，人工智能生成代碼的技術迅速發展，亞馬遜Q Developer、GitHub Copilot和谷歌Gemini等工具借助大型語言模型（LLM）實現代碼生成功能。這些工具起初扮演輔助開發者的角色，助力代碼創建與調試工作，而代理式人工智能則通過賦予系統自主性，將這一能力提升至全新高度，使其能夠在無人干預的情況下完成代碼生成、調試、測試及部署全流程操作。

這種功能并不局限于單個人工智能代理，實際應用中已出現多個AI代理協同作業的場景，它們分別承擔軟件設計、測試、編碼及項目管理等不同角色。這一模式轉變影響深遠，不僅改變了軟件開發的傳統模式，也對網絡安全領域產生了顛覆性影響，從根本上重塑了網絡安全威脅格局。

除了傳統軟件開發中已存在的風險外，人工智能生成的代碼還可能引入新的安全隱患，任何有意在軟件開發中采用人工智能代理的企業，都必須對這些潛在問題予以充分考量。

新的威脅形勢

以下將對這一模式引入的新型安全風險展開分析：

1. 安全性設計薄弱

傳統軟件開發過程中，開發人員與網絡安全專業人士憑借自身經驗，能夠充分考慮潛在威脅場景，遵循安全設計模式，并運用專業領域知識進行開發。然而，人工智能代理若未得到明確指導，便缺乏實際應用場景理解與威脅建模能力。

若在提示信息或訓練數據中未融入安全設計原則，人工智能代理生成的代碼雖可能具備基礎功能，但在抵御攻擊方面存在嚴重缺陷，例如出現硬編碼密鑰、未對輸入進行安全校驗、訪問控制配置錯誤等問題。

2. 有毒的訓練數據和模型偏差

人工智能代理高度依賴從公共存儲庫中抓取的大型數據集。若這些數據集中包含不安全代碼或惡意模式（如已知存在安全漏洞的依賴項、不良編程實踐等），代理可能會在無意識的情況下“學習”并復制這些不安全行為。

此外，攻擊者可能試圖投毒訓練數據集或注入惡意代碼，誘使代理生成包含后門的代碼。在持續集成（CI）環境中使用人工智能代理時，這一問題尤為突出，可能引發嚴重的安全后果。

3. 缺乏可追溯性

在人工開發模式下，Git等版本控制系統能夠完整記錄代碼編寫的歷史信息，實現代碼的可追溯性。但人工智能代理生成的代碼片段往往缺乏明確的來源標識與背景信息。這種可追溯性的缺失使得以下問題難以確定：

• 代碼是從哪里來的；
• 代碼是否復用自存在安全隱患或已遭破壞的來源；
• 是否存在違反軟件許可證使用規定的情況。

4. 代理式AI漏洞

如果代理能夠訪問文檔、外部應用程序編程接口（API）及運行時環境，這些代理自身便成為攻擊目標。惡意提示、被污染的文檔或不安全的插件，都可能操縱代理生成不安全的配置或導致憑證泄露。

這意味著軟件安全防護工作已延伸至保護人工智能代理的運行環境，而這一全新挑戰或許超出了當前網絡安全專業人士的應對能力范疇。以下為具體威脅場景分析：

（1）與開發者意圖不一致

代理系統無法真正理解人類價值觀及企業安全政策，僅以任務成功執行為優化目標，這可能導致目標不一致問題。例如，開發人員創建用于“自動化新工程師入職流程”的人工智能代理，該代理可能出于追求效率與簡便性，為新用戶賬戶賦予過高的管理權限，從而違反企業最小權限原則。此類情況并非出于惡意，而是自然語言表達與安全設計理念之間存在理解偏差所致。

（2）代理接管和提示劫持

具備文件、命令或API讀寫權限的代理系統，可能因惡意或已遭破壞的數據源而被攻擊者劫持。這類攻擊可能類似于供應鏈攻擊，不同之處在于此處的“供應鏈”涉及文檔、提示信息或插件等。截至2025年，已有相關案例報道顯示代理遭受攻擊后執行了未經授權的操作。

新方法：Secure-AI-DevOps

對人工智能代理的安全防護不能僅局限于代碼審查與掃描，而需重新審視“左移”策略的實施方式。為此，我們提出一種全新的方法——Secure-AI-DevOps，該方法集成了以下核心原則：

1. 人在循環（HITL）監督

無論人工智能代理的技術如何先進，人類監督始終是整個流程中不可或缺的關鍵環節，具體涵蓋以下方面：

• 對人工智能生成的代碼進行邏輯錯誤檢查；
• 手動開展威脅建模工作；
• 運用靜態和動態分析工具對代碼進行驗證；
• 對架構決策進行核實，尤其是當代理生成基礎設施即代碼（Infrastructure as Code，IaC）模板時，需進行嚴格審查。

代理防護機制和提示工程

提示工程已成為保障安全的關鍵技能。如同編寫安全的函數一樣，我們必須精心設計安全的提示內容。例如：

• “編寫一個采用安全密碼哈希算法和速率限制機制的登錄函數”；
• “避免出現任何硬編碼密鑰或明文日志記錄”；
• “在身份與訪問管理（IAM）角色中遵循最小權限原則”。

此外，還應為人工智能代理設置下述防護措施：

• 限制其可導入的軟件包范圍；
• 在代碼執行前執行嚴格的質量標準檢查；
• 隔離其對生產環境的訪問權限，防止潛在風險擴散。

3. 人工智能代理行為監測

人工智能代理不應僅被視為開發工具，而應作為具有實際操作影響的軟件實體進行全面監控。需重點關注以下行為：

• 代理是否對不應修改的配置進行了變更；
• 是否調用了未經驗證的應用程序編程接口（API）；
• 是否在生產環境而非預發布環境中創建資源。

將人工智能代理的行為監測、日志記錄及警報機制集成到持續集成/持續交付（CI/CD）管道中，是保障系統安全的重要控制手段。

4. 協同責任機制

在人工智能時代，開發人員的角色不再局限于編寫代碼，同時還需承擔人工智能輸出內容優化與審核的工作。安全保障也演變為多方協作的模式，各相關方需共同承擔以下責任：

• 開發人員：編寫安全提示內容，審查代碼，并確保開發過程符合相關規范；
• 安全團隊：構建自動化掃描工具并制定人工智能安全策略；
• 運維團隊：實時監控代理活動，維護環境隔離；
• 法律/合規部門：追蹤軟件許可證使用情況及代碼來源，確保合規性；
• 從被動到主動：安全防護必須從被動應對轉向主動防御，安全性應從首個提示輸入階段便開始嵌入。

核心結論

• 人工智能代理正逐漸從單純的生產力工具轉變為具備自主編碼能力的實體，在GPT-4.1、Gemini Code Assist等工具的推動下，深刻影響著應用程序開發模式。
• 當人工智能代理生成的代碼缺乏明確的設計意圖與威脅建模時，便容易出現安全漏洞，進而導致邏輯缺陷、不安全默認設置及配置隱患等問題。
• 當前，網絡安全威脅形勢正在不斷演變，數據投毒、代碼來源不透明以及因代理行為導致的攻擊面擴大等新型風險日益凸顯。
• 在此背景下，Secure-AI-DevOps這一全新范式成為必要選擇，它融合了人工監督、安全提示設計、軟件溯源以及人工智能代理行為監測等關鍵要素。
• 開發人員需要轉變角色定位，不僅要履行編碼職責，更要承擔起人工智能監督者的重任，確保代理生成的內容符合安全標準與組織策略要求。
• 安全防護工作需再次深化“左移”理念，從提示輸入、約束條件設定到工作流程設計的各個初始環節，均應引導人工智能代理的行為，以保障系統安全。

原文標題：Securing Software Created by AI Agents: The Next Security Paradigm，作者：Pranjal Sharma