跳至主要内容

FAQ

XecGuard 產品概覽 (Overview)​

XecGuard 是什麼？

XecGuard 是由 CyCraft 所開發的 AI 安全防護 Guardrail APIs，專為防禦各類針對大型語言模型（LLM）的 Prompt Attacks 而設計。它能即時檢測與分析惡意對話內容，並提供完整的 LLM Safety 防護能力，包括 Prompt Injection Protection、Prompt Extraction Protection、System Prompt Enforcement、Harmful Content Protection、Malicious Skills Protection、Sensitive Data Protection，以及 Custom Policy 自訂安全策略。XecGuard 特別適用於 AI Agent 與各類 AI 應用場景，可有效防止來自外部的惡意輸入，例如 Prompt Injection 或攻擊型留言，避免模型被誘導產生錯誤、偏離任務，甚至做出有害行為，進一步提升整體系統的安全性與可信度。

XecGuard 在 AI 安全架構中扮演什麼角色？

XecGuard 是 AI 安全體系中的關鍵防護組件，主要用來補強傳統安全工具難以處理的語意層級攻擊風險。它可部署於 User Input 與 Assistant Response 之間，分別針對使用者輸入與 LLM 回應進行即時安全分析，協助企業偵測 Prompt Injection、Prompt Extraction、越權指令、敏感資料外洩，以及不符合企業政策的內容風險。
在 AI Agent 應用情境中，XecGuard 可協助確保 Agent 的執行流程不被惡意指令操控，並檢查輸出內容是否符合企業定義的任務範圍、角色邏輯與限制條件。透過語意層級的檢測與阻擋，XecGuard 能降低 AI 應用被濫用、誤導或誘導產生不當行為的風險。
但 XecGuard 並不會取代企業整體安全治理機制。企業仍應結合提示詞設計、身分與存取控管、權限最小化、流量監控、DLP、日誌稽核與人工審查流程，建立完整的 AI 安全防護架構。

XecGuard 是通用語言模型，還是專用 Guardrail 模組？

XecGuard 是基於語言模型技術微調與優化而成的專用 Guardrail 模組，並非通用型聊天模型，也不是 RAG 系統。
它的核心角色是作為 AI 應用前後端的「安全警衛」，負責檢查使用者輸入、模型輸出或相關內容是否符合企業安全規則與治理政策，並判斷是否允許通過。XecGuard 的目的不是與使用者對話、生成文章，或回答一般性問題，而是專注於偵測、判斷與防護。
XecGuard 採用 API 模式運作，重點在於即時檢測與阻擋風險內容，而不是改寫內容。因此，XecGuard 不會自動將使用者輸入改寫成無害版本，也不會替應用程式決定最終回應方式。當偵測到風險時，應用程式可依照自身產品邏輯、企業政策或使用者體驗設計，決定要阻擋、提示、記錄、轉交人工審核，或採取其他處理方式。

甚麼是 XecGuard CSP 社群回饋計畫 (XecGuard Community Support Program)？

XecGuard Community Support Program 的設立，旨在支持並推動 AI 開發者社群打造更安全的應用。我們觀察到，當前開發者社群在 AI 領域的創新與發展速度極快，但相對而言，安全機制往往未被同等重視。因此，本計畫不僅提供實質資源支持，更希望倡議一個核心理念：「AI 的 Safety 應該是標配，而不是選配」。唯有在設計之初即將安全納入核心架構，AI 系統才能真正走向可長期信任與規模化發展。 凡符合資格的開源專案維護者與貢獻者，將可獲得為期三個月的 XecGuard Lite API 免費訂閱，於計畫期間內無需支付任何費用。透過這項支持，我們希望降低開發者導入 AI 安全機制的門檻，使更多開源專案能夠在快速創新的同時，兼顧安全與穩定性。詳細申請資格與使用規範，請參閱服務條款說明。

XecGuard Policy 與規則設計 (Policy)​

XecGuard 能執行未寫在 System Prompt 的全域規則嗎？

