Bảo mật LLM: Threat model và checklist phòng thủ

Trả lời nhanh: bảo mật LLM là bảo vệ toàn bộ ứng dụng dùng mô hình, không chỉ bảo vệ model. Threat model phải bao phủ input, dữ liệu, RAG, tool, output, supply chain, hạ tầng và người vận hành. Phòng thủ hiệu quả dùng nhiều lớp: tách quyền, xác thực bên ngoài model, lọc dữ liệu, sandbox, approval, logging, eval và kế hoạch ứng phó.

Cập nhật lần cuối: 20/08/2026

Một chatbot chỉ tạo văn bản có blast radius khác hẳn một agent được phép đọc email, truy vấn CRM, sửa file và gửi thanh toán. Cả hai có thể dùng cùng một model, nhưng threat model không giống nhau.

Sai lầm phổ biến là xem prompt injection như toàn bộ bài toán bảo mật LLM. Prompt injection quan trọng, nhưng sự cố chỉ trở nên nghiêm trọng khi chỉ dẫn độc hại đi qua trust boundary, chạm dữ liệu nhạy cảm hoặc kích hoạt một hành động có hậu quả.

Vì vậy, câu hỏi đúng không phải “làm sao để model không bao giờ bị lừa?”. Câu hỏi đúng là: “nếu model bị lừa, hệ thống bên ngoài giới hạn thiệt hại đến đâu?”.

Bảo mật LLM là gì?

Bảo mật LLM là tập hợp biện pháp bảo vệ tính bí mật, toàn vẹn, sẵn sàng và khả năng kiểm soát của hệ thống có sử dụng mô hình ngôn ngữ lớn trong toàn bộ vòng đời.

Phạm vi gồm:

dữ liệu huấn luyện và dữ liệu đầu vào;
model weights, model API và cấu hình;
system prompt, template và policy;
retrieval index và nguồn RAG;
tool, plugin, MCP server và API tích hợp;
output được hiển thị hoặc thực thi;
log, evaluation, monitoring và pipeline CI/CD;
nhà cung cấp, dependency và con người có quyền truy cập.

OWASP duy trì Top 10 cho ứng dụng LLM và GenAI. NIST AI RMF GenAI Profile mở rộng góc nhìn sang quản trị rủi ro trong toàn vòng đời. MITRE ATLAS cung cấp cơ sở tri thức về chiến thuật và kỹ thuật tấn công hệ thống AI. Ba nguồn này bổ sung cho nhau, không thay thế security engineering truyền thống.

Threat model cho LLM bắt đầu từ đâu?

Threat model là bản mô tả tài sản, tác nhân đe dọa, trust boundary, luồng dữ liệu, abuse case và biện pháp kiểm soát. Với LLM, hãy bắt đầu bằng một sơ đồ luồng thật của sản phẩm.

Người dùng / tài liệu ngoài
  -> lớp ứng dụng
  -> prompt builder
  -> model
  -> tool / RAG / database
  -> output parser
  -> hành động hoặc giao diện

Mỗi mũi tên là nơi dữ liệu đổi mức độ tin cậy. Văn bản lấy từ website không trở thành chỉ dẫn đáng tin chỉ vì nó được đặt trong context. Output model cũng không trở thành code an toàn chỉ vì model nói rằng nó hợp lệ.

Tài sản nào cần bảo vệ?

dữ liệu khách hàng và PII;
secret, token, cookie và credential;
system prompt hoặc logic sở hữu trí tuệ;
model weights và dataset độc quyền;
ngân sách compute và quota API;
quyền gửi, sửa, xóa hoặc thanh toán;
uy tín thương hiệu và tính đúng của quyết định;
log điều tra và khả năng truy vết.

Ai có thể là tác nhân đe dọa?

người dùng ác ý;
nội dung độc hại được model đọc gián tiếp;
nhà cung cấp hoặc dependency bị xâm nhập;
nhân sự nội bộ dùng sai quyền;
bot lạm dụng tài nguyên;
attacker khai thác endpoint thông thường;
dữ liệu bị đầu độc từ trước.

