Sự khác biệt giữa Bộ lọc và Bức tường

Bạn đang xây dựng một tác nhân AI có quyền truy cập vào dữ liệu của mình. Bạn có hai lựa chọn về bảo mật. Bạn có thể lọc dữ liệu, hoặc bạn có thể thiết lập rào chắn cho nó.

Lọc có nghĩa là truy vấn của bạn chỉ trả về một số hàng nhất định. Thiết lập rào chắn có nghĩa là tác nhân AI hoàn toàn không thể tiếp cận được các hàng bị ẩn.

Chúng trông có vẻ giống nhau cho đến khi có sự cố xảy ra.

Gần đây tôi đã xây dựng một hệ thống để chuyển đổi 1,2 triệu từ thành một cơ sở tri thức. Tôi đã sử dụng Supabase để quản lý dữ liệu. Tôi muốn các tác nhân AI của mình chỉ thấy được nội dung công khai.

Tôi đã sử dụng một Postgres view tiêu chuẩn để lọc dữ liệu:

CREATE VIEW public_seeds AS
  SELECT * FROM moments
  WHERE visibility = 'public'
    AND is_canonical = true;

Điều này trông có vẻ đúng. Nhưng nó có một lỗ hổng lớn. Theo mặc định, một Postgres view chạy dưới quyền của chủ sở hữu (owner), chứ không phải người gọi nó. Chủ sở hữu view thường có toàn quyền truy cập. Điều này có nghĩa là các chính sách Bảo mật cấp hàng (RLS) của bạn không áp dụng cho view này.

Bạn không xây dựng một bức tường. Bạn chỉ xây dựng một bộ lọc.

Nếu một bộ lọc thất bại, một tác nhân AI sẽ không nhận ra. Con người sẽ thấy lỗi hoặc dữ liệu sai. Một tác nhân AI sẽ chỉ xử lý bất cứ thứ gì nó nhận được. Nếu bộ lọc của bạn thất bại, tác nhân của bạn sẽ bắt đầu sử dụng dữ liệu riêng tư mà không có cảnh báo nào.

Postgres 15 đã giải quyết vấn đề này với tùy chọn security_invoker.

Khi bạn đặt security_invoker thành true, view sẽ chạy dưới quyền của vai trò (role) đang gọi nó. Điều này buộc view phải tuân thủ các chính sách RLS của bạn. View trở thành một cổng ngăn cách về mặt cấu trúc.

Cách làm đúng:

CREATE VIEW public_seeds
  WITH (security_invoker = true)
AS
  SELECT * FROM moments
  WHERE visibility = 'public'
    AND is_canonical = true;

Giờ đây, bức tường đã mang tính cấu trúc. Ngay cả khi một nhà phát triển viết một truy vấn tồi hoặc một phép join, chính sách RLS vẫn bảo vệ bảng dữ liệu.

"Điều này không nên xảy ra" dựa trên việc mọi thứ hoạt động hoàn hảo. "Điều này không thể xảy ra" dựa trên kiến trúc của bạn.

Khi bạn xây dựng cho AI, bạn phải thiết kế cho những gì không thể xảy ra.

Ba điều cần kiểm tra trong thiết lập của bạn:

Source: https://dev.to/chadtdyar/the-difference-between-this-shouldnt-happen-and-this-cannot-happen-in-ai-content-pipelines-1g0p

Optional learning community: https://t.me/GyaanSetuAi