Bài kiểm tra Alice/Bob
Hỏi agent bằng tài khoản Alice.
Rồi hỏi lại bằng tài khoản Bob.
Cùng một câu hỏi. Nếu Bob thấy dữ liệu của Alice, bạn chỉ cách sự cố lộ dữ liệu đúng một cú prompt injection. Phần lớn agent đều trượt, vì chúng đăng nhập cơ sở dữ liệu bằng một tài khoản đọc được mọi thứ. Agent chạy trên AgentHippo thì đạt: chính cơ sở dữ liệu của bạn quyết định ai được xem gì. Và chúng tôi chứng minh điều đó trên dữ liệu của bạn trước khi đưa vào vận hành.
› Vì sao đạt ở đây, và trượt ở mọi nơi để prompt gác cửa
Lời dặn phân quyền trong prompt thì lúc nào cũng có thể bị dụ bỏ qua. Ở đây, chính câu truy vấn chạy bằng quyền của người đang hỏi, nên chẳng còn gì để dụ agent nữa.
Agent không bao giờ giữ credential
Không mật khẩu cơ sở dữ liệu, không API key trong môi trường của agent. Mỗi lượt, agent nhận một token chỉ sống đúng trong lượt đó, còn credential thật nằm ở một tiến trình riêng, cách ly. Chiếm trọn agent, kẻ tấn công vẫn không lấy được gì dùng lâu dài.
Cơ sở dữ liệu của bạn gác cửa
Không phải middleware, không phải policy trên proxy, càng không phải prompt. Postgres Row-Level Security, session tag của AWS IAM trên DynamoDB hoặc Databricks Unity Catalog quyết định mỗi truy vấn được chạm tới đâu. Cũng chính là những cơ chế đội bảo mật của bạn vẫn tin dùng để phân quyền cho nhân viên.
Người dùng × agent: lấy phần giao
Agent hóa đơn có bộ quyền hẹp riêng, tách khỏi quyền của người dùng. Nên kể cả khi bị prompt injection trong phiên của một quản trị viên nhân sự, agent hóa đơn vẫn không đọc được bảng lương, dù bản thân người quản trị có quyền xem, vì agent này chưa từng được cấp đường vào bảng đó.
Prompt không có một chữ về phân quyền
Agent mẫu của chúng tôi trên Databricks không có lấy một chỉ dẫn kiểm soát truy cập, mà vẫn trả đúng dữ liệu cho từng người dùng. Prompt viết khéo đến đâu cũng không cho bạn sự bảo đảm này: kẻ tấn công chẳng còn câu lệnh nào để thuyết phục.
› Chạy trên cơ sở dữ liệu bạn đang có
Postgres thuần
Không cần tính năng đặc biệt. Row-Level Security cộng với chọn role theo từng lượt: kết nối dùng chung trong pool không bao giờ mang danh tính người này sang truy vấn của người khác. Đã kiểm thử thực tế từ đầu đến cuối.
Amazon DynamoDB
Dữ liệu theo từng người dùng do chính AWS IAM thực thi: credential ngắn hạn gắn tag người dùng, chỉ mở đúng các key của họ. Đã kiểm chứng thực tế, do chính cơ chế đánh giá policy của AWS phân xử.
Databricks
Token on-behalf-of của chính nền tảng đi qua nguyên vẹn, nên row filter và column mask của Unity Catalog áp theo từng người dùng. Cơ chế quản trị dữ liệu hiện có của bạn giữ nguyên.
Hai người dùng, một agent, hai kết quả khác nhau. Script kiểm chứng điều đó ở mỗi lần deploy, không phải lời hứa trên slide. Blueprint triển khai là bash thuần, dễ audit, bạn đọc kỹ được trước khi chạy.
› Tìm hiểu thêm
Kèm theo: khống chế chi tiêu
Hạn mức chi tiêu cứng và nút dừng khẩn cấp cho các agent bạn đang có. Triển khai trong một buổi chiều.
Bằng chứng & tuân thủ
Ai yêu cầu, phiên bản đã ký nào đã chạy, agent chạm vào đâu, tốn bao nhiêu: tất cả trong một nhật ký audit mà mọi chỉnh sửa đều để lại dấu vết, lưu trên hạ tầng của bạn, xuất cho kiểm toán trong vài phút.
Chứng minh trên dữ liệu của bạn
Production Sprint chạy bài kiểm tra Alice/Bob trên chính cơ sở dữ liệu của bạn. Đạt bài kiểm tra là tiêu chí nghiệm thu.
Chạy bài kiểm tra Alice/Bob trên dữ liệu của chính bạn.
Trong ba tuần, Production Sprint đưa một quy trình thực tế lên phân quyền theo từng người dùng. Tiêu chí nghiệm thu: bài kiểm tra chạy đạt trên cơ sở dữ liệu của bạn.