Threat Model theo Hành động & Cách ly Môi trường

Thiết kế niềm tin ngay trong quy trình làm việc

Đến Ngày 3, agent trong bài capstone đã có thể dùng tool và nạp các quy trình nghiệp vụ. Những năng lực ấy cũng làm tăng phạm vi tác động khi xảy ra sự cố (blast radius). Một model chỉ trở thành agent khi harness cung cấp state, tool, khả năng thực thi và phản hồi. Vì thế, security phải bảo vệ toàn bộ harness, thay vì chỉ bảo vệ prompt hoặc endpoint của model.

Phần mềm truyền thống thường coi trust là một cổng: xác thực một lần, nhận một role, rồi chạy mã có hành vi dự đoán được. Hành vi của agent lại mang tính xác suất và phụ thuộc vào ngữ cảnh. Một credential hợp lệ không chứng minh hành động hiện tại phù hợp với ý định của người dùng. Trust vì vậy phải được kiểm tra liên tục theo danh tính, ngữ cảnh, tool, dữ liệu, thời điểm và tác động dự kiến.

Khung an ninh cho agent (secure agent framework) bên dưới sắp xếp trách nhiệm đó thành bảy trụ cột.

Hãy đọc khung security này từ lớp nền tảng đến khả năng phản ứng trong runtime:

1. Hạ tầng và mạng (Infrastructure and networking): Cô lập code được sinh ra và kiểm soát truy cập đi ra ngoài (outbound access).
2. Dữ liệu (Data): Bảo vệ ngữ cảnh nhạy cảm, memory và ranh giới tenant (tenant boundaries).
3. Model: Bảo vệ system instructions và lọc tấn công ngữ nghĩa (semantic attacks).
4. Ứng dụng và runtime (Application and runtime): Chặn lệnh gọi tool và thực thi các hook xác định (deterministic hooks).
5. Danh tính và truy cập (Identity and access): Cấp danh tính tường minh cho agent cùng quyền hạn ngắn hạn.
6. Khả năng quan sát và vận hành security (Observability and security operations): Tái dựng hành vi và phản ứng với bất thường (anomalies).
7. Quản trị (Governance): Xác định trách nhiệm, lưu bằng chứng và đáp ứng nghĩa vụ phát hành.

Product Manager không trực tiếp cài đặt từng cơ chế kiểm soát, nhưng phải quyết định hành động nào của người dùng cần chúng. Yêu cầu security chỉ hữu ích khi được ánh xạ vào hành trình người dùng. “Áp dụng quyền tối thiểu” vẫn quá trừu tượng. “Research agent chỉ được đọc dữ liệu tài khoản giả lập trong workspace hiện tại và không được ghi vào CRM” mới là yêu cầu kiểm thử được.

Bảy trụ cột tạo thành hệ thống phòng thủ nhiều lớp, không phải bảy mục kiểm tra độc lập. Một lỗi ở trụ cột này vẫn phải gặp cơ chế kiểm soát ở trụ cột khác:

Kiến trúc này chuyển ranh giới an toàn từ danh tính tĩnh sang ngữ cảnh là ranh giới. Đầu ra của runtime là Effective Trust: không phải huy hiệu vĩnh viễn, mà là quyết định được tính lại liên tục theo tính toàn vẹn của chuỗi cung ứng, danh tính, các liên kết hiện tại, hành vi và tác động được yêu cầu. PM phải xác định bằng chứng nào làm trust tăng hoặc giảm, và tín hiệu nào thiếu đi sẽ khiến hệ thống chặn an toàn (fail-closed).

Xây dựng threat model xoay quanh hành động

Hãy bắt đầu từ những hành động sản phẩm có thể thực hiện, thay vì một danh sách mối đe dọa AI chung chung. Với mỗi tool hoặc tác vụ được ủy quyền, hãy ghi nhận:

