GitHub công bố các chính sách sandbox được quản trị cho Copilot trong JetBrains. Mục đích không phải là bổ sung một chỉ dẫn cho lập trình viên, mà là kiểm tra những ranh giới nào thực sự được áp đặt lên agent, trong từng môi trường của hệ thống máy tính.
GitHub công bố điều gì trong JetBrains
Bản xem trước, không phải bảo đảm cho toàn bộ hệ thống
Sandbox là một môi trường thực thi giới hạn các tài nguyên mà một chương trình có thể truy cập. Ở đây, câu hỏi là về các hạn chế mà doanh nghiệp có thể áp đặt lên trợ lý phát triển.
Ngày 8 tháng 9 năm 2026, GitHub công bố bản xem trước công khai các chính sách sandbox được quản trị cho Copilot trong JetBrains. Thông báo mô tả các hạn chế do doanh nghiệp quyết định, được ưu tiên hơn các thiết lập cá nhân, với phạm vi bao gồm đặc biệt là tệp, mạng, công cụ hoặc dịch vụ cục bộ và các yếu tố chẩn đoán của chính sách đã nhận. Các thông tin này xuất phát từ changelog GitHub, được tham khảo ngày 9 tháng 9. Chúng không chứng minh khả năng sử dụng phổ quát cũng như hành vi của một cài đặt cụ thể.
Do đó, một bản xem trước cần được đánh giá theo từng môi trường: phiên bản và edition của IDE, plugin, hệ thống, gói Copilot và chính sách thực sự đã nhận. Một quy tắc được khai báo trong bảng điều khiển chưa phải là ranh giới được chứng minh trên máy trạm nơi agent làm việc.
Cái bẫy của các tài liệu lân cận
Tài liệu GitHub về cấu hình sandbox cục bộ cung cấp ngữ cảnh về các kiểm soát, công cụ và ngoại lệ được phê duyệt. Nó hướng đến giao diện dòng lệnh (CLI). Nó không chứng minh rằng mọi thiết lập, định dạng hoặc lệnh đều áp dụng cho JetBrains. Vì vậy, mọi cấu hình đề xuất cho một đội ngũ cần gắn với một client đã được kiểm tra, thay vì lắp ghép từ các ví dụ lân cận.
Mô tả ranh giới mong đợi trước khi cấu hình
Tệp, mạng và công cụ: ba danh mục riêng biệt
Trước một đợt thí điểm, hãy lập ma trận nhu cầu theo từng tác vụ. Một trợ lý sửa kiểm thử không nhất thiết cần cùng tệp, máy chủ hay công cụ như một trợ lý được giao phân tích một dependency. Sự tách biệt này tránh biến một quyền rộng thành giải pháp mặc định.
| Môi trường | Phiên bản plugin | Chính sách mong đợi | Hành động vô hại | Kết quả ghi nhận | Bằng chứng | Chủ sở hữu |
|---|---|---|---|---|---|---|
| Cần điền | Cần điền | Cần điền | Tệp, máy chủ hoặc công cụ minh họa | Chưa đo lường | Chưa đo lường | Cần chỉ định |
Hãy dùng các đường dẫn minh họa, máy chủ thử nghiệm và bí mật giả. Mục tiêu là xác minh một ranh giới mà không làm lưu chuyển dữ liệu khách hàng hay thay đổi một chính sách doanh nghiệp thực tế.
Ai có thể yêu cầu hoặc chấp nhận một ngoại lệ?
Hãy lập bản đồ riêng cho quản trị viên sửa chính sách trung tâm, lập trình viên nhận thấy một chặn và người phê duyệt chấp nhận một ngoại lệ. Một yêu cầu có tài liệu, một phê duyệt và một cách vượt qua được cho phép không đồng nghĩa với nhau. Sự tồn tại và khả năng quan sát của chúng vẫn cần được xác nhận trong client và tổ chức triển khai bản xem trước.
Xác minh chính sách có hiệu lực
Một kiểm tra dương tính và một kiểm tra âm tính cho mỗi ranh giới
Hãy chuẩn bị một cặp kiểm tra cho mỗi quyền mong đợi: một tệp bên trong và bên ngoài không gian được phép, một điểm truy cập minh họa được chấp nhận rồi bị từ chối, một tài nguyên cục bộ giả có thể truy cập rồi bị loại trừ. Với mỗi lần thử, hãy lưu điều mong đợi, kết quả ghi nhận, phiên bản và bằng chứng có sẵn. Một kết quả trống nghĩa là « chưa đo lường », không bao giờ là « an toàn ».
Chẩn đoán thay vì kết luận từ một thất bại riêng lẻ
Một sự từ chối có thể cho thấy chính sách; một sự cố mạng, một tùy chọn xem trước bị tắt hoặc sự không tương thích phiên bản có thể tạo cùng triệu chứng. Hãy ghi lại chính sách đã nhận, các chỉ báo hiển thị, phiên bản và nhật ký phù hợp trước khi kết luận. Khả năng chẩn đoán GitHub công bố trở nên hữu ích khi nó cho phép đội ngũ phân biệt một hạn chế có chủ đích với một lỗi triển khai.
Triển khai mà không làm gián đoạn công việc hằng ngày
Hãy bắt đầu với một nhóm thí điểm, các tác vụ đã biết và một chủ sở hữu cho từng ngoại lệ. Trước khi triển khai, hãy xác định điều gì phải dừng đợt thí điểm: mất khả năng truy vết, không thể chẩn đoán một chặn hoặc tình trạng ngoại lệ lan rộng. Các tiêu chí này là lựa chọn nội bộ; GitHub ở đây không đưa ra một ngưỡng phổ quát.
Hãy theo dõi sự cản trở hữu ích: các yêu cầu hợp lệ bị chặn, các ngoại lệ trở thành lâu dài và các tác vụ bị đưa ra ngoài cơ chế. Những quan sát này không đo lường việc giảm sự cố. Chúng cho phép thấy liệu ranh giới có đáp ứng công việc thực tế không và liệu các quyền còn lại có vẫn được hiểu rõ không.
Điều mà một chính sách trung tâm không thể thay thế
Một chính sách trung tâm không thay thế review mã hoặc đặc quyền tối thiểu, cũng không làm đầu ra của agent trở nên đúng đắn một cách mặc định. Khung được trình bày trong bài viết của chúng tôi về các agent AI zero trust vẫn bổ sung: các thao tác ghi, danh tính và hành động nhạy cảm đòi hỏi bằng chứng và kiểm soát riêng.
Sản phẩm bàn giao của một đợt thí điểm có thể vẫn đơn giản: một ma trận được phê duyệt, các kiểm tra có thể tái lập và một chủ sở hữu cho từng ngoại lệ. Đó là điều làm cho các ranh giới có thể quan sát. Khi đó, một chính sách được công bố trở thành quyết định kỹ thuật có thể bảo vệ được, mà không trình bày nó như một sandbox bất khả xâm phạm.