Chuyển đến nội dung chính
Khi một người duyệt compliance hỏi “ai đã đổi chính sách firewall này, và khi nào?”, câu trả lời là một hàng trong audit log của workspace bạn. Mọi đột biến chạm tới một tài nguyên được quản trị — một chính sách firewall, một quy tắc, một guardrail, một prompt, một quyết định phê duyệt, vai trò của một thành viên — đều ghi một hàng audit bất biến đóng dấu với actor, target, timestamp, và một động từ hành động ổn định. Trang này là bảng tra cứu cho các động từ đó: tập đầy đủ các hành động audit log, nhóm theo tài nguyên chúng mô tả, để bạn có thể lọc trail xuống đúng các event bạn cần.
Một hàng audit ghi lại ai đã làm gì với tài nguyên nào. Nó không bao giờ mang giá trị secret, plaintext gateway-key, blob quy tắc, hay body prompt — payload chỉ là metadata an toàn (id, tên, verdict, stage, is_default). Về trail thực thi của những gì một chính sách đã làm với traffic live — cuộc gọi tool bị từ chối, PII đã mask — xem các feed Firewall events và Guardrail Matches, vốn là một store riêng với audit log này.

​
1. Danh mục hành động audit log bao quát những gì

Hai thứ ghi vào audit trail, và việc giữ chúng tách biệt sẽ hữu ích:
  • Audit log — trang này. Một bản ghi chỉ-thêm về các thay đổi cấu hình và quản trị: một chính sách được sửa, một thành viên được mời, một lần phê duyệt được giải quyết. Đóng dấu với động từ hành động, actor, và khoảnh khắc nó commit, sau khi thay đổi thành công.
  • Feed thực thi — các feed Firewall events và Guardrail Matches. Bản ghi của mọi quyết định runtime mà gateway đã ra trên một request. Khối lượng cao hơn, store khác.
Các động từ hành động bên dưới là các chuỗi lower-snake-case ổn định. Chúng sống sót qua các lần đổi tên trong console, grep sạch sẽ trong một export, và là cái bạn lọc theo khi bạn cắt trail theo kiểu event.
Mọi thao tác ghi được quản trị phát ra hàng audit của nó trong cùng transaction với thay đổi, nên trail không bao giờ có thể trôi lệch khỏi thực tế — không có cửa sổ “lần sửa đã commit nhưng hàng audit thì không”.

​
2. Các hành động audit log, nhóm theo tài nguyên

OrcaRouter cung cấp một danh mục cố định các động từ hành động. Những cái bạn soạn hằng ngày rơi vào các nhóm bên dưới.
Mọi lần create / update / delete trên một chính sách firewall hoặc một trong các quy tắc của nó, cộng các thay đổi settings ở cấp workspace:firewall_policy_create · firewall_policy_update · firewall_policy_delete · firewall_rule_create · firewall_rule_update · firewall_rule_delete · firewall_settings_updatePayload chính sách mang {id, name, is_default, default_verdict, enabled}; payload quy tắc mang {id, policy_id, verdict, stage, tool_name_glob, priority}. Không bao giờ blob quy tắc đầy đủ.
Trình chọn autonomy một cú nhấp (tight / balanced / permissive) ghi một hàng khi áp dụng và một khi hoàn tác:firewall_autonomy_applied · firewall_autonomy_undoneHàng applied mang snapshot hoàn tác trước-khi-áp-dụng trong payload của nó, chính là cái mà lần hoàn tác một cú nhấp tái dựng từ đó.
Khi một người duyệt giải quyết một cuộc gọi tool đã giữ (một verdict pending_approval), quyết định được ghi lại:firewall_approval_approve · firewall_approval_rejectPayload ghi chú liệu quyết định đến qua console hay một webhook callback out-of-band — không bao giờ các argument tool.
Các hành động trên tập tool được quản trị của một MCP server đã đăng ký — khi tập tool live của nó được phát hiện khác với tập đã phê duyệt, khi một admin phê duyệt lại tập hiện tại, và khi một admin cách ly một server:firewall_mcp_schema_changed · firewall_mcp_schema_approved · firewall_mcp_schema_quarantinedPayload là {mcp_server_id, name, tool_count} — không bao giờ argument tool hay credential.
Trail pháp y cho registry prompt — tạo, sửa, soft-delete (Trash), hard-delete (Purge), khôi phục, di chuyển label, rollback phiên bản, và import từ một provider đã kết nối:prompt_created · prompt_updated · prompt_deleted · prompt_purged · prompt_restored · prompt_label_moved · prompt_rollback · prompt_importedPayload chỉ serialize metadata an toàn (id, name, kind, tag) — không bao giờ nội dung prompt hay message.
Các event vòng đời và thành viên trên chính workspace — tạo, lưu trữ, mời, đổi vai trò, gỡ bỏ, nạp ví, và thay đổi seat / group / status:workspace_create · workspace_archive · invite · invite_resend · invite_revoke · accept · member_leave · role_change · remove · workspace_topup · group_change · seats_limit_change · status_change · workspace_promote_to_team
Các lần sửa guardrail giữ lịch sử phiên bản theo từng guardrail của riêng chúng — một trail diff-và-revert đính vào mỗi chính sách — bên cạnh audit log. Khi bạn cần roll back một thay đổi chính sách nội dung, lịch sử đó là bề mặt để dùng.