XecGuard 支援企業設定全域規則（Global Policy），即使這些規則未寫在各別 AI Application 的 System Prompt 中，也能優先被檢測。
這讓企業可以更彈性地管理 AI 行為，例如禁止提及特定主管姓名、公司名稱或產品名稱等。

當 System Prompt 與 XecGuard Policy 衝突時，如何判定？

XecGuard 會對每條 Policy 獨立執行檢查，不處理 Policy 之間的相依關係。
所設定的 Policy 每一個模組都會執行檢測，只要任一條 Policy 被判定違反，API 就會回傳 UNSAFE，並指出違反了哪些規則。至於最終要如何回應，則由使用者的應用程式依照自身場景決定。

Guardrail Policy 與 System Prompt 應如何區隔與分工？

Guardrail Policy 適合用來定義高階、企業級的安全政策，主要描述 AI 應用「不能做什麼」或「必須避免哪些風險」。例如：禁止處理特定類型內容、禁止輸出違反企業政策的資訊、禁止洩露敏感資料，或禁止執行特定高風險行為。
如果規則內容是在描述 AI 應用「應該做什麼」，例如任務目標、角色設定、回答格式、業務流程、操作步驟或細節條件，則更適合寫在 Application 的 System Prompt 中。
簡單來說，System Prompt 負責定義任務與行為邏輯，Guardrail Policy 負責定義安全邊界與不可跨越的紅線。

若 Guardrail Policy 過長或超出數量限制，應如何處理？

目前 Policy 可包含兩組自訂規則模組，每組最多三條自訂 Rules；每條 Rule 最多約 400 個英文單字。
如果規則很多，建議將 AI Application 的工作條件盡量寫清楚在 System Prompt 中，再由 XecGuard 作為更高層級的安全防護，強化模型遵循這些規範的能力。

XecGuard 能檢測LLM幻覺嗎？

可以，XecGuard 提供 Context Grounding 檢測功能，適合檢查忠實性幻覺（Fidelity Hallucination），特別適合 RAG 場景。當使用者提供 RAG 參考內容作為 Context 時，XecGuard 可檢測回應是否遵循這些資料，並回傳四種類型的結果：完整、不完整、缺乏根據、資訊衝突。
Hallucination 可以分成兩類：
事實性幻覺（Factual Hallucination），指的是模型產生的內容，和真實世界的事實不一致。也就是它說出來的東西本身就是錯的、不存在的、過時的，或沒有可靠依據。當模型面對不確定資訊時，或是沒有對應的知識時，它往往傾向於「編造」一個邏輯完整的回應，而不是回答「我不知道」。Factual Hallucination 需要外部事實查核與知識更新機制。
忠實性幻覺（Fidelity Hallucination），指的是模型的回答雖然聽起來可能合理，甚至內容本身不一定是錯的，但它沒有忠實遵守給定的來源、上下文、任務要求或原始資料，擅自補充、推論或扭曲來源內容。Fidelity Hallucination 則需要 Context Grounding、引用驗證、來源約束與輸出一致性檢查。

XecGuard 的 PII Policy 支援哪些資料格式？

目前支援多種常見中文個資與敏感格式檢查，包括地址、電話、電子郵件、信用卡號、IBAN、台灣身分證、護照號碼、健保卡號、銀行帳號、統一編號與車牌號碼等。可用範圍涵蓋一般國際格式以及多種台灣在地格式。
請注意，PII Policy 檢測的是內容屬性是否包含個資相關資訊，而非用於惡意偵測類的告警，因此檢測方式較為寬鬆，且定義的 Risk Level 比較低，PII Policy 比較適合用在金融應用場景，或是其他特殊情境。

XecGuard 是否能驗證輸入輸出是否涉及著作權等智慧財產權內容？

