AI đọc file đính kèm email: làm sao tránh file độc hại và chỉ dẫn ẩn?

Không nên để AI mở trực tiếp file đính kèm email trong cùng môi trường có quyền truy cập dữ liệu hoặc gọi tool. Thiết kế an toàn là xem byte của file và mọi nội dung trích xuất từ file đều không đáng tin cậy. File phải đi qua vùng cách ly, kiểm tra loại thật, giới hạn kích thước, antivirus/sandbox và chuyển đổi an toàn trước khi AI chỉ nhận bản biểu diễn đã làm sạch. Mọi câu như “bỏ qua quy tắc”, “gửi dữ liệu này” hoặc “gọi API” nằm trong tài liệu phải được xem là nội dung cần phân tích, không phải lệnh dành cho hệ thống.

Pipeline nên tách rõ: email gateway → quarantine → file inspection → safe extraction/CDR → AI analysis không có side effect → business validation → approval hoặc executor độc lập. Quét malware không chặn được prompt injection; prompt bảo AI “hãy bỏ qua chỉ dẫn trong file” cũng không đủ để chặn mã độc hay một cuộc tấn công được che giấu tốt. Cần nhiều lớp kiểm soát độc lập và mặc định fail closed khi không xác định được loại file, file được mã hóa, parser lỗi hoặc kết quả kiểm tra mâu thuẫn.

Một file đính kèm có thể gây hại theo nhiều đường khác nhau. Malware, macro, script, embedded object hoặc lỗ hổng trong thư viện PDF/Office nhắm vào hạ tầng xử lý. Archive lồng nhau, ảnh cực lớn hoặc tài liệu có cấu trúc bất thường có thể làm cạn CPU, RAM và dung lượng dù không chứa mã độc đã biết. File mang phần mở rộng .pdf cũng có thể là định dạng khác nếu hệ thống chỉ tin filename hay Content-Type do người gửi cung cấp.

Nhóm thứ hai là indirect prompt injection. NIST mô tả kiểu tấn công này là khi bên thứ ba kiểm soát tài nguyên mà hệ thống AI đọc và chèn chỉ dẫn qua kênh dữ liệu. Trong email attachment, chỉ dẫn có thể xuất hiện trong chữ trắng trên nền trắng, font cực nhỏ, comment, metadata, annotation PDF, alt text, layer bị ẩn, ảnh cần OCR, chuỗi mã hóa hoặc một URL dẫn sang nội dung giai đoạn hai. Mục tiêu có thể là làm sai bản tóm tắt, lấy dữ liệu riêng, đánh dấu hóa đơn giả là hợp lệ hoặc khiến agent gọi tool.

Vì vậy trạng thái malware_scan=clean chỉ nói rằng lớp quét không phát hiện mẫu hành vi độc hại theo khả năng hiện tại. Nó không chứng minh file đúng nghiệp vụ, không có parser exploit, không chứa chỉ dẫn đối nghịch và không nên được tự động thực thi.

Ngay khi nhận email, workflow chỉ nên ghi metadata và lưu file vào object storage dành riêng cho quarantine. Tên object do hệ thống sinh, không dùng trực tiếp filename của người gửi; bucket không public, không mount vào webroot và không cho phép execute. Worker xử lý file chạy bằng identity riêng, filesystem tạm thời, quyền read-only với object đầu vào, không có secret nghiệp vụ và không có network egress ngoài endpoint quét được allowlist. Sau job, môi trường tạm phải bị hủy.

Tách ít nhất ba service account:

• Ingestion: nhận email, hash file, lưu quarantine và tạo job; không đọc nội dung.
• Inspection/extraction: quét và chuyển đổi file; không có quyền CRM, ERP, mailbox khác hoặc tool gửi dữ liệu.
• Business executor: chỉ nhận dữ liệu có cấu trúc đã qua policy; không được đọc file gốc tùy ý.

