AI RADAR DAILY 2026-07-15 — Agent資安與無向量RAG崛起
今天這份清單讀完，最清楚的訊號不是「又多了幾個 coding agent」，而是 Agent 真正要上線時，安全與可驗證性突然變成第一優先。半數以上專案直接打在 prompt injection、MCP 流量、egress 外洩、runtime 攔截與可驗證收據上；同時，檢索端出現明確的無向量路線，PageIndex 用層級樹與推理搜尋取代「靠相似度碰運氣」。一句話：生態正在從「能生成、能呼叫工具」切到「能控管、能審計、能可靠找回答案」。若你的團隊還把 Agent 資安當上線後再補的 checklist，今天這份清單會告訴你——那條路已經來不及了。
一、今天的趨勢
第一個洞察是：Agent 資安正在從「事後審計」轉成「即時攔截 + 可驗證收據」。過去一年大家常見的作法，是看 log、跑 pen-test、出事再追；但當 Agent 具備 shell、瀏覽器、MCP 工具與環境變數中的 API key 時，單一惡意工具呼叫就可能把金鑰打出去。今日清單裡的 pipelock、Adrian、api-relay-audit 都在回應同一個現實——威脅發生在「工具實際被呼叫的那一瞬間」，因此防火牆必須坐在 egress 與 MCP 邊界上，而不是只存在於合規報表裡。NSA 與產業聯盟對 MCP 安全設計的持續關注，也印證這不是少數專案的焦慮，而是基礎設施層的共識。
第二個洞察是：MCP 已成為攻擊面與防禦面的交會點。多個專案專門做 MCP 流量掃描、SSRF 防護、工具描述投毒偵測、對手模擬與紅隊。企業若要部署 Agent，不能只問「接了哪些模型」，必須先做 egress 白名單、工具呼叫治理、以及「這個 MCP server 是否可被信任」的盤點。agent-opfor 把 OWASP LLM / Agentic AI / MCP Top 10 收進同一套對手模擬，本身就是訊號：紅隊已經把 MCP 當成一級目標，而不是附屬選項。
第三個洞察是：生態同時在補「可靠檢索」與「可審計工作區」。PageIndex 推無向量、推理導向的文件索引；oh-my-pi 強化終端 coding agent 的工具 harness 與 LSP 深度整合；h5i 則把每個 Agent 丟進可沙箱、可稽核的 Git worktree，並記錄 prompt、指令與審核軌跡。這三條線合在一起，說明市場不再滿足於 demo 級生成——企業要的是可追溯的檢索、可重現的工作區、以及出事時能拿出證據的系統。
二、Top 8 工具
#1 ifixai-ai/iFixAi（Score: 5.0，AI Agent）
用途：在五分鐘內對 AI Agent／部署跑一組對齊與風險檢查，輸出 A–F 字母成績與分項記分卡。核心 32 項檢查涵蓋 fabrication、manipulation、deception、unpredictability、opacity 五大支柱，另有 13 項 frontier 延伸（含 sabotage、sandbagging、oversight evasion 等）。支援 CLI 嚮導、顯式旗標與 Claude Code／Codex plugin；評分預設由不同廠商的 judge 完成，避免自我評分。評語：這不是「又一個 prompt 測試腳本」，而是把營運失準（operational misalignment）產品化成可重跑、可進 CI 的診斷。適合上線前做基線，也適合當漂移訊號。若你連「現在的 Agent 到底偏到哪裡」都講不清楚，先跑這支比再堆工具有用。
#2 luckyPipewrench/pipelock（Score: 4.8，MCP）
用途：開源 AI Agent 防火牆，坐在 Agent 與網路之間，掃描 HTTP、WebSocket、MCP、A2A 等中介流量，攔截憑證外洩、prompt injection、SSRF 等，並發出可離線驗證的 mediator-signed action receipts。內建大量 credential 與 injection pattern，支援 process sandbox（Linux Landlock／seccomp、macOS sandbox-exec），也可 wrap MCP server。評語：這條路的價值在「決策有內容感知的收據」——不是只記 log，而是第三方能驗證「當下實際過界的內容與裁決」。企業要做 egress 與工具呼叫治理，pipelock 是少數把 VEC（Verifiable Egress Control）講清楚並開源落地的專案。
#3 secureagentics/Adrian（Score: 4.5，MCP）
用途：開源 runtime 安全監控與控制引擎，同時看 Agent 的行為 log（工具呼叫、輸出）與 reasoning traces，在惡意工具使用、prompt injection、policy drift 真正落地前介入。提供 Python（LangChain／LangGraph）與 TypeScript SDK，可走 managed dashboard 或完全 self-host。評語：多數監控停在「它呼叫了什麼」；Adrian 強調還要理解「為什麼要呼叫、下一步想幹嘛」，這與近年行為＋推理聯合監控的研究方向一致。適合已有 Agent 產線、需要 runtime 關卡而非只做靜態掃描的團隊。
#4 toby-bridges/api-relay-audit（Score: 4.7，AI Security）
用途：本地執行的 AI API 中繼／LLM proxy 安全審計，偵測 prompt injection、model substitution 訊號、tool-call 改寫、SSE 異常、錯誤外洩，以及 Web3 wallet 相關風險。以 Python 腳本為主，API key 只送往你指定的 relay URL，產出可審閱 Markdown 報告與 LOW／MEDIUM／HIGH 結論；另提供 OpenClaw／Hermes skill 整合。評語：第三方 relay 與「相容代理」是 2026 很現實的供應鏈面。這工具不自稱認證安全，而是給你可重跑的本地證據邊界——在把 production 或錢包相關流量丟進陌生 proxy 之前，至少先有一份報告。
#5 can1357/oh-my-pi（Score: 4.8，MCP）
用途：功能完整的終端 AI coding agent（Pi 的 fork 強化版），強調 hash-anchored edits、優化 tool harness、LSP／DAP 整合、Python／browser、subagents 等。多 provider、多內建工具，編輯格式與重試迴圈針對實際模型行為調校，目標是「第一次就改對、少燒 token」。評語：在資安主題佔半壁江山的今天，oh-my-pi 提醒另一半現實——開發者仍需要高可靠的終端 coding surface。它代表生態在「能寫」這一側繼續硬化 harness，與「能控」那一側並行，而不是互相取代。
#6 KeyValueSoftwareSystems/agent-opfor（Score: 4.3，MCP）
用途：針對 AI Agent 與 MCP 的對手模擬（OPFOR）框架，覆蓋 OWASP LLM Top 10、Agentic AI Top 10、MCP Top 10 等 suite；支援 CLI、瀏覽器擴充、MCP server、IDE skills 與 SDK。可對 prompt、tools、memory、multi-turn 做紅隊，並以 LLM judge 產出 HTML／JSON 報告；另有 trace-aware 整合（如 Langfuse）以看內部工具軌跡。評語：防禦堆再厚，沒有紅隊就只是感覺安全。agent-opfor 把「像真攻擊者一樣打」產品化，且入口含非工程職也能用的瀏覽器路徑，適合把紅隊從安全團隊特權變成跨職能例行。
#7 h5i-dev/h5i（Score: 4.3，MCP）
用途：可審計的 AI coding agent 工作區：每個 Agent 一個 sandboxed Git worktree，記錄 prompts、commands、logs、policies 與 reviews；支援 conflict-free multi-agent orchestra，並聲稱可大幅降低 token 浪費。證據以 `refs/h5i/*` 留在 repo 內，不依賴 SaaS。評語：多 Agent 同時改同一 repo 最容易變成互相覆寫與無法稽核的黑箱。h5i 把「隔離 + 版本化證據 + 審核後再 merge」做成預設流程，對 platform／DevEx／安全負責人特別有用——你要的不是更多 Agent，而是 diff 仍可被辯護。
#8 VectifyAI/PageIndex（Score: 5.7，RAG）
用途：無向量、推理導向的文件索引 RAG：把長文件建成層級樹（類似目錄樹），再以 LLM 在樹上做 reasoning／tree search 檢索，強調可追溯、可解釋，無需 vector DB 與人工 chunking。在 FinanceBench 等專業文件場景有高準確率宣稱，並有 self-host、MCP／API 與 agentic demo。評語：今日清單裡它是「檢索範式」的代表作。當專業文件要的是 relevance 而非 similarity，「丟掉向量、改靠結構與推理」不再只是論文口號。若你的 RAG 卡在長 PDF、法規或財報，這條線值得認真對照既有 pipeline。
三、今日首選：ifixai-ai/iFixAi
今日首選給 ifixai-ai/iFixAi，理由很務實：在防火牆、紅隊、中繼審計都變多的同時，多數團隊仍缺一個「五分鐘內講清楚風險字母成績」的入口。iFixAi 的定位是 operational misalignment 診斷——抓的是 KPI 上看不到、卻會變成客訴、資安事件或監管問題的行為：捏造引用、被誘導越權、長對話人格漂移、決策不可重現、沒有審計軌跡等。
它的產品設計有幾個值得肯定的點。第一，檢查分層清楚：32 項核心對應五大支柱，延伸項覆蓋 frontier agent 風險，headline grade 與 exploratory 信號分開，避免把所有結果糊成一個「安全分」。第二，評分角色分離：SUT 與 judge 預設不同廠商，Full 模式可 ensemble，這比「自己模型評自己」可信得多。第三，輸出是工程可用的：JSON／Markdown、content-addressed manifest、可進 CI 的重跑路徑，並且誠實標示它不是認證、不是 safety guarantee，而是可重現的 diagnostic。
更重要的是使用時機：企業部署 Agent 前，應該先回答「我們現在偏到哪裡、哪一柱最弱」，再決定要先上 egress 防火牆、runtime 監控，還是紅隊。iFixAi 適合當第一刀基線；拿到字母成績與分項後，再用 pipelock／Adrian 補邊界、用 agent-opfor 打洞、用 h5i 管工作區。把診斷、防禦、紅隊串成閉環，比單點工具堆疊更接近可落地的治理。
四、評分方式說明
AI Radar 分數綜合多維訊號，而非單一 star 數。主要面向包括：與當日主題的相關度與時效性、問題定義是否對準真實痛點、技術路線是否可驗證（有 benchmark、收據、報告或可重跑流程）、開源可用性與文件完整度、以及是否具備可複用的工程入口（CLI、SDK、MCP、CI）。分數接近代表各有取捨：高分通常表示「今天就該看、且能動手驗證」；較低分不代表品質差，可能是範圍更窄、成熟度仍在爬升，或對多數讀者屬補強角色。閱讀時請以用途與風險面為主，分數只是排序輔助。
結語與 CTA
Agent 落地加速後，安全不再是加分項，而是能不能上線的門檻；無向量 RAG 則提醒我們：可靠檢索比炫技生成更決定業務價值。建議今天就挑一條線動手——先用 iFixAi 量基線，或把 pipelock／PageIndex 接到現有流程做小範圍驗證。歡迎回覆你最在意的痛點（egress、MCP、紅隊或長文件檢索），下期 Radar 會依現場需求加深追蹤。