Cẩm nang bảo mật Codex

Sử dụng hướng dẫn này khi nhân viên cần đăng nhập Codex qua không gian làm việc ChatGPT của công ty và cấm sử dụng tài khoản ChatGPT cá nhân cũng như xác thực bằng API key trên các thiết bị đầu cuối được quản lý.

Kết quả mong muốn

Trên các thiết bị do công ty quản lý, Codex chỉ chấp nhận đăng nhập bằng ChatGPT vào không gian làm việc ChatGPT của công ty.

Điều kiện tiên quyết

• UUID của không gian làm việc ChatGPT Enterprise đã được phê duyệt.

• Phương thức phân phối cấu hình Codex được quản lý đến các thiết bị đầu cuối.

• Quyết định cấm xác thực bằng API key trên các thiết bị đầu cuối được quản lý.

Cấu hình

1. Ghi lại UUID của không gian làm việc đã được phê duyệt trong kho cấu hình nội bộ.

2. Thêm các yêu cầu xác thực bắt buộc vào requirements.toml cục bộ:

   allowed_login_methods = ["chatgpt"]
   allowed_chatgpt_workspaces = ["00000000-0000-0000-0000-000000000000"]

Khóa đầu tiên chỉ cho phép xác thực bằng ChatGPT; khóa thứ hai giới hạn đăng nhập vào không gian làm việc đã được phê duyệt. Thay UUID minh họa bằng UUID của không gian làm việc của bạn. Xem tài liệu tham khảo về yêu cầu.

3. Triển khai qua requirements.toml cục bộ hoặc các yêu cầu macOS MDM bằng những đường dẫn trong Đặt cấu hình ở đâu. Các yêu cầu xác thực này áp dụng trước khi thông tin xác thực được nạp và trước khi chính sách đám mây được truy xuất; Codex bỏ qua chúng trong yêu cầu được quản lý trên đám mây. Bảo vệ tệp và thư mục mẹ khỏi việc người dùng sửa đổi. Các giá trị mặc định managed_config.toml cũ không thực thi hạn chế này.

4. Trong giai đoạn thí điểm, cho người dùng đăng xuất hoặc xóa các phiên Codex cá nhân đã lưu trước đó. Đừng mặc định rằng chính sách mới sẽ vô hiệu hóa hồi tố một phiên hiện có.

5. Kết hợp hạn chế đăng nhập với vai trò và quyền truy cập theo nhóm trong không gian làm việc. Xác thực kiểm soát danh tính nào đăng nhập; RBAC kiểm soát những tính năng Codex mà danh tính đó được phép sử dụng. Xem Xác thực.

Xác minh

• Đăng xuất khỏi Codex.

• Thử đăng nhập bằng tài khoản ChatGPT cá nhân. Dự kiến: Đăng nhập vào không gian làm việc cá nhân bị từ chối.

• Thử đăng nhập Codex bằng API key. Dự kiến: Đăng nhập bằng API key bị từ chối.

• Đăng nhập vào không gian làm việc đã được phê duyệt bằng tài khoản công ty. Dự kiến: Đăng nhập thành công.

• Khởi động lại ứng dụng máy tính, CLI và tiện ích mở rộng IDE, rồi lặp lại.

Khôi phục

Khôi phục các yêu cầu xác thực cục bộ trước đó và triển khai lại gói đã được rà soát.

Giới hạn

Biện pháp này kiểm soát các ứng dụng khách Codex được quản lý trên thiết bị đầu cuối được quản lý. Kết hợp với các biện pháp kiểm soát ứng dụng trên thiết bị đầu cuối và chính sách mạng nếu yêu cầu là “không sử dụng Codex cá nhân từ tài sản của công ty”.

Sử dụng hướng dẫn này khi nhà phát triển cần quyền chỉ đọc hoặc quyền trong phạm vi không gian làm việc, và bạn muốn ngăn họ chọn Quyền truy cập đầy đủ hoặc bỏ qua phê duyệt và môi trường cô lập bằng --yolo.

Kết quả mong muốn

Người dùng chỉ có thể chọn các hồ sơ chỉ đọc hoặc trong phạm vi không gian làm việc đã được phê duyệt. Họ không thể chọn danger-full-access, approval_policy = "never" hoặc --yolo.

Cấu hình

1. Định nghĩa một hồ sơ không gian làm việc đã được phê duyệt:

   [permissions.corp-workspace]
   description = "Company workspace access with no unrestricted host access."
   extends = ":workspace"

2. Thực thi các hồ sơ và chính sách phê duyệt được phép:

   allowed_approval_policies = ["on-request", "untrusted"]
   allowed_approvals_reviewers = ["user"]
   default_permissions = "corp-workspace"

   [allowed_permission_profiles]
   ":read-only" = true
   "corp-workspace" = true
   ":danger-full-access" = false

Danh sách cho phép này là toàn bộ tập hợp được phép: các hồ sơ không có trong danh sách hoặc được đặt thành false đều bị từ chối, kể cả hồ sơ được thêm trong các phiên bản tương lai. Xem Tài liệu tham khảo cấu hình.

3. Với các ứng dụng khách cũ vẫn sử dụng sandbox_mode, hãy dùng:

   allowed_approval_policies = ["on-request", "untrusted"]
   allowed_sandbox_modes = ["read-only", "workspace-write"]

4. Phân phối cấu hình này dưới dạng yêu cầu do quản trị viên thực thi, không phải tệp cấu hình mà người dùng có thể chỉnh sửa.

5. Nếu sau này cho phép Tự động rà soát, hãy chủ động thêm tính năng đó sau khi kiểm thử. Tự động rà soát thay đổi đối tượng rà soát việc vượt ranh giới; tính năng này không khôi phục ranh giới đã bị loại bỏ. Xem Tự động rà soát.

Xác minh

• Mở bộ chọn quyền. Dự kiến: Quyền truy cập đầy đủ không khả dụng hoặc bị từ chối.

• Khởi chạy với --dangerously-bypass-approvals-and-sandbox. Dự kiến: Codex từ chối khởi chạy hoặc buộc dùng hồ sơ tương thích.

• Khởi chạy với --sandbox danger-full-access --ask-for-approval never. Dự kiến: Việc khởi chạy bị từ chối.

• Chạy một tác vụ thông thường trong không gian làm việc. Dự kiến: Tác vụ thành công; việc vượt ranh giới vẫn yêu cầu phê duyệt.

Khôi phục

Khôi phục gói yêu cầu trước đó. Tiếp tục chặn quyền truy cập không hạn chế trừ khi có ngoại lệ được phê duyệt riêng.

Giới hạn

Biện pháp này kiểm soát quyền lúc chạy của Codex. Nó không biến tài khoản hệ điều hành có đặc quyền thành tài khoản không có đặc quyền.

Sử dụng hướng dẫn này khi tổ chức cần quyết định những MCP server mà Codex được phép sử dụng và thực thi danh sách đã được phê duyệt.

Cho phép máy chủ và cấu hình máy chủ là hai bước riêng biệt. Một mục trong danh sách cho phép cấp quyền cho máy chủ khớp với mục đó; mục này không tạo cấu hình máy chủ. Hãy cấu hình máy chủ riêng với tên và danh tính khớp, cùng phương thức xác thực mà máy chủ yêu cầu.

Kết quả mong muốn

Codex chỉ bật các MCP server có tên và danh tính được cấu hình khớp với danh sách do doanh nghiệp phê duyệt.

Cấu hình

1. Kiểm kê từng máy chủ đã được phê duyệt: chủ sở hữu, mục đích, phương thức truyền tải, tệp thực thi hoặc URL chính xác, xác thực, phân loại dữ liệu và các công cụ có khả năng ghi.

2. Bắt đầu bằng việc từ chối tất cả. Một bảng được quản lý để trống sẽ vô hiệu hóa mọi MCP server:

   [mcp_servers]

3. Thêm các máy chủ HTTP đã được phê duyệt theo URL chính xác:

   [mcp_servers.internal_docs]
   identity = { url = "https://mcp.example.com/docs" }

