Chuyển đến nội dung chính
Bạn đã kết nối một MCP server, và giờ bạn muốn gateway tước một secret bị rò rỉ khỏi một lời gọi tool trước khi nó đến được server thật — và giữ bất cứ thứ gì tool đó trả về khỏi việc lén đưa một credential (hoặc một payload injection) ngược trở lại mô hình. Đó là hai công việc khác nhau, được xử lý bởi hai biện pháp kiểm soát khác nhau, và phiên bản trung thực quan trọng: nếu bạn giả định một núm bao trùm cả hai, bạn sẽ ship một khoảng trống. Trang này là hướng dẫn tập trung về sanitize mcp output trên OrcaRouter — verdict sanitize của firewall thực sự redact cái gì, nó không làm cái gì, và biện pháp kiểm soát nào kiểm soát nội dung mà một tool trả về.
Verdict sanitize redact các argument của lời gọi tool, không bao giờ kết quả mà một tool trả về. Nó viết lại cái mà agent của bạn gửi vào một tool. Để kiểm soát cái mà một tool gửi lại, bạn dùng một guardrail stage output trên phản hồi của mô hình — xem §3.

​
1. “sanitize” nghĩa là gì trên bề mặt mcp

Khi một agent gọi một tool qua MCP gateway, mọi tools/call được đánh giá trên bề mặt mcp trước khi dispatch. Một quy tắc khớp có thể mang một trong các verdict firewall soạn được — allow, audit, deny, sanitize, pending_approval, hoặc cap_cost. Verdict sanitize là cái redact:
  • Nó chạy một tập detector hình-dạng-secret trên các argument của cuộc gọi (JSON mà mô hình truyền vào tool).
  • Mỗi match được thay bằng một token chính tắc như [redacted:openai_key], và các argument đã viết lại là cái được chuyển tiếp tới server.
  • Tool vẫn chạy — sanitize là một verdict không-block, cho-qua. Agent không crash; nó chỉ không bao giờ trao secret thô cho tool.
Các detector tích hợp sẵn bao trùm các hình dạng secret nổi tiếng (AWS access key, các API key kiểu sk-, các token Bearer, US SSN, các số thẻ hợp lệ Luhn, email), và một quy tắc có thể thêm các regex tùy chỉnh mà các match của chúng render thành [redacted:custom].
Trên bề mặt inbound — các tools[] được quảng bá mà một request khai báo, trước khi bất kỳ tool nào được gọi — không có argument lúc-gọi nào để redact, nên một verdict sanitize ở đó fail closed và leo thang lên deny. Sanitize chỉ có ý nghĩa nơi có một payload argument live để viết lại: các bề mặt mcp và response.

​
2. Một quy tắc cụ thể

Giả sử bạn muốn bất kỳ lời gọi tool nào có các argument chứa một key kiểu OpenAI được chuyển tiếp với key bị scrub ra, thay vì bị block. Soạn một quy tắc trên bề mặt mcp với một verdict sanitize, được cấu hình để phát hiện hình dạng secret đó. Làm việc này từ console (Firewall → policy → rules); việc ghi yêu cầu Developer+. Quy tắc, về mặt khái niệm:
TrườngGiá trị
Surfacemcp
tool_name_glob* (hoặc thu hẹp về một server, ví dụ github.*)
Verdictsanitize
Sanitize presetscác secret detector để bật
Vào lúc gọi, một payload argument như: 
{ "note": "use key sk-AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHH for the upstream" }
được chuyển tiếp tới server thành: 
{ "note": "use key [redacted:openai_key] for the upstream" }
Cuộc gọi thành công; secret không bao giờ đến được server. Sự kiện firewall ghi lại verdict sanitize, bề mặt, và quy tắc đã khớp.
Với tới sanitize khi một tool hợp lệ cần hầu hết một argument nhưng một secret thi thoảng đi kèm trong văn bản tự do. Khi cả cuộc gọi nguy hiểm, dùng deny (hoặc pending_approval) thay vào đó — xem Allow-list các tool MCP.

​
3. Các kết quả tool không đáng tin cậy — kiểm soát chúng trên phản hồi mô hình

