AI Agent 真正執行過哪些操作？CrowdStrike 把 MCP、Skills 與端點行為串成稽核證據

一名工程師要求 AI Agent 協助設定開發環境。對話紀錄顯示，AI 收到指令、列出步驟，甚至回覆「完成」。但企業的資安團隊還有另一組問題：它是否從外部網站下載檔案？是否執行安裝程式？過程中有沒有接觸雲端金鑰？防護軟體攔截的動作，究竟是不是這次 AI 任務造成的？

2026 年 10 月 30 日，CrowdStrike 在技術文章中介紹 CrowdStrike Agent Graph，展示如何把 AI Agent 的提示詞、工具呼叫、Skills、MCP 連線與電腦實際發生的程序、檔案和網路活動連結起來。這是 Falcon Guardian 的關聯分析能力，而不是一個新的 AI 寫作工具。它要處理的問題很具體：企業不能只知道 AI「說自己做了什麼」，還需要證據來判斷它「實際做了什麼」。

這個差別看似細微，卻決定 AI Agent 能否從個人試用進入受管理的企業流程。當 AI 只能產生一份草稿，主管或許只需檢查內容；當 AI 能發信、修改程式、下載套件、存取客戶資料，驗收對象就從「答案」擴大為「整串操作」。本文根據 CrowdStrike 官方技術揭露、其開發者文件，以及 MCP 規格、MITRE 資安技術資料，釐清它展示了什麼、尚未證實什麼，以及企業可以如何設計自己的稽核機制。

從 AI 對話紀錄到行為證據，缺的究竟是哪一段？

企業最早管理生成式 AI，往往從帳號、使用政策和輸入資料開始。員工是否使用核准的服務？可否輸入個資？對話能否保留？這些議題重要，但主要聚焦在 AI 的入口。AI Agent 讓問題往下一層移動：收到任務後，AI 可能自行判斷步驟，接著呼叫工具，讓另一個程式替它操作。

假設業務同仁請 Agent「整理本週報價，寄送更新通知」。只看提示詞，這是合理的工作指令；只看最後輸出的郵件草稿，也可能完全沒有問題。真正的風險出現在執行階段：Agent 讀取了哪一份客戶清單？是否使用最新版價格？寄件範圍是 10 人還是 1,000 人？有沒有將附件送往未核准的外部地址？最後郵件是建立草稿、成功寄出，還是遭系統拒絕？

因此，稽核至少有三種不同層次。第一種是意圖紀錄，保存誰交辦了什麼；第二種是工具紀錄，保存 AI 呼叫了什麼能力與帶入何種參數；第三種是結果紀錄，驗證外部系統或作業系統究竟產生了什麼變化。三者可以互相佐證，卻不能互相取代。Agent 說「已寄出」不等於郵件服務接受寄送；工具回覆「成功」也不一定代表最終業務狀態完全正確。

這正是 CrowdStrike 切入的缺口。該公司表示，既有 Falcon 感測器本來就能觀察受管理端點的程序、檔案及網路活動；Agent Graph 進一步將支援的 AI Agent 工作階段與這些端點訊號關聯。從資安調查角度看，價值不只是收集更多紀錄，而是讓不同來源的紀錄能回答同一個因果問題：哪個任務、哪次工具呼叫，導致哪個程序或網路連線被啟動？

10 月 30 日公布的是什麼？先分清產品、功能與發表時間

CrowdStrike 早在 2026 年 9 月 1 日便宣布 Falcon Guardian，定位為針對 AI 應用與 Agent 的偵測及回應方案，並提出從提示詞到執行結果的觀察與控制能力。10 月 30 日發布的文章，則更具體說明底層的 Agent Graph，以及使用者能在介面上看到的代理程式清單、工作階段圖和威脅評分。因此，正確的時間線應是「9 月公布產品方向，10 月公開解釋 Agent Graph 的操作與展示」，不能寫成 11 月 2 日才首度推出。

根據官方說明，Agent Graph 會把使用者、裝置、模型、提示詞、工具、Skills、MCP 伺服器、程序、檔案和偵測事件建立關係。支援的 Agent 可呈現在同一份清單中，方便區分組織核准的工具與未經批准的工具。工程師不必先知道問題出在何台電腦，便可從一個高風險 Agent 的紀錄展開調查，再追到它的特定工作階段。