4. Thêm các máy chủ stdio đã được phê duyệt theo tệp thực thi và đối số vị trí:

   [mcp_servers.internal_build.identity]
   command = { executable = "/usr/local/bin/company-mcp", args = [
     { match = "exact", value = "serve" },
     { match = "prefix", value = "--workspace=" },
   ] }

Bộ so khớp có cấu trúc kiểm tra tệp thực thi, số lượng đối số và thứ tự đối số. Nó không ràng buộc cwd, env hoặc env_vars. Hãy coi việc kiểm soát toàn bộ ngữ cảnh khởi chạy là điều kiện tiên quyết để phê duyệt máy chủ stdio: bảo vệ tệp thực thi và các phần phụ thuộc, đồng thời ngăn cấu hình người dùng hoặc dự án không đáng tin cậy cung cấp thư mục làm việc hay môi trường có thể thay đổi hành vi của máy chủ. Nếu không thể thực thi ranh giới đó một cách độc lập, hãy giữ máy chủ stdio ở trạng thái chưa được phê duyệt và dùng máy chủ HTTP đã được rà soát thay thế.

5. Thêm riêng các danh tính MCP đi kèm plugin trong plugins.<plugin>.mcp_servers.<server>.

6. Lưu danh sách đã được phê duyệt trong kho cấu hình được rà soát và triển khai thông qua các yêu cầu do quản trị viên thực thi.

Ứng dụng khách chỉ bật máy chủ khi cả tên lẫn danh tính đều khớp với một mục đã được phê duyệt. Xem Cấu hình được quản lý.

Xác minh

• Cấu hình chính xác máy chủ đã được phê duyệt. Dự kiến: Máy chủ khởi động.

• Thay đổi một ký tự trong URL. Dự kiến: Máy chủ bị vô hiệu hóa.

• Thay đổi số lượng hoặc thứ tự đối số stdio, hoặc cung cấp đối số nằm ngoài các quy tắc đối số đã cấu hình. Dự kiến: Máy chủ bị vô hiệu hóa. Các giá trị vẫn đáp ứng tiền tố được phép thì vẫn được phép.

• Trong một dự án đáng tin cậy dùng một lần, thử các giá trị ghi đè cwd, env và env_vars vô hại, đồng thời giữ nguyên tệp thực thi và các đối số khớp. Chỉ so khớp danh tính không từ chối các giá trị ghi đè này. Xác minh rằng biện pháp kiểm soát ngữ cảnh khởi chạy độc lập của bạn từ chối các giá trị ghi đè không an toàn hoặc máy chủ stdio vẫn chưa được phê duyệt; không sử dụng tải trọng chèn mã thực sự.

• Thêm một tên chưa được phê duyệt. Dự kiến: Máy chủ bị vô hiệu hóa.

• Kiểm thử máy chủ đi kèm plugin. Dự kiến: Máy chủ chỉ hoạt động với danh tính đã được phê duyệt.

Khôi phục

Xóa mục vừa thêm. Để dừng ngay toàn bộ việc sử dụng MCP, hãy triển khai bảng mcp_servers để trống.

Giới hạn

Danh sách cho phép danh tính không chứng minh rằng các công cụ, dữ liệu thượng nguồn, thông tin xác thực hoặc môi trường khởi chạy của máy chủ là an toàn. Các tiến trình MCP stdio cục bộ chạy bên ngoài môi trường cô lập lệnh cục bộ; việc khớp tệp thực thi và đối số không giới hạn quyền truy cập của máy chủ hoặc ngăn nạp mã dựa trên môi trường. Hãy rà soát độc lập toàn bộ ngữ cảnh khởi chạy và quyền của máy chủ. Xem Yêu cầu về danh tính MCP.

Sử dụng hướng dẫn này khi đội ngũ bảo mật cần hiểu Codex đang làm gì trên thiết bị đầu cuối và trong mạng của bạn. Hướng dẫn tập hợp các sự kiện về lượt chạy và công cụ, quyết định phê duyệt, bản ghi kiểm toán không gian làm việc và nhật ký mạng để phục vụ điều tra.

Kết quả mong muốn

Đội ngũ bảo mật có thể đối chiếu các lượt chạy Codex, quyết định về công cụ, phê duyệt, bản ghi kiểm toán không gian làm việc và lưu lượng mạng đi ra thực tế mà không dựa vào lời tường thuật của chính mô hình.

Sử dụng bốn nguồn bằng chứng

1. Codex OpenTelemetry: các sự kiện về lượt chạy, API, mô hình, môi trường cô lập, phê duyệt và công cụ.

2. Hook vòng đời được quản lý: bản ghi phía thiết bị đầu cuối liên quan đến việc sử dụng công cụ và yêu cầu quyền.

3. Nhật ký proxy hoặc cổng mạng: đích đến DNS/HTTP thực tế và kết quả kết nối.

4. Compliance API: bản ghi kiểm toán và điều tra ở cấp không gian làm việc.

Không nguồn đơn lẻ nào cung cấp khả năng giám sát mạng đầy đủ.

Cấu hình

1. Gửi nhật ký Codex OpenTelemetry đến bộ thu thập của bạn, với nội dung prompt gốc được che đi:

   [otel]
   environment = "enterprise"
   log_user_prompt = false

   [otel.exporter.otlp-http]
   endpoint = "https://otel.example.com/v1/logs"
   protocol = "binary"
   headers = { "x-otlp-api-key" = "${OTLP_TOKEN}" }

Cung cấp OTLP_TOKEN cho tiến trình Codex qua trình quản lý bí mật đã được phê duyệt hoặc môi trường tiến trình trước khi khởi động ứng dụng khách. Không đưa token vào tệp TOML được triển khai hoặc hệ thống quản lý mã nguồn.

Codex có thể phát ra các sự kiện bắt đầu cuộc hội thoại, yêu cầu API, sự kiện truyền luồng, siêu dữ liệu prompt, quyết định về công cụ và kết quả công cụ. Xem Cấu hình nâng cao.

2. Triển khai OTel bên ngoài cấu hình cục bộ của dự án. Các tệp .codex/config.toml của dự án không thể ghi đè định tuyến dữ liệu đo từ xa.

3. Thêm hook vòng đời được quản lý cho SessionStart, PreToolUse, PermissionRequest, PostToolUse, Stop và SessionEnd.

4. Cài đặt các tập lệnh hook trong thư mục do quản trị viên quản lý và đặt allow_managed_hooks_only = true nếu cần bỏ qua hook của người dùng, dự án và plugin.

5. Định tuyến lưu lượng lệnh trong môi trường cô lập qua một proxy có nhật ký độc lập. OTel ghi nhận công cụ đã chạy; proxy ghi nhận nơi tiến trình con đã cố kết nối.

6. Cấu hình dữ liệu đo từ xa riêng cho tìm kiếm web, ứng dụng, trình kết nối, MCP server, hoạt động trình duyệt và Codex Cloud. Các quy tắc proxy lệnh cục bộ không tự động bao phủ chúng.

7. Truyền liên tục các bản ghi Compliance API được hỗ trợ vào SIEM và áp dụng các biện pháp kiểm soát riêng về lưu giữ và bảo toàn dữ liệu phục vụ pháp lý. Xem Compliance API và sự kiện kiểm toán.

8. Đối chiếu người dùng hoặc tài khoản dịch vụ, máy chủ hoặc trình chạy, ID cuộc hội thoại, mô hình, phiên bản ứng dụng khách, hồ sơ quyền, quyết định phê duyệt, đích đến và tên công cụ.

Xác minh

Chạy một phiên có kiểm soát thực hiện các thao tác sau:

• Đọc một tệp được phép.

• Thử đọc một tệp bị chặn.

• Chạy một lệnh được phép.

• Thử gửi một yêu cầu đi ra bị chặn.

• Yêu cầu phê duyệt và nhận quyết định từ chối.

• Kết thúc phiên.

