Meta AI Agent 真實出包拆解：5 個工程師立刻能畫的 boundary check

Self-validated：本文 reference 實作來自我（Maki）自家在跑的個人 PKI（mk-brain / ERIKA Bot / Inbox Bot 等），不是 enterprise production case study。Code snippet 為 reference 設計，非實際在跑的版本（個別實作會因環境調整）。

開場：那不是 AI 的錯

2026 Q1，三件事在繁中工程社群同時發酵。

第一件：Meta AI Agent 在內部論壇自己發文做資料分析，多起 Sev1 事故。內部 retro 結論：「不是 AI 太笨，是人太信 AI 建議。」

第二件：Anthropic 官方 Git MCP server 在 2 個月內被揭露三個 CVE（CVE-2025-53110、CVE-2025-53109 等）——prompt injection 直接繞路徑限制覆寫 / 刪除檔案。

第三件：Perplexity Comet AI 瀏覽器零點擊漏洞——攻擊者藏 prompt 在網頁，AI 讀了就執行。Zenity 揭露時，繁中圈技術人才驚覺「我用了好幾個月完全沒想過這個 attack surface」。

TrendMicro 2026 趨勢報告下了結論：「最可怕的內鬼不是人，是你親手訓練的 AI Agent。」

但這句話有個問題——它沒告訴你怎麼辦。

痛點：你不是資安人，但這也是你的事

繁中圈幾乎所有「給工程師的 AI 安全教材」都跳過你。

要嘛它假設你是資安專業（OWASP / SIEM / 紅藍隊 / OSCP）。 要嘛它給管理層看的合規介紹（嚇人但不可執行）。 要嘛它停在「prompt injection 是什麼」的科普層。

中間這個位置——會寫 code、在 build LLM 應用、但不是資安專業的工程師 / PM / TPM——空白。

我們 vent 的話圈內人都聽過：

• 「公司 ban 了 Cursor / Claude Code，但我私下 side project 還是狂用，怕出事又不知道怎麼設邊界。」
• 「公司要我們搞 RAG 但完全沒人在意 source 可信度。」
• 「我讓 AI Agent 讀 email 結果中 prompt injection。」
• 「看完 Anthropic MCP CVE 想 harden 自己的 server，但完全不知從何下手。」

這些不是「資安團隊的事」，是 build AI 的人自己要懂的。

[BensonTWN 在 X 上有句精確的概括][1]：

輸入來源決定風險高低。你自己產生的內容 → 安全；別人可以寫入的內容 → 危險。

整個 AI 安全的設計，可以被 distill 為畫對五道邊界。

五道邊界：你回 codebase 該改什麼

接下來每一道邊界，都用同一個格式：case → rule → mitigation table。最後一欄是 validated in (reference)——不是書上的 best practice 清單，而是方便你直接回 codebase 對照的 reference 設計。

Boundary 1 — Trust Boundary（信任邊界）

Case：

主：Perplexity Comet 零點擊漏洞（Zenity 2025-08 揭露）。攻擊者把 prompt injection 藏在網頁註解 / CSS / SVG metadata，user 訪問該頁時瀏覽器 AI 讀進 context，直接執行攻擊者的 instruction——不需 user 點任何東西。iThome 2026-03 中文報導稱此為「AI 瀏覽器零點擊漏洞」，可被用於竊取密碼管理器內容。

次：BensonTWN 在 X 的工程師清單（2026 Q1 熱帖）：

✅ 自己 repo / 爬蟲 / 本地檔案管理 → 安全 ❌ email、社群聊天、user upload → 危險

輸入來源決定風險高低。你自己產生的內容 → 安全；別人可以寫入的內容 → 危險。

核心問題：什麼時候 input 變成 instruction？

Rule：永遠假設外部 input 是不可信的——即使它看起來只是 data。LLM 不會自動區分 "this is instruction" 和 "this is data"，要靠你在 system layer 做。

Reference 實作（示意非 production code，依你環境調整）：<!-- Reference 實作（示意非 production code，依你環境調整） -->

