Chuyển đến nội dung chính
Bất kỳ prompt nào ứng dụng của bạn gửi tới mô hình đều có thể mang theo dữ liệu cá nhân mà nó không nên mang — một email được dán vào ticket hỗ trợ, một SSN trong ghi chú CRM, một số thẻ mà người dùng gõ vào hộp chat. Một khi văn bản đó đến được một provider thượng nguồn thì nó nằm ngoài tầm kiểm soát của bạn: bị ghi log, cache, có thể được dùng để huấn luyện. Phản hồi của mô hình cũng có thể rò rỉ PII ngược lại, lặp lại hoặc suy luận ra các chi tiết rồi rơi vào log ứng dụng của bạn. Trang này cho thấy cách chặn một rò rỉ PII của llm tại gateway bằng một guardrail PII — một quy tắc theo phạm vi workspace mask hoặc block các thực thể nhạy cảm trên request trước khi mô hình kịp nhìn thấy chúng. Nó là đối tác ở tầng nội dung của Agent Firewall, và nó không cần thay đổi code ứng dụng của bạn.
Một guardrail PII sàng lọc văn bản của prompt và phản hồi. Để kiểm soát các hành động mà một agent thực hiện với dữ liệu — các tool fetch, các host egress — xem Rò rỉ dữ liệu. Hai mặt phẳng kết hợp với nhau; hầu hết các đội đều chạy cả hai.

1. Phơi nhiễm xảy ra thế nào

PII đến được một provider thượng nguồn qua traffic bình thường, có thiện ý:
  • Một người dùng dán thông tin liên hệ của chính họ vào một cuộc chat và ứng dụng của bạn chuyển tiếp toàn bộ tin nhắn nguyên văn.
  • Một pipeline RAG truy xuất một tài liệu chứa hồ sơ khách hàng và nhồi nó vào prompt làm ngữ cảnh.
  • Một agent đọc một hàng cơ sở dữ liệu và đưa các trường thô vào một argument tool hoặc một prompt tiếp theo.
  • Phản hồi của mô hình nhắc lại hoặc suy luận ra PII, mà ứng dụng của bạn sau đó ghi vào log của chính nó.
Không cái nào trong số này là một cuộc tấn công — chúng là hình dạng bình thường của các ứng dụng LLM. Cách khắc phục là một chính sách sàng lọc mọi request và phản hồi tại một điểm nghẽn duy nhất, thay vì audit từng nơi gọi trong code của bạn.

2. Phòng thủ rò rỉ PII của llm bằng một guardrail PII

Một guardrail là một chính sách nội dung có tên, theo phạm vi workspace. Một quy tắc pii bên trong nó phát hiện các thực thể nhạy cảm và áp dụng một action cho mỗi match:
ActionHiệu ứng
maskThay mỗi match bằng một tag có kiểu — jane@acme.com[EMAIL] — và chuyển tiếp văn bản đã làm sạch. Mô hình không bao giờ thấy bản gốc.
blockTừ chối toàn bộ request với HTTP 400 guardrail_blocked. Dùng khi PII tuyệt đối không được đến provider.
flagKhông thay đổi gì về traffic; ghi lại một match. Đo lường phơi nhiễm trước khi bạn thực thi.
Tập bộ phát hiện là built-in và tất định — thuần khớp mẫu, không có cuộc gọi mạng, an toàn trên đường nóng. Các thực thể built-in: email, phone, credit_card, ssn, ip, iban, mac_address, jwt, aws_access_key, api_key_openai, bitcoin_address, cộng với các định danh khu vực có cổng checksum jp_mynumber, kr_rrn, và cn_resident_id. Trên một action mask, mỗi match hiển thị dưới dạng tag có kiểu của nó — [EMAIL], [SSN], [CREDIT_CARD], v.v. — nên cấu trúc của prompt được giữ lại trong khi giá trị thì biến mất.
Cần một bộ phát hiện không có sẵn built-in (một ID nhân viên nội bộ, một số tài khoản)? Thêm một thực thể tùy chỉnh — một regex với checksum Luhn tùy chọn, tối đa 25 mỗi quy tắc — ngay bên cạnh các thực thể built-in. Xem Tham chiếu Guardrails.

3. Ví dụ cụ thể — mask PII trên request

Khởi đầu nhanh nhất là preset PII Shield: một quy tắc pii duy nhất mask email, phone, ssn, credit_card, và ip. Cấu hình nó trong console — không thay đổi code, không có key trong bước này.
1

Tạo guardrail

Trong console, mở Guardrails và nhấn New guardrail. Chọn preset PII Shield từ danh mục pii, hoặc tự soạn một quy tắc pii với action mask trên các thực thể ở trên. Lưu lại. (Ghi yêu cầu vai trò Developer trở lên.)
2

Chứng minh trong sandbox

Mở tab Test, dán “reply to jane@acme.com, chọn stage input, và chạy. Sandbox trả về reply to [EMAIL] — cục bộ, không có cuộc gọi thượng nguồn và không tốn quota.
3

