Mọi bài mình viết về containment năm nay đều xoay quanh sandbox — bubblewrap, Seatbelt, microVM, blast radius. Bài blog ngày 23/9 của Microsoft, “Designing agent-first platforms,” lại nói đó là sai lớp cần tập trung. Cược của họ: một agent không có identity thật thì dù sandbox có tốt đến đâu cũng không quản lý được, vì bạn không audit, không revoke, không scope quyền được cho một thứ mà hệ thống còn không nhận diện riêng lẻ được.

Ba mảnh ghép

Microsoft gộp ba thứ vốn từng là ba thông báo riêng biệt:

  • Entra Agent ID — agent có identity object riêng trong Entra, không còn mượn service principal chung từ một tài khoản người dùng.
  • Azure Container Apps Sandboxes — microVM cách ly phần cứng, Microsoft nói nội bộ họ đã chạy hơn 1 triệu sandbox mỗi ngày.
  • Foundry — lớp runtime gắn identity của agent với những gì nó được phép đụng vào trong một phiên sandbox cụ thể.

Luận điểm là identity và sandbox không phải hai chiến lược containment cạnh tranh nhau — sandbox giới hạn process của agent chạm tới đâu, identity giới hạn credential của agent chạm tới đâu, và bạn cần cả hai vì một agent bị compromise nhưng chạy trong sandbox tốt mà identity scope quá rộng vẫn có thể gây hại thật, bằng cách gọi ra một API mà nó chưa bao giờ được phép chạm vào.

Con số khiến chuyện này không chỉ là marketing

Hai case khách hàng trong bài đủ cụ thể để đáng chú ý:

  • KPMG chạy hơn 30.000 sandbox đồng thời trên stack này. Đây không phải con số pilot.
  • EdChat của Nam Úc, phục vụ khoảng 60.000 học sinh, migrate sang Foundry runtime có sandbox và theo báo cáo đã bỏ được hơn 50.000 dòng code — logic cách ly và guardrail tự viết tay giờ Container Apps Sandboxes xử lý sẵn.

Con số thứ hai mới là thứ mình để ý với tư cách Tech Lead. Team nào xây hạ tầng agent cũng rốt cuộc tự viết một lớp sandbox-cộng-permission nửa vời, vì đến gần đây chưa có lựa chọn managed nào tốt. Nếu con số giảm 50K dòng của EdChat mang tính đại diện, thì đây không phải cải thiện bảo mật — mà là loại bỏ gánh nặng bảo trì, một dòng ngân sách khác, một luận điểm khác để trình bày với sếp.

Thực hành: scope identity agent trong Bicep

Đây là dạng gần đúng của việc đăng ký identity agent có scope hiện nay:

resource agentIdentity 'Microsoft.Entra/agentIdentities@2026-06-01' = {
  name: 'invoice-processing-agent'
  properties: {
    displayName: 'Invoice Processing Agent'
    allowedScopes: [
      'Storage.Read.InvoicesContainer'
      'Foundry.Sandbox.Execute'
    ]
    sandboxProfile: {
      runtime: 'containerAppsSandbox'
      hardwareIsolation: true
    }
  }
}

resource sandboxSession 'Microsoft.App/sandboxSessions@2026-06-01' = {
  name: 'invoice-agent-session'
  properties: {
    agentIdentityId: agentIdentity.id
    maxDurationMinutes: 15
  }
}

Điểm đáng để ý: allowedScopes nằm ở identity, không nằm ở sandbox session. Nghĩa là cùng một đoạn code agent, deploy vào hai sandbox session khác nhau với hai identity khác nhau, sẽ có quyền thực sự khác nhau — không chỉ khác network policy. Nếu bạn từng cố gắn least-privilege vào agent bằng cách tự viết IAM role tay cho từng deployment, đây là thứ Microsoft đang cố biến thành primitive hạng nhất, thay vì một workaround.

Chỗ mình còn nghi ngờ

Containment kiểu identity-first chỉ có tác dụng nếu team bạn thực sự scope identity chặt, mà thực tế thì hầu hết team không làm vậy — họ cấp scope rộng lúc đầu để không bị chặn tiến độ dev, rồi không bao giờ siết lại, y hệt cách S3 bucket cuối cùng lại world-readable. Entra Agent ID làm cho việc scope chi tiết khả thi; nó không bắt ai phải làm. Mình dám cá là sáu tháng nữa, audit sẽ tìm thấy identity agent trong production có scope rộng gấp ba lần thứ agent thực sự dùng, vì chẳng ai quay lại sửa file Bicep sau khi demo chạy được.

Còn có một câu hỏi về lock-in mà chưa ai hỏi đủ lớn. Entra Agent ID là primitive identity gắn chặt Azure. Nếu agent stack của bạn cần portable — kiểu cùng một agent LangGraph chạy trên cả AWS lẫn Azure tùy theo region khách hàng — bạn giờ phải maintain hai mô hình identity riêng biệt, vì AWS chưa có cái tương đương và có lẽ cũng sẽ không ra một cái tương thích.

Quan điểm thật của mình

Nếu bạn đã cam kết Azure và đang chạy agent chạm vào dữ liệu khách hàng thật — hóa đơn, PII, luồng thanh toán — thì Entra Agent ID cộng Foundry sandbox đáng để áp dụng ngay, cụ thể là vì audit trail nó cho bạn, không chỉ vì containment. Khi có ai hỏi “agent nào đã chạm vào record này, với scope gì,” bạn muốn có câu trả lời không cần grep log ứng dụng.

Nếu bạn thiết kế multi-cloud từ đầu, coi đây là bản xem trước của xu hướng containment agent theo identity đang lan ra khắp nơi, nhưng đừng xây kiến trúc quanh một primitive gắn chặt Azure ngay lúc này. Pattern thì đúng. Còn implementation vẫn chỉ là ý kiến của một vendor.

Một bước thực tế dù bạn chọn cloud nào: viết ra trước những scope mà mỗi identity agent thực sự cần, trước khi provision bất cứ thứ gì, chứ không phải sau. Team nào bỏ qua bước này rốt cuộc phải làm audit ngược sáu tháng sau, cố tái dựng lại ý định ban đầu từ log thay vì đọc thẳng từ spec. Một file YAML năm dòng cho mỗi agent — tên, scope được phép, ai chịu trách nhiệm review — hôm nay không tốn gì cả, nhưng cứu bạn khỏi một buổi họp rất khó chịu với đội security sau này.

Xuất nội dung

Bình luận