部分程度上可以。XecGuard 可透過客戶自訂規則（Custom Policy 與 Rule），協助企業落實資料使用政策與合規控管。例如，企業可以定義特定政策，用來檢查員工是否將特定專案資料、原始碼、內部文件，或包含特定版權宣告、機密標記、智慧財產權相關內容的資料傳送至 AI 系統，進而偵測與驗證 AI 的輸入與輸出是否可能涉及著作權、營業秘密或其他智慧財產權風險。
但需要特別說明的是，XecGuard 是一套 Prompt Attack 偵測與防禦系統，並非專門的法律合規審查系統。因此，XecGuard 可作為企業 AI 使用治理與資料外洩風險控管的一部分，但不能取代公司既有且完整的著作權法、專利法、商標法、營業秘密法等相關法規審查與合規管理機制。

XecGuard 部署架構、效能 (Deployment and Performance)​

掃描不夠快，有什麼加速的方法？

在效能方面，分析速度會受到多項因素影響。首先，啟用的 Policy 數量越多，分析所需時間也會相應增加；每增加一項 Policy，實測來說平均約增加 350 至 800 毫秒的延遲。此外，若同時對 User Input 與 Assistant Response 進行分析，整體處理時間可能增加至原先的兩倍。另一方面，Context 的內容長度亦會影響分析效能，內容越長，處理時間越長。


可透過以下方式改善效能：

  • 只啟用必要的 Policy，減少每次 Scan 套用的規則數量
  • 減少 API 呼叫次數，避免對每一輪對話都檢查
  • 在 Agent / A2A / MCP 場景中，改為只在關鍵步驟（如工具調用前、最終結論）進行檢查，而非逐句掃描
  • 避免瞬間大量併發呼叫，搭配請求排隊或流量控管機制
XecGuard API 有哪些 Cloud 上支援

XecGuard 目前已支援雲端架構有 AWS 與 Azure 兩類雲，近期也會支援部屬到 GCP。

On-Premise 部署的建議硬體規格為何？

On-Premise 部署，這不是我們標準方案，目前 XecGuard 標準版本僅提供 Cloud API 形式服務。若有自建需求，必需以專案方式另行討論。專案版本規劃支援 On-Premise 部署，但最終規格仍需依實際專案確認，建議與奧義團隊直接洽詢。

XecGuard 是否支援 HA mode？

是，可以支援。
透過 LiteLLM 的 API gateway，可以在這層進行設定，切換給多台 XecGuard API Server。
但是機器也要採購多台，並且需要 LiteLLM 的服務導入與設定。

XecGuard 有 Dashboard 或是 Web UI 介面嗎？為甚麼我只有 API 可以操作？

XecGuard 付費商業版本有提供 Web 管理介面與 Dashboard，License Standard、Advanced 等商業版本僅提供企業用戶使用。
如果您是 XecGuard 社群回饋計畫的 User，則 License 為 Lite 版本，僅提供 API 介面，不提供 Web Dashboard 管理介面，不過請放心 API 介面與 Web Dashboard 管理介面功能完全相同。唯一的差異只有 Lite License 的 API Rate Limit 是 100 RPM，比較低。

XecGuard 是否支援 Multi-Tenant 架構多種使用者角色，讓企業同時管理多個 AI 應用？

可以。XecGuard 支援 Multi-Tenant 架構與多角色權限管理，可協助企業集團、子公司或不同業務單位，統一管理多個 AI 應用與不同使用場景。
XecGuard 提供彈性的「多層級規則管理機制」，可依照不同 LLM、不同 Chatbot 功能、不同 AI 應用，或不同子公司與部門需求，配置各自適用的 Guardrail Rules 與安全政策。同時，企業也可透過不同 Service Tokens 區分各 AI 應用或使用場景，分別進行使用量統計、政策套用、紀錄追蹤與維運管理，使 AI 治理更加清楚且容易擴展。
此外，XecGuard Dashboard 提供多種帳號角色，以支援企業安全治理與分層管理需求，包含：

  • Territory Admin：企業集團管理員，可管理整體租戶與跨組織設定。
  • Org Manager：子公司或組織管理員，可管理所屬組織內的應用、規則與設定。
  • Org User：子公司或組織 API 使用者，可使用 Scan API 進行安全檢測。
  • Org Auditor：子公司或組織唯讀帳號，可檢視紀錄、設定與報表資料，但不可修改系統設定。

