Chuyển đến nội dung chính
Một credential bạn có thể đọc trên màn hình là một credential bạn có thể làm rò rỉ. Một khi bạn đã sao chép một key mới, bạn gần như không bao giờ cần plaintext của nó lần nữa — bạn cần nhận ra nó: key này là cái nào, trong môi trường nào, có phải là cái mà agent đang lỗi dùng không. Console của OrcaRouter trả lời điều đó mà không bao giờ in lại một secret hoạt động: mỗi key được render ở dạng đã che giữ vừa đủ ký tự để nhận diện nó và ẩn phần còn lại. Trang này đề cập dạng đã che trông như thế nào, khi nào plaintext được và không được hiển thị, và cách che an toàn giá trị api key trong log và tooling của riêng bạn.

​
1. Tại sao che giá trị api key khi hiển thị

Key đầy đủ là một bearer credential: bất kỳ ai đọc nó đều có thể gọi gateway như bạn, tới các giới hạn của key đó. Các chế độ xem console được sao chép vào ảnh chụp màn hình, chia sẻ màn hình, support ticket, và bug report liên tục — nên hiển thị secret sống trong một danh sách key sẽ biến mỗi cái trong số đó thành một vụ rò rỉ credential. Che giải quyết điều này bằng cách tách hai nhu cầu thường bị gộp lẫn:
  • Nhận diện — key nào là cái này? Được trả lời bởi một dấu vân tay đã che, ổn định mà bạn có thể đọc trong nháy mắt.
  • Sử dụng — secret là gì? Được trả lời đúng một lần lúc tạo, và đằng sau một lần tiết lộ có chủ đích bị kiểm soát theo vai trò sau đó.
Console thỏa mãn nhu cầu thứ nhất ở mọi nơi và kiểm soát nhu cầu thứ hai, nên bề mặt mặc định — danh sách key bạn nhìn chằm chằm cả ngày — không bao giờ mang theo một secret dùng được.
Một key đã che không phải là một credential hoạt động. Nó không thể xác thực một request. Chỉ plaintext đầy đủ (sk-orca-…) bạn đã sao chép lúc tạo, hoặc tiết lộ lại qua endpoint bị kiểm soát, mới có thể gọi gateway.

​
2. Dạng đã che trông như thế nào

Console hiển thị tiền tố thương hiệu của key, rồi một chuỗi dấu hoa thị cố định, rồi bốn ký tự cuối — đủ để phân biệt hai key, không đủ để tái dựng cái nào.
Bạn đã tạoConsole hiển thị
sk-orca-9f3aK2…long…7Qm4sk-orca-9f3****7Qm4
Đoạn đầu giữ tiền tố sk-orca- và vài ký tự dẫn đầu; bốn ký tự cuối là phần đuôi bạn sẽ nhận ra khi đối chiếu một dòng log hoặc một lỗi. Mọi thứ ở giữa bị thu gọn thành một mask cố định — chuỗi dấu hoa thị là một hằng số, nên độ rộng của nó không bao giờ tiết lộ độ dài thật của key.
Ghép phần đuôi đã che với nhãn environment và tên của key khi bạn cần tìm một key cụ thể nhanh — phần đuôi bốn ký tự cộng với tag prod / staging gần như luôn đủ để chọn đúng cái ra khỏi một danh sách mà không bao giờ tiết lộ plaintext.

​
3. Khi nào plaintext được hiển thị — và khi nào không

Có đúng một thời khắc key đầy đủ là của bạn để sao chép, và một đường bị kiểm soát duy nhất để lấy lại nó.
Khi bạn đúc một key, console hiển thị plaintext sk-orca-… đầy đủ một lần. Sao chép nó vào secret manager của bạn khi đó. Mọi lần xem sau đó của key đó — danh sách, panel chi tiết, kết quả tìm kiếm — chỉ hiển thị dạng đã che.
Bạn có thể tiết lộ lại plaintext của một key thông thường khi cần, nhưng đó là một hành động có chủ đích đằng sau vai trò Developer+ — không phải thứ mà danh sách mặc định từng phơi bày. Tiết lộ lại một key có phạm vi gateway (is_firewall_gateway) yêu cầu vai trò Admin (hoặc Owner), vì token đó có thể đọc credential của các MCP server đã đăng ký.
Liệt kê key, mở chi tiết một key, tìm kiếm, và mọi lần đọc đối tượng token đều trả về dạng đã che. Plaintext không bao giờ được bao gồm trong một danh sách hay phản hồi tìm kiếm.
Vì tiết lộ lại bị kiểm soát và một key có phạm vi gateway cần Admin để đọc lại, hãy coi bản sao lúc tạo là lần ghi lại đáng tin cậy duy nhất của bạn. Lưu nó vào secret manager ngay lập tức. Nếu bạn mất plaintext của một key thông thường, bạn có thể tiết lộ lại nó (Developer+); nếu bạn không thể tiết lộ nó và không thể khôi phục nó, hãy xoay vòng sang một key mới thay vì xoay xở quanh một key bạn không còn đọc được nữa.