1. Thẩm quyền (Authority): Quyền của ai đang được dùng.
2. Phạm vi (Scope): Ranh giới dữ liệu và hành động nhỏ nhất cần thiết.
3. Tác động (Impact): Điều gì thay đổi nếu hành động thành công.
4. Khả năng hoàn tác (Reversibility): Kết quả có thể đảo ngược không.
5. Khả năng hiển thị (Visibility): Người dùng và operator có thể kiểm tra gì.
6. Can thiệp (Intervention): Con người hoặc chính sách có thể dừng workflow ở đâu.

Sau đó, truy vết cách ngữ cảnh không đáng tin cậy có thể ảnh hưởng đến hành động ấy. Chỉ dẫn độc hại có thể đến từ trang web được truy xuất, file trong repository, phản hồi từ MCP server, ticket hỗ trợ hoặc tài liệu người dùng tải lên. Model có thể không phân biệt nội dung này với hướng dẫn hợp lệ, trừ khi harness tách dữ liệu khỏi chỉ dẫn và xác thực hành động phát sinh ở bên ngoài model.

Với sales research agent của bài capstone, một thang rủi ro hữu ích có thể là:

Bảng này gắn quyền tự chủ với bằng chứng. Sản phẩm vẫn tạo giá trị qua nghiên cứu và tạo nháp mà không cần cấp quyền ghi quá rộng ngay từ ngày đầu.

Hãy biến threat model thành sổ đăng ký hành động do PM sở hữu, thay vì một slide chỉ được review một lần. Mỗi dòng phải nêu user job, tool, phân loại dữ liệu, tác động tối đa, người phê duyệt, cách rollback và bằng chứng cần lưu. Cập nhật sổ khi tool, model, nguồn truy xuất hoặc phân quyền thay đổi. Các chỉ số hữu ích gồm số hành động tác động cao bị chặn, hành động chạy với phê duyệt đã cũ, thời gian trung bình thu hồi quyền, tỷ lệ lệnh gọi tool được chính sách bao phủ và tỷ lệ rollback thành công.

Cô lập môi trường thực thi và bảo vệ chuỗi cung ứng

Code do agent sinh ra nên chạy trong môi trường tạm thời, ít quyền và có truy cập mạng hạn chế. Sandbox không phải toàn bộ chiến lược security, nhưng giới hạn phạm vi mà script xấu có thể chạm tới và ngăn state âm thầm tồn tại qua nhiều lượt chạy.

Việc cài dependency cần cơ chế kiểm soát riêng. Model có thể đề xuất package lỗi thời, sai hoặc không tồn tại; kẻ tấn công có thể phát hành package độc hại dưới tên rất hợp lý. Hãy dùng registry đã duyệt, ghim phiên bản, Software Composition Analysis (SCA) và kiểm tra CI xác định trước khi một thành phẩm được sinh ra được chuyển tiếp.

Network egress phải đi qua đường dẫn có quản trị. Một domain allowlist rộng không ngăn agent lấy chỉ dẫn độc hại từ trang web được phép. Hãy ưu tiên dịch vụ truy xuất đã được làm sạch, proxy nội bộ hoặc cache offline cho nội dung bên ngoài không đáng tin cậy. Không đưa credential vào prompt, log, script được sinh ra hoặc test fixture.

Đó là truy cập internet không tương tác: agent yêu cầu nội dung qua đường dẫn truy xuất có quản trị, nhưng không được tự do duyệt web, đăng nhập vào các trang tùy ý hoặc theo các liên kết chứa chỉ dẫn. Sản phẩm phải xác định các loại nội dung được phép, độ mới của cache, cách xử lý khi làm sạch thất bại và phương án dự phòng hiển thị cho người dùng khi không thể lấy nguồn an toàn.