透過 Multi-Tenant 架構、Service Token 分流管理，以及角色權限控管，XecGuard 可協助企業在多 AI 應用、多部門與多子公司的環境中，建立一致且可管理的 AI 安全治理機制。

XecGuard 如果落地版本客戶自行採購 Red Hat，是否可以替代？

否，不能替代。
XecGuard 落地版本是以完整產品套件形式交付，相關系統組件不得自行拆分或替換，以避免後續維運、升級、相容性驗證與問題排除產生管理風險。
XecGuard 系統包含多台 VM/Docker 架構，並需搭配 NVIDIA Linux Driver 及相關 GPU 運行環境。相關作業系統版本、驅動程式、系統參數與效能設定，均已依產品需求完成優化與驗證。因此，落地版本目前不支援由客戶指定或替換 Linux OS。

XecGuard 採用 PostgreSQL DB，客戶自行採購 SQL Server 納入共同管理，是否可以替代？

否，不能替代。
XecGuard 落地版本是以完整產品套件形式交付，相關系統組件不得自行拆分或替換，以避免後續維運、升級、相容性驗證與問題排除產生管理風險。
XecGuard 的系統服務、資料庫結構、應用程式介接方式與部署流程，均已針對 PostgreSQL 及既有容器化運行環境完成開發、優化與驗證。因此，落地版本目前不支援由客戶指定或替換 Database，也不支援以 SQL Server 取代 PostgreSQL。

XecGuard API 使用 (XecGuard API Usage)​

XecGuard 是否支援 JSON 等結構化輸出？

是的，XecGuard API 都是 JSON 結構化輸出，也可配合 Function Calling（Tool Calls）等方式使用，方便後續系統自動化判讀、串接與處理。

XecGuard API 是否容易整合到既有 AI 應用中？

是的。XecGuard API 的設計接近 OpenAI API 等業界常見介接規格，既有 AI 應用通常可透過調整 API Endpoint、Token 與相關參數快速接入，降低導入成本與系統改造門檻。
此外，XecGuard 也提供 LiteLLM Plugin 模組，可直接整合至既有 AI Gateway 架構，將原本的 LLM Gateway 升級為具備 Guardrail 防護能力的 AI 安全閘道。在此模式下，應用程式端通常不需要大幅修改，即可導入 Prompt Attack 偵測、防護與政策控管能力。

XecGuard 是否支援 streaming 回應的即時檢查？

目前暫不支援 streaming 檢查。
在現有條件下，XecGuard 的延遲約為 350 至 800 毫秒，通常不需要特別透過 streaming 方式來降低等待時間。

XecGuard 計價方式為何? 如何估計我公司用量應該選哪個方案?

XecGuard 的一項重要優勢是其計價方式並非以 Token 用量為基礎，而是以 API Request 數量與請求頻率作為主要計價依據。相較於其他 Guardrail 都是用 Token 計費成本很可觀 (Token-based pricing)，XecGuard 這種模式可讓企業在大量使用 AI 應用時，更容易預估與控制 Guardrail 防護成本，避免因輸入內容長度、對話歷史或模型輸出量增加，導致安全防護成本快速膨脹。
以效能規格來看，XecGuard 單一運算單位最高可支援約 1,500 RPM（Requests Per Minute）。依據我們的實務經驗，此規模約可支援 300 至 400 名使用者同時使用。
不過，實際可支援人數仍會受到 AI Application 的設計方式、使用者互動頻率、請求內容長度、是否採用串流或多輪對話、以及應用場景特性影響。因此，上述數字僅作為初步容量規劃參考，實際部署時仍建議依企業的應用情境與流量模型進行壓力測試與容量評估。

XecGuard 的 Dashboard User 登入怎麼跟企業的 SSO 或是 AD 整合？也支援 SAML 嗎?

