Ba tuần trước mình chứng kiến một agent code chạy trên laptop đồng nghiệp tự nhiên curl vào một endpoint metrics nội bộ chẳng liên quan gì task đang làm. Không ai bảo nó làm vậy. Không phải cố ý phá hoại, chỉ là “đi lạc” trong lúc dò xét môi trường trước khi sửa code. Bắt được vì đồng nghiệp mình tình cờ mở terminal cạnh bên. Nếu lúc đó anh ấy đang họp, hoặc agent chạy nền như xu hướng hiện giờ, request đó cứ thế bay đi và chẳng ai biết.

Đó là lỗ hổng GitHub vừa bắt đầu vá. Bản tin phát hành hàng tuần của Copilot ngày 21/9 (đăng 25/9, github.blog/changelog) liệt kê sandbox cho agent local vào public preview, cộng tích hợp OpenTelemetry để đẩy hoạt động agent vào stack giám sát bạn đang dùng. Hai tính năng ra cùng tuần, chỉ có ý nghĩa khi đặt cạnh nhau — một cái giới hạn agent đụng vào cái gì, cái kia cho biết nó đã đụng vào cái gì rồi.

Thực tế đã ra mắt cái gì

Đoạn changelog khá ngắn gọn, bình thường với kiểu bản tin tuần của GitHub, nhưng câu chữ đáng chú ý:

“Limit agents’ access to files, networks, and credentials with local sandboxing, now in public preview.”

Ba nhóm: file, network, credential. Đó là ranh giới. Tính năng nằm trong Copilot app, tức nói về agent chạy local trên máy dev — không phải session agent chạy cloud mà GitHub đã tự cô lập bằng hạ tầng riêng. Agent local chạy bằng shell của bạn, quyền của bạn, SSH key của bạn, token CLI cloud nằm sẵn trong ~/.aws/credentials. Trước bản này, “local” và “sandbox” chưa từng đi chung một câu khi nói về Copilot agent mode. Agent chạy như chính bạn. Cái gì bạn với tới được thì nó cũng với tới được.

Phần OTel là nửa còn lại:

“Track agent activity in your existing monitoring tools with OpenTelemetry, configured through enterprise-managed settings.”

Cấu hình quản lý ở cấp enterprise, đẩy thẳng vào stack sẵn có — Datadog, Grafana, bất cứ thứ gì team bạn đang trả tiền và đã có sẵn dashboard, alert. Không phải một sản phẩm observability riêng của Copilot bắt bạn phải học thêm và nhét vào quy trình on-call.

Hai chi tiết nhỏ hơn ra cùng tuần, đáng nhắc qua nhưng không phải trọng tâm. VS Code giờ chạy được agent bên trong Dev Container qua SSH, Tunnel, và WSL — đang rollout dần dần — hữu ích nếu team bạn dev trên máy remote và muốn agent chạy ngay nơi có toolchain thật, chứ không phải trên máy client mỏng. Bốn model mới cũng xuất hiện: Claude Opus 5.5 và GPT-6 Sol cho Pro+/Max/Business/Enterprise, GPT-6 Luna và Grok 4.7 xuống tới cả gói Pro cơ bản. Không cái nào là câu chuyện chính hôm nay. Câu chuyện chính là sandbox và trace.

Đáng lẽ phải ra mắt từ một năm trước rồi

Sandbox không nên là tính năng preview để bạn tự chọn bật vào cuối 2026. Nó phải là hành vi mặc định ngay từ ngày đầu Copilot chạy được shell command mà không cần người xác nhận từng bước. Ý tưởng “agent tự chạy không cần giám sát” được bán trên tiền đề chạy độc lập là giá trị cốt lõi — giao task rồi đi làm việc khác. Nhưng chạy độc lập với toàn quyền truy cập file system, network, kho credential không phải tính năng, đó là rủi ro khoác áo tính năng. Ra mắt dưới dạng preview tự chọn thay vì mặc định bật sẵn cho thấy cả ngành xây năng lực trước, rồi một chu kỳ sản phẩm sau mới quay lại lắp dây an toàn.

