Bài 2 — Least-privilege: cấp quyền vừa đủ cho agent

Least-privilege (nguyên tắc đặc quyền tối thiểu) nghĩa là: agent chỉ được cấp đúng quyền cần để hoàn thành nhiệm vụ, trong đúng phạm vi, trong đúng khoảng thời gian — không hơn một chút nào. Đây là lá chắn số một khi agent bị prompt injection hay lỗi logic.

Bốn chiều của least-privilege

Một quyền không chỉ là "có/không". Hãy thu hẹp theo 4 chiều:

• Hành động (verb): chỉ read thay vì read+write+delete.
• Phạm vi (scope): chỉ đọc đơn hàng của khách đang chat, không phải toàn bộ bảng orders.
• Thời gian (TTL): token sống 15 phút, không phải vĩnh viễn.
• Điều kiện (condition): chỉ hoàn tiền khi số tiền < 500k và giờ hành chính.

Ví dụ cụ thể: agent phân tích doanh thu

Sai (cấp cả cụm quyền database):

GRANT ALL PRIVILEGES ON sales_db.* TO 'agent'@'%';

Đúng (chỉ đọc đúng view cần thiết):

CREATE VIEW v_revenue_readonly AS
  SELECT month, region, SUM(amount) AS revenue
  FROM orders GROUP BY month, region;

GRANT SELECT ON sales_db.v_revenue_readonly TO 'agent_analytics'@'10.0.%';

Agent chỉ thấy dữ liệu tổng hợp, không đọc được email hay số thẻ khách hàng, và chỉ kết nối được từ subnet nội bộ.

Các bước áp dụng least-privilege

• Bắt đầu từ số 0: agent khởi tạo với không quyền nào.
• Chạy thử nhiệm vụ thật, ghi lại mọi quyền bị thiếu (deny log).
• Cấp thêm từng quyền một, ở scope hẹp nhất có thể (view/row-level thay vì full table).
• Gắn TTL và điều kiện cho token/role.
• Định kỳ rà soát và thu hồi quyền không dùng trong 30 ngày.

Scoped tool: least-privilege ở tầng ứng dụng

Không chỉ database — bản thân định nghĩa tool cũng phải hẹp. So sánh:

# Tệ: một tool vạn năng, agent tự viết SQL
def run_sql(query: str): ...

# Tốt: tool hẹp, tham số bị ràng buộc
def get_customer_orders(customer_id: int, limit: int = 20):
    assert limit <= 50
    # chỉ chạy truy vấn cố định, tham số hóa
    return db.query(
        "SELECT id, status, total FROM orders WHERE customer_id=%s LIMIT %s",
        (customer_id, limit))

Tool run_sql cho agent toàn quyền viết truy vấn — cực kỳ nguy hiểm. Tool get_customer_orders chỉ làm đúng một việc, tham số bị chặn.

Least-privilege theo thời gian: token ngắn hạn

Một quyền cấp vĩnh viễn là một quyền chờ bị lạm dụng. Hãy gắn TTL cho mọi credential và ưu tiên token dùng-một-lần khi có thể:

# Token sống 15 phút, chỉ đủ cho một phiên làm việc
token = sts.assume_role(
    role="agent_analytics_readonly",
    duration_seconds=900,           # tự hết hạn sau 15'
    scope=["read:revenue_view"])    # đúng một scope

Khi token hết hạn, kể cả khi bị lộ, kẻ tấn công cũng chỉ có một cửa sổ rất hẹp để khai thác. So với một API key tĩnh sống ba năm, đây là khác biệt giữa một vết xước và một thảm họa. Kết hợp scope hẹp + TTL ngắn khiến "bán kính thiệt hại" (blast radius) của một quyền bị lạm dụng nhỏ đi rất nhiều.

Khung tư duy: "Deny by default"

Mọi quyền mặc định là cấm. Chỉ mở khi có lý do rõ ràng, và mỗi lần mở phải trả lời được 3 câu:

• Nhiệm vụ nào thực sự cần quyền này?
• Scope hẹp nhất để làm được nhiệm vụ đó là gì?
• Quyền này sống bao lâu và ai thu hồi?

Checklist least-privilege

• [ ] Agent bắt đầu với zero quyền, chỉ thêm khi chứng minh cần.
• [ ] Mỗi quyền hẹp theo verb + scope + TTL + condition.
• [ ] Không có tool "vạn năng" (run_sql, exec, eval, http_request tự do).
• [ ] Row-level / view-level thay vì full-table access.
• [ ] Có job định kỳ thu hồi quyền không sử dụng.

Sai lầm thường gặp

• Cấp quyền theo cụm cho tiện (:, ALL PRIVILEGES, wildcard scope). Tiện lúc dev, thảm họa lúc bị injection.
• Tool nhận chuỗi tự do (SQL, shell, URL) rồi thực thi — agent bị lừa viết lệnh độc.
• Quyền không có TTL: token cấp một lần, sống mãi mãi, không ai nhớ để thu hồi.
• Nhầm "agent hoạt động được" là "đủ an toàn": agent chạy tốt vẫn có thể đang dư thừa quyền chờ bị lạm dụng.
• Cấp quyền dựa trên "biết đâu sau này cần" — quyền dự phòng chính là quyền bị khai thác.

Bài 3 sẽ giải quyết câu hỏi: những secret (API key, token) mà agent cần — cất ở đâu và đưa vào agent thế nào cho an toàn?