Đừng chỉ mô hình hóa attacker gõ prompt trực tiếp. Một tài liệu, email, issue GitHub, website hoặc kết quả search đều có thể chứa chỉ dẫn nhằm thao túng agent.

Bề mặt tấn công đầy đủ gồm những lớp nào?

Lớp	Rủi ro chính	Kiểm soát ưu tiên
Input	Prompt injection, jailbreak, payload lớn	Phân loại, giới hạn, tách chỉ dẫn và dữ liệu
Data/RAG	Poisoning, rò rỉ, sai phân quyền	ACL tại truy xuất, provenance, quarantine
Model	Extraction, evasion, unsafe behavior	Rate limit, eval, monitoring, access control
Tool	Excessive agency, command injection	Allowlist, schema, least privilege, sandbox
Output	XSS, SQL/code injection, sai quyết định	Parse, validate, encode, policy check
Supply chain	Model/dependency bị thay đổi	Pin version, ký artifact, SBOM, review
Infrastructure	Secret leak, DoS, tenant escape	Isolation, quota, vault, network policy
People/process	Dùng sai, phê duyệt giả	RBAC, training, change control, incident plan

Threat model tốt phải nối từng rủi ro với control owner và bằng chứng kiểm thử. Danh sách chung chỉ là điểm khởi đầu.

Prompt injection trực tiếp và gián tiếp khác nhau thế nào?

Prompt injection trực tiếp

Người dùng đưa chỉ dẫn nhằm ghi đè mục tiêu, policy hoặc format. Ví dụ: yêu cầu bỏ qua quy tắc và tiết lộ dữ liệu không được phép.

Prompt injection gián tiếp

Chỉ dẫn độc hại nằm trong nội dung mà model được yêu cầu đọc: tài liệu, email, website, file, comment hay kết quả retrieval. Agent có thể hiểu văn bản này như mệnh lệnh thay vì dữ liệu.

OWASP xếp prompt injection ở vị trí nổi bật trong danh sách rủi ro LLM. Điểm khó là LLM xử lý cả chỉ dẫn và dữ liệu bằng cùng một kênh token. Dấu phân cách hoặc system prompt giúp giảm rủi ro nhưng không tạo ranh giới bảo mật tuyệt đối.

Phòng thủ prompt injection thế nào?

Không dựa vào một bộ lọc duy nhất. Kết hợp:

gắn nhãn rõ nguồn và độ tin cậy của context;
không cho nội dung ngoài tự quyết định quyền;
giảm dữ liệu và tool được đưa vào mỗi bước;
kiểm tra tool call bằng policy xác định;
yêu cầu approval cho hành động có hậu quả;
sandbox khi xử lý code hoặc file;
quan sát hành vi bất thường và dừng an toàn.

Mục tiêu là để một prompt injection thành công ở tầng model vẫn không vượt qua kiểm soát quyền ở tầng ứng dụng.

Rò rỉ dữ liệu nhạy cảm xảy ra ở đâu?

Rò rỉ có thể đến từ nhiều hướng:

người dùng đưa PII hoặc secret vào prompt;
RAG trả tài liệu mà người dùng không có quyền xem;
log lưu nguyên prompt, response và credential;
model lặp lại dữ liệu đã thấy;
tool response chứa trường nhạy cảm không cần thiết;
error message tiết lộ nội bộ;
cache dùng chung sai tenant;
dữ liệu bị gửi sang nhà cung cấp ngoài phạm vi cho phép.

Một nguyên tắc quan trọng: phân quyền phải được kiểm tra trước và trong lúc truy xuất, không giao cho model quyết định dựa trên lời người dùng.

Với RAG, query embedding không mang ý nghĩa ACL. Vector search phải lọc theo tenant, user, role, document permission và trạng thái dữ liệu ở tầng đáng tin. Sau đó mới trả chunk phù hợp cho model.