Kết quả dự kiến theo nguồn bằng chứng:

• OTel hiển thị các sự kiện về lượt chạy và công cụ.

• Hook hiển thị vòng đời phiên.

• Nhật ký proxy hiển thị các đích đến được phép và bị chặn.

• Quy trình thu nạp dữ liệu Compliance nhận được các bản ghi được hỗ trợ.

• SIEM đối chiếu các bản ghi đó với người dùng hoặc khối lượng công việc.

Khôi phục

Vô hiệu hóa bộ xuất và hook bằng cách khôi phục cấu hình trước đó. Không loại bỏ việc ghi nhật ký proxy độc lập khi khôi phục cấu hình đo từ xa.

Giới hạn

Không cam kết rằng dữ liệu đo từ xa của Codex ghi lại mọi đối số lệnh, byte đầu ra hoặc gói tin mạng. Hãy ghi rõ phạm vi bao phủ của từng lớp.

Sử dụng hướng dẫn này khi Codex không được phép truy cập internet hoặc chỉ được kết nối đến các đích đã được phê duyệt. Chọn quy trình cục bộ hoặc đám mây cho môi trường bạn đang cấu hình và lưu ý phạm vi chính sách riêng của từng quy trình.

Kết quả mong muốn

Codex không có quyền truy cập internet hoặc chỉ kết nối đến các miền đã được phê duyệt, tùy theo cấu hình bạn chọn. Môi trường Codex Cloud (Legacy) còn có thể hạn chế các phương thức HTTP.

Cấu hình Codex Cloud hiện tại

1. Tạo các môi trường riêng cho những mức độ tin cậy khác nhau, chẳng hạn no-internet-review, approved-dependencies-build và cyber-lab.

2. Trong cấu hình môi trường, để Cho phép Codex truy cập internet ở trạng thái tắt trừ khi quy trình cần truy cập internet.

3. Khi cần truy cập, bật Cho phép Codex truy cập internet. Trong Cho phép miền, chọn Chỉ các miền tùy chỉnh, rồi thêm chính xác các máy chủ cần thiết trong Các miền được phép bổ sung.

4. Lưu và kiểm thử các dịch vụ trong quá trình thiết lập. Công bố hoặc công bố lại môi trường, sau đó kiểm thử quyền truy cập đến các đích đã được phê duyệt và chưa được phê duyệt trong một tác vụ mới. Rà soát riêng các tập lệnh thiết lập: cố định phiên bản phần phụ thuộc, ưu tiên các máy chủ mirror đã được phê duyệt và tránh tải xuống tệp thực thi chưa được rà soát.

Xem Kết nối đến dịch vụ. Các thiết lập Codex Cloud hiện tại không cung cấp bộ chọn phương thức HTTP của Legacy.

Cấu hình Codex Cloud (Legacy)

1. Giữ quyền truy cập internet của tác nhân ở trạng thái Tắt khi không cần thiết. Legacy Cloud mặc định chặn internet trong giai đoạn tác nhân; các tập lệnh thiết lập vẫn chạy với quyền truy cập internet để cài đặt phần phụ thuộc.

2. Khi tác nhân cần truy cập, chuyển sang Bật với danh sách cho phép có phạm vi hẹp. Bắt đầu với Không có rồi thêm chính xác từng miền.

3. Với quy trình chỉ tải xuống, chỉ cho phép GET, HEAD và OPTIONS. Điều này chặn POST, PUT, PATCH, DELETE và các phương thức khác. Rà soát riêng các tập lệnh thiết lập vì hạn chế trong giai đoạn tác nhân không chi phối quyền truy cập internet của chúng.

Xem Quyền truy cập internet của tác nhân Legacy. Các thiết lập sẵn và biện pháp kiểm soát phương thức HTTP này chỉ áp dụng cho Legacy Cloud.

Cấu hình Codex cục bộ

1. Trong requirements.toml do quản trị viên quản lý, định nghĩa và chọn hồ sơ mạng đã được phê duyệt, đồng thời giới hạn người dùng chỉ được dùng hồ sơ đó:

   default_permissions = "corp-build"

   [allowed_permission_profiles]
   "corp-build" = true

   [permissions.corp-build]
   description = "Workspace access with approved dependency destinations."
   extends = ":workspace"

   [permissions.corp-build.network]
   enabled = true
   allow_local_binding = false

   [permissions.corp-build.network.domains]
   "registry.npmjs.org" = "allow"
   "pypi.org" = "allow"
   "files.pythonhosted.org" = "allow"

2. Triển khai gói yêu cầu đã được rà soát theo Cấu hình được quản lý. Chỉ có hồ sơ được đặt tên thì chưa kích hoạt hồ sơ đó; default_permissions chọn hồ sơ, còn danh sách cho phép ngăn chọn các hồ sơ khác.

3. Kích hoạt proxy do quản trị viên quản lý trong cùng gói yêu cầu để các hạn chế miền được thực thi và người dùng không thể mở rộng chúng. Triển khai proxy và hồ sơ có bật mạng cùng nhau; hồ sơ có bật mạng mà không có proxy hoạt động sẽ cấp quyền truy cập mạng trực tiếp mà không thực thi các quy tắc miền:

   Thận trọng: [experimental_network] đang ở giai đoạn thử nghiệm và có thể thay đổi. Xác thực trên từng phiên bản ứng dụng khách cục bộ và hệ điều hành được hỗ trợ trước khi triển khai rộng hơn. Khả năng hỗ trợ Windows còn hạn chế; không áp dụng chính sách này cho người dùng Windows cho đến khi bạn đã kiểm thử việc thực thi trong môi trường của mình.

   [experimental_network]
   enabled = true
   managed_allowed_domains_only = true

   [experimental_network.domains]
   "registry.npmjs.org" = "allow"
   "pypi.org" = "allow"
   "files.pythonhosted.org" = "allow"

4. Giữ tính năng liên kết cổng cục bộ ở trạng thái tắt trừ khi quy trình cần đến. Cấu hình riêng quyền truy cập các đích mạng riêng; cho phép một miền không tự động phê duyệt các địa chỉ riêng của miền đó. Xem Yêu cầu về quyền truy cập mạng.

5. Cấu hình riêng tìm kiếm web, ứng dụng, MCP server, hoạt động trình duyệt và Codex Cloud. Các quy tắc môi trường cô lập cục bộ không kiểm soát chúng.

Xác minh

• Gửi yêu cầu đến một miền đã được phê duyệt và xác nhận yêu cầu thành công.

• Gửi yêu cầu đến một miền chưa được phê duyệt và xác nhận yêu cầu bị chặn.

• Gửi yêu cầu đến localhost, một IP riêng và một điểm cuối siêu dữ liệu đám mây. Xác nhận từng yêu cầu đều bị chặn trừ khi được phê duyệt rõ ràng.

• Trong Codex Cloud (Legacy), thử gửi yêu cầu POST đến một miền được phép. Xác nhận yêu cầu bị chặn khi chỉ cho phép GET, HEAD và OPTIONS.

• Xác nhận nhật ký proxy hoặc cổng mạng có các mục cho cả yêu cầu được phép lẫn bị từ chối.

Khôi phục

Đưa môi trường về trạng thái Tắt hoặc khôi phục chính sách miền trước đó. Tránh khôi phục về trạng thái internet không hạn chế.

Giới hạn

Việc nâng quyền để thoát hoàn toàn khỏi môi trường cô lập đã được phê duyệt có thể bỏ qua proxy lệnh cục bộ. Hãy kiểm thử riêng các lệnh thông thường trong môi trường cô lập và các lệnh nâng quyền đã được phê duyệt trước khi dựa vào hạn chế này.

Một miền được phép vẫn có thể chứa nội dung chèn chỉ dẫn độc hại, gói đã bị xâm phạm hoặc tài liệu không an toàn.