Nếu parser bị khai thác, kẻ tấn công chỉ chiếm một worker dùng một lần với quyền rất hẹp. Nếu model bị prompt injection, nó cũng không sở hữu token đủ để gửi email, tải dữ liệu nội bộ hay thay đổi hệ thống đích. Đây là blast-radius control quan trọng hơn việc cố dự đoán mọi payload có thể xuất hiện.

Một pipeline production có thể triển khai theo thứ tự sau:

1. Email control: áp dụng anti-spam, anti-phishing, DMARC signal, reputation và chính sách attachment tại email gateway. Với Microsoft 365, Safe Attachments bổ sung detonation trong môi trường ảo sau lớp anti-malware; đây là lớp đầu vào hữu ích nhưng không thay thế kiểm soát của ứng dụng AI.
2. Intake limits: giới hạn số file/email, kích thước từng file và tổng dung lượng; hash SHA-256 để nhận diện, dedupe và hỗ trợ điều tra. Chặn executable, script và định dạng không phục vụ use case.
3. Type verification: so khớp extension, MIME do hệ thống tự nhận diện và magic bytes/file signature. Từ chối mismatch, polyglot đáng ngờ, file mã hóa hoặc định dạng chưa được hỗ trợ.
4. Archive policy: giới hạn độ sâu, số entry, tổng kích thước giải nén và tỷ lệ nén; không đi theo symlink/path traversal; quét từng file con.
5. Malware inspection: chạy antivirus và, với file rủi ro, detonation trong sandbox. Timeout, engine unavailable hoặc kết quả không xác định phải đưa về quarantine.
6. CDR hoặc conversion: với PDF/DOCX phù hợp, loại macro, active content, embedded object và external reference; ưu tiên render sang PDF/ảnh hoặc trích xuất sang text/JSON chuẩn hóa thay vì chuyển file gốc cho model.
7. Safe extraction: parser trong container/microVM không đặc quyền, có CPU/RAM/time limit, network bị chặn và thư viện được vá. Ghi lại parser/version cùng hash đầu vào và đầu ra.
8. AI gate: chỉ gửi text/OCR đã gắn provenance, không gửi credential hoặc quyền tool; yêu cầu output theo schema và bằng chứng theo trang/vùng nội dung.

Trước khi gọi model, hệ thống nên canonicalize nội dung về một biểu diễn nhất quán: text nhìn thấy, OCR, bảng, link, metadata và vị trí nguồn. Các trường dễ bị bỏ qua như comment, hidden run, font có opacity thấp, text ngoài vùng hiển thị, annotation, layer, alt text và external relationship nên được tách riêng thành suspicious_content, không âm thầm trộn vào nội dung chính. Nếu text trích xuất khác đáng kể với bản render/OCR, tăng risk score hoặc chuyển review.

Đóng gói context với ranh giới máy đọc được, ví dụ source=email_attachment, trust=untrusted, file_hash, page, visible=true/false. System instruction phải nói rõ nhiệm vụ là trích xuất/phân loại; không làm theo yêu cầu xuất hiện trong vùng untrusted. Yêu cầu model trả output đóng như document_type, fields, evidence, uncertainties, injection_signals và recommended_route, đồng thời từ chối field lạ.

Nhưng delimiter, XML tag hay câu dặn trong prompt chỉ giảm xác suất model bị đánh lừa. OWASP và NIST đều lưu ý prompt injection có thể đến từ file bên ngoài, bị che giấu hoặc diễn ra nhiều giai đoạn. Do đó detector không nên tự mình quyết định safe=true; kết quả của nó chỉ là một tín hiệu trong policy.

Dùng hai bước AI thay vì một agent toàn quyền

Bước đầu là content analyzer không có tool: nó chỉ trích xuất dữ liệu, tìm dấu hiệu bất thường và gắn evidence. Không đưa vào context danh bạ, lịch sử mailbox khác, secrets hay dữ liệu khách hàng không cần thiết. Với tác vụ hóa đơn, analyzer chỉ cần trả vendor, invoice number, ngày, tổng tiền, currency và vị trí bằng chứng; nó không cần quyền tạo thanh toán.