​
3. Một ví dụ cụ thể: truy vết một thay đổi chính sách firewall

Giả sử một đồng đội nới lỏng một quy tắc deny tuần trước và bạn cần biết chính xác cái gì đã thay đổi. Mở ngăn kéo audit workspace trong console và lọc theo hành động firewall_rule_update. Mỗi hàng khớp cho bạn cùng một hình dạng:
TrườngNó cho bạn biết gì
Actionfirewall_rule_update — động từ bạn đã lọc theo.
ActorThành viên đã thực hiện thay đổi.
Target{id, policy_id} của quy tắc và verdict, stage, tool_name_glob, priority mới của nó.
Đó là đủ để tái dựng trước/sau của quy tắc mà không bao giờ phơi bày các mệnh đề khớp đầy đủ của nó. Nếu thay đổi thay vào đó là một lần chuyển autonomy-level, lọc theo firewall_autonomy_applied và hàng mang theo snapshot mà lần hoàn tác một cú nhấp khôi phục từ đó.
Lọc theo một động từ hành động đơn lẻ là cách nhanh nhất để trả lời một câu hỏi tại một thời điểm (“khi nào chúng ta bật auto-approve?”, “ai đã xóa chính sách đó?”). Các động từ là chuỗi ổn định, nên một bộ lọc đã lưu tiếp tục hoạt động qua các lần thiết kế lại console.

​
4. Scope, retention & xóa bỏ

Scope theo workspace

Mọi hàng audit thuộc về đúng một workspace và chỉ đọc được bên trong nó — không gì vượt qua ranh giới tenant. Actor, target, và payload đều được scope vào workspace đó. Xem Scope, key & chính sách.

Retention

Hàng audit được giữ tới 180 ngày, rồi hết hạn bởi một lần dọn dẹp nền. Request log của bạn là một store riêng với retention riêng của chúng — mặc định 30 ngày, server kẹp ở mức tối đa cứng 180 ngày.

Quyền được xóa bỏ

Khi xóa một workspace hoặc một yêu cầu xóa bỏ tường minh, OrcaRouter cấp một cửa sổ ân hạn 30 ngày, rồi xóa sạch PII khỏi log và bản ghi audit cho workspace đó. Xem bảng thuật ngữ.

Bằng chứng compliance

Audit trail là một trong các tín hiệu mà một compliance pack rút ra cho một báo cáo readiness có chữ ký. Báo cáo được ký Ed25519 và xác minh được công khai.
Đừng dùng audit log để trả lời “request này có bị chặn không?” — cái đó sống trong các feed thực thi, không phải ở đây. Audit log trả lời “chính sách này có bị đổi không, và bởi ai?”. Chúng là các store tách biệt có chủ đích với retention khác nhau và đường truy cập khác nhau. Xem Tại sao bị chặn? cho phía runtime.

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

Khả năng quan sát firewall

Các feed event, run, và discovered-tools — bản ghi thực thi runtime bổ trợ cho trail cấu hình này.

Bảng thuật ngữ verdict

Mọi verdict firewall và hành động guardrail mà trail tham chiếu, với trạng thái HTTP và tác động quota.

Compliance API

Biến trail thành một báo cáo readiness có chữ ký, chia-sẻ-được-cho-auditor.

Scope, key & chính sách

Cách scope workspace giới hạn những gì bất kỳ một hàng audit nào có thể phơi bày.