Sử dụng hướng dẫn này khi Codex cần truy cập các thư mục mã nguồn đã được phê duyệt, trong khi bí mật, tệp .env, khóa SSH và các kho mã không liên quan phải nằm ngoài tầm truy cập. Hướng dẫn bao gồm việc hạn chế quyền truy cập tệp và giảm số lượng biến môi trường chứa thông tin xác thực được truyền cho các lệnh được khởi chạy.

Kết quả mong muốn

Codex có thể làm việc trong các thư mục mã nguồn đã được phê duyệt nhưng không thể đọc các tệp thường chứa bí mật hoặc kế thừa nhiều biến môi trường chứa thông tin xác thực.

Cấu hình

1. Định nghĩa các mẫu từ chối đọc trong một hồ sơ không gian làm việc:

   [permissions.corp-workspace]
   description = "Workspace edits with secret-bearing paths denied."
   extends = ":workspace"

   [permissions.corp-workspace.filesystem]
   glob_scan_max_depth = 6

   [permissions.corp-workspace.filesystem.":workspace_roots"]
   "**/.env*" = "deny"
   "**/*.pem" = "deny"
   "**/*.p12" = "deny"
   "**/id_*" = "deny"
   "**/.aws/**" = "deny"
   "**/.kube/**" = "deny"

2. Thêm các đường dẫn từ chối chính xác cho những thư mục thông tin xác thực, khóa ký, cấu hình production và kho mã lân cận đã biết.

3. Trong /etc/codex/config.toml của hệ thống hoặc ~/.codex/config.toml của người dùng, giảm các biến môi trường được truyền cho các lệnh được khởi chạy:

   [shell_environment_policy]
   inherit = "core"
   ignore_default_excludes = false

   [shell_environment_policy.filters]
   "AWS_*" = "exclude"
   "AZURE_*" = "exclude"
   "GITHUB_*" = "exclude"
   "*_TOKEN" = "exclude"
   "*_SECRET" = "exclude"
   "*_PASSWORD" = "exclude"

Đây là giá trị mặc định mà người dùng có thể cấu hình, không phải yêu cầu bắt buộc. Nó giảm các biến được kế thừa nhưng không ngăn truy cập tệp thông tin xác thực, trình trợ giúp, nội dung khởi động shell hoặc các danh tính khác. Xem Cấu hình nâng cao.

4. Trong requirements.toml do quản trị viên quản lý, chọn hồ sơ bị hạn chế và chỉ cho phép hồ sơ đó. Các hồ sơ tích hợp sẵn không kế thừa các quy tắc từ chối tệp bí mật của hồ sơ này:

   default_permissions = "corp-workspace"

   [allowed_permission_profiles]
   "corp-workspace" = true
   ":danger-full-access" = false

5. Chọn quy trình xử lý thông tin xác thực cho môi trường Cloud của bạn:

   • Trong Codex Cloud hiện tại, sử dụng Bí mật mạng cho thông tin xác thực được gửi đến dịch vụ HTTPS được phép. Chương trình nhận một giá trị giữ chỗ và proxy thay thế bằng giá trị thực cho các đích đã được phê duyệt trên cổng 443 trong quá trình thiết lập và thực hiện tác vụ. Thông tin xác thực gốc không được đặt trong tiến trình hoặc tệp cục bộ. Chương trình có thể truy cập các biến môi trường trực tiếp. Xem Biến môi trường và bí mật mạng.
   • Trong Codex Cloud (Legacy), bí mật hỗ trợ xác thực trong giai đoạn thiết lập và được xóa trước giai đoạn tác nhân; biến môi trường được giữ lại trong toàn bộ cuộc trò chuyện. Xem Môi trường Legacy Cloud.

6. Nếu tác nhân cần xác thực, sử dụng một dịch vụ trung gian độc lập để cung cấp thông tin xác thực ngắn hạn, giới hạn đúng đích và hành động cụ thể. Xem Cấu hình khuyến nghị.

Xác minh

Tạo các tệp và giá trị kiểm thử vô hại:

.env.test
test-key.pem
.aws/credentials
.kube/config

Sau đó yêu cầu Codex:

• Đọc một tệp thông thường.

• Đọc từng tệp kiểm thử.

• Tìm kiếm đệ quy các bí mật.

• In môi trường lệnh của nó.

• Đọc một kho mã lân cận.

Dự kiến: Đọc tệp thông thường thành công; các tệp bị từ chối và kho mã lân cận vẫn không thể truy cập, còn các biến bị loại trừ không xuất hiện trong môi trường lệnh.

Khôi phục

Khôi phục hồ sơ trước đó, nhưng giữ lại các quy tắc từ chối tệp bí mật có độ tin cậy cao trong khi điều tra lỗi quy trình.

Giới hạn

Các quy tắc từ chối của hệ thống tệp không xóa những bí mật đã được dán vào prompt, commit vào mã nguồn có thể đọc, trả về qua trình kết nối hoặc ghi vào nhật ký mà mô hình có thể truy cập.

Sử dụng hướng dẫn này khi các hành động như git push, triển khai, di chuyển cơ sở dữ liệu và lệnh CLI đám mây cần được phê duyệt trước khi chạy. Quyết định lệnh nào cần yêu cầu rà soát và lệnh nào phải bị cấm, sau đó cấu hình quy tắc cho các lệnh đó.

Kết quả mong muốn

Các lệnh nhạy cảm luôn tạm dừng để chờ phê duyệt hoặc bị cấm, ngay cả khi mô hình cho rằng chúng phù hợp.

Cấu hình

1. Quyết định lệnh nào cần yêu cầu phê duyệt và lệnh nào bị cấm.

2. Thêm các quy tắc lệnh do quản trị viên thực thi:

   [rules]
   prefix_rules = [
     { pattern = [{ token = "git" }, { any_of = ["push", "commit"] }], decision = "prompt", justification = "Require review before mutating shared Git state." },
     { pattern = [{ token = "terraform" }, { token = "apply" }], decision = "prompt", justification = "Require review before infrastructure changes." },
     { pattern = [{ token = "kubectl" }, { any_of = ["apply", "delete", "patch"] }], decision = "prompt", justification = "Require review before Kubernetes changes." },
     { pattern = [{ token = "rm" }], decision = "forbidden", justification = "Destructive removal is not permitted in managed Codex workflows." },
   ]

Quy tắc trong yêu cầu có thể yêu cầu phê duyệt hoặc cấm một lệnh; chúng không thể cho phép lệnh. Xem Cấu hình được quản lý.

3. Với các hồ sơ có rủi ro cao, thêm một mục trình bao shell vào cùng mảng prefix_rules khi trình bao có thể che khuất lệnh nhạy cảm:

   { pattern = [{ any_of = ["bash", "sh", "zsh"] }], decision = "prompt", justification = "Review shell wrappers that could obscure sensitive commands." },

Mục trình bao shell tạo ra nhiều yêu cầu phê duyệt; hãy sử dụng có chọn lọc.

4. Nếu lệnh phải được con người phê duyệt, hãy thực thi các thiết lập sau:

   allowed_approval_policies = ["on-request", "untrusted"]
   allowed_approvals_reviewers = ["user"]

Tự động rà soát thay đổi đối tượng rà soát; tính năng này không phải bảo đảm bảo mật có tính xác định. Xem Tự động rà soát.

5. Gửi các sự kiện PermissionRequest, tool-decision và tool-result đến quy trình xử lý bảo mật.

Xác minh

• Chạy git status. Dự kiến: Không xuất hiện yêu cầu phê duyệt.

• Chạy git push. Dự kiến: Xuất hiện yêu cầu phê duyệt.

• Chạy terraform apply. Dự kiến: Xuất hiện yêu cầu phê duyệt.

• Chạy kubectl delete pod test. Dự kiến: Xuất hiện yêu cầu phê duyệt.

• Chạy rm -rf test-directory. Dự kiến: Lệnh bị cấm.

• Từ chối một yêu cầu phê duyệt. Dự kiến: Lệnh không chạy và quyết định từ chối được ghi nhật ký.