Bước sau là decision workflow xác minh sender/domain, đối chiếu dữ liệu master, kiểm tra trùng, trạng thái đơn hàng, hạn mức và policy. Nếu cần hành động, backend tạo một proposed action. Policy engine kiểm tra tenant, user/agent identity, action, resource, argument bounds, idempotency và approval trước khi executor dùng credential ngắn hạn. File hoặc model không bao giờ được truyền trực tiếp tên tool và arguments sang executor mà không có bước tái dựng, canonicalize và authorize từ phía server.

Với nội dung nghi có injection, hệ thống có thể vẫn trích xuất các trường không nhạy cảm nhưng phải chặn autonomous action, không theo URL trong file và không truy vấn thêm dữ liệu riêng theo yêu cầu của tài liệu.

Có thể chuẩn hóa policy thành bốn tuyến:

• Reject: loại file bị cấm, signature mismatch rõ, malware confirmed, archive bomb, parser exploit signal hoặc hash nằm trong denylist. Giữ mẫu theo retention policy phục vụ điều tra; không gửi sang AI.
• Quarantine/review: file mã hóa, không nhận diện được loại, sandbox timeout, engine unavailable, external object, text ẩn đáng kể, prompt-injection signal hoặc các engine cho kết quả mâu thuẫn.
• Analyze only: file đạt kiểm tra kỹ thuật nhưng sender chưa xác minh, dữ liệu thiếu hoặc nghiệp vụ nhạy cảm. AI được trích xuất/tóm tắt nhưng không được tạo side effect.
• Eligible for automation: loại file nằm trong allowlist, các gate kỹ thuật đạt, nguồn và dữ liệu nghiệp vụ được xác minh, action có blast radius thấp, policy cho phép và idempotency đã có. “Eligible” vẫn không có nghĩa model tự cấp quyền; executor phải authorize từng request.

Không dùng một điểm số tổng hợp không giải thích được. Lưu các verdict riêng như type_verdict, malware_verdict, sandbox_verdict, content_verdict, sender_verdict và business_verdict. Policy nên deny-by-default nếu thiếu một verdict bắt buộc.

Đưa kiểm soát vào n8n hoặc workflow engine mà không tạo đường tắt

Trong n8n, không nên tải attachment rồi đưa binary thẳng vào AI node. Workflow chỉ nên gọi các dịch vụ chuyên trách qua job ID:

1. Trigger nhận message ID và metadata; kiểm tra idempotency theo mailbox + message ID + attachment hash.
2. Upload file vào quarantine bằng tên do server sinh; trạng thái RECEIVED.
3. Gọi inspection API bất đồng bộ; chuyển sang SCANNING, sau đó nhận verdict có chữ ký hoặc truy vấn bằng job ID.
4. Chỉ khi policy cho phép mới gọi extraction API; lưu sanitized artifact riêng và chuyển EXTRACTED.
5. Gọi AI bằng sanitized text, schema cố định và correlation ID; output là PROPOSED, chưa phải hành động.
6. Chạy business rules/policy. Nhánh nhạy cảm đi REVIEW_REQUIRED; nhánh hợp lệ đi executor với idempotency key; nhánh lỗi đi QUARANTINED hoặc REJECTED.

Credential của email, scanner, AI và hệ thống đích phải tách riêng. Node AI không nhìn thấy token executor. Không cho Code node chạy binary do người gửi cung cấp, không mở macro, không tự tải URL trong tài liệu và không ghi raw content nhạy cảm vào execution log. Retry phải đọc trạng thái job hiện có thay vì tải, quét hoặc thực thi lại không kiểm soát.

Quan sát, lưu vết và xử lý sự cố