Thứ tự đó không hẳn liều lĩnh — làm sandbox tốt cho process local, không phá vỡ workflow hợp lệ cần network hay file ngoài phạm vi project hẹp, là bài toán kỹ thuật thật sự khó. Docker mất nhiều năm mới đưa container escape xuống mức hiếm gặp thay vì chuyện cơm bữa. Nhưng khó không có nghĩa nên chờ. Một sandbox default-deny hợp lý, kèm allowlist theo project dễ dùng, đáng lẽ đã là lựa chọn mặc định an toàn hơn ngay từ dạng sơ khai.

OpenTelemetry có phải là lớp trừu tượng đúng cho quan sát agent không?

“Đẩy qua OTel” nghe như câu trả lời kỹ thuật hiển nhiên đúng, nhưng mình không nghĩ nó đúng hoàn toàn.

OTel giỏi đúng việc nó sinh ra để làm: distributed tracing xuyên service, với hệ sinh thái collector, exporter, dashboard chín muồi mà phần lớn team platform đã có sẵn. Tận dụng đường ống đó cho hoạt động agent là lựa chọn thực dụng — chẳng ai muốn mở thêm dashboard vendor thứ tư cạnh ba cái đã có. Ở lớp hạ tầng ống dẫn, OTel là lựa chọn đúng.

Nhưng một span HTTP và bản ghi kiểu “agent ghi vào file này vì suy luận từ ngữ cảnh X và được duyệt qua cơ chế Y” là hai loại thông tin khác hẳn nhau dù khoác cùng định dạng dây truyền. Distributed tracing trả lời “độ trễ nằm ở đâu” và “service nào ném lỗi.” Quan sát agent cần trả lời vì sao agent tin hành động này được phép, ranh giới sandbox nào đang áp dụng lúc nó hành động, và có người thật trong vòng lặp phê duyệt hay agent tự duyệt theo policy cũ. Mô hình span/attribute của OTel chở được dữ liệu đó nếu bạn kỷ luật với attribute. Nhưng bản thân nó không ép ai kỷ luật cả. Không gì trong định dạng dây truyền cho biết trace của bạn có hữu ích cho hậu kiểm bảo mật, hay chỉ là biểu đồ độ trễ dán thêm tên agent. Đó là vấn đề schema mà GitHub chưa công bố câu trả lời, ít nhất chưa có trong changelog này.

Một span ghi hành động của agent nên trông như thế nào

Nếu tự mình instrument việc này, đây là hình dạng mình muốn có cho mỗi hành động của agent — không chỉ “một tool đã được gọi” mà đủ dữ liệu để dựng lại quyết định sau này:

{
  "trace_id": "a1b2c3d4e5f6",
  "span_id": "7f8e9d0c1b2a",
  "name": "agent.tool_call.file_write",
  "start_time": "2026-09-26T03:14:22.104Z",
  "end_time": "2026-09-26T03:14:22.311Z",
  "attributes": {
    "agent.session_id": "copilot-local-9f21",
    "agent.model": "gpt-6-luna",
    "agent.task_description_hash": "sha256:7c4a...",
    "sandbox.boundary_id": "project-scoped-default",
    "sandbox.fs_scope": ["/home/dev/repo/**"],
    "sandbox.network_policy": "deny-all",
    "sandbox.credential_scope": "none",
    "action.type": "file_write",
    "action.target_path": "/home/dev/repo/src/config.ts",
    "action.bytes_written": 842,
    "action.within_sandbox_boundary": true,
    "approval.required": false,
    "approval.granted_by": null,
    "approval.mechanism": "auto-allowed-in-scope",
    "outcome.status": "success",
    "outcome.diff_ref": "git:working-tree:src/config.ts"
  }
}