CrowdStrike 將主要檢視方式分為三個部分。Agent Inventory 回答「有哪些 Agent、在哪裡運作、與誰及哪些能力有關」；Session Graph 回答「這一段任務如何一步步導致實際操作」；Agent Threat Score 則把風險訊號彙整成 0 至 100 的分數，以利資安團隊決定先調查哪一個對象。分數是產品的警示排序機制，並非證明某個人或某個 AI 已經違規的司法判定。

官方文章舉了一個 Claude Code 情境：開發者將來源不可信的設定說明交給 Agent，要求依序執行其中的命令。工作階段圖顯示數次工具呼叫與後續行為，包括連向外部主機、安裝套件，以及執行下載目錄中的安裝程式。該展示中，防護偵測被連回觸發安裝程式的工具呼叫，並呈現程序遭阻擋、檔案遭隔離的結果。這是產品展示中的案例，不代表所有企業客戶都已觀察到同樣的事件，也不能當作獨立測試報告。

MCP、Skills、Hooks 是三種不同位置的資訊，並非同義詞

想理解 Agent Graph，得先把幾個經常混用的名詞放回各自的位置。MCP 是 Model Context Protocol，讓 AI 用一致的方式發現與呼叫外部工具或讀取資源。它處理的是「怎麼連接」；Skills 通常是可重複使用的操作說明或工作流程，告訴 Agent「做這類任務時，依哪些規則與步驟進行」；Tool 則是具體可呼叫的功能，例如查詢資料、執行指令、建立文件或呼叫 API。

三者不是永遠沿著單一路徑排列。Agent 可以不使用 MCP，直接呼叫內建工具；一份 Skill 也可能只給操作指引，沒有獨立的工具介面；另一份 Skill 則可能要求呼叫多個 MCP 工具與本機命令。對企業來說，這種重疊不需要刻意否認。更重要的是，稽核系統要辨認不同資訊來源各自能證明什麼，不能看到「某個 Skill 被載入」就直接推定其中所有步驟都已執行。

Hooks 又不同。它通常是在特定事件發生前後插入檢查或紀錄，例如使用者送出提示詞、工具即將執行或工具執行完畢。CrowdStrike 表示，Falcon Guardian 可以利用支援 Agent 的原生 Hooks，補充提示詞內容、工具輸入與輸出，並在工具呼叫執行前套用政策。官方截至 10 月 30 日列出支援 Hooks 的代理工具包括 Claude Code、OpenAI Codex、GitHub Copilot、OpenCode 與 Cursor。實際支援程度仍須依版本、平台、設定與授權確認。

還有一個容易混淆的產品名稱：CrowdStrike 自己也提供 Falcon MCP Server，讓 AI 助手透過 MCP 查詢 Falcon 資安平台，進行威脅調查、資產查詢等操作。它是「提供安全工具給 AI 使用」的接口；Agent Graph 則是「觀察 AI 如何使用能力以及實際做了什麼」的追蹤能力。兩者可以出現在同一套產品生態中，卻不等於同一件事。

稽核一個 AI 工作階段，真正要保留哪些欄位？

傳統系統稽核通常知道某個帳號在什麼時間呼叫 API。Agent 場景還要補上一個關鍵背景：這次呼叫與哪個指令、哪個工作階段、哪份操作規則有關。否則，資安團隊看到「某電腦執行一條命令」，仍無法判斷是人工操作、一般背景程序，還是某次 Agent 任務的後續結果。

一份具備調查價值的紀錄，最好包含任務識別碼、發起人與授權主體、Agent 與版本、模型、時間戳記、工具或 MCP 伺服器、呼叫參數摘要、執行身分、目標資源、實際結果、政策決策及證據來源。若動作跨越多個系統，還應建立可相互對照的請求編號，並保存時間同步資訊。這不是 CrowdStrike 公布的一份完整標準欄位清單，而是本文綜合實務風險提出的企業設計建議。

例如一個刪除檔案的要求，工具紀錄顯示 Agent 呼叫 delete_file，仍無法單憑該紀錄認定檔案已刪除。必須檢查工具是否回報錯誤，作業系統有無實際檔案事件，必要時再到雲端儲存服務確認檔案狀態。反過來說，端點看見檔案被刪除，也不必然知道哪一段模型判斷促成這個結果。能把不同層次串接起來，才是關聯分析的價值。