Cách giảm dữ liệu lộ ra

data minimization ở input và tool response;
redaction hoặc tokenization trước khi gọi model;
secret scanning trong prompt và output;
log có phân loại, retention và quyền truy cập;
encryption khi truyền và lưu;
tenant isolation cho cache, index và storage;
DLP cùng alert cho trường đặc biệt;
cơ chế xóa và xử lý yêu cầu dữ liệu.

System prompt “không tiết lộ bí mật” không thay thế các biện pháp này.

Excessive agency nguy hiểm ra sao?

Excessive agency xảy ra khi hệ thống trao cho model nhiều chức năng, quyền hoặc mức tự chủ hơn cần thiết. Một agent chỉ cần đọc lịch làm việc không nên có token cho phép xóa sự kiện. Một agent soạn email không nhất thiết được quyền gửi không cần duyệt.

Blast radius được quyết định bởi ba yếu tố:

Tác động = quyền truy cập x phạm vi dữ liệu x mức tự chủ

Giảm bất kỳ yếu tố nào cũng giúp giảm rủi ro.

Kiểm soát tool-use

mỗi tool có scope tối thiểu;
credential riêng theo agent và môi trường;
allowlist action, domain, file path và recipient;
schema chặt, từ chối field lạ;
giới hạn số lần gọi, chi phí và thời gian;
dry-run cho thay đổi quan trọng;
approval ngoài model;
idempotency key và audit log;
kill switch để thu hồi token hoặc dừng workflow.

Model có thể đề xuất hành động. Policy engine quyết định hành động có được thực thi hay không.

Improper output handling là gì?

Output LLM là dữ liệu không đáng tin. Nếu đưa trực tiếp vào HTML, shell, SQL, template, workflow hoặc API, hệ thống có thể gặp injection truyền thống.

Ví dụ nguy hiểm:

render HTML model tạo mà không sanitize;
thực thi code hoặc shell command nguyên văn;
nối output vào câu SQL;
dùng URL model đề xuất mà không kiểm tra domain;
parse JSON lỏng lẻo và mặc định field thiếu là an toàn;
dùng kết luận model để duyệt khoản chi tự động.

Biện pháp:

yêu cầu structured output có schema;
parse bằng thư viện chuẩn;
validate type, range, enum và length;
encode theo output context;
dùng parameterized query;
không chạy code nếu chưa sandbox và policy check;
buộc con người duyệt quyết định rủi ro cao.

Structured output giảm ambiguity, không chứng minh nội dung là đúng hoặc được phép.

Data poisoning và vector weakness ảnh hưởng thế nào?

Kẻ tấn công có thể đưa nội dung sai hoặc chỉ dẫn độc hại vào nguồn mà pipeline ingest tin tưởng. Khi được index, nội dung đó có thể xuất hiện trong nhiều truy vấn tương lai.

Các điểm cần kiểm soát:

nguồn nào được phép ingest;
ai phê duyệt tài liệu;
file có được quét malware và secret không;
chunk có giữ provenance không;
embedding/index được version thế nào;
tài liệu bị thu hồi có biến mất khỏi mọi replica và cache không;
nội dung có dấu hiệu prompt injection có bị quarantine không.

Không nên cho crawler public ghi thẳng vào knowledge base production. Dùng staging, validation, trust score và review theo mức rủi ro.

Supply chain của LLM gồm những gì?

Supply chain rộng hơn package manager. Nó gồm:

base model và license;
fine-tune, adapter và checkpoint;
dataset và dữ liệu tổng hợp;
tokenizer, model config và custom code;
container image, CUDA kernel và serving engine;
prompt template, evaluation set và policy file;
plugin, MCP server và SaaS API;
CI/CD cùng kho artifact.

Kiểm soát nên có:

pin version hoặc digest;
xác minh checksum và chữ ký khi có;
SBOM cho code và container;
chỉ tải model từ nguồn được phép;
không bật remote code tùy tiện;
scan dependency, secret và artifact;
tách quyền build, approve và deploy;
lưu provenance từ dataset đến model release;
rollback được về phiên bản đã kiểm chứng.