Và một lần thử network bị chặn — có khi còn quan trọng hơn để lưu lại, vì sáu tháng sau có người hỏi “cái này có bao giờ cố vươn ra ngoài sandbox không”:

{
  "name": "agent.tool_call.network_request",
  "attributes": {
    "agent.session_id": "copilot-local-9f21",
    "sandbox.network_policy": "deny-all",
    "action.type": "network_request",
    "action.target_host": "internal-metrics.corp.example.com",
    "action.method": "GET",
    "action.within_sandbox_boundary": false,
    "outcome.status": "blocked_by_sandbox",
    "outcome.reason": "network_policy_deny_all"
  }
}

Field làm việc thật sự ở đây không phải mấy field OTel chuẩn — trace_id, start_time đâu cũng có. Mà là sandbox.boundary_id, sandbox.network_policy, action.within_sandbox_boundary, và approval.granted_by. Chúng cho người review, sau khi sự việc xảy ra, biết chính xác rule set nào đang hiệu lực, hành động có nằm trong ranh giới không, và có người thật ký duyệt hay hệ thống tự động duyệt vì rơi vào allowlist sẵn có. Bỏ mấy field này, bạn chỉ còn trace chứng minh agent đã làm gì đó, không cách nào biết nó có được phép hay không.

GitHub chưa công bố schema span thật sự, ít nhất mình chưa tìm thấy, và đó là thứ mình muốn thấy tiếp theo, không phải thêm tính năng nổi bật. Một đường ống trace không có schema tường minh cho “ngữ cảnh phê duyệt của agent” chỉ trở thành nơi chất đống log thô, chẳng ai đọc, cho đến khi sự cố buộc ai đó lục lại.

Trước khi tin tưởng sandbox agent local trên team của bạn, kiểm tra những gì

Đừng vội coi “sandbox ra mắt” và “OTel ra mắt” là chuyện đã xong. Tự kiểm tra trước khi triển khai rộng hơn nhóm thử nghiệm:

  • Policy mặc định, không chỉ feature flag. Xác nhận sandbox chặn gì ngay từ đầu — phạm vi file, khả năng vươn network, quyền credential — trước khi có cấu hình riêng theo project. “Public preview” không có nghĩa “an toàn sẵn.”
  • Cửa thoát hiểm và cách nó được ghi log. Sandbox nào cũng cần lý do chính đáng để cấp quyền rộng hơn cho một task cụ thể. Tìm hiểu việc cấp quyền diễn ra thế nào, có cần người phê duyệt tường minh không, và việc cấp quyền có xuất hiện trong trace không.
  • “Chặn credential” thực chất loại trừ cái gì. Chặn đọc ~/.aws/credentials khác với chặn agent thừa hưởng một SSH agent socket đang chạy hay token CLI cloud đã cache. Changelog không phân biệt rõ hai bề mặt tấn công này.
  • Hành động bị chặn có được trace không, hay chỉ hành động thành công. Network call bị chặn là sự kiện đáng quan tâm bảo mật hơn. Nếu pipeline OTel chỉ nhận span cho hành động hoàn tất, bạn đang bỏ lỡ nửa dữ liệu thú vị.
  • Ai sở hữu schema OTel bên team bạn. Đừng để việc này biến thành đống span thô trong Datadog chẳng ai query. Giao ai đó định nghĩa “trace agent đáng nghi” và dựng alert thật trước khi sự cố buộc bạn dựng ngược.
  • Tự tay test ranh giới. Đừng tin nhãn preview. Giao agent đã sandbox một task tự nhiên muốn đọc file credential hay vươn tới host nội bộ, xác nhận nó thật sự bị chặn đứng.

Sandbox và trace đều cần thiết. Không cái nào đủ nếu đứng một mình, và không cái nào coi là xong chỉ vì đã ra mắt.

Xuất nội dung

Bình luận