XecGuard 的 Dashboard User 登入，協議是 OAuth 2.0，外加身份識別層就是 OIDC。XecGuard 用 OIDC（OpenID Connect）跟 AWS Cognito 對話，拿到 JWT 格式的 token。
當客戶的內部用企業 SSO（AD FS、Azure AD SAML、傳統 Okta SAML 等）時，企業的 IdP 用 SAML 而不是 OIDC。
可以這樣使用：
User → XecGuard Dashboard ← OIDC → AWS Cognito ← SAM → 企業的 IdP (AD FS、Azure Entra ID)
AWS Cognito 原生支援 SAML，如果客戶用企業 SSO（AD/ADFS），就會在 Cognito 那層接 SAML，前端維持 OIDC 不變。
注意，落地版本我們使用別的 AWS Cognito 平替方案。

常見的 XecGuard API Error Code 有哪些？

400 Bad Request
說明：請求格式有誤，或輸入內容超過 Context Length 上限
常見原因與處理方式：

  • 確認 request body 欄位名稱與型別正確
  • 若輸入過長，請縮短 messages 內容或移除不必要的歷史對話
  • 在 Scan 時未指定任何 Policy 或使用不合法的 Policy ID 也會出現此錯誤
  • 若使用 pattern_regex Policy，請確認規則為合法的 Regex 語法

401 Unauthorized
說明：API Token 無效、未提供，或 License 已過期
常見原因與處理方式：

  • 確認 Authorization header 格式為 Bearer <YOUR_TOKEN>
  • 確認使用的是完整 Token 字串（Service Token 格式：xgs_[16碼hex]_[密鑰]）
  • 確認 Token 狀態為 enable 且尚未過期
  • 可透過 GET /xecguard/v1/licenses 確認 License 是否仍在有效期內

403 Forbidden
說明：已完成驗證，但該 Token 不具備此操作的權限
常見原因與處理方式：

  • 管理類操作（建立/更新 Token、Policy、查詢統計）需使用 Management Token（xgm_）
  • 掃描類操作（/scan、/grounding）需使用 Service Token（xgs_）
  • 確認使用了對應該端點的正確 Token 類型

409 Conflict
說明：請求與目前系統資源狀態衝突
常見原因與處理方式：

  • 常見情境：重複建立同名 Policy 或 Service Token、更新時版本不同步
  • 建立前先確認資源是否已存在（GET /xecguard/v1/policies 或 GET /xecguard/v1/tokens）
  • 若要修改現有資源，請使用 PATCH 而非重新 POST

413 Content Too Large
說明：請求內容超過系統可接受的最大 Context Length 上限（128K tokens）
常見原因與處理方式：

  • 縮短 messages 內容或移除不必要的對話歷史
  • 確認輸入內容未超過 128K tokens 的上限
  • XecGuard 設計用於即時聊天內容分析，不建議用於掃描大型文件或完整檔案

422 system_prompt_exceeds_license_scan_budget
說明：System Prompt 超過 License 單次掃描的 Token 上限（Lite：10K tokens／Standard·Advanced：38K tokens）
常見原因與處理方式：

  • 縮短 System Prompt 內容，使其落在對應方案的上限以內
  • 若 System Prompt 有多個 segment，可確認合併後的總長度是否接近上限

429 Too Many Requests
說明：每分鐘 API 呼叫次數超過 License 所允許的速率限制（RPM）
常見原因與處理方式：

  • 實作 Retry with Backoff（指數退避重試）
  • 加入請求排隊或流量控管，避免瞬間大量併發呼叫
  • 若長期觸發，評估是否需要升級 License 方案
Token 無效或 License 過期時會發生什麼？

當 Service Token 不存在、已停用，或 License 已過期時，API 會回傳 401 Unauthorized 或 403 Forbidden 錯誤，所有 API 端點皆無法使用。
License 過期後，即使 Token 本身尚未到期，仍無法進行任何操作，需重新申請 License 以取得新的 Management Token。
建議定期透過 GET /xecguard/v1/licenses 確認 License 有效期限，避免服務中斷。

Management Token 遺失或需要刪除，該如何處理？