CrowdStrike 的開發者文件提供一個實務線索：Guardian 相關接口可以查詢 Agent 工作階段、工具與 Skill 使用、程序樹、檔案寫入、網路連線，以及不同工作階段的關聯。這表示相關資料不只用於單一視覺介面，也可以在具備必要 API 權限與支援的部署條件下，被整合到安全調查流程。但 API 文件的存在不等於任何用戶都能取得全部資料，實際可用欄位與保留期限仍需驗證。

一個工具呼叫到最後結果，中間可能隔著多層系統

以企業內部的「自動處理客服退費」為假設案例：Agent 讀取客服訊息，透過 Skill 依序確認訂單、比對退款資格，再經由 MCP 連接訂單系統。從對話表面看，可能只剩下一個「已完成退款」的句子。實際上，操作可能分成讀取訂單、取得付款狀態、提交退款請求、等待金流回應、建立客服通知五個不同事件。

其中任何一步都可能出現權限不足、逾時、重複請求、資料不一致或錯誤收件人的情況。Agent 的最終回答，可能比真實系統狀態早一步，甚至與它不一致。如果企業只保存最後回答，很難在事後還原錯誤；如果只保存 API 呼叫，又可能遺漏產生這串操作的原始任務與外部資料。要做真正可用的稽核，必須讓意圖、工具與業務結果能對應起來。

這也提醒我們，端點監控並非唯一資料來源。Windows、macOS 或 Linux 上的本機程序與檔案操作，可以由受管理裝置上的感測器提供強而有力的觀察。但若 Agent 直接呼叫遠端 SaaS API，在端點上看到的可能只是網路請求或客戶端程序；訂單到底有沒有建立、CRM 哪個欄位被更新，還需要服務端 API 日誌與業務資料庫佐證。把「觀察到網路連線」寫成「完整證實雲端交易」會越過證據邊界。

因此，企業真正要設計的是一條跨系統的證據鏈。端點活動提供程序與檔案證據，MCP 或工具日誌提供呼叫過程，業務系統提供狀態變更，身分管理提供權限背景，審批紀錄提供授權依據。沒有任何單一畫面能天然取代其他資料來源。即使新一代 Agent 安全平台能降低調查成本，也不應讓企業停止對業務系統建立必要的原生日誌。

為什麼只依賴 Prompt 防護，仍然可能漏掉危險行為？

提示詞注入（Prompt Injection）是 Agent 特別需要留意的風險。攻擊者未必直接對 Agent 下命令，也可能把指令藏在網頁、文件、搜尋結果或第三方資料中，讓 Agent 在處理正常任務時讀入。若 Agent 把不可信內容誤當成具有權威的操作指令，就可能呼叫本來合法的工具，做出原本不應發生的事情。

MITRE 的公開技術資料已描述「透過 AI Agent 工具呼叫外洩資料」的攻擊方式：惡意引導可以把敏感內容塞進合法工具的輸入參數，藉由寄信、更新文件、操作 CRM 等一般功能把資料送往不應抵達的位置。這提醒企業，資安風險不全是明顯的惡意程式；正常工具被錯誤使用，也可能造成實質損害。

單看 Prompt，可能知道 Agent 收到危險指示，卻無法證實它是否照做；單看網路流量，可能知道連向外部主機，卻不知道是什麼指令促成；單看檔案偵測，可能知道某程序被阻擋，卻無法直接連回 AI 工具呼叫。CrowdStrike 公布的示範，就是嘗試補上這些層次之間的關聯。不過，這不表示任何 Prompt Injection 都可被完整辨識，更不代表觀察紀錄本身就是防護效果的保證。

有些企業把稽核和防堵混在一起。稽核回答「發生了什麼」，控制回答「允許發生什麼」，偵測回答「什麼值得懷疑」，回應則處理「發現問題後怎麼限制損害」。CrowdStrike 主張把這些能力整合在 Falcon Guardian，但治理設計仍應分別驗收。能在事後重建事件，不代表能在事前阻擋；能阻擋一種命令，也不能推論其他所有危險行為都會被擋下。