• Khởi động lại ứng dụng khách và lặp lại các bước kiểm tra. Dự kiến: Quy tắc vẫn được thực thi.

Khôi phục

Khôi phục gói yêu cầu trước đó. Thu hẹp mẫu token quá rộng thay vì loại bỏ toàn bộ một nhóm lệnh nhạy cảm.

Giới hạn

Quy tắc tiền tố không phải là một bộ máy chính sách hệ điều hành hoàn chỉnh. Kết hợp chúng với môi trường cô lập, tài khoản hệ điều hành có đặc quyền tối thiểu, hạn chế mạng, IAM đám mây, bảo vệ nhánh, phê duyệt triển khai và phân quyền cơ sở dữ liệu.

Sử dụng các hướng dẫn cấu hình sau: Giới hạn hồ sơ quyền và Quyền truy cập đầy đủ; Bảo vệ bí mật và các kho mã không liên quan; Yêu cầu phê duyệt các lệnh nhạy cảm.

Nhà phát triển có quyền truy cập production hợp lệ, nhưng bạn muốn Codex hỗ trợ phát triển mà không thực hiện các thay đổi production chưa được rà soát.

• Định nghĩa một hồ sơ không gian làm việc đã được phê duyệt và thực thi các hồ sơ cùng chính sách phê duyệt được phép. Phân phối các thiết lập này dưới dạng yêu cầu do quản trị viên thực thi để ngăn người dùng ghi đè.

• Chạy Codex bằng một danh tính riêng có đặc quyền thấp hơn hoặc trong môi trường không thể truy cập hay lấy được thông tin xác thực có quyền ghi vào production. Nhà phát triển có thể giữ quyền truy cập production thông qua một quy trình riêng đã được cấp phép.

• Giảm thiểu các biến môi trường được truyền cho các lệnh được khởi chạy. Nếu tác nhân cần xác thực, sử dụng một dịch vụ trung gian độc lập để cung cấp thông tin xác thực ngắn hạn, giới hạn đúng đích và hành động cụ thể.

• Quyết định lệnh nào cần yêu cầu phê duyệt và lệnh nào bị cấm. Yêu cầu con người phê duyệt các lệnh có tác động lớn được chọn, chẳng hạn git push, terraform apply, thay đổi Kubernetes và di chuyển cơ sở dữ liệu; cấm những lệnh tuyệt đối không được chạy.

• Duy trì việc thực thi IAM production, bảo vệ nhánh và phê duyệt triển khai độc lập với Codex.

Giới hạn hồ sơ quyền và yêu cầu con người rà soát

Trong requirements.toml do quản trị viên quản lý, cho phép các hồ sơ không gian làm việc và chỉ đọc tích hợp sẵn, đồng thời yêu cầu người dùng rà soát những hành động cần phê duyệt:

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["user"]
default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true

Hồ sơ không gian làm việc cho phép làm việc trong không gian làm việc, trong phạm vi môi trường cô lập của nó; hồ sơ chỉ đọc dành cho công việc có phạm vi hẹp hơn. Các hồ sơ truy cập đầy đủ không nằm trong danh sách cho phép.

Đặt approval_policy = "on-request" trong cấu hình ứng dụng khách nếu ứng dụng khách cần một lựa chọn tương thích được chỉ định rõ. on-request cho phép hiển thị yêu cầu phê duyệt khi cần; nó không yêu cầu phê duyệt cho mọi lệnh. Thêm quy tắc rõ ràng cho những hành động cần rà soát và duy trì cơ chế cấp phép production độc lập.

Danh sách cho phép hồ sơ được quản lý yêu cầu Codex 0.138.0 trở lên; với ứng dụng khách cũ hơn, hãy sử dụng và kiểm thử các yêu cầu về chế độ môi trường cô lập cũ đã được ghi trong tài liệu.

Khởi động lại từng ứng dụng khách thí điểm, xác minh hồ sơ đã được phê duyệt hoạt động và hồ sơ truy cập đầy đủ không được phép bị từ chối.

Tách danh tính Codex khỏi thông tin xác thực production

Trong hệ thống quản lý thiết bị hoặc cấp phát môi trường phát triển, tạo người dùng Codex, container hoặc máy chủ phát triển chuyên dụng, chỉ có quyền truy cập mã nguồn và các dịch vụ phát triển cần thiết. Không gắn các tệp thông tin xác thực production, trình trợ giúp token hoặc chuỗi khóa của nhà phát triển vào môi trường đó, đồng thời ngăn danh tính này có được các vai trò có quyền ghi vào production.

Nếu tác nhân cần truy cập dịch vụ, cấu hình dịch vụ trung gian cấp thông tin xác thực của tổ chức để cấp thông tin xác thực ngắn hạn, giới hạn cho tài nguyên và hành động phát triển. Nhà phát triển có thể sử dụng danh tính thông thường của mình qua một quy trình production riêng đã được cấp phép.

Ví dụ, trong AWS IAM, mở Vai trò, chọn vai trò phát triển Codex, rồi trong Quyền, thêm một chính sách nội tuyến đã được rà soát như chính sách dưới đây, thay tài khoản và vai trò bằng giá trị của bạn:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAssumeExampleProductionRole",
      "Effect": "Deny",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::111122223333:role/ExampleProductionRole"
    }
  ]
}

Ví dụ này từ chối các nỗ lực đảm nhận vai trò được nêu tên, nhưng không từ chối các nỗ lực đảm nhận những vai trò khác. Đồng thời xóa các quyền production trực tiếp, hạn chế những vai trò production và nguồn thông tin xác thực khác, đồng thời rà soát các chính sách tin cậy và biện pháp kiểm soát ở cấp tổ chức.

Kiểm thử vai trò phát triển với các quyền phát triển và sản xuất điển hình mà không thực hiện thay đổi trên môi trường sản xuất. Xem Ví dụ về chính sách vai trò AWS IAM.

Tối giản môi trường shell

Trong /etc/codex/config.toml để thiết lập cấu hình ban đầu cho toàn hệ thống, hoặc ~/.codex/config.toml cho một người dùng, hãy cấu hình những biến môi trường mà các lệnh được khởi chạy sẽ kế thừa:

[shell_environment_policy]
inherit = "core"
ignore_default_excludes = false

[shell_environment_policy.filters]
"AWS_*" = "exclude"
"AZURE_*" = "exclude"
"GITHUB_*" = "exclude"
"*_TOKEN" = "exclude"
"*_SECRET" = "exclude"
"*_PASSWORD" = "exclude"

Đây là giá trị mặc định có thể cấu hình, không phải ranh giới bảo vệ thông tin xác thực được thực thi bắt buộc. Cài đặt của người dùng, quá trình khởi tạo hoặc ảnh chụp trạng thái shell, trình trợ giúp thông tin xác thực và các nguồn thông tin xác thực khác vẫn có thể làm lộ thông tin xác thực.

Trong requirements.toml, hãy dùng các hạn chế tùy chọn sau để tắt shell đăng nhập và ảnh chụp trạng thái shell nếu chúng tương thích với quy trình làm việc của bạn:

allow_login_shell = false

[features]
shell_snapshot = false

Triển khai thí điểm các cài đặt này vì một số quy trình làm việc phụ thuộc vào quá trình khởi tạo shell đăng nhập.

Khởi động Codex với các biến giả lập vô hại khớp với bộ lọc và kiểm tra môi trường của một lệnh được khởi chạy; đồng thời xác minh rằng yêu cầu dùng shell đăng nhập bị từ chối nếu tính năng này đã bị tắt. Xác minh độc lập rằng danh tính thực thi không thể truy cập thông tin xác thực sản xuất thật. Xem Chính sách môi trường shell.

Yêu cầu phê duyệt cho một số lệnh có tác động lớn

Thêm các quy tắc bắt buộc cho những lệnh mà tổ chức của bạn sử dụng. Ví dụ:

[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { token = "push" }], decision = "prompt", justification = "Review Git pushes." },
  { pattern = [{ token = "terraform" }, { token = "apply" }], decision = "prompt", justification = "Review infrastructure changes." },
  { pattern = [{ token = "kubectl" }, { any_of = ["apply", "delete", "patch"] }], decision = "prompt", justification = "Review cluster changes." },
  { pattern = [{ token = "python3" }, { token = "manage.py" }, { token = "migrate" }], decision = "prompt", justification = "Review database migrations." },
]

Dùng forbidden cho lệnh tuyệt đối không được chạy; thay thế hoặc thêm các mẫu cho công cụ triển khai và di chuyển dữ liệu thực tế.

Các quy tắc này khớp theo tiền tố lệnh và không bao quát mọi hành động tương đương. Kiểm thử riêng các đường dẫn tuyệt đối, trình bao bọc, thứ tự đối số khác, ứng dụng khách khác và công cụ khác.

Trên một đích thử nghiệm có thể loại bỏ, hãy chạy một lệnh thông thường, yêu cầu một hành động trong danh sách, từ chối yêu cầu phê duyệt và xác minh rằng hành động đó không được thực thi. Xem Thực thi quy tắc lệnh.

Thực thi phê duyệt kho mã và triển khai bên ngoài Codex

Trong nền tảng quản lý mã nguồn, hãy bảo vệ các nhánh sản xuất như main: yêu cầu các thay đổi phải được rà soát cùng các phê duyệt và kiểm tra trạng thái cần thiết, đồng thời rà soát những vai trò có thể bỏ qua các yêu cầu đó. Cấu hình phê duyệt triển khai trong hệ thống triển khai liên quan và quyền cơ sở dữ liệu ngay trong cơ sở dữ liệu.

Dùng một kho mã thử nghiệm có thể loại bỏ để xác minh rằng thay đổi đã được rà soát có thể áp dụng thành công và thao tác đẩy trực tiếp không được phép bị từ chối. Các biện pháp kiểm soát này áp dụng bất kể hành động có được yêu cầu thông qua Codex hay không.

Xác minh

Trên một đích kiểm thử có thể loại bỏ:

• Chạy một tác vụ thông thường trong không gian làm việc. Kết quả mong đợi: Tác vụ thành công.

• Thử một lệnh nhạy cảm điển hình và từ chối yêu cầu phê duyệt. Kết quả mong đợi: Lệnh bị từ chối không chạy.

• Xác minh rằng danh tính Codex không thể có được quyền ghi vào môi trường sản xuất.

• Khởi động lại ứng dụng khách và lặp lại.

Giới hạn

Quy tắc tiền tố không phải là một công cụ thực thi chính sách hệ điều hành hoàn chỉnh. Kết hợp chúng với cơ chế cô lập, tài khoản hệ điều hành có đặc quyền tối thiểu, hạn chế mạng, IAM đám mây, bảo vệ nhánh, phê duyệt triển khai và phân quyền cơ sở dữ liệu.

Sử dụng các hướng dẫn cấu hình sau: Bảo vệ bí mật và các kho mã không liên quan; Hạn chế đích đến mạng; Chỉ cho phép các MCP server đã được phê duyệt; Yêu cầu phê duyệt cho các lệnh nhạy cảm.

Các nhà phát triển sử dụng Codex với kho mã nội bộ và bạn muốn giảm nguy cơ mã được gửi đến kho mã công khai, đoạn mã công khai hoặc đích đến khác chưa được phê duyệt.

• Thêm các đường dẫn từ chối chính xác cho những thư mục thông tin xác thực và kho mã không liên quan đã biết, đồng thời giảm tối đa số biến môi trường được truyền cho các lệnh được khởi chạy.

• Khi tác nhân cần truy cập internet, hãy dùng một danh sách cho phép giới hạn gồm các miền đã được phê duyệt. Chỉ cho phép tên và danh tính MCP server đã được phê duyệt, đồng thời yêu cầu rà soát hoặc từ chối một số lệnh công bố, chẳng hạn như git push.

• Dùng hook và quyền quản lý mã nguồn, chính sách cho kho mã và đoạn mã công khai, cùng các biện pháp ngăn ngừa thất thoát dữ liệu phù hợp với tổ chức của bạn.

Từ chối truy cập các kho mã không liên quan và tệp thông tin xác thực

Trong requirements.toml do quản trị viên quản lý, hãy thêm các đường dẫn chính xác mà tác nhân cục bộ không được đọc:

[permissions.filesystem]
deny_read = ["~/.ssh", "~/.aws/credentials", "~/.kube/config", "/work/unrelated-repository"]

Thay các ví dụ bằng đường dẫn có trên thiết bị được quản lý của bạn. Quy tắc từ chối được quản lý này áp dụng trên mọi hồ sơ quyền được phép; quy tắc từ chối chỉ được cấu hình trong một hồ sơ tùy chỉnh sẽ không bảo vệ người dùng chọn hồ sơ khác. Ưu tiên các đường dẫn chính xác đã biết và kiểm thử mọi mẫu glob ở các độ sâu cần thiết.

Trên Windows gốc, deny_read được quản lý bao quát các công cụ thao tác tệp trực tiếp nhưng tự nó không ngăn được việc đọc qua tiến trình con của shell; hãy dùng thêm danh tính hệ điều hành và danh sách kiểm soát truy cập tệp.

Tạo các tệp mồi vô hại tại những vị trí bị từ chối. Với mỗi hồ sơ được phép, xác minh rằng cả thao tác đọc trực tiếp lẫn đọc qua shell đối với các tệp đó đều bị từ chối và một tệp mã nguồn được phê duyệt vẫn có thể được đọc. Xem Yêu cầu từ chối đọc được quản lý.

Giảm tối đa các biến shell chứa thông tin xác thực

Trong /etc/codex/config.toml hoặc ~/.codex/config.toml, hãy giới hạn môi trường được kế thừa:

[shell_environment_policy]
inherit = "core"
ignore_default_excludes = false

[shell_environment_policy.filters]
"AWS_*" = "exclude"
"AZURE_*" = "exclude"
"GITHUB_*" = "exclude"
"*_TOKEN" = "exclude"
"*_SECRET" = "exclude"
"*_PASSWORD" = "exclude"

Cài đặt này giảm số biến được kế thừa nhưng người dùng có thể cấu hình lại và nó không ngăn truy cập các tệp thông tin xác thực, trình trợ giúp, nội dung khởi tạo shell hoặc danh tính khác.

Khi phù hợp, quản trị viên cũng có thể thêm các hạn chế sau vào requirements.toml và triển khai thí điểm để đánh giá tác động đến quy trình làm việc của nhà phát triển:

allow_login_shell = false

[features]
shell_snapshot = false

Kiểm thử bằng các biến mồi giả lập và một danh tính thực thi riêng có đặc quyền tối thiểu. Không dùng thông tin xác thực thật. Xem Chính sách môi trường shell.

Chỉ cho phép các đích đến mạng đã được phê duyệt cho lệnh cục bộ

Nếu các lệnh cục bộ chạy trong môi trường cô lập cần truy cập mạng, hãy hợp nhất cả cài đặt hồ sơ lẫn proxy được quản lý bên dưới vào requirements.toml, thay các miền bằng điểm cuối đã được phê duyệt:

default_permissions = "corp_network"

[allowed_permission_profiles]
corp_network = true

[permissions.corp_network]
extends = ":workspace"

[permissions.corp_network.network]
enabled = true

[experimental_network]
enabled = true
managed_allowed_domains_only = true

[experimental_network.domains]
"git.corp.example" = "allow"
"registry.corp.example" = "allow"

Hồ sơ bật mạng cấp đường truy cập mạng cho lệnh chạy trong môi trường cô lập, còn proxy được quản lý giới hạn các đích đến của lệnh. Triển khai cả hai cùng nhau; hồ sơ bật mạng mà không có proxy được quản lý theo dự định sẽ không áp dụng cùng các hạn chế về đích đến. Nếu không cần truy cập internet, hãy giữ truy cập mạng ở trạng thái tắt.