XecGuard Management Token 為每位使用者唯一的管理憑證，無法自行重新產生或刪除。
若您的 Management Token 遺失、需要重新核發，或希望提早結束計畫並刪除 Token，請透過 email 向我們提出申請。
目前此類操作僅由專人處理，收到申請後將儘速回覆。

Service Token 遺失或需要刪除，該如何處理？

若 XecGuard Service Token 遺失、疑似外洩，或已不再使用，使用者可至 XecGuard 應用程式介面進行處理。
請依序進入 Application 頁面，選取對應的應用程式，並透過 Manage 功能重新產生或刪除 Service Token。

  • 若 Token 遺失或疑似外洩，建議使用 Regenerate Service Token 重新產生新的 Token。
  • 若該 Token 已不再使用，或對應的應用程式不應再存取 XecGuard API，可直接刪除該 Service Token。

重新產生 Service Token 後，系統會核發新的 Token Secret。請立即複製並妥善保存；基於安全性考量，新 Token 僅會顯示一次，關閉視窗後將無法再次查看。

偵測結果有誤判或漏判，該如何改善？

由於自然語言內容具有高度語境差異，且業界對於「惡意意圖」與「不安全內容」並不存在完全一致且精準的判定標準，因此任何 AI Guardrail 系統都無法保證 100% 的偵測率。實際偵測效果會受到應用場景、System Prompt 設計、任務邊界、使用者輸入內容，以及 Guardrail Policy / Custom Policy 規則撰寫方式等因素影響。
若出現誤判或漏判，建議可從以下方向進行調整：

  • 優化 Custom Policy 的 Rule 寫法 使規則描述更明確，避免過於模糊、過度寬泛或缺乏判斷條件。必要時可加入正反範例，協助系統更準確理解應阻擋與應放行的內容邊界。
  • 增加明確的黑名單或禁止條件 若企業已有明確不可出現的詞彙、專案名稱、機密代號、資料類型或高風險行為，可在 XecGuard Policy 中加入額外的黑名單或明確禁止條件，以提升特定場景下的防護效果。
  • 優化 Application 的 System Prompt 若偵測結果與應用任務邊界有關，建議同步檢查並強化 Application 的 System Prompt，使角色設定、允許行為、禁止行為與任務限制更加清楚，讓 System Prompt Enforcement 能發揮更好的效果。

整體而言，Guardrail 的最佳效果通常來自「清楚的應用任務邊界」與「明確的安全政策規則」共同配合。關於 Custom Policy 的撰寫方式與最佳實務，請參考 XecGuard API 手冊中的相關說明。

Service Token 與 Management Token 有什麼不同？
  • Service Token：用於實際 API 呼叫（如 Guardrail Scan），可以有多個 Service Token。Service Token 的數量上限依 License 方案而定。
  • Management Token：每個 License 只有一個唯一 Management Token，用於管理功能，例如 Token 管理、Policy 管理、使用量統計、系統治理。

    ⚠️ Management Token 與 Service Token 為持有者憑證（bearer tokens），可用於存取您的資源。這些憑證極為敏感，必須妥善保存、嚴格控管存取權限，且絕不可外洩。
Request Body 是否有格式限制？

是的，Request Body 必須為合法的 JSON 格式，並符合 API 所定義的請求結構。
若傳送內容格式錯誤或無法解析，API 將回傳錯誤訊息，且不會執行該次安全檢測。

Policy 名稱錯誤會發生什麼？

若在 Scan 請求的 policy_names 中指定了不存在的 Policy 名稱，API 會回傳 400 Bad Request，錯誤訊息為 "The following policy_names do not exist: <錯誤的名稱>"，該次掃描不會執行。
請確認使用的是完整且正確的 Policy 名稱（例如 Default_Policy_GeneralPromptAttackProtection），名稱區分大小寫。
可透過 GET /xecguard/v1/policies 查詢目前可用的所有 Policy 清單，以避免名稱輸入錯誤。

XecGuard API 在掃描分析後，會回傳哪些結果狀態？