企業需要的不是更多監視，而是更清楚的責任邊界

談到完整對話紀錄、工具輸入與輸出，下一個問題往往是隱私。AI 工作階段可能包含員工對話、客戶資料、程式碼、內部文件，甚至一時誤貼的密碼或 API 金鑰。如果為了稽核而不加區分地保存全部內容，企業可能把原本零散的敏感資訊集中成一個高價值資料庫。

CrowdStrike 的示範提到，可以在同一張圖上標示工作階段中出現的雲端金鑰與個資風險。這展現安全調查的潛在價值，同時也提高紀錄治理的必要性。企業應先確認哪些事件真的需要保存原文，哪些只需保存遮罩後的參數、雜湊值或證據指標；明確區分資安分析人員、系統管理員與一般主管的讀取權限；並訂定保留、刪除、調閱及例外審批規則。

另一個經常被忽略的問題是證據完整性。如果操作紀錄可以被執行者或一般管理員任意改寫，它的稽核價值就會下降。具體做法可以包括集中紀錄、限制刪改權限、時間同步、事件簽章或雜湊鏈、獨立備份及定期抽樣重播。這些是一般性的稽核工程建議，並不表示 CrowdStrike 已對所有這些機制提供相同的產品保證。

在合規或客訴情境中，「能查到歷程」也不同於「證據必然足以作為法律證明」。日誌是否完整、取得過程是否合法、資料保存政策是否一致，以及事件是否能由其他資料源交叉確認，都會影響可信程度。企業採購任何 Agent 安全產品時，都應要求廠商示範紀錄缺漏、離線情境及保存限制，而不是只看一張漂亮的流程圖。

端點視角很重要，但它不是整個企業 AI 的全知視角

CrowdStrike 的策略優勢來自端點感測器，這是它與只在 AI 對話入口觀察流量的方案不同的地方。但任何安全主張都應帶著適用範圍閱讀。第一，必須確認裝置受到管理、感測器正常運作，以及當下的作業系統、Agent 類型與版本受到支援。第二，某些 Agent 可能在雲端執行，或透過瀏覽器、遠端服務與第三方插件完成任務，未必在同一台受管理裝置上留下完整的程序樹。

第三，Agent 的工作階段不見得總有一對一的對應關係。一個使用者要求可能觸發多個子任務與子 Agent；一個工具呼叫也可能透過佇列或非同步流程，稍後才在其他系統生效。若沒有跨系統識別碼、時間同步和業務結果比對，圖形上的連線可能只是相關性證據，而非每個步驟都可無歧義地認定為因果。

第四，產品功能有正式可用、特定客戶啟用、測試階段與未來規劃等不同狀態。CrowdStrike 在 9 月公告時提及 AI Gateway，並在文章中標示未發布功能仍在開發中，可能變更。企業不能把已公開的 Agent Graph 展示、現有 Hooks 支援，以及規劃中的 Gateway 能力，全部當作今天每位客戶都已取得的同一套功能。若要採購，應逐項索取目前版本、支援矩陣與合約服務範圍。

第五，威脅評分是決策輔助，不是自動判決。高分可能代表有必要優先調查的異常；低分也不能保證 Agent 沒有業務錯誤。報價寄錯版本、退款超過政策、採購單重複建立，都可能造成真實損失，卻未必符合傳統資安威脅模型。這類情境還需要應用層規則、帳務核對、人工覆核與例外處理。

從資安產品走向可稽核的工作流程，企業應如何落地？

許多企業談 AI 治理時，第一件事就是採購工具；但從第一性原理來看，目標不是部署最多監控產品，而是讓重要任務可以被授權、執行、驗證、追查及必要時停止。因此，更有效的順序是先選定高風險流程，再定義誰可以授權、Agent 可以碰哪些資源、哪些行為需要留痕，最後才評估現有日誌是否足夠。

不妨從「自動報價與寄送」這種具體工作開始。企業先把任務分成讀取商品資料、計算價格、生成 PDF、選取收件人、送出郵件及更新 CRM。讀取公開商品資料可能風險較低；修改成交價格、寄送包含客戶資訊的附件，以及更新正式訂單則需要更嚴格的權限或審批。這樣一來，控制點不是建立在模糊的「是否使用 AI」，而是落在真正可能造成損失的操作。

