Nền tảng nào cũng nói rằng họ coi trọng bảo mật. Cũng chẳng ai nói điều đó trong bản mổ xẻ sự cố rò rỉ dữ liệu — đó là lúc họ cuối cùng mới mô tả kiến trúc thay vì các tính từ hoa mỹ. Vậy hãy đi thẳng vào kiến trúc. Cách dễ nhất để giải thích việc cách ly tenant là điểm qua ba cách mà các đội thường làm sai, và điều gì sẽ hỏng khi họ làm sai như vậy.
Sai lầm một: lọc theo tenant ID trong mã ứng dụng
Đây là mặc định vì nó là điều hiển nhiên để viết ra: mỗi truy vấn nhận được một mệnh đề WHERE user_id = ? , và miễn là mọi lập trình viên nhớ điều đó, mọi yêu cầu vẫn nằm trong ranh giới riêng của nó. Hậu quả xuất hiện sau đó, khi codebase có bốn trăm endpoint thay vì bốn. Ai đó thêm một truy vấn báo cáo nối hai bảng và quên bộ lọc trên bảng thứ hai. Người khác xây dựng một công cụ quản trị "chỉ để dùng nội bộ" mà truy vấn không có bất kỳ giới hạn tenant nào, vì lúc đó cảm thấy an toàn. Không sai lầm nào trong hai cái đó làm fail một bài test, vì truy vấn vẫn trả về các dòng hợp lệ — chỉ là các dòng hợp lệ của tenant sai.
Chúng tôi không dựa vào việc mọi truy vấn đều nhớ hỏi một cách lịch sự. Bảo mật cấp độ dòng dữ liệu được thực thi ngay tại tầng cơ sở dữ liệu, vì vậy chính cơ sở dữ liệu sẽ từ chối trả về dữ liệu của tenant khác bất kể mã gọi yêu cầu gì. Cũng không có đường tắt đặc quyền nào nằm trong luồng xử lý yêu cầu — chính sách này luôn được áp dụng, kể cả với những đường dẫn mà ta có thể bị cám dỗ coi là đáng tin cậy.
Sai lầm hai: coi sandbox là một tối ưu hóa, không phải một ranh giới
Các agent ở đây thực thi mã thật — đó chính là mục đích cốt lõi của sản phẩm — và lối tắt hấp dẫn là chạy đoạn mã đó ở đâu đó tiện lợi rồi khóa lại "nếu có thời gian thì làm sau". Hậu quả trong kịch bản này là một dependency bị xâm phạm được kéo vào trong quá trình dựng rồi vươn ra internet mở, hoặc một lượt chạy agent của tenant này đọc được các file thuộc về một workspace mà nó không bao giờ nên thấy, vì hệ thống file được chia sẻ mặc định và chỉ hạn chế theo ngoại lệ.
Thay vào đó, khối lượng công việc của agent chạy trong các môi trường cách ly:
- Hệ thống file bị khóa chặt.
- Lưu lượng ra ngoài mạng là danh sách cho phép (allowlist) chứ không phải cánh cửa mở.
Một agent đang làm việc trên bản dựng của bạn chỉ thấy workspace của bạn, chấm hết. Mã không đáng tin — kể cả bản dựng của chính ứng dụng bạn — được biên dịch bên trong các container nơi sự cách ly mang tính cấu trúc, chứ không phải một tùy chọn mà ai đó nhớ để bật lên.
Sai lầm ba: đưa thông tin đăng nhập cho agent
Đây là sai lầm tinh vi nhất, và tôi đoán là sai lầm khiến nhiều đội bất ngờ nhất. Nếu agent cần triển khai lên host của bạn hoặc đăng lên cửa hàng của bạn, con đường ngắn nhất là đặt token OAuth hoặc SSH key vào ngữ cảnh của nó rồi để nó tự sử dụng. Đó cũng là con đường ngắn nhất dẫn đến thảm họa: một chỉ thị bị prompt injection, một hành động do ảo giác (hallucination) tạo ra, một thông tin đăng nhập cuối cùng nằm lại trong log transcript ở nơi lẽ ra không nên có. Agent không cần phải có ác ý để chuyện này xảy ra sai — nó chỉ cần sai một lần, trong khi đang nắm giữ chìa khóa thật.
Vì vậy agent không bao giờ nắm giữ chìa khóa. Thông tin đăng nhập đã kết nối được lưu trữ giới hạn phạm vi theo tenant của bạn và chỉ được dùng cho đúng hành động mà bạn đã kết nối nó:
- Tài khoản cửa hàng
- Token OAuth mạng xã hội
- Deploy key
- Tài khoản dịch vụ Google
Khi một agent cần triển khai hoặc tải lên, nó yêu cầu nền tảng thực hiện việc đó; nền tảng giữ thông tin đăng nhập và thực hiện hành động. Agent không bao giờ nhìn thấy bí mật mà nó đang yêu cầu sử dụng. Còn ở phía phân tích dữ liệu, nơi các thuộc tính Google đôi khi được chia sẻ giữa nhiều trang web, mỗi lượt lấy dữ liệu GA4 đều được lọc theo tên miền để bảng điều khiển của bạn không thể vô tình hiển thị số liệu của người khác, ngay cả khi thuộc tính bên dưới thu thập dữ liệu cho nhiều tên miền.
Những gì thực sự được kiểm tra trước khi bất cứ thứ gì được đưa lên
Hai quy tắc áp dụng ở mọi nơi trong nền tảng này, và chúng quan trọng nhất chính ở đây:
- Agent không thể tiêu tiền của bạn.
- Agent không thể đăng bài nhân danh bạn.
Cả hai điều đó đều cần có cú click của bạn. Nghĩa là ngày tồi tệ nhất mà bất kỳ thành phần tự động nào có thể gặp phải vẫn không chạm tới ví tiền hay danh tiếng của bạn — phạm vi thiệt hại được giới hạn theo thiết kế, chứ không phải nhờ vào sự sáng suốt của agent. Chi tiết đầy đủ về việc lưu trữ và xóa dữ liệu có tại Chính sách Quyền riêng tư; các yêu cầu xóa dữ liệu có hiệu lực trong vòng 30 ngày.