Không kết hợp bảng chuẩn domains với các cài đặt cũ allowed_domains hoặc denied_domains; hãy chuyển đổi và kiểm thử chính sách hiện có.

Khởi động lại ứng dụng khách và xác minh rằng điểm cuối được phê duyệt hoạt động còn điểm cuối chưa được phê duyệt bị chặn.

Các cài đặt này mang tính thử nghiệm; hãy xác nhận khả năng hỗ trợ của hệ điều hành và ứng dụng khách, đồng thời cấu hình riêng quyền truy cập mạng riêng nếu một máy chủ được phê duyệt phân giải thành địa chỉ riêng. Việc nâng quyền ra khỏi toàn bộ môi trường cô lập được phê duyệt có thể bỏ qua proxy lệnh.

Biện pháp kiểm soát mạng cho lệnh cục bộ này tự nó không bao quát tìm kiếm web, ứng dụng, MCP server, hoạt động trình duyệt hoặc môi trường đám mây; những thành phần đó cần chính sách riêng. Một miền lưu trữ được phê duyệt cũng có thể chứa kho mã hoặc đoạn mã công khai, nên chỉ dùng danh sách đích đến được phép không đủ để bảo vệ nội dung. Xem Yêu cầu truy cập mạng.

Cấu hình riêng mạng cho môi trường đám mây

Trong giao diện Codex Cloud hiện tại, mở cấu hình môi trường. Giữ Cho phép Codex truy cập internet ở trạng thái tắt. Nếu cần truy cập internet, hãy bật tùy chọn này và chọn Chỉ các miền tùy chỉnh, thêm chính xác các máy chủ cần thiết trong Các miền bổ sung được phép, rồi lưu cấu hình, công bố hoặc công bố lại môi trường và kiểm thử một tác vụ mới.

Rà soát độc lập cơ chế xác thực và khả năng của dịch vụ.

Codex Cloud phiên bản cũ dùng cài đặt internet riêng cho tác nhân theo từng môi trường, với các biện pháp kiểm soát miền và phương thức HTTP được phép; tập lệnh thiết lập có cách truy cập riêng.

Kiểm thử phiên bản môi trường bạn thực sự sử dụng. Xem Kết nối với dịch vụ và cài đặt internet phiên bản cũ.

Hạn chế MCP server và yêu cầu phê duyệt trước khi đẩy Git

Chỉ cho phép các danh tính MCP server cục bộ đã được phê duyệt trong requirements.toml. Ví dụ:

[mcp_servers.internal]
identity = { url = "https://mcp.corp.example/mcp" }

Cấu hình riêng máy chủ thực tế trong config.toml của người dùng hoặc cấu hình mặc định được quản lý, dùng tên và URL khớp cùng cơ chế xác thực mà máy chủ của bạn yêu cầu:

[mcp_servers.internal]
url = "https://mcp.corp.example/mcp"

Yêu cầu này chỉ cho phép máy chủ khớp và không tạo máy chủ đó. Rà soát quyền truy cập và công cụ của chính máy chủ đó.

Xác minh rằng máy chủ được phê duyệt có thể kết nối và máy chủ có tên hoặc URL khác không được phép.

Thêm quy tắc lệnh được quản lý để yêu cầu rà soát trước một lệnh công bố điển hình:

[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { token = "push" }], decision = "prompt", justification = "Review the destination before publishing." },
]

Kết hợp quy tắc này với allowed_approval_policies = ["on-request"] và allowed_approvals_reviewers = ["user"] dưới dạng yêu cầu cấp cao nhất nếu cần có người rà soát.

Từ chối một lần đẩy thử và xác nhận thao tác đó không chạy.

So khớp tiền tố không bao quát mọi trình bao bọc, ứng dụng khách API, ứng dụng hoặc cách công bố khác.

Hạn chế công bố công khai bằng các biện pháp kiểm soát quản lý mã nguồn và DLP

Trong nền tảng quản lý mã nguồn, hãy hạn chế việc tạo kho mã công khai và giới hạn người có thể thay đổi chế độ hiển thị của kho mã, nếu nền tảng hỗ trợ. Rà soát quyền bỏ qua dành cho người dùng có đặc quyền. Kiểm tra riêng tài khoản cá nhân, đoạn mã, tổ chức bên ngoài và quyền truy cập bằng token: cài đặt tổ chức không chi phối mọi đích đến.

Trong kho mã liên quan, yêu cầu các thay đổi phải được rà soát và rà soát cơ chế bảo vệ nhánh cùng quyền bỏ qua.

Trong bảng điều khiển DLP của tổ chức, cấu hình chính sách thí điểm cho nội dung mã nguồn nhạy cảm và các kênh tải lên hoặc kho mã mà sản phẩm DLP của bạn thực sự bao quát; đặt hành động thành chặn và kiểm thử bằng một dấu đánh dấu giả lập vô hại.

Nếu nền tảng quản lý mã nguồn hỗ trợ các biện pháp kiểm soát phía máy chủ, hãy cấu hình và thực thi các hook đã được rà soát cho những kho mã nhận thao tác đẩy.

Dùng các đích kiểm thử được cho phép và xác nhận việc chặn có hiệu lực trước mọi thao tác công bố.

Xác minh

• Tạo các tệp mồi vô hại và xác nhận rằng những lần thử đọc tệp bị từ chối đều thất bại.

• Nếu truy cập mạng được bật, kiểm tra rằng đích đến được phê duyệt truy cập thành công và đích đến chưa được phê duyệt bị chặn; nếu không, xác minh rằng các yêu cầu mạng bị chặn.

• Với một dấu đánh dấu vô hại và tài khoản hoặc đích kiểm thử có thể loại bỏ, xác minh rằng các lần thử công bố công khai điển hình bị chặn trước khi nội dung được công bố.

Giới hạn

Một miền được phép vẫn có thể lưu trữ nội dung công khai. Cấu hình riêng tìm kiếm web, ứng dụng, MCP server, hoạt động trình duyệt và Codex Cloud; các quy tắc môi trường cô lập cục bộ không kiểm soát chúng.

Sử dụng các hướng dẫn cấu hình sau: Hạn chế hồ sơ quyền và Full Access; Chỉ cho phép các MCP server đã được phê duyệt; Hạn chế đích đến mạng; Bảo vệ bí mật và các kho mã không liên quan; Yêu cầu phê duyệt cho các lệnh nhạy cảm.

Bạn muốn các hạn chế chi phối Codex tiếp tục có hiệu lực khi Codex làm việc trong kho mã hoặc khi người dùng thay đổi cấu hình cục bộ.

• Phân phối các hạn chế được hỗ trợ về quyền, phê duyệt, MCP, mạng và lệnh dưới dạng yêu cầu do quản trị viên thực thi.

• Cài đặt tập lệnh hook trong thư mục do quản trị viên quản lý và chỉ dùng hook được quản lý nếu cần bỏ qua hook của người dùng, dự án và plugin.

• Bảo vệ các tệp chính sách và đường dẫn phân phối cấu hình bằng biện pháp kiểm soát của hệ điều hành và quản lý thiết bị. Chạy Codex mà không có các đặc quyền cần thiết để thay đổi những biện pháp bảo vệ đó.

• Rà soát cấu hình có hiệu lực cho từng ứng dụng khách và môi trường trong phạm vi áp dụng.

Thực thi các hồ sơ, phê duyệt, danh tính máy chủ và lệnh được phép

Hợp nhất các cài đặt đã được rà soát vào requirements.toml do quản trị viên quản lý, thay vì dựa vào cài đặt mà người dùng hoặc kho mã có thể chỉnh sửa. Ví dụ:

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["user"]
default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true

[mcp_servers.internal]
identity = { url = "https://mcp.corp.example/mcp" }

[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { token = "push" }], decision = "prompt", justification = "Review Git pushes." },
]

Ví dụ này cho phép hai hồ sơ, yêu cầu người rà soát khi cần phê duyệt, cho phép một danh tính MCP khớp và yêu cầu phê duyệt cho một tiền tố lệnh cụ thể.