​
4. Một ví dụ cụ thể: nhận diện key bị rò rỉ

Giả sử một cảnh báo kích hoạt — một key đang gọi từ một IP không mong đợi — và dòng log mang theo phần đuôi đã che …7Qm4. Bạn không cần plaintext để hành động:
  1. Mở danh sách Keys trong console (/console/token). Mỗi hàng hiển thị dấu vân tay đã che của nó — sk-orca-9f3****7Qm4 và nhãn environment của nó.
  2. Khớp phần đuôi …7Qm4 (và tag prod) với hàng vi phạm. Dạng đã che chính xác là định danh bạn cần ở đây — không secret nào bị phơi bày trong danh sách, cảnh báo, hay ảnh chụp màn hình của bạn về nó.
  3. Vô hiệu hóa key đó để tạm dừng nó, hoặc xóa nó để thu hồi vĩnh viễn — cả hai đều là các hành động an-toàn-khi-che không bao giờ in plaintext. Xem Quản lý key và Phản ứng key bị rò rỉ.
Toàn bộ phân loại chạy trên dấu vân tay đã che. Plaintext ở lại trong secret manager của bạn nơi nó thuộc về.

​
5. Che trong log và tooling của riêng bạn

Gateway che các bề mặt của chính nó; bạn kiểm soát phía của bạn. Cùng nguyên tắc áp dụng cho bất cứ nơi nào một key có thể rơi vào trong stack của bạn:
  • Không bao giờ log header Authorization hay giá trị sk-orca-… thô. Nếu bạn phải ghi lại key nào đã thực hiện một cuộc gọi, hãy log cùng hình dạng mà console dùng — tiền tố và bốn ký tự cuối — không phải secret đầy đủ.
  • Chỉ lưu plaintext trong một secret manager, không bao giờ trong source control, CI log, hay một file config được commit vào repo. Key bị che trong console chính xác để các hệ thống của riêng bạn là nơi duy nhất secret sống tồn tại.
  • Định phạm vi key hẹp để ngay cả một credential bị rò rỉ cũng có bán kính ảnh hưởng bị giới hạn — một mô hình, một dải IP, một mức trần chi tiêu. Xem Checklist least-agency.
Che giảm phơi bày khi hiển thị; nó không giảm sức mạnh của một key thật sự rò rỉ. Một dấu vân tay đã che trong một log thì an toàn, nhưng key sống trong một secret manager vẫn xác thực đầy đủ — đó là lý do phạm vi hẹp và xoay vòng nhanh quan trọng ngang với che.

​
6. Vị trí của nó trong phần còn lại của vệ sinh key

Che là một lớp của tư thế phòng-thủ-theo-chiều-sâu cho credential:

Quản lý key

Tạo, vô hiệu hóa, và thu hồi key — vòng đời đằng sau mỗi hàng đã che trong danh sách.

Đối tượng token

Mọi trường mà một key mang theo, bao gồm các giới hạn ràng buộc bán kính ảnh hưởng của một key bị rò rỉ.

Xoay vòng key

Việc chuyển giao không gián đoạn sang một key mới khi bạn không thể khôi phục hay tin tưởng một key cũ.

Phản ứng key bị rò rỉ

Phải làm gì ngay khi bạn nghi một credential bị lộ.
Để biết bức tranh lớn hơn về cách key, chính sách, và workspace lồng vào nhau để trao cho mỗi agent danh tính hẹp nhất, xem Phạm vi & key. Quy tắc đơn giản: console cho bạn thấy đủ để nhận ra một key và không bao giờ đủ để làm rò rỉ một cái. Giữ plaintext trong secret manager của bạn, dựa vào dấu vân tay đã che ở mọi nơi khác, và xoay vòng ngay thời khắc danh tính của một key bị nghi ngờ.