Chuyển đến nội dung chính
Một key xuất hiện trong một public commit, một CI log, một ảnh chụp màn hình, hoặc một vụ vi phạm của nhà cung cấp. Đồng hồ đang chạy: bất kỳ ai giữ chuỗi sk-orca-… đó đều có thể tiêu số dư của bạn và điều khiển các agent của bạn cho đến khi bạn cắt nó. Trang này là runbook sự cố — cắt credential trước, rồi audit những gì nó đã làm — cho các khách hàng tự quản lý key của mình trong console. Cơ chế vòng đời (vô hiệu hóa vs. xóa, trạng thái key, vai trò) nằm ở Quản lý key; trang này là trình tự đang bị tấn công và, quan trọng nhất, kiểm tra gì trong audit trail một khi máu đã cầm.
Dừng chi tiêu trước khi bạn điều tra. Một key có phạm vi với mức trần credit_limit_usd và một danh sách allow_ips ràng buộc thiệt hại, nhưng một key bị rò rỉ không có mức trần có thể đốt số dư bao lâu nó còn sống. Thu hồi trước; pháp y sau.

​
1. Thu hồi api key bị rò rỉ (làm cái này trước)

Bạn có hai động tác cắt, cả hai đều ở màn hình Keys trong console (/console/token). Cả hai yêu cầu vai trò Developer trở lên — hành động chạy trên session / access token của bạn, không bao giờ trên một relay key.

Vô hiệu hóa — tạm dừng có thể đảo ngược

Gạt trạng thái của key sang Disabled. Mọi request nó thực hiện bị từ chối ngay lập tức, nhưng key, các giới hạn của nó, các phần đính kèm chính sách của nó, và lịch sử sử dụng của nó đều ở nguyên. Dùng cái này khi bạn cần config và log được bảo toàn trong khi đào sâu.

Xóa — thu hồi vĩnh viễn

Chọn Delete trên key. Credential không bao giờ có thể ủy quyền một request nữa và không thể khôi phục. Dùng cái này một khi vụ rò rỉ được xác nhận và bạn đã thu thập những gì bạn cần từ trail.
Một khuôn mẫu phổ biến: vô hiệu hóa tức thì ngay thời khắc bạn nghi phơi bày (kiềm chế độ trễ bằng không, không mất gì), chạy audit ở §3–§4, rồi xóa một khi bạn đã định phạm vi bán kính ảnh hưởng. Dù bạn làm gì, hãy phát hành một key mới cho thay thế — không bao giờ bật lại một credential đã bị thấy ngoài tự nhiên. Việc chuyển giao không gián đoạn nằm ở Xoay vòng key.
Vô hiệu hóa hoặc xóa có hiệu lực ở request kế tiếp — không có triển khai lại và không có độ trễ lan truyền.

​
2. Nhân tiện, siết chặt thay thế

Một vụ rò rỉ là thời khắc để sửa phạm vi đã khiến nó gây hại. Key thay thế nên mang theo danh tính hẹp nhất mà khối lượng công việc thực sự cần, để vụ rò rỉ kế tiếp là một sự kiện không đáng kể:
Một danh sách IP cho phép nghĩa là một key bị rò rỉ vô dụng từ bất kỳ địa chỉ nào ngoài của bạn. Các request từ các IP không được liệt kê bị từ chối ở tầng auth trước khi chúng tốn bất cứ gì.
Một mức trần chi tiêu (0 = không giới hạn) ràng buộc trường hợp tệ nhất. Một key bị rò rỉ với một mức trần hằng tuần chặt không thể rút cạn số dư workspace của bạn.
Giới hạn mô hình chặn một kẻ trộm khỏi chuyển key rẻ của bạn sang mô hình đắt nhất của bạn.
Một mốc hết hạn (-1 = không bao giờ) nghĩa là một key thoát khỏi sự chú ý của bạn vẫn tự ngừng ủy quyền.
Xem Checklist least-agency để biết toàn bộ tư thế một-key-cho-mỗi-agent.

​
3. Audit request log — key đã gọi gì?

Với credential đã cắt, hãy định phạm vi thiệt hại. Mọi cuộc gọi relay mà key đó thực hiện đều được ghi trong request log workspace của bạn, và mỗi hàng mang theo các trường bạn cần để tái dựng sự cố:
TrườngNó cho bạn biết gì
token_name / token_idKey nào — xác nhận bạn đang nhìn cái bị rò rỉ.
ipĐịa chỉ nguồn của mỗi cuộc gọi. Một loạt từ một IP bạn không nhận ra là bằng chứng tang vật.
model + usageNhững mô hình nào bị chạm và chúng tốn gì — phơi bày chi tiêu của bạn.
Lọc chế độ xem log về key bị rò rỉ và sắp xếp theo thời gian. Hai câu hỏi trả lời “tệ tới mức nào” nhanh nhất:
  1. Có traffic từ một IP không phải của bạn không? Đó là lạm dụng được xác nhận, không phải báo động giả.
  2. Chi tiêu hay mẫu cuộc gọi có spike quanh cửa sổ rò rỉ không? Một bước nhảy đột ngột là dấu chân của kẻ tấn công.