Gắn nó vào một key

Trong API Keys, sửa một key và chọn guardrail từ dropdown Guardrail, hoặc đặt guardrail làm mặc định của workspace để mọi key chưa gắn đều kế thừa nó. Liên kết nằm trên key trong gateway.
4

Gọi gateway như thường lệ

Dùng key đó, cuộc gọi relay của bạn không thay đổi:
curl https://api.orcarouter.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "messages": [
      {"role": "user", "content": "Draft a reply to jane@acme.com"}
    ]
  }'
Gateway viết lại email thành [EMAIL] trước khi chuyển tiếp. Mô hình thượng nguồn không bao giờ nhận được địa chỉ.
PII Shield là một quy tắc stage both, nhưng masking ở stage request trực tiếp là cái đang ship hôm nay — gateway mask prompt trước khi nó rời đi tới mô hình. Masking ở stage output (response) trên relay trực tiếp đang nằm trong roadmap. Để xác minh một quy tắc stage response hành xử thế nào, đánh giá nó trong tab Test. Với streaming, xem §5.

4. Mask phần lớn, block phần tệ nhất — ghi đè theo từng thực thể

Một quy tắc duy nhất có thể áp dụng các action khác nhau cho các thực thể khác nhau qua entity_actions. Mask các định danh rủi ro thấp nhưng cứng rắn block các thực thể bạn không bao giờ muốn chuyển tiếp — một quy tắc thay vì ba quy tắc chồng chéo:
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "ip", "credit_card", "ssn"],
  "entity_actions": {
    "credit_card": "block",
    "ssn": "block"
  }
}
Ở đây email, số điện thoại, và IP được mask và đi qua; một prompt mang theo một số thẻ hoặc SSN bị từ chối với HTTP 400 guardrail_blocked thay vào đó. Một request bị block không tốn quota — một block ở stage input kích hoạt trước khi đo lường — và được đánh dấu skip-retry. Mỗi khóa entity_actions phải là một thực thể được khai báo trên quy tắc (built-in hoặc tùy chỉnh); action của nó được kiểm tra đối với tập action của quy tắc.

5. Những gì hoạt động trên streaming hôm nay

Action và stage tương tác với streaming khác nhau — hãy biết ma trận trước khi bạn phụ thuộc vào nó:
Hoàn toàn trực tiếp. Prompt được sàng lọc trước cuộc gọi thượng nguồn, nên masking và blocking hoạt động giống hệt dù response có stream hay không. Đây là bề mặt mà PII Shield thực thi hôm nay.
Được thực thi trên cả response streaming và non-streaming. Trên một stream, một scanner cắt stream giữa chừng và phát ra một tin nhắn thay thế trước khi bất kỳ nội dung bị block nào đến được client; một output block hoàn lại quota đã tiêu trước.
Hiện tại chỉ non-streaming. Trên một response được stream, chunk gốc đi qua mà không bị mask — viết lại stream trong luồng là một cải tiến đã được lên kế hoạch. Để mask response hôm nay, dùng các request non-streaming, hoặc dựa vào masking ở stage input. Chứng minh tổ hợp stage/stream chính xác của bạn trong tab Test trước.

6. Xem những gì đã bị bắt

Mỗi quy tắc kích hoạt đều ghi lại một match — kiểu, action, stage, và một chuỗi chi tiết của nó — hiển thị trên feed Matches của workspace (GET /api/guardrail/match, mở cho mọi thành viên). Từ đó bạn có thể nhóm, lọc, export ra CSV, và đánh dấu false positive.
Giá trị thô không được ghi log theo mặc định. Công tắc Log raw content của một guardrail bị tắt — tư thế thận trọng về quyền riêng tư — nên feed Matches ghi lại rằng một quy tắc PII đã kích hoạt và thực thể nào, nhưng không ghi chuỗi con đã khớp (chính địa chỉ email). Chỉ bật nó theo từng guardrail khi bạn cần giá trị để phân loại; cài đặt này không hồi tố. Bắt PII vào audit trail của chính bạn để debug một rò rỉ PII sẽ là tự đánh bại mình.

7. Đi xa hơn

Để có đầy đủ các kiểm soát về cư trú, lưu giữ, và quyền được xóa — bao gồm cài đặt một compliance pack hiện thực hóa các guardrail này cho GDPR, HIPAA, hoặc PCI DSS — hãy bắt đầu từ các trang tham chiếu bên dưới.

Tham chiếu Guardrails

Mọi kiểu quy tắc, stage, action, thực thể tùy chỉnh, versioning, và bộ khung eval — tham chiếu chuyên sâu đằng sau trang này.

Rò rỉ secret

Người anh em hình dạng credential — token AWS, OpenAI, GitHub — bị bắt bởi guardrail Secrets Blocker.

Output không an toàn

Sàng lọc những gì mô hình gửi lại, không chỉ những gì nó nhận.

Guardrails vs Firewall

Khi nào sàng lọc văn bản và khi nào kiểm soát hành động — và tại sao bạn thường muốn cả hai.