Một thay đổi prompt hoặc model cũng là thay đổi production và cần change control.

Model theft, extraction và denial of service là gì?

Model extraction

Attacker gửi nhiều truy vấn để học hành vi, dựng model thay thế hoặc suy ra thông tin. Rate limit, anomaly detection, output restriction và điều khoản truy cập giúp giảm rủi ro, nhưng mức bảo vệ tùy loại API.

Membership inference và data extraction

Attacker cố suy ra một mẫu có nằm trong dữ liệu train hay ép model tiết lộ chuỗi ghi nhớ. Data governance, privacy evaluation và giới hạn đầu ra là cần thiết.

Model denial of service

Prompt cực dài, output không giới hạn, tool loop hoặc request phức tạp có thể đốt token, GPU và API quota. Cần giới hạn input, output, concurrency, số bước, timeout và ngân sách.

Resource abuse

Endpoint LLM có giá thành biến đổi nên credential bị lộ có thể tạo hóa đơn lớn. Theo dõi chi phí theo user, tenant, key và workflow; đặt hard cap cùng alert.

Threat model cho AI Agent khác chatbot thế nào?

Khía cạnh	Chatbot tạo văn bản	AI Agent có tool
Tác động chính	Nội dung sai hoặc rò rỉ	Thay đổi dữ liệu, gửi, mua, xóa
Trust boundary	Input, model, output	Thêm tool, credential, memory, network
Vòng lặp	Thường một lượt hoặc ngắn	Nhiều bước, trạng thái động
Kiểm soát	Moderation, grounding, output validation	Thêm least privilege, approval, sandbox, budget
Incident	Thu hồi nội dung, sửa response	Có thể cần đảo giao dịch và thu hồi credential

Agent cần threat model theo từng tool và từng action, không chỉ theo model. Nếu một workflow gọi 12 tool, hãy hỏi mỗi tool đọc gì, ghi gì, dùng credential nào, có idempotent không và rollback ra sao.

Quy trình 9 bước xây threat model bảo mật LLM

Bước 1: Chốt use case và mức tự chủ

Ghi rõ model chỉ tư vấn, tạo nháp hay tự thực thi. Liệt kê hành động không bao giờ được tự động hóa.

Bước 2: Vẽ luồng dữ liệu

Đưa cả RAG, cache, log, queue, tool, model provider và con người vào sơ đồ. Đánh dấu dữ liệu nhạy cảm.

Bước 3: Xác định trust boundary

Phân biệt user input, nội dung bên ngoài, dữ liệu nội bộ, output model và quyết định policy. Mỗi lần dữ liệu vượt boundary phải có validation hoặc authorization.

Bước 4: Liệt kê tài sản và attacker

Xếp hạng tài sản theo mức tác động. Mô tả attacker có quyền gì, biết gì và có thể gửi bao nhiêu request.

Bước 5: Viết abuse case

Ví dụ: tài liệu RAG yêu cầu agent gửi secret; người dùng ép output thành script; attacker dùng prompt dài làm cạn quota; nhân viên truy xuất tài liệu ngoài quyền.

Bước 6: Chấm likelihood và impact

Dùng ma trận đơn giản nhưng nhất quán. Tách tác động dữ liệu, tài chính, vận hành, pháp lý và thương hiệu.

Bước 7: Gắn kiểm soát nhiều lớp

Với mỗi abuse case, có preventive, detective và responsive control. Ghi owner cùng bằng chứng kiểm thử.

Bước 8: Red-team và eval

Tạo test prompt trực tiếp, gián tiếp, đa ngôn ngữ, encoding, tool manipulation, data exfiltration và DoS. Chạy lại khi model, prompt, tool hoặc dataset thay đổi.

Bước 9: Chuẩn bị incident response