Nếu key mang theo một danh sách allow_ips, các cuộc gọi từ bên ngoài nó không bao giờ ủy quyền ngay từ đầu — nên việc thiếu vắng các hàng IP-ngoại lai bản thân nó là một bản kết luận sức khỏe sạch. Đây chính xác là lý do ghim nguồn (§2) biến một vụ rò rỉ thành một sự kiện không đáng kể.

​
4. Đọc policy trail — nó đã cố làm gì?

Request log cho bạn biết key đã gọi gì; các mặt phẳng chính sách cho bạn biết nó đã cố làm mô hình nói hay làm gì, và liệu guardrails và firewall của bạn có bắt được không. Cả hai đều theo phạm vi workspace. Guardrail match có thể đọc bởi bất kỳ thành viên workspace nào; chế độ xem firewall Events / Runs yêu cầu vai trò Developer trở lên (chính sách và cài đặt firewall vẫn mở cho mọi thành viên).

Guardrail match

Mỗi lần traffic của key chạm một quy tắc guardrail, một bản ghi match rơi vào GET /api/guardrail/match — mang theo kiểu quy tắc, action (block / mask / flag), stage, và chi tiết vi phạm. Lọc về cửa sổ của key bị rò rỉ để thấy nó đẩy qua nội dung gì (PII, secrets, nỗ lực jailbreak).

Firewall event

Mỗi cuộc gọi tool mà key phát ra là một firewall event — allow, audit, deny, sanitize, hoặc held. Một loạt sự kiện deny là một agent đã cố điều gì đó nó không được phép. Gộp chúng theo run trong chế độ xem Events / Runs.
Một vài điểm cụ thể đáng biết khi bạn đọc trail:
  • Guardrail match log chuỗi con đã khớp chỉ khi “Log raw content” được bật cho guardrail đó (nó tắt theo mặc định) — nên một hàng match có thể hiển thị quy tắc và hành động mà không có văn bản thô. Kiểu / hành động / stage thì luôn có.
  • mark-fp trên một match (POST /api/guardrail/match/:id/mark-fp, Admin) cho phép bạn gắn cờ một hit là false positive để nó ngừng làm lệch chế độ xem sự cố của bạn — đừng dùng nó để chôn vùi lạm dụng thật.
  • Firewall deny là trước-tool. Một sự kiện deny nghĩa là cuộc gọi tool của kẻ tấn công bị block trước khi nó đến tool — firewall đã kiềm chế hành động đó. Sự kiện là bằng chứng của bạn rằng nó đã cố.
Đối chiếu ba trail trên cùng cửa sổ thời gian: một IP ngoại lai trong request log, một spike guardrail match, và một cụm firewall event deny cùng nhau vẽ nên bức tranh đầy đủ — kẻ tấn công đã có gì, chúng đã thử gì, và cái gì bị chặn.

​
5. Sau sự cố

Kiểm tra lại danh sách Keys: key bị rò rỉ nên đọc là Disabled hoặc biến mất hoàn toàn. Nếu bạn chỉ vô hiệu hóa nó, lên lịch xóa một khi bạn đã hoàn tất audit — xem Quản lý key.
Chuyển traffic sang key mới, có phạm vi chặt hơn trước khi cho cái cũ nghỉ để không bao giờ có khoảng không-có-key-hoạt-động. Chuyển giao đầy đủ: Xoay vòng key.
Nếu key bị rò rỉ không có allow_ips, không có credit_limit_usd, và model_limits rộng, đó là phát hiện thực sự. Trao cho mỗi agent key có phạm vi hẹp riêng của nó — Checklist least-agency và Phạm vi & key đi qua toàn bộ tư thế.

​
6. Liên quan

Quản lý key

Vô hiệu hóa vs. xóa, trạng thái key, và các cổng vai trò đằng sau mỗi hành động.

Xoay vòng key

Việc chuyển giao không gián đoạn từ một key bị xâm phạm sang một key sạch.

Danh sách IP cho phép

Ghim một key vào các địa chỉ nguồn của bạn để một vụ rò rỉ không thể dùng được ở nơi khác.

Tuồn dữ liệu

Mối đe dọa mà một key bị rò rỉ thường nuôi nhất, và cách bề mặt egress của firewall ràng buộc nó.
Toàn bộ trình tự cố tình ngắn: thu hồi, rồi audit. Mỗi key có phạm vi càng hẹp ngay từ đầu, audit bạn phải chạy càng nhỏ — và một credential bị rò rỉ càng nhanh đi từ khẩn cấp sang chú thích cuối trang.