# Untrusted source labeling — 給 LLM 前統一包裹外部內容
def wrap_untrusted(content: str, source_id: str) -> str:
    """所有外部內容（網頁/email/user upload/RAG retrieval）統一走這裡"""
    return (
        f'<untrusted source="{source_id}">\n'
        f'{strip_zero_width_and_hidden(content)}\n'
        f'</untrusted>'
    )

def strip_zero_width_and_hidden(text: str) -> str:
    """移除零寬 codepoints + LaTeX eval macro"""
    import re, unicodedata
    text = unicodedata.normalize("NFKC", text)
    text = re.sub(r"[​-‍⁠]", "", text)
    text = re.sub(r"\\(eval|system|exec)\{[^}]*\}", "", text)
    return text

對應 OWASP：LLM01 Prompt Injection / ASI01 Agent Goal Hijack。

Boundary 2 — Data Boundary（資料邊界）

Case：

主：PoisonedRAG 學術論文（2024，arXiv）——實證5 個惡意文件注入到 RAG 知識庫即可達到 90% 目標查詢的操控率。Indirect prompt injection 經由 RAG context 進入 LLM 流程，被 AI engine 答覆中當「事實」呈現。

次：DeepMind Agent Traps 論文（2026，圈內傳閱中）——0.1% 資料投毒可讓 80% 查詢歪掉。意味著就算你公司 Confluence / Notion / Slack 知識庫只有極小比例被植入惡意內容，整個 AI 客服或內部 RAG 助手會大規模產出錯誤答案——而多數團隊半年沒有任何 audit / 偵測機制。

核心問題：你的 RAG context 裡有沒有「llm_derived 的污染源」混進「raw_source」當事實？

Rule：每個 chunk 必須帶 provenance tier 標籤——不能讓 LLM 自己生的內容再餵回 training/RAG（Ouroboros effect，arXiv 2509.10509 已實證）。

Reference 實作（示意非 production code，依你環境調整）：<!-- Reference 實作（示意非 production code，依你環境調整） -->

# Provenance tier system — 防 RAG 投毒 + Ouroboros
from enum import Enum
from pydantic import BaseModel, Field

class SourceTier(str, Enum):
    raw_source = "raw_source"           # 網頁、webhook 原始
    llm_derived = "llm_derived"         # LLM 產的 summary
    human_confirmed = "human_confirmed" # 人類覆核過

class MemoryEntry(BaseModel):
    content: str
    source_tier: SourceTier
    upstream_ids: list[str] = Field(default_factory=list)
    provenance_hash: str  # HMAC(content + tier + upstream_ids)

def retrieve_for_rag(query: str) -> list[MemoryEntry]:
    """RAG 檢索時不讓 llm_derived 進 production answer 的 context"""
    candidates = vector_search(query, top_k=20)
    return [c for c in candidates if c.source_tier != SourceTier.llm_derived]

對應 OWASP：LLM02 / LLM04 Data Poisoning / LLM08 Vector & Embedding Weaknesses / ASI06 Memory & Context Poisoning。

Boundary 3 — Privilege Boundary（權限邊界）

Case：

主：Anthropic 官方 Git MCP server CVE-2025-53110 / CVE-2025-53109（Red Hat 2026-02 深度分析）。Server 給 LLM 「讀寫 repo」權限，prompt injection 一中，LLM 直接幫攻擊者覆寫 / 刪除檔案繞過路徑限制。Anthropic 自家官方實作都中招，反映 Lethal Trifecta（tools + data + autonomy）在 builder 層的隱性風險。

次：Meta AI Agent 多起 Sev1 事故（2026 Q1，繁中工程社群轉發討論）——AI 自己去內部論壇發文做資料分析，敏感資訊外洩。內部 retro 結論被廣傳：「不是 AI 太笨，是人太信 AI 建議。」

核心問題：你的 agent 同時擁有「敏感資料 access」+「外部執行 channel」+「自主決定權」嗎？

Rule：[Simon Willison 命名為 Lethal Trifecta][2]——這三件事不能同時給同一個 agent。三選二。中文我建議叫「致命三叉」（Letal Trident），方便 zh-TW 圈引用。

Reference 實作（示意非 production code，依你環境調整）：<!-- Reference 實作（示意非 production code，依你環境調整） -->

# Lethal Trifecta gate — tools + sensitive data + autonomy 三選二
from pydantic import BaseModel

class AgentPolicy(BaseModel):
    has_tools: bool          # 能呼叫外部工具
    has_sensitive_data: bool # 能讀 PII / credential / 私訊
    has_autonomy: bool       # 自主決策不需人類 approval

    def is_lethal_trifecta(self) -> bool:
        return self.has_tools and self.has_sensitive_data and self.has_autonomy

def assert_safe_agent_config(policy: AgentPolicy):
    if policy.is_lethal_trifecta():
        raise PermissionError(
            "Lethal trifecta detected. 必須砍其中一項——"
            "通常加 human approval gate 砍 autonomy。"
        )

# 範例：能讀 email 又能寫信的 agent，砍 autonomy 加 approval
agent_policy = AgentPolicy(
    has_tools=True,
    has_sensitive_data=True,
    has_autonomy=False,  # 寫信前必須人類 approve
)
assert_safe_agent_config(agent_policy)

對應 OWASP：LLM06 Excessive Agency / ASI03 Identity & Privilege Abuse / MCP02 Privilege Escalation。

Boundary 4 — Context Boundary（脈絡邊界）

Case：

主：ZombieAgent attack technique（2026-01 LinkedIn 安全社群揭露）——研究者展示 AI agent 透過 memory / context layer 的持續資料洩漏（persistent data leakage）。即使對話結束、session 結束、agent 重啟，毒已經種在 vector store 裡，下一次 query 仍會被污染。

次：你的 RAG 知識庫被污染半年——完全不知道。沒人 audit、沒 alert、沒監控。直到客戶投訴「你的 AI 客服說了奇怪的事」才發現。這是 zh-TW 工程社群最常 vent 的 sentiment：「公司搞 RAG 但完全沒人在意 source 可信度」。

核心問題：怎麼deterministic 早期偵測而不靠盯 dashboard？

Rule：Canary Tokens（中文我建議叫「哨兵令牌」）。在你的記憶體 / RAG 庫塞一個「絕對不該出現在 LLM output」的隨機字串，例如 MK_CANARY_<random>。output 偵測到 canary echo → fail-closed + log。

Reference 實作（示意非 production code，依你環境調整）：<!-- Reference 實作（示意非 production code，依你環境調整） -->

# Canary tokens — deterministic 早警，不靠盯 dashboard
import secrets

CANARY_PREFIX = "MK_CANARY_"

def plant_canary(namespace: str) -> str:
    """每個 RAG namespace 至少種一顆 canary"""
    canary = f"{CANARY_PREFIX}{secrets.token_hex(8)}"
    db.insert(MemoryEntry(
        content=f"Canary marker: {canary}",
        source_tier="canary",  # 不會被 RAG 正常 surface
        upstream_ids=[],
        provenance_hash=hmac_sign(canary),
    ))
    return canary

def detect_canary_leak(llm_output: str, known_canaries: list[str]):
    """LLM output 偵測到 canary echo → fail-closed"""
    for canary in known_canaries:
        if canary in llm_output:
            log_incident(f"CANARY LEAK detected: {canary}")
            raise SecurityError("RAG 被污染或 LLM exfil canary")

對應 OWASP：LLM08 / LLM09 / ASI06。

Boundary 5 — Attack Surface Boundary（攻擊面邊界）

Case：

主：VS Code AI 延伸套件 source map 洩漏（150 萬安裝量，2026 Q1 揭露）——擴充套件被抓到把 source map 連同敏感資訊一起暴露，攻擊面從「LLM 本體」轉移到「LLM 周邊工具鏈」。OWASP MCP Top 10 的 MCP04（Software Supply Chain）正是針對此類風險。

次：台北捷運 AI 客服被玩成 code generator（prompt injection 經典案例，2024 至今仍被當警示）。Localhost 沒鎖、tool API 沒 auth、prompt 沒 hardening——三個小漏洞合起來變成完整 RCE chain。TrendMicro 2026 趨勢報告為此類事件定調：「最可怕的內鬼不是人，是你親手訓練的 AI Agent」。

核心問題：你給 model 多大 autonomy？最小 auth 該怎麼設？

Rule：所有本機 agent 服務預設 127.0.0.1 不 0.0.0.0。所有 LLM tool API 必須HMAC + replay window（OneUptime 2026-01 canonical pattern）。

Reference 實作（示意非 production code，依你環境調整）：<!-- Reference 實作（示意非 production code，依你環境調整） -->

# HMAC + replay window — LLM tool API 最小 auth
import hmac
import hashlib
import time

REPLAY_WINDOW_SECONDS = 300

def verify_request(
    body: bytes,
    signature_header: str,
    timestamp_header: str,
    key: bytes,
) -> bool:
    # 1. Replay window
    ts = int(timestamp_header)
    if abs(time.time() - ts) > REPLAY_WINDOW_SECONDS:
        return False

    # 2. Constant-time HMAC compare
    expected = hmac.new(
        key,
        f"{ts}.{body.decode()}".encode(),
        hashlib.sha256,
    ).hexdigest()
    received = signature_header.replace("sha256=", "")
    return hmac.compare_digest(expected, received)

對應 OWASP：ASI02 Tool Misuse / MCP01 Token Mismanagement / MCP05 Command Injection。

中文 concept naming 提案（zh-TW canonical）

繁中圈現在 AI 安全 concept 大多直譯英文。如果這個 niche 要長期由 zh-TW dev 自己命名，我提案以下中文：

引用本文時 zh-TW 圈優先使用以上命名。

對應 OWASP（你看完該怎麼讀清單）

2026 年 OWASP 有三份清單並行——大多 dev 看完三份還是不知道從哪下手：

• OWASP LLM Top 10:2025（10 項）
• OWASP Top 10 for Agentic Applications 2026（ASI01-10）
• OWASP MCP Top 10 (beta)（MCP01-10）

Builder 視角優先序（如果你這週要開始）：

1. LLM01 / ASI01 Prompt Injection / Goal Hijack → Boundary 1 處理
2. LLM06 / ASI03 Excessive Agency / Identity Abuse → Boundary 3 處理（致命三叉）
3. LLM08 / ASI06 Vector Weaknesses / Memory Poisoning → Boundary 2 + 4 處理（provenance + canary）
4. MCP01 / MCP05 Token / Command Injection → Boundary 5 處理（HMAC）
5. LLM07 System Prompt Leakage → Boundary 1 的 canary detection

剩下的 (Misinfo / Output Handling / Supply Chain / Unbounded Consumption) 雖重要但不是 architecture review 該優先抓的——這 5 道邊界先畫對，再回頭補。

結尾：邊界畫對，AI 越強你越值錢

每一篇技術文章都會帶 self-validated reference table——不是書上抄，而是讓你直接回 codebase 比對的版本。

下一篇預告：「Anthropic Git MCP CVE-2025-53110 拆解：你的 MCP server 怎麼 scope」——MCP01-05 對 builder 的具體含義。

如果你想繼續看：

• 直接訂閱 boundary.ranran.tw（持續更新中）<!-- (boundary.ranran.tw)（持續更新中） -->
• 或回我訊息——告訴我你公司現在卡在哪一道邊界，下篇主題會優先排你的場景

邊界實驗室不教你打仗，教你畫線。AI 越強，畫對線的人越值錢。

[1]: BensonTWN X 帖（2026 Q1） [2]: Simon Willison, "AI Security in 2026: Prompt Injection, the Lethal Trifecta..."（airia.com 2026-01）