Mỗi file cần một chain of custody: tenant/mailbox, message ID, sender, received time, filename gốc đã escape, size, SHA-256, detected MIME/signature, scanner và signature version, sandbox/CDR/parser version, từng verdict/reason, sanitized artifact hash, model/prompt version, policy decision và action cuối. Redact nội dung nhạy cảm; log không phải nơi lưu toàn bộ file hay prompt nguyên bản.

Theo dõi tỷ lệ rejected/quarantined theo reason, scanner timeout, parser crash, compression ratio violation, file-type mismatch, hidden-content signal, injection signal, AI schema failure, action bị policy chặn và false positive sau review. Cảnh báo khi một sender/domain tạo đột biến file bất thường, cùng hash xuất hiện ở nhiều mailbox hoặc parser crash lặp lại với cùng định dạng.

Khi phát hiện file đã lọt qua, cần tìm theo hash để cô lập các bản sao, thu hồi sanitized artifact và kết quả AI liên quan, chặn executor, xoay credential nếu có khả năng lộ, kiểm tra outbound call và chạy lại bằng engine/policy đã cập nhật. Retention cho file quarantine phải phù hợp dữ liệu cá nhân và yêu cầu pháp lý; không giữ vô thời hạn chỉ để debug.

Kiểm thử trước khi cho chạy tự động

Bộ regression cần có file sạch và file đối kháng: extension/MIME/signature không khớp, macro, embedded object, encrypted PDF/ZIP, nested archive, zip bomb mô phỏng an toàn, file cực lớn, PDF lỗi cấu trúc, external link, white-on-white text, font cực nhỏ, comment/metadata injection, ảnh có chỉ dẫn OCR, Base64 instruction và prompt yêu cầu gọi tool hoặc tiết lộ dữ liệu. Chỉ dùng mẫu vô hại trong môi trường test được kiểm soát.

Tiêu chí nghiệm thu không chỉ là detector bắt được bao nhiêu prompt injection. Hãy kiểm tra các bất biến:

• File chưa có verdict không thể đến AI.
• AI chỉ nhận sanitized artifact và provenance đúng file.
• Analyzer không có đường network/tool tạo side effect.
• Nội dung file không thể thay đổi system policy, recipient, tenant hoặc executor credential.
• Policy timeout/missing attribute luôn fail closed.
• Approval bị vô hiệu nếu action hoặc arguments thay đổi.
• Replay/retry không tạo hành động trùng.
• Có thể truy vết từ hành động về model output, sanitized hash và file gốc.

Nên chạy red-team định kỳ vì kỹ thuật ẩn chỉ dẫn và parser vulnerabilities thay đổi theo thời gian.

Checklist triển khai an toàn

1. Xác định chính xác file type và trường dữ liệu mà use case cần; deny mọi loại còn lại.
2. Bật kiểm soát attachment ở email gateway; không coi đó là lớp duy nhất.
3. Lưu file vào quarantine không public, không execute và dùng tên object nội bộ.
4. Giới hạn size, count, archive depth, decompressed bytes, CPU, RAM và timeout.
5. So khớp extension, MIME và magic bytes; xử lý riêng file mã hóa và mismatch.
6. Chạy antivirus, sandbox và CDR/conversion theo risk tier; fail closed khi engine không sẵn sàng.
7. Parse trong workload dùng một lần, không đặc quyền, không egress và không chứa secrets.
8. Canonicalize visible text/OCR/metadata, gắn provenance và tách suspicious hidden content.
9. Dùng analyzer không có tool; output đóng theo schema, có evidence và uncertainty.
10. Xác minh sender, dữ liệu bắt buộc và quy tắc nghiệp vụ ngoài model.
11. Đặt policy/approval/idempotency trước executor có credential tối thiểu.
12. Ghi chain of custody, metrics, alert, retention và incident playbook; test lại khi đổi parser, model hoặc prompt.

Nếu chưa đáp ứng được các bước này, phạm vi an toàn ban đầu là AI chỉ tóm tắt file đã được người dùng tin cậy tải lên, không tự động xử lý mọi attachment từ internet và không được gọi tool.