Cô lập dữ liệu
Cô lập giữa các tổ chức, cô lập end-user, khoá chỉ dùng phía server.
Harnix được xây multi-tenant từ đầu: mọi dữ liệu nghiệp vụ (agent, knowledge base, tài liệu, hội thoại, run, run event…) đều gắn với đúng một tổ chức, và mọi truy vấn đọc/ghi đều đi qua một tầng bắt buộc lọc theo tổ chức đó — không phải một bộ lọc thêm vào sau ở tầng API. Tổ chức A không thể, bằng bất kỳ cách nào qua API công khai hay console, đọc hoặc sửa dữ liệu của tổ chức B.
Cô lập giữa các tổ chức
- Mỗi request quản trị xác thực qua danh tính đăng nhập của bạn, và tổ chức trong đường dẫn URL phải khớp đúng tổ chức bạn thuộc về — không thì trả về "không tìm thấy" (404), không phải "không có quyền" (403), để một kẻ dò URL không thể biết được id tổ chức khác có tồn tại hay không.
- Mọi bộ kiểm thử cô lập chạy trên toàn bộ route trước khi một thay đổi được phát hành — một route org-scoped mới mà thiếu ca kiểm thử cô lập sẽ chặn việc phát hành, không phải một quy ước tự giác.
Cô lập giữa các end-user
Trong cùng một tổ chức, end-user này không đọc được hội thoại hay run của end-user khác. Điều này áp dụng cả cho:
- Danh tính ẩn danh (chỉ publishable key) — mỗi phiên trình duyệt là một end-user riêng.
- Danh tính đã ký (
end-user-id+user-hash) — end-user id do backend của bạn cấp, được xác minh bằng chữ ký, không phải tự khai. - Gọi server-to-server bằng API key — một API key của tổ chức A không bao giờ chạm được run hay hội thoại của tổ chức B, dù có cố tình đoán id.
Khoá và bí mật chỉ ở phía server
API key, identity secret, khoá gọi LLM của agent, và header xác thực của MCP server đều chỉ nên tồn tại trên backend của bạn — không bao giờ trong mã chạy ở trình duyệt hoặc app di động. Publishable key là ngoại lệ có chủ đích: nó an toàn để công khai vì chỉ mở được bước đổi token, và chỉ từ các domain bạn cho phép (xem Tích hợp).
Xem Dữ liệu để biết những gì được lưu và mã hoá ra sao.