當 Guardrail Scan 完成後，API 會回傳本次安全檢測的判斷結果，供應用系統進行後續處理與決策。主要包含以下資訊：

  • Decision（SAFE / UNSAFE）：表示輸入或輸出內容是否被判定為存在安全風險
  • Violated Policy：指出觸發安全判斷的 Policy 名稱
  • Violated Rules：列出被判定違反的規則項目
  • Rationale：提供模型判定為風險內容的原因說明
  • Trace ID：若判定為 UNSAFE，系統會產生對應的 Security Trace，可用於後續查詢詳細紀錄

    可用於回應控管、安全提示顯示、事件稽核與風險分析。

XecGuard 技術規格 (Specifications)​

XecGuard 的上下文處理能力與輸入上限為何？

單次請求可接受的最大 Context Length 為 128K tokens。若輸入超過此上限，API 將回傳 413 Content Too Large，該次請求不會被處理。
實際參與安全檢測的內容依 License 方案而定：Lite 版僅掃描最後 10K tokens，Standard 與 Advanced 版僅掃描最後 38K tokens。當輸入超過上述掃描範圍時，系統只會分析最後一段內容，其餘內容將不納入檢測，可能影響判斷完整性與準確度。
因此，XecGuard 較適用於分析即時聊天內容或 Prompt / Response，而不建議用於掃描大型文件或完整檔案。

XecGuard 提供哪些檢測模組與 Policy？

XecGuard 目前提供八大檢測模組與 Policy：

General Prompt Attack Protection（通用提示攻擊防護）
說明：可偵測並防止大部分的提示詞注入（Prompt Injection）、提示詞竊取（Prompt Extraction）與繞過防護（Evasion）等攻擊行為，避免攻擊者試圖覆寫模型行為、暴露受保護的系統指令，或透過混淆與編碼手法繞過安全機制。

System Prompt Enforcement（任務情境遵循）
說明：可確保 AI 系統嚴格遵循企業所指派的 AI Agent 任務範圍（System Prompt Following），實現超越傳統內容過濾的真正情境感知安全。

Content Bias Protection（內容偏見防護）
說明：可偵測並緩解帶有偏見、騷擾或有害刻板印象的輸出，確保生成內容不具歧視性，並尊重受保護屬性、健康狀態與社經背景。

Harmful Content Protection（有害內容防護）
說明：透過語意層分析，偵測並防止有違善良風俗、有害或危險的 AI 輸出，而非僅依賴關鍵字過濾。

PII & Sensitive Data Protection（個資與敏感資料防護）
說明：企業級 AI 的隱私與資料外洩防護，確保 AI 不會暴露個人或敏感資訊。

Malicious Skills Protection（惡意 Agent Skills 防護）
說明：檢測 AI Agent 的 Skills 與相關檔案內容是否包含對系統惡意或有害內容，以保護 Agent AI 免於惡意 Skills 的影響。

Custom Policy Enforcement（自訂 AI 安全政策）
說明：使組織能依其業務或是 AI/Chatbot 任務規則，可用自然語言自定義 Guardrail Rule，並強制執行專屬的 AI 治理規則。

Context Grounding Validation（內容幻覺檢驗）
說明：僅限 API 使用的功能，用於偵測 AI 幻覺，檢測回應內容是否嚴格依據使用者提供的文件與核准的 RAG 情境。

XecGuard 有哪些 License 方案？

XecGuard 提供三種主要的 License 方案：

  • XecGuard Lite：最大請求速率（RPM）100(~180) requests/min；Service Tokens（API keys）最多 2 個；Context 長度限制約 10K Tokens。設計用於 proof-of-concept（POC）與小規模部署、XecGuard Community Support Program。
  • XecGuard Standard：最大請求速率（RPM）700 requests/min；Service Tokens 最多 7 個。推薦用於大多數生產情境與多應用環境。
  • XecGuard Advanced：最大請求速率（RPM）1500 requests/min；Service Tokens 最多 15 個。適用於高流量或企業級部署。
    如需根據流量或管理需求選擇或升級方案，請聯絡業務或系統管理員取得建議與方案細節。