Đây là phần mà hầu hết các thiết lập “sanitize the output” hiểu sai. Verdict sanitize chạm chỉ các argument. Kết quả của một tool — văn bản hoặc JSON mà một MCP server trao lại — không bao giờ được một verdict firewall viết lại. OrcaRouter coi nội dung tool-result là input không đáng tin cậy cho mô hình. Một MCP server bị xâm nhập hoặc bị đầu độc có thể trả về một secret, một bản ghi PII, hoặc một payload prompt-injection cải trang thành dữ liệu. Biện pháp kiểm soát cho nội dung đó là một guardrail trên stage output — phản hồi của mô hình, được đánh giá sau khi mô hình đã tích hợp kết quả tool.
Đính một guardrail với preset Secrets & API-Key Blocker (category secrets). Nó block các credential kiểu AWS / OpenAI / GitHub; ghép nó với Private Keys & Cloud Tokens cho các PEM key, các token Slack/Stripe, các Google key, và JWT. Một block stage output trả về guardrail_blocked (HTTP 400) và hoàn lại quota của request.
Preset PII Shield mask các thực thể có kiểu — [EMAIL], [SSN], [CREDIT_CARD], … — render các giá trị đã khớp thành các tag. Việc mask stage input live trên mọi request (streaming hay không): nó mask request trước khi mô hình thấy. Việc mask stage output viết lại phản hồi của mô hình chỉ trên các phản hồi non-streaming; việc viết lại in-band của một phản hồi streaming nằm trong roadmap, nên một quy tắc mask chưa redact một phản hồi đã được stream.
Một kết quả bị đầu độc có thể mang văn bản kiểu “ignore previous instructions”. Preset an toàn Prompt-Injection Basics (keyword/regex) cộng với một quy tắc llm_judge chấm điểm cho ý đồ injection là các biện pháp kiểm soát ở đây. Xem đầu độc tool MCP và prompt injection.
Thực thi output và streaming. block stage output được thực thi trên cả các phản hồi streaming lẫn non-streaming — trên một stream, một block cắt stream khi nó khớp và phát ra một thông báo block chung. mask stage output áp dụng chỉ cho các phản hồi non-streaming; việc viết lại in-band của một phản hồi streaming nằm trong roadmap, nên một quy tắc mask chưa redact một phản hồi đã được stream.

​
4. Mỗi biện pháp kiểm soát nằm ở đâu

Một bản đồ gọn của hai bề mặt, để bạn nối đúng núm vào đúng rủi ro:
Bạn muốn kiểm soát…Biện pháp kiểm soátỞ đâu
Các secret trong argument của một lời gọi toolVerdict sanitize của firewall (bề mặt mcp)Quy tắc Firewall
Secret / PII / injection trong kết quả của một toolGuardrail trên stage outputGuardrails
Đừng cố làm sanitize bao trùm các kết quả tool — nó không thể thấy chúng. Và đừng giả định một guardrail stage input sẽ bắt cái mà một tool trả về giữa hội thoại; nội dung tool-result được kiểm soát trên phản hồi của mô hình, vốn là stage output.

​
5. Đính và quan sát

Cả hai biện pháp kiểm soát đều theo phạm vi workspace, được đặt tên, và có thứ tự, và cả hai đều đính cùng hai cách:
  • Theo từng key — đặt firewall_policy_id (cho quy tắc sanitize) và guardrail_id (cho chính sách output) trên key mà agent dùng.
  • Mặc định workspace — đánh dấu một chính sách / guardrail làm mặc định workspace để mọi key kế thừa nó.
Cấu hình tất cả điều này từ console với session/access token của bạn (các route quản lý dùng UserAuth, không phải relay key). Các lần ghi firewall yêu cầu Developer+; các lần ghi guardrail yêu cầu Developer+. Một khi live, các match sanitize hiện ra như các sự kiện firewall (verdict, bề mặt, quy tắc đã khớp), và các match guardrail hiện ra trong feed match guardrail. Hai cái có các cổng đọc khác nhau: feed các sự kiện firewall yêu cầu Developer+, trong khi feed match guardrail đọc được bởi bất kỳ thành viên workspace nào. Theo mặc định một match ghi lại type, action, và stage của nó nhưng không ghi nội dung thô đã khớp; bật Log raw content chỉ khi bạn cần substring để triage.

​
6. Đi đâu tiếp theo

Allow-list các tool MCP

Default-deny một server và chỉ cho phép các tool bạn đã xem xét.

Quy tắc Firewall

Toàn bộ rule DSL — các verdict, globs, args-match, cấu hình sanitize.

Guardrails

Các chính sách nội dung, presets, các thực thể PII, và thực thi stage output.

Đầu độc tool MCP

Mối đe dọa làm cho các kết quả tool không đáng tin cậy ngay từ đầu.
Mới với sự phân chia giữa hai lớp này? Đọc Guardrails vs. firewall, rồi Exfiltration dữ liệu để biết đường rò mà sanitize và các guardrail output đóng lại cùng nhau.