Cấu hình riêng MCP server và thêm các mẫu lệnh nhạy cảm khác của tổ chức. Thêm các hạn chế tệp toàn cục và hạn chế mạng khi cần; các yêu cầu ràng buộc những cài đặt được hỗ trợ nhưng không thể thay thế các biện pháp kiểm soát danh tính, dịch vụ và đích đến bên ngoài Codex.

Danh sách hồ sơ được phép do quản trị viên quản lý yêu cầu Codex 0.138.0 trở lên.

Trên ứng dụng khách thí điểm, thử chọn một hồ sơ không được phép, thay đổi một cài đặt bị hạn chế của người dùng hoặc dự án và dùng danh tính MCP không nằm trong danh sách cho phép; xác minh rằng mỗi thao tác đều bị từ chối hoặc vẫn bị ràng buộc sau khi khởi động lại. Từ chối phê duyệt một lệnh thử và xác minh rằng lệnh đó không chạy.

Thêm các hạn chế hệ thống tệp và mạng được quản lý

Để từ chối truy cập các tệp cục bộ nhạy cảm trên mọi hồ sơ được phép, hãy thêm bảng sau vào requirements.toml và thay các ví dụ bằng đường dẫn của tổ chức:

[permissions.filesystem]
deny_read = ["~/.ssh", "~/.aws/credentials", "~/.kube/config"]

Khi các lệnh cục bộ chạy trong môi trường cô lập cần truy cập mạng, hãy định nghĩa đồng thời một hồ sơ bật mạng được phép và các đích đến được quản lý:

default_permissions = "corp_network"

[allowed_permission_profiles]
corp_network = true

[permissions.corp_network]
extends = ":workspace"

[permissions.corp_network.network]
enabled = true

[experimental_network]
enabled = true
managed_allowed_domains_only = true

[experimental_network.domains]
"git.corp.example" = "allow"

Chọn chính sách hồ sơ này thay cho mặc định :workspace trước đó, hoặc chủ động hợp nhất cả hai tên hồ sơ; không dán các khóa hoặc bảng trùng lặp. Nếu các lệnh không cần mạng, hãy giữ mạng ở trạng thái tắt.

Xác minh các đường dẫn chính xác bị từ chối bằng tệp vô hại, đồng thời xác minh các đích đến được phê duyệt và chưa được phê duyệt.

Trên Windows gốc, hãy dùng thêm danh sách kiểm soát truy cập tệp vì chỉ riêng deny_read được quản lý không bao quát việc đọc qua tiến trình con của shell.

Cấu hình mạng cho lệnh cục bộ không chi phối các ứng dụng khách khác, ứng dụng, trình kết nối hoặc việc thực thi trên đám mây.

Cài đặt và thực thi hook do quản trị viên quản lý

Yêu cầu quản trị viên cài đặt chương trình hook đã được rà soát trong thư mục do root quản lý, chẳng hạn như /etc/codex/hooks/pre_tool_use_policy.py, và ngăn người dùng chạy Codex thay đổi tệp hoặc thư mục đó. Trong requirements.toml, bật hook và bỏ qua hook của người dùng, dự án, phiên và plugin:

allow_managed_hooks_only = true

[features]
hooks = true

[hooks]
managed_dir = "/etc/codex/hooks"

[[hooks.PreToolUse]]
matcher = "^Bash$"

[[hooks.PreToolUse.hooks]]
type = "command"
command = "/usr/bin/python3 /etc/codex/hooks/pre_tool_use_policy.py"
timeout = 30
statusMessage = "Checking managed Bash command"

Yêu cầu này đăng ký hook nhưng không cài đặt nó. Để kiểm thử tích hợp cục bộ trên macOS, lưu nội dung sau thành pre_tool_use_policy.py và yêu cầu quản trị viên cài đặt bằng các lệnh bên dưới.

Nó chỉ chặn dấu đánh dấu giả lập; hãy thay bằng chính sách riêng của tổ chức đã được rà soát trước khi dựa vào nó. Xác nhận rằng /usr/bin/python3 tồn tại trên đích và điều chỉnh đường dẫn trình thông dịch nếu cần:

import json
import sys

event = json.load(sys.stdin)
command = event.get("tool_input", {}).get("command", "")
if "CODEX_HOOK_TEST_DENY" in command:
    print("Synthetic test command blocked by managed hook.", file=sys.stderr)
    sys.exit(2)

sudo install -d -o root -g wheel -m 755 /etc/codex/hooks
sudo install -o root -g wheel -m 644 ./pre_tool_use_policy.py /etc/codex/hooks/pre_tool_use_policy.py

Khởi động lại ứng dụng khách cục bộ, sau đó:

• Xác nhận một lệnh Bash vô hại chạy được.

• Xác nhận một lệnh chứa CODEX_HOOK_TEST_DENY bị chặn.

• Xác minh rằng người dùng chạy Codex không thể thay đổi chính sách và các thành phần phụ thuộc.

allow_managed_hooks_only bỏ qua mọi hook không được quản lý của người dùng, dự án, phiên và plugin, đồng thời có thể ảnh hưởng đến các quy trình làm việc khác.

Bộ so khớp Bash không bao quát mọi công cụ hoặc dữ liệu đầu vào được cung cấp sau đó cho một tiến trình đang tồn tại; lỗi, hết thời gian chờ hoặc phản hồi hook sai định dạng có thể cho phép một lệnh gọi công cụ tiếp tục.

Work được điều phối trên đám mây sử dụng các trình xử lý hook được hỗ trợ khác. Duy trì các biện pháp bảo vệ độc lập ở cấp hệ điều hành và dịch vụ. Xem Hook được quản lý và hành vi của hook.

Bảo vệ chính sách và quá trình phân phối chính sách

Trên macOS, quản trị viên có thể triển khai tệp yêu cầu đã được rà soát và hợp nhất trong thư mục cha thuộc sở hữu của root, đồng thời ngăn người dùng chạy Codex ghi vào tệp:

sudo install -d -o root -g wheel -m 755 /etc/codex
sudo install -o root -g wheel -m 644 ./requirements.reviewed.toml /etc/codex/requirements.toml
ls -ld /etc/codex
ls -l /etc/codex/requirements.toml

Trên Linux, dùng nhóm quản trị viên phù hợp; trên Windows, bảo vệ thư mục ProgramData và tệp bằng danh sách kiểm soát truy cập do quản trị viên quản lý. Hạn chế người có thể thay đổi MDM hoặc chính sách đám mây, rà soát các thay đổi và giữ một bản sao để khôi phục.

Dùng tài khoản thí điểm không có quyền quản trị, xác minh rằng tài khoản không thể sửa đổi chính sách, thư mục cha hoặc chương trình hook được quản lý; thử một cài đặt ít nghiêm ngặt hơn của người dùng hoặc dự án, khởi động lại Codex và xác minh rằng hành vi được thực thi vẫn duy trì.

Kiểm thử từng ứng dụng khách và môi trường trong phạm vi áp dụng thay vì giả định mọi ứng dụng khách đều tải cùng một chính sách.

Xác minh

Dùng một danh tính kiểm thử không có quyền quản trị:

• Thử chỉnh sửa chính sách được quản lý. Kết quả mong đợi: Không thể thay đổi tệp được quản lý.

• Thử nới lỏng một hạn chế thông qua cấu hình người dùng hoặc dự án. Kết quả mong đợi: Các cài đặt ít nghiêm ngặt hơn bị từ chối hoặc vẫn bị ràng buộc.

• Khởi động lại ứng dụng khách và xác minh rằng các hạn chế vẫn áp dụng.

Giới hạn

Người dùng hoặc tác nhân có đủ đặc quyền quản trị trên máy chủ có thể thay đổi các biện pháp bảo vệ xung quanh. Chỉ riêng các cài đặt mà người dùng có thể chỉnh sửa không thể thay thế các yêu cầu do quản trị viên quản lý.