Với thay đổi ứng dụng, hãy tách phản hồi mang tính tư vấn khỏi việc cưỡng chế. Hướng dẫn trong IDE giúp lập trình viên nhận ra code rủi ro; CI vẫn là cổng cứng đối với dependency có lỗ hổng, rò rỉ secret, thiếu test và quy tắc security về cấu trúc. Agent không được phép thuyết phục pipeline xác định bỏ qua vi phạm.

Hãy viết containment contract thật cụ thể. Sandbox phải chặn truy cập trực tiếp vào host, cách ly mạng, chỉ dùng credential theo phạm vi tác vụ và reset mọi state có thể ghi giữa các lượt chạy. Container vẫn giữ file do agent tạo hoặc dùng chung credential của tiến trình cha thì không phải môi trường tạm thời. Hãy kiểm thử vượt rào container, đọc file bị cấm, egress bị cấm, credential hết hạn và reset sạch; ghi nhận kết quả theo phiên bản sandbox.

Sự cố chuỗi cung ứng có một hình thái cụ thể: model bịa ra một package nghe hợp lý, kẻ tấn công phát hành malware dưới tên đó, rồi agent tự động cài đặt package. Đây gọi là hiện tượng slopsquatting. Ngăn chặn nó bằng các registry đã duyệt, cố định phiên bản bằng chữ ký số, xác minh SBOM, chữ ký package, SCA và phân quyền nhị phân (Binary Authorization) trước khi thăng cấp (promotion). PM thiết lập chính sách dependency và người sở hữu ngoại lệ; bằng chứng bao gồm số lần chặn package lạ, thành phẩm chưa ký, tỷ lệ rò rỉ package có lỗ hổng và thời gian thu hồi một phiên bản bị xâm nhập.

An ninh ứng dụng cũng cần các trường hợp không hợp lệ (negative cases) rõ ràng. Code UI được sinh ra thường đặt API key, kiểm tra mật khẩu hoặc các cờ session trong browser-nơi người dùng có thể xem hoặc sửa đổi. Backend được sinh ra thường bỏ qua phân quyền mặc định từ chối (default-deny authorization) hoặc an ninh cấp dòng (row-level security), khiến các bản ghi riêng tư hoặc hệ thống staging bị lộ ra ngoài. Hãy thêm các bài test thao túng trạng thái client, gọi backend không qua UI, vượt ranh giới tenant và truy cập staging dưới danh nghĩa ẩn danh. Linting tư vấn trong IDE có thể giải thích nhanh vấn đề, nhưng SAST, SCA, quét secret cố định, test phân quyền và chính sách triển khai vẫn là các cổng kiểm soát trong CI/CD.

Repository cũng là một kênh đầu vào, không phải nguồn chân lý mặc nhiên đáng tin. Kẻ tấn công có thể giấu payload ẩn trong code, tài liệu hoặc ví dụ được truy xuất bằng Unicode zero-width, homoglyph, comment đánh lạc hướng hoặc văn bản chỉ dẫn dành cho agent thay vì người review. Khi agent sao chép nội dung này, repository poisoning có thể lan sang nhiều file nhanh hơn khả năng review từng dòng.

Hãy xem việc nạp thông tin từ repository như một ranh giới an ninh:

• Chuẩn hóa và quét Unicode trước khi nội dung vào context của agent.
• Phân biệt chỉ dẫn có thể thực thi với dữ liệu được trích dẫn và tài liệu.
• Ghi nguồn gốc và tính toàn vẹn của snippet cùng dependency được truy xuất.
• Chặn thay đổi được sinh ra đưa vào package chưa duyệt, payload được mã hóa hoặc lệnh gọi mạng không giải thích được.
• Quét lại toàn bộ diff trong CI, kể cả khi IDE không báo lỗi.

Quyết định của PM không phải mua scanner nào, mà là sản phẩm cam kết tin nguồn nào, xử lý ra sao khi thiếu provenance, và nguồn đáng ngờ sẽ chặn toàn bộ lượt chạy hay chỉ bị loại khỏi context.