Biết cách tắt tool, thu hồi key, cô lập tenant, bảo toàn log, liên hệ người chịu trách nhiệm và thông báo theo nghĩa vụ. Tabletop exercise trước sự cố.

Checklist production ngắn gọn

Trước khi ra mắt

Sau khi ra mắt

Theo dõi anomalous tool call và data access.
Redact log nhưng vẫn giữ khả năng điều tra.
Đo false allow, false block và task success.
Rà soát quyền định kỳ.
Patch model, runtime và connector có kiểm chứng.
Chạy lại regression eval cho mọi thay đổi.
Diễn tập thu hồi credential và kill switch.

Đo bảo mật LLM bằng chỉ số nào?

Không có một điểm “an toàn” duy nhất. Scorecard nên gồm:

tỷ lệ attack success trên bộ test;
tỷ lệ tool call vượt policy;
số lần truy xuất tài liệu trái quyền;
secret/PII exposure rate;
false positive của guardrail;
thời gian phát hiện và ngăn workflow;
thời gian thu hồi credential;
chi phí tối đa mỗi phiên;
độ phủ logging và trace;
task success sau khi thêm kiểm soát.

Guardrail làm hệ thống không dùng được cũng là thất bại. Mục tiêu là giảm rủi ro mà vẫn giữ utility trong ngưỡng đã định.

FAQ - Câu hỏi thường gặp

Bảo mật LLM có thể giải quyết chỉ bằng system prompt không?

Không. System prompt là hướng dẫn cho model, không phải security boundary. Authorization, validation, sandbox và approval phải nằm trong code hoặc hạ tầng đáng tin.

Prompt injection có thể bị chặn hoàn toàn không?

Không nên giả định có thể chặn mọi biến thể. Thiết kế tốt giảm xác suất thành công và giới hạn thiệt hại khi model vẫn bị thao túng.

RAG có làm model an toàn hơn không?

RAG có thể grounding bằng nguồn cụ thể nhưng mở thêm bề mặt tấn công ở ingestion, index, ACL và nội dung truy xuất. Nó không tự động tăng an toàn.

Có nên cho agent dùng cùng credential với người dùng không?

Không mặc định. Dùng delegated scope tối thiểu, thời hạn ngắn, audit rõ và kiểm tra chính sách theo action. Tránh token toàn quyền dùng chung.

Structured output có ngăn injection không?

Nó giúp parse và validate, nhưng giá trị hợp lệ theo schema vẫn có thể độc hại hoặc không được phép. Cần authorization và semantic validation.

Khi nào cần con người phê duyệt?

Khi hành động liên quan tiền, dữ liệu nhạy cảm, gửi ra ngoài, xóa, thay đổi quyền, cam kết pháp lý hoặc không dễ đảo ngược. Mức duyệt nên dựa trên impact.

Tóm lại

Bảo mật LLM là security engineering cho một hệ thống có thành phần xác suất, không phải cuộc thi viết prompt kín kẽ nhất. Model sẽ gặp input không đáng tin và đôi khi đưa ra output sai. Kiến trúc phải chịu được thực tế đó.

Năm nguyên tắc cốt lõi:

coi mọi input và output model là không đáng tin;
kiểm tra quyền ở lớp xác định bên ngoài model;
giảm quyền, dữ liệu, công cụ và thời gian sống của credential;
dùng nhiều lớp phòng thủ cùng khả năng quan sát;
kiểm thử và diễn tập lại mỗi khi hệ thống thay đổi.

Để mở rộng sang vận hành agent, đọc Rủi ro AI Agent trong marketing. Nếu hệ thống ghép nhiều dịch vụ, API Composition là gì? giúp làm rõ dependency và trust boundary. Bài Chi phí bộ nhớ LLM bổ sung góc nhìn về resource abuse và giới hạn serving.

Nguồn tham khảo

LLM Security Basics: The Full Threat Model, ByteByteGo.
OWASP Top 10 for LLM and GenAI, OWASP.
NIST AI RMF Generative AI Profile, NIST.
MITRE ATLAS, MITRE.