Đừng cho AI skill lên prod bằng niềm tin

Đừng cho AI skill lên prod bằng niềm tin

Một playbook ngắn để quét rủi ro AI skill trước khi đưa vào workflow thật: static analysis, SARIF, custom rules và quyết định khi nào cần LLM review.

Có một niềm tin mình gặp khá nhiều ở team đang build agent: “Skill này chỉ là vài đoạn prompt với chút glue code, chắc không nguy hiểm bằng service backend đâu.”

Nghe hợp lý, vì một AI skill thường trông rất hiền: đọc file, gọi API, tóm tắt dữ liệu, điền form, bắn request. Không có database migration, không có payment flow, không có infra phức tạp. Nhưng chính vì nó hiền quá nên nhiều team cho nó vào workflow thật như nêm muối bằng cảm giác: thấy vừa miệng là bê ra bàn.

Phản đề của mình hôm nay: AI skill cần được scan như code deployable, không phải review như prompt phụ trợ. Nếu skill có quyền đọc env var, gọi shell, truy cập tool, hoặc chạm vào dữ liệu người dùng, nó đã là một phần của attack surface — bề mặt có thể bị khai thác.

Sơ đồ minh họa cho bài Đừng cho AI skill lên prod bằng niềm tin

Sơ đồ tóm tắt ý chính của bài viết.

Mục tiêu: chặn skill rủi ro trước khi nó biết chạy

NVIDIA SkillSpector đáng chú ý không phải vì nó “phát hiện mọi thứ”, mà vì nó đẩy một thói quen đúng vào sớm hơn trong pipeline: quét rủi ro bảo mật của AI skill trước khi skill được dùng trong workflow thật.

Ở đây có vài thuật ngữ cần neo nhanh:

Điểm quan trọng: đừng biến SkillSpector thành “máy phán đúng sai cuối cùng”. Hãy coi nó là lớp lọc trước khi review, để team không phải đọc từng skill bằng mắt và hy vọng ai đó đủ tỉnh.

Checklist trước khi scan: phân loại skill theo quyền hạn

Trước khi cắm tool, mình sẽ bắt team trả lời 5 câu này cho từng skill:

  1. Skill có đọc environment variable không?
  2. Skill có gọi eval, exec, shell command, hoặc dynamic import không?
  3. Skill có gửi dữ liệu ra ngoài qua HTTP, webhook, email, logging service không?
  4. Skill có nhận input trực tiếp từ user hoặc tài liệu không đáng tin không?
  5. Skill có thể bị prompt injection — lệnh độc được nhét vào nội dung đầu vào — không?

Ví dụ cụ thể: một skill “tóm tắt ticket support” nghe vô hại. Nhưng nếu nó đọc toàn bộ ticket, rồi gọi tool tạo comment nội bộ, thì prompt injection trong ticket có thể bảo nó tiết lộ hướng dẫn hệ thống hoặc gọi nhầm tool. Nếu skill còn đọc env var để lấy token, rủi ro tăng hẳn.

Đây là framework quyết định nhanh:

| Loại skill | Ví dụ | Mức kiểm soát tối thiểu |
|---|---|---|
| Chỉ xử lý text nội bộ | tóm tắt mô tả task | static scan + review prompt |
| Có gọi tool/API | tạo issue, cập nhật CRM | static scan + allowlist tool + test injection |
| Có đọc secret hoặc chạy code | env var, shell, dynamic execution | chặn mặc định, cần approval riêng |
| Có xuất dữ liệu ra ngoài | webhook, email, external API | scan + data policy + audit log |

Nói thẳng ra thì, quyền hạn của skill quan trọng hơn độ dài của prompt. Một skill 20 dòng nhưng có quyền đọc secret nguy hiểm hơn một skill 200 dòng chỉ format markdown.

Playbook một buổi chiều: dựng corpus, scan, rồi đưa vào CI

Nếu là team builder, mình sẽ không bắt đầu bằng việc scan toàn bộ repo. Làm vậy dễ ngợp và dễ bị false positive làm nản. Bắt đầu bằng một corpus nhỏ có chủ đích.

Bước 1: tạo bộ skill mẫu để hiệu chỉnh mắt nhìn

Tạo thư mục kiểu này:

ai-skills/
  safe_summary.skill
  env_harvest.skill
  dynamic_exec.skill
  prompt_injection.skill

Trong đó:

Mục tiêu không phải “lừa tool”, mà là hiểu tool nhìn rủi ro theo category nào, severity nào, recommendation nào.

Bước 2: chạy scan và gom kết quả thành bảng

SkillSpector cho phép scan qua workflow lập trình được, trong nguồn có nhắc tới cách dùng LangGraph workflow để chạy phân tích. LangGraph ở đây hiểu ngắn là cách mô hình hóa các bước xử lý thành graph: node này scan, node kia tổng hợp, node khác xuất báo cáo.

Bạn có thể gom kết quả vào bảng với các cột như:

skill_name | risk_score | severity | category | finding | recommendation

Nếu dùng pandas, mục tiêu là trả lời được:

Ẩn dụ bếp núc một chút: đừng chỉ hỏi “món này có cay không”, hãy tách ra cay vì ớt, vì tiêu, hay vì nước chấm. Security finding cũng vậy — category quan trọng để biết sửa ở đâu.

Bước 3: xuất SARIF cho CI/CD

Khi đã tin luồng scan cơ bản, xuất kết quả ra SARIF 2.1.0 để CI/CD đọc được. CI/CD là pipeline tự động build, test, scan, deploy. Với SARIF, finding có thể hiện trong code scanning UI hoặc được lưu như artifact của pipeline.

Policy gợi ý:

ai_skill_security:
  block_on:
    - critical
    - high
  require_review_on:
    - medium
  allow_with_note:
    - low
  artifact:
    format: sarif

Đây là policy minh họa, không phải cấu hình chuẩn của một tool cụ thể. Ý chính là: đừng để báo cáo nằm trong notebook rồi chết ở đó. Findings phải có đường đi vào pull request, merge gate, hoặc ít nhất là release checklist.

Bước 4: thêm custom analyzer cho luật nhà mình

Nguồn có ví dụ mở rộng SkillSpector bằng custom analyzer để phát hiện từ password trong skill content. Điểm này rất đáng giữ: security của AI skill thường có luật nội bộ mà tool mặc định không thể biết.

Ví dụ team bạn có thể thêm rule cho:

Đừng tham rule ngay từ đầu. Chọn 3-5 rule mà team từng suýt dính hoặc có khả năng dính cao. Nêm quá tay thì món nào cũng bị báo mặn, dev sẽ tắt cảnh báo cho yên.

Pitfall: scan tĩnh không hiểu hết ý đồ

Static analysis rất hợp để bắt dấu hiệu rõ: đọc env var, dynamic code execution, chuỗi nhạy cảm, pattern gọi tool đáng ngờ. Nhưng nó yếu khi rủi ro nằm ở ngữ nghĩa.

Hình dung thế này: skill không viết “gửi secret ra ngoài”. Nó chỉ nói “tổng hợp toàn bộ cấu hình runtime và gửi tới endpoint kiểm tra chất lượng”. Về mặt chữ, nghe như telemetry. Về mặt vận hành, đó có thể là exfiltration — tuồn dữ liệu ra ngoài.

Vì vậy, lớp kiểm tra nên chia làm ba mức:

  1. Rule tĩnh: nhanh, rẻ, chạy mọi pull request.
  2. Custom analyzer: luật riêng theo repo, domain, compliance của team.
  3. LLM semantic review: chỉ dùng cho skill rủi ro cao hoặc thay đổi lớn, để đọc ý đồ và luồng dữ liệu.

Đừng đưa mọi thứ vào LLM review. Vừa tốn, vừa khó ổn định, vừa làm pipeline chậm. LLM review nên giống lửa nhỏ liu riu ở nồi cần hầm kỹ, không phải bật hết bếp cho mọi món rau luộc.

Quyết định mới: chọn gate theo tác động, không theo độ mới của tool

Sau bài này, mình muốn bạn đổi một suy nghĩ: đừng hỏi “tool scan nào hot nhất?”, hãy hỏi “skill này nếu sai thì phá hỏng cái gì?”

Một decision matrix thực dụng:

| Nếu skill... | Gate nên có |
|---|---|
| chỉ đọc dữ liệu public | scan tĩnh khi merge |
| đọc dữ liệu nội bộ | scan + reviewer bắt buộc |
| gọi tool ghi dữ liệu | scan + test prompt injection + audit log |
| đọc secret/chạy code | chặn mặc định, cần security approval |
| xuất dữ liệu ra ngoài | scan + allowlist endpoint + kiểm tra data boundary |

Liên hệ nhẹ với các nguồn liên quan: câu chuyện này giống cách chọn Copilot plan không nên bắt đầu từ quota model mà từ policy, file exclusions và audit. Hoặc như faceted search trong PostgreSQL: counts và filter giúp bạn thấy hình dạng corpus trước khi bấm tiếp. Với AI skill cũng vậy, dashboard severity/category không phải để làm đẹp; nó giúp lead biết rủi ro đang tụ ở nhóm nào.

Việc nên làm ngay sau khi đọc

Trong một buổi chiều, bạn có thể làm đủ 4 việc:

  1. Chọn 5-10 AI skill đang hoặc sắp lên production.
  2. Gắn nhãn quyền hạn: đọc, ghi, gọi tool, chạy code, xuất dữ liệu.
  3. Scan bằng SkillSpector hoặc một static-analysis workflow tương đương, rồi xuất finding thành bảng.
  4. Đặt merge gate tối thiểu: high/critical thì block, medium thì review, low thì ghi chú.

Nếu team chưa có SkillSpector trong stack, vẫn làm được bước phân loại và policy trước. Tool đến sau cũng được; tư duy gate phải đến trước.

Takeaway của mình: AI skill không nhỏ chỉ vì nó ít dòng; nó nhỏ hay lớn tùy quyền nó cầm trong tay. Đọc công thức trước khi bật bếp vẫn đỡ hơn vừa cháy nồi vừa debug production.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo