← 部落格

這是提示注入嗎？不是——原因在此

2026-07-19 · 部落格 · prompt-injectionsecurityconsent

敏銳的人對操作層問的第一個問題就是對的那個：「一個網站告訴我的 AI 該做什麼，不就是提示注入嗎？」它值得一個直接的答案，因為這個差別不是細微末節——它就是整套設計本身。

提示注入究竟是什麼

提示注入是一種攻擊。指令被藏在內容裡——白色文字、埋藏的 HTML、一份下了毒的文件——好讓代理在用戶不知情、也未經用戶同意的情況下執行它們。三個定義性的特徵：

1. 隱藏。 用戶從來看不到那道指令。
2. 劫持。 它服務的是攻擊者的目標，凌駕於用戶的目標之上。
3. 未經同意。 它未經許可就執行。

每一個嚴肅的代理平台，都針對這個模式建立了防禦。理當如此。

操作層是什麼

一個操作層是一份發佈出來、機器可讀的脈絡，由服務公開提供——是 robots.txt、sitemap.xml 和 llms.txt 的手足——讓用戶自己的 AI 代理在用戶允許下，替他們採用並操作這項服務。逐一特徵來比對：

1. 公開發佈。 它位在一個已知的公開位置，任何人都讀得到——用戶、代理、稽核者、競爭對手。沒有任何東西被藏起來。
2. 服務用戶的目標。 用戶派他的代理去完成某件事——註冊、購買、設定。操作層是發佈者在幫助用戶自己的任務成功，完全依照發佈者為用戶的代理所定義的方式。
3. 同意把關。 代理把操作層呈現給它的用戶，並在行動前先問。一句「好」就授權——一次性或逐項操作。見同意閘門。

注入藏起指令，以劫持代理去對付它的用戶。操作層則發佈協助，讓代理呈現給它的用戶。它們在每一個重要的軸線上都是相反的。

一個網路早已信任的類比

robots.txt 是一個網站在告訴爬蟲該做什麼——而沒有人稱它為攻擊，因為它是開放的、標準化的，並且與爬蟲想要的行為方式對齊。sitemap.xml 告訴引擎該索引什麼。llms.txt 告訴 AI 該讀什麼。操作層把同一個受信任的模式再往前延伸一步：經同意把關、而且是可操作的，不只是描述性的。

網路一直都是這樣運作的。發佈者宣告；行為端正的用戶端讀取那份宣告，並在它們自己的規則內行動。

錄下的測試顯示了什麼

在錄下的測試場次中，各家獨立的 AI 助理擷取了一個發佈的操作層，並呈現出同意問題。那個觀察僅限於那些場次，並不證明這個格式是安全的、普遍相容的，或對提示注入和授權風險免疫。

公開發佈和明確確認，讓來源和權威更容易評估。每一個助理仍必須套用它自己的規則、驗證所請求的動作，而且可能拒絕。

防護仍然重要

透明加上同意是核心防禦，但一個建構良好的操作層還會在上面加上紀律：它宣告能力，而不是發號施令；它把每一項操作都保持在六個通用類別（評估、註冊加入、交易、設定、使用、管理）之內；而且它從不要求代理去做用戶批准範圍以外的事。服務控制圖說明每項操作如何被觸發——API 端點、函式／動作、介面控制項——附上輸入、順序和預期結果，讓代理沒有可以誤讀的模稜兩可之處。操作如何被對映，涵蓋在 /how-it-works。

為什麼這對發佈者很重要

信任是一個採用因素。用戶能評估他們看得到的指引，而代理必須套用它們自己的防護措施。我們發佈的每一個操作層，都由建構過程遵循透明與同意的模式——從免費方案的單一網址，到基本方案（每月 $29）涵蓋你網域上最多 10 組網址。

隱藏的指令和公開的廠商指引，帶來的是不同的風險。透明和確認能減少模稜兩可；它們並不能消除攻擊、混淆代理人（confused deputy）、惡意端點或授權方面的風險。

常見問題

攻擊者能濫用操作層格式嗎？

這個格式被設計成讓濫用變得沒有吸引力：操作層的力量來自同意，而任何被發佈的東西，在任何事情發生之前都會呈現給用戶。開放和同意閘門大幅降低了藏匿指令的價值——它們並不能讓攻擊變得不可能，這正是為什麼代理平台會保留它們自己的防禦，也是為什麼用戶在說「好」之前，仍應檢視代理所提議的內容。

為什麼代理會遵從、而不是忽略操作層？

錄下的場次顯示，這些助理擷取了操作層並呈現出同意步驟。其他助理或往後的版本，可能會忽略、警告、誤解或拒絕它。

每一次都會發生同意嗎？

同意閘門兩種模式都支援：採用一項服務的一次性授權，或針對個別動作的逐項操作批准。發佈者宣告；用戶的代理和用戶做決定。

繼續閱讀

https://swma.link/f32a90e2