接著，為每一個關鍵動作建立可驗收的證據。寄信需要有郵件服務的訊息識別碼與寄送結果，PDF 需要有文件版本與內容核對，CRM 更新需要有變更前後值及執行身分。若 Agent 有本機下載或執行程式的能力，再補上程序、檔案與網路活動紀錄。不同能力使用不同監控方法，整體以相同任務識別碼串起來，比要求單一工具包辦所有事情更務實。

對涉及金流、刪除資料、大量外寄或正式部署的動作，最好設置人類審批（Human-in-the-Loop）。但審批也必須具體：批准的是哪個訂單、哪份文件、哪批收件人、哪個金額，以及哪段時間內的操作。若只有一個籠統的「同意讓 Agent 自動處理」，很容易讓形式上的批准掩蓋權限過大的問題。

最後，企業可定期安排一次受控測試。模擬 Agent 讀到不可信指令、工具回覆失敗、網路中斷、收件名單錯置或重複執行，檢查三件事：系統有沒有阻止不該發生的操作；日誌能否重建發生過程；營運人員能否復原錯誤。測試應使用無敏感資料的環境與核准帳號，不把危險操作直接放進正式生產流程。

衡量 AI Agent，不能只看省下多少時間

企業導入 Agent 常見的成效指標是完成任務數、縮短工時、節省人力或降低成本。這些數字有商業價值，但假如沒有品質與風險的分母，可能導致錯誤結論。一個 Agent 每天寄出 1,000 封信，不代表它創造了 1,000 次有效接觸；自動更新 100 筆客戶資料，也不代表 100 筆都是正確的。

因此，績效應加入可驗收的操作結果。例如「成功完成且經業務系統驗證的任務比例」、「需要人工補救的件數」、「未經授權的操作被阻擋比例」、「發現異常到完成處置的時間」與「能從任務追到實際結果的紀錄完整率」。這些是本篇提出的管理指標，不是 CrowdStrike 已發布的客戶成效統計。企業可以依流程自行定義分母和抽樣方法，避免把有記錄誤認成零風險。

更成熟的做法是將 Agent 的營運績效與安全績效放在同一個流程檢視，而不是由兩個部門各自報喜。業務部門希望快速完成報價，資安部門希望降低未授權存取，財務部門希望訂單與金額一致；這三個目的原本就不衝突。當資料能證明每次執行的結果，企業才能同時談效率、品質與責任。

對台灣中小企業來說，不需要一開始就建置大型安全平台。即使只有 Google Workspace、Microsoft 365、CRM 或簡單的自動化腳本，也可以先從任務編號、權限分層、操作紀錄與異常通知做起。真正不能省略的是關鍵交易的驗收與撤銷機制。企業規模較大、受監管程度較高或有大量本機 Agent 時，再評估端點與 Agent 之間的深度關聯分析，通常更有明確的採購依據。

企業也應區分「安全事件」和「業務錯誤」的稽核證據。前者可能由可疑程序、惡意網域或憑證接觸引發，後者則可能只表現在訂單金額、核准狀態或客戶通知內容。若風險分類只依賴傳統惡意行為偵測，正常操作也可能造成重大業務損失。好的驗收設計會分別指定技術證據與業務證據，讓調查者知道哪個系統才是該結果的最終事實來源。

當流程跨越多個部門時，證據歸屬也應事先約定。資訊部門負責系統可用性與權限紀錄，流程負責人驗證商業規則，資安部門調查異常操作，內控或稽核單位確認資料足以供事後追查。若事後才分工，往往在事故發生後才發現關鍵欄位根本沒被保存。

接下來值得觀察的，是覆蓋率而不是展示畫面有多完整

CrowdStrike Agent Graph 的意義，是把原本分散在提示詞、工具介面與作業系統之間的線索，嘗試整合成一條可追查的執行路徑。這提供了一個有價值的方向，但產業能否普遍採用，還要看覆蓋率、跨平台整合、效能開銷、紀錄保留、授權費用，以及組織是否真能把這些資料用在事件處理上。

未來的評估不應只問「可不可以看到 MCP 和 Skills」，還應問「能看到哪些 Agent、哪些版本、哪些操作、哪些雲端服務，以及哪些情境會失去連線」。同時，任何產品都需要說明日誌能保留多久、誰能存取敏感提示詞，以及是否能把證據交給獨立的稽核或事件管理系統。這些細節會比單一展示影片，更直接影響企業能否長期使用。

回到最初的問題：AI Agent 真正執行過哪些操作？答案不應由 AI 自己的總結來決定，也不能單靠某一種工具日誌。只有把任務、授權、工具呼叫、端點活動與業務系統結果相互對照，企業才能對一段自動化流程提出可信的解釋。CrowdStrike 這次展示提醒市場，AI Agent 治理的焦點正在從「能不能使用 AI」移到「做過什麼、誰批准、結果如何、如何證明」。

延伸觀點：企業若準備導入 AI Agent，最先需要建立的不是更多提示詞，而是每個關鍵任務的驗收規格與操作證據。 有了這套基礎，監控工具才有明確的工作可做；沒有這套基礎，即使保留大量日誌，也可能無法回答管理者真正關心的問題。

常見問題

Q：MCP 本身會保存所有 Agent 操作紀錄嗎？

不會。MCP 定義工具與資源的連接方式，具體日誌由客戶端、伺服器與部署環境決定。工具呼叫紀錄不等於端點或業務結果紀錄。

Q：Skills 被使用，就代表 Skill 中每個步驟都執行了嗎？

不代表。載入或引用一份 Skill，只能說明 Agent 接觸了某種操作說明；是否真的執行某個命令，還要查看工具與系統事件。

Q：Falcon MCP Server 和 Agent Graph 有什麼差別？

前者讓 AI Agent 透過 MCP 呼叫 CrowdStrike Falcon 的安全功能；後者是 Falcon Guardian 用來關聯 Agent 工作階段與實際執行行為的分析能力。

Q：有了 Agent Graph 就不需要人工審批了嗎？

不是。觀察和追查無法取代授權，尤其是刪除資料、金融交易、正式部署與大量寄送等高影響操作。應同時保留最小權限、人類審批、業務驗收及異常處置機制。

延伸閱讀

如果需要先建立基本觀念，可先讀天地人的〈AI Agent 是什麼？從運作原理、實際案例到企業導入〉；想理解工具介面可參考〈MCP 是什麼？2026 新版協定與企業安全指南〉；若要把權限、責任與證據轉成公司政策，則可延伸閱讀〈AI 治理是什麼？企業落地指南〉。上述文章均為站內知識延伸，與本文的第三方新聞事實查核分開。

主要參考資料

1. CrowdStrike，〈CrowdStrike Agent Graph Shows How Agents Act on the Endpoint〉，2026 年 10 月 30 日。https://www.crowdstrike.com/en-us/blog/crowdstrike-agent-graph-shows-how-agents-act-on-endpoint/
2. CrowdStrike，〈CrowdStrike Falcon Guardian Defines the Next Generation of AI Security〉，2026 年 9 月 1 日。https://www.crowdstrike.com/en-us/blog/falcon-guardian-defines-next-generation-of-ai-security/
3. CrowdStrike，Falcon Guardian 開發者文件，查閱於 2026 年 11 月 2 日。https://developer.crowdstrike.com/falcon-mcp/modules/guardian/
4. Model Context Protocol，2026 年版 Tools 規格。https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/docs/specification/2026-07-28/server/tools.mdx
5. OpenAI Developers，MCP Server 與 Plugins 概念說明。https://developers.openai.com/plugins/concepts/mcp-server
6. MITRE D3FEND，〈Exfiltration via AI Agent Tool Invocation〉，查閱於 2026 年 11 月 2 日。https://d3fend.mitre.org/offensive-technique/attack/AML.T0086/
7. CrowdStrike Developer Center，Falcon MCP 產品文件。https://developer.crowdstrike.com/falcon-mcp/

編輯說明：本文以截至 2026 年 11 月 2 日可取得的公開資料撰寫。CrowdStrike 產品功能、示範案例與成效宣稱均明確歸屬原發布單位；企業場景與管理指標是本文所提出的假設與建議，不代表該公司客戶的實際部署成果。本文不構成特定產品的採購保證或法律意見。

製作說明：本文由 AI 協助整理公開資料與編排，已進行來源核對；未進行獨立產品實測或外部專家審查。