AI Agent có thêm một điểm yếu mới: Một “skill” tưởng vô hại có thể làm lộ cả credential

Nghiên cứu được chấp nhận tại ASE 2026 cho thấy 520 trong 17.022 agent skill được phân tích có vấn đề rò credential. Nguy cơ không chỉ đến từ malware: log debug, file cấu hình và sự kết hợp giữa hướng dẫn tự nhiên với code có thể khiến API key, OAuth token hay secret lọt vào context của AI agent hoặc bị gửi ra ngoài.

Tháng 8 27, 2026

AI Agent có thêm một điểm yếu mới: Một “skill” tưởng vô hại có thể làm lộ cả credential

Một “skill” cho AI agent có thể trông vô hại như công cụ lấy dự báo thời tiết, xử lý file hoặc kết nối Google Workspace. Nhưng đằng sau vài dòng mô tả bằng ngôn ngữ tự nhiên có thể là code đang đọc biến môi trường, in token ra console hoặc thậm chí gửi credential tới một endpoint không được khai báo.

Đó là cảnh báo từ một nghiên cứu quy mô lớn về rò rỉ credential trong hệ sinh thái AI agent skill, được một nhóm nhà nghiên cứu từ Wake Forest University, Griffith University, Nanyang Technological University, UNSW, University of Tokyo và các tổ chức khác thực hiện. Phiên bản mới nhất của công trình được công bố trên arXiv tháng 6/2026 và đã được chấp nhận tại hội nghị IEEE/ACM International Conference on Automated Software Engineering (ASE 2026), dự kiến diễn ra tại Munich từ ngày 12 đến 16/10/2026.

Nhóm phân tích 17.022 skill, tương đương khoảng 10% snapshot gồm 170.226 artifact trên SkillsMP tại thời điểm thu thập dữ liệu. Họ tìm thấy 520 skill có vấn đề rò credential, chứa tổng cộng 1.708 vấn đề bảo mật.

Điều đáng chú ý là phần lớn không phải malware được viết với mục đích xấu. Trong 520 skill bị ảnh hưởng, 437 skill — khoảng 84% — bị xếp vào nhóm vulnerable do lỗi hoặc thực hành lập trình không an toàn. 83 skill còn lại được xác nhận là malicious.

Và một trong những con đường rò rỉ phổ biến nhất lại cực kỳ quen thuộc với mọi developer: debug logging.

Agent skill là gì?

AI agent khác chatbot truyền thống ở chỗ nó không chỉ tạo câu trả lời. Một agent có thể lập kế hoạch nhiều bước, đọc file, gọi API, thực thi script, truy cập database hoặc thao tác với dịch vụ bên ngoài để hoàn thành mục tiêu.

“Skill” là một cách đóng gói khả năng đó để tái sử dụng. Một skill có thể dạy agent cách triển khai ứng dụng, truy vấn hệ thống cloud, đọc tài liệu tài chính, lấy dữ liệu web hoặc xử lý một workflow cụ thể.

Trong nhiều hệ sinh thái hiện nay, một skill không chỉ là source code. Nó thường kết hợp hai lớp:

Natural language: file mô tả, workflow hoặc hướng dẫn như SKILL.md, cho model biết phải làm gì và khi nào nên gọi công cụ.
Programming logic: script Python, JavaScript, shell hoặc thành phần thực thi nhiệm vụ thật sự.

Sự kết hợp này rất tiện. Developer có thể mô tả hành vi ở tầng cao bằng tiếng người, còn code xử lý chi tiết ở tầng thấp.

Nhưng chính kiến trúc đó tạo ra một bề mặt tấn công đặc biệt: một skill có thể nói một đằng với người dùng và làm một nẻo trong code.

Một skill “dự báo thời tiết” có thể âm thầm đọc file credential

Nghiên cứu đưa ra một ví dụ thực tế đã được gỡ khỏi marketplace: một skill có tên weather-data-fetcher.

Ở phần mô tả dành cho agent, chức năng của nó rất đơn giản: lấy dự báo thời tiết.

Nhưng phần JavaScript phía sau lại đọc một file môi trường chứa credential của người dùng rồi gửi nội dung tới một webhook do attacker kiểm soát.

Đây là kiểu rủi ro khó phát hiện nếu người dùng chỉ đọc phần mô tả. Ngược lại, một scanner truyền thống chỉ nhìn code cũng có thể thiếu ngữ cảnh để biết việc truy cập credential có thực sự cần thiết cho chức năng mà skill quảng cáo hay không.

Nhóm nghiên cứu gọi đây là vấn đề cross-modal: phải đọc cả ngôn ngữ tự nhiên lẫn logic chương trình mới hiểu được hành vi thực tế.

Trong 520 skill bị ảnh hưởng, 76,3% chỉ bộc lộ đầy đủ vấn đề khi phân tích kết hợp cả hai lớp. Chỉ 20,6% là lỗi có thể nhìn thấy hoàn toàn ở code, trong khi 3,1% xuất phát chỉ từ hướng dẫn natural-language như prompt injection.

Đây là điểm khiến agent skill khác một package npm hoặc Python library thông thường. Một dependency cổ điển chủ yếu được đánh giá qua source code và binary. Skill còn có một “lớp thực thi mềm” là câu chữ mà model đọc và biến thành hành động.

Điểm yếu lớn nhất lại là một câu print để debug

Nếu có một con số nổi bật nhất trong nghiên cứu, đó là 73,5%.

Trong 1.371 vấn đề thuộc nhóm skill vulnerable do lỗi developer, 1.007 trường hợp là dạng information exposure thông qua console log, debug output hoặc response.

Trong phần mềm thông thường, developer có thể nghĩ rằng:

“Tôi chỉ in token ra console để kiểm tra trong lúc debug.”

Đó đã là thực hành không an toàn. Nhưng trong môi trường AI agent, hậu quả có thể nghiêm trọng hơn vì nhiều framework thu stdout và stderr của tool rồi đưa output trở lại context của LLM.

Nói cách khác, một token vốn chỉ “xuất hiện trong terminal” có thể trở thành một đoạn văn bản mà model nhìn thấy, ghi nhớ trong session và có khả năng sử dụng trong các bước tiếp theo.

Nhóm nghiên cứu đưa ra trường hợp một skill Google Workspace in cả OAuth access token và refresh token bằng console logging. Khi agent framework thu output này, credential được đưa vào context. Trong thử nghiệm sandbox, nhóm xác nhận thông tin có thể bị trích xuất thông qua input đối nghịch.

Đây là một thay đổi quan trọng trong threat model: stdout không còn chỉ là stdout. Nó có thể trở thành một phần bộ nhớ làm việc của AI agent.

Tại sao context của LLM lại làm vấn đề trở nên mới?

Trong phần mềm truyền thống, dữ liệu thường đi qua các boundary tương đối rõ: process A gọi process B, API request gửi tới server C, log nằm trong file D.

Agent phá mờ một số boundary này.

Tool output được đưa cho model để model quyết định bước tiếp theo. Nội dung trang web được đưa vào context để agent tóm tắt. Kết quả một script shell có thể được model đọc để xác định lệnh tiếp theo. File cấu hình, metadata và mô tả skill cũng có thể đi vào cùng một luồng suy luận.

Điều này tạo ra một tình huống lạ: data và instruction có thể xuất hiện trong cùng một context.

Một trang web chứa dữ liệu cần phân tích cũng có thể chứa câu lệnh prompt injection. Một log chứa kết quả debug cũng có thể chứa API key. Một skill mô tả chức năng hợp lệ nhưng script phía sau lại truyền thêm dữ liệu ra endpoint khác.

Vì vậy, một credential chỉ cần lọt vào context là phạm vi người hoặc thành phần có thể tác động tới nó đã rộng hơn rất nhiều.

Không chỉ API key: nghiên cứu tìm nhiều loại credential nhạy cảm

Nhóm nghiên cứu xây taxonomy gồm chín nhóm credential để tìm kiếm và kiểm thử.

Các loại được quan sát gồm:

API key và cloud credential như khóa dịch vụ AI hoặc AWS/GCP;
OAuth token và refresh token;
credential database và connection string;
password và passphrase;
SSH/TLS private key;
encryption key;
session và bearer token;
webhook secret;
private key hoặc seed phrase của ví crypto.

Đây không phải những chuỗi vô nghĩa. Nếu còn hiệu lực, một credential bị rò có thể cho phép attacker tiêu thụ quota trả phí, truy cập repository, đọc cloud storage, đăng nhập database, giả mạo service account hoặc tiếp cận tài sản số.

Trong 107 skill có hardcoded credential, API key chiếm tỷ lệ lớn nhất trong các loại secret được nhóm phân loại, tiếp theo là token và password/secret.

89,6% trường hợp được xác nhận là khai thác được trong thực tế thử nghiệm

Để tránh chỉ đếm những pattern đáng ngờ trên source code, nhóm không dừng ở static analysis.

Họ dựng môi trường sandbox bằng container, cấp credential giả có marker riêng qua những kênh giống triển khai thật như environment variable, file cấu hình và runtime argument.

Mỗi skill được chạy trong điều kiện bình thường và điều kiện có nội dung đối nghịch. Nhóm theo dõi network traffic, system call, filesystem, stdout và stderr để xác định credential có thực sự đi ra ngoài boundary dự kiến hay không.

Kết quả: 466 trong 520 skill bị ảnh hưởng, tương đương 89,6%, có credential có thể bị lộ qua ít nhất một kênh runtime.

Khoảng 75,8% các skill bị ảnh hưởng có rò rỉ qua stdout. 18,7% có exposure dựa trên file, còn 13,1% có hành vi gửi credential tới endpoint do attacker kiểm soát qua HTTP, API hoặc command-and-control.

Điểm đáng lo là 92,5% skill bị ảnh hưởng trở nên exploitable trong giai đoạn execute, tức đúng lúc agent đang thực hiện workflow bình thường và credential được đưa vào bộ nhớ, API call hoặc output stream.

84% là lỗi vô ý — và đó có thể là phần đáng sợ hơn malware

Malware dễ hình dung: attacker viết một skill để đánh cắp dữ liệu.

Nhưng nghiên cứu cho thấy số lượng lớn hơn đến từ developer bình thường làm những việc tưởng vô hại.

Bốn nhóm vulnerability chính gồm:

Information Exposure: in credential ra console, debug output hoặc response.
Hardcoded Credentials: đặt trực tiếp API key, password hoặc token trong source code, config hoặc documentation.
Insecure Storage: truyền secret qua command-line argument, process parameter hoặc URL.
Artifact Leakage: để credential lại trong shell history, temporary file, cache hoặc artifact khác.

Trong một ví dụ, một skill xử lý code signing ghi RSA private key ra file tạm dạng plaintext. Một process khác trên cùng hệ thống có thể đọc file này trước khi nó được xóa.

Điểm chung của những lỗi này là chúng không cần attacker viết malware tinh vi. Chúng chỉ cần developer giữ nguyên thói quen coding cũ trong một runtime mới có trust boundary khác.

AI-assisted coding cũng xuất hiện trong nhiều case hardcoded secret

Một phát hiện đáng chú ý khác là khoảng 72% trường hợp hardcoded credential có dấu hiệu liên quan tới quá trình phát triển có AI hỗ trợ, dựa trên commit message nhắc tới những công cụ như Copilot, Claude hoặc ChatGPT.

Con số này không chứng minh AI tự động “gây ra” credential leak. Commit message chỉ là dấu hiệu tương quan, không phải bằng chứng nhân quả.

Nhưng nó đặt ra một vấn đề thực tế: nếu developer yêu cầu AI viết nhanh một integration và code mẫu chứa pattern không an toàn — chẳng hạn nhét key vào biến string, in toàn bộ response để debug hoặc truyền secret qua CLI — pattern đó có thể được sao chép với tốc độ rất cao.

Vibe coding làm tốc độ phát triển tăng mạnh. Security review nếu không tăng theo cùng tốc độ sẽ trở thành bottleneck.

Malicious skill có thể dùng lớp mô tả như “vỏ bọc”

83 skill trong dataset được nhóm xác nhận là malicious.

Những skill này không chỉ làm một việc xấu. 37,3% kết hợp nhiều kỹ thuật tấn công.

Các pattern malicious được phân thành sáu nhóm: remote exploitation, credential compromise, data exfiltration, defense evasion, persistence và resource hijacking.

Một chiến thuật phổ biến là làm code khó nhận biết trước bằng encoding hoặc obfuscation, sau đó tải payload từ xa hoặc mở backdoor.

Nhưng điểm đặc biệt của agent skill nằm ở sự tách biệt giữa phần marketing và phần thực thi.

Người dùng hoặc thậm chí chính model có thể chỉ thấy một mô tả rất hợp lý: “phân tích file”, “kiểm tra quota”, “lấy dữ liệu thị trường” hoặc “hỗ trợ quản trị hệ thống”. Hành vi thật nằm ở script đi kèm.

Trong hệ sinh thái package truyền thống, một README sai lệch cũng có thể che malware. Với agent skill, natural-language instruction còn có vai trò sâu hơn vì nó trực tiếp tham gia vào logic mà model dùng để quyết định khi nào và bằng cách nào chạy code.

Một icon SVG cũng có thể trở thành bề mặt tấn công

Nghiên cứu còn đưa ra một case study cho thấy không chỉ file script mới nguy hiểm.

Một skill malicious chứa JavaScript nhúng trong file logo SVG. Khi tài nguyên này được render trong webview của agent, script có thể truy cập các loại dữ liệu trình duyệt như local storage, session storage và cookie rồi gửi chúng ra ngoài.

Điểm đáng chú ý là file trông như một asset giao diện vô hại. Người review code có thể tập trung vào Python hoặc JavaScript chính mà bỏ qua icon.

Đây là bài học quen thuộc từ supply-chain security nhưng có ý nghĩa lớn với agent ecosystem: mọi artifact mà runtime có thể đọc, render hoặc thực thi đều phải nằm trong threat model.

Agent skill đang biến thành một software supply chain mới

Trong hai thập kỷ qua, ngành phần mềm đã học bài học đắt giá từ npm, PyPI, Maven và nhiều registry khác: dependency của người khác chính là code chạy trong hệ thống của mình.

Agent skill đang lặp lại bài học đó với một twist mới.

Khi cài một package truyền thống, rủi ro chủ yếu nằm ở code. Khi cài một skill, bạn có thể đang cấp cho một bundle cả:

quyền đọc file mà agent có quyền truy cập;
quyền dùng environment variable chứa API key;
quyền gọi network;
quyền thực thi shell hoặc script;
và khả năng chèn instruction trực tiếp vào context của model.

Nghiên cứu gọi tình huống này là dạng ambient authority: skill thừa hưởng quyền của process hoặc agent host thay vì phải xin quyền riêng cho từng credential.

Nếu agent đang chạy trong môi trường developer có AWS credential, GitHub token, database password và nhiều API key, một skill chỉ cần được thực thi đúng context là có thể đứng rất gần những tài sản giá trị đó.

“Skill chỉ là Markdown” là một giả định nguy hiểm

Nhiều developer nhìn file SKILL.md và có cảm giác đây chỉ là documentation.

Nhưng với agent, documentation có thể trở thành instruction.

Nếu model được thiết kế để đọc file và tuân theo workflow trong đó, Markdown đã bước sang một vai trò khác: nó là behavioral configuration.

Điều này không có nghĩa mọi file hướng dẫn đều “code” theo nghĩa CPU thực thi opcode. Nhưng về mặt security, nội dung đó có khả năng thay đổi hành vi của hệ thống và vì thế phải được review như một phần executable surface.

Nghiên cứu phát hiện 16 trong 520 skill bị ảnh hưởng có leakage nằm hoàn toàn ở lớp natural-language, không cần code độc hại.

Đó là tỷ lệ nhỏ, nhưng nó chứng minh scanner chỉ tìm hàm nguy hiểm trong source code sẽ không đủ.

Credential có thể tiếp tục sống sau khi repo gốc đã sửa

Một vấn đề khác của open-source supply chain là fork.

Sau responsible disclosure, nhóm cho biết toàn bộ 83 malicious skill được báo cáo đã bị gỡ khỏi SkillsMP và 91,6% trường hợp hardcoded credential được remediation.

Nhưng xóa secret khỏi repository gốc không xóa secret khỏi lịch sử Internet.

Trong nghiên cứu, credential đã bị loại khỏi 107 upstream repository vẫn còn xuất hiện trong hơn 50 fork độc lập. Một payload command-and-control khác đã lan ra 330 file trong 70 repository dưới 15 tên skill khác nhau.

Đây là lý do security response cho secret leak luôn phải gồm hai việc:

xóa secret khỏi code và revoke/rotate chính credential đó.

Nếu chỉ commit một phiên bản mới không còn API key nhưng key cũ vẫn active, bất kỳ fork, cache hoặc commit history nào còn giữ nó vẫn là nguồn tấn công.

Một skill bị gỡ khỏi marketplace chưa chắc đã biến mất khỏi máy người dùng

Marketplace có thể chặn publisher hoặc gỡ listing. Nhưng skill đã được clone, fork hoặc cài trên workstation có thể tiếp tục tồn tại.

Đây là khác biệt giữa “distribution control” và “runtime control”.

Một hệ sinh thái an toàn hơn cần biết:

skill nào đang được cài trên máy;
phiên bản nào đang chạy;
source có còn khớp với artifact đã được review hay không;
skill đã bị revoke từ registry có cần bị vô hiệu hóa cục bộ hay không;
credential nào đã từng được skill đó truy cập.

Nói cách khác, agent skill cần dần có những cơ chế provenance, signing, inventory và revocation tương tự package management trưởng thành.

Permission prompt đơn thuần có thể chưa đủ

Một phản xạ tự nhiên là yêu cầu agent hỏi người dùng trước khi chạy lệnh nguy hiểm.

Điều đó hữu ích, nhưng không giải quyết toàn bộ vấn đề.

Một skill hợp lệ có thể thực sự cần gọi API. Người dùng sẽ thấy prompt kiểu “cho phép truy cập network?” và bấm đồng ý vì đây đúng là chức năng họ muốn.

Nhưng permission “network access” quá rộng không nói được endpoint nào được phép nhận dữ liệu gì.

Tương tự, skill xử lý cloud deployment có thể cần AWS credential. Câu hỏi security thực tế là:

Nó được phép dùng credential đó cho AWS API đã khai báo, hay được phép đọc rồi gửi credential sang bất kỳ domain nào?

Đây là lý do nhóm nghiên cứu đề xuất hướng capability-based isolation: reasoning engine và execution engine nên có boundary rõ, còn skill chỉ nhận đúng capability cần thiết thay vì quyền môi trường chung.

Framework nên chặn secret trước khi stdout đi vào context

Một biện pháp cụ thể từ nghiên cứu là lọc credential pattern trước khi tool output được đưa trở lại LLM.

Nếu stdout chứa chuỗi giống API key, private key, bearer token hoặc credential khác, framework có thể redact hoặc thay bằng handle an toàn.

Ví dụ, thay vì model nhìn thấy toàn bộ:

Authorization: Bearer eyJ...

nó chỉ cần nhận:

Authorization credential configured successfully

Trong nhiều workflow, model không cần biết giá trị secret để quyết định bước tiếp theo.

Đây là nguyên tắc quan trọng: LLM nên biết credential tồn tại, không nhất thiết biết credential là gì.

Secret manager vẫn chưa đủ nếu agent có thể in secret ra ngoài

Dùng secret manager là bước tốt hơn hardcode key vào repo. Nhưng nó không tự động giải quyết agent security.

Nếu skill đọc secret từ vault rồi ngay sau đó log giá trị ra console, secret vẫn bị lộ.

Nếu tool nhận secret qua environment variable nhưng script có thể gọi bất kỳ domain nào, attacker vẫn có đường exfiltration.

Vì vậy credential isolation cần đi cùng với:

scope tối thiểu;
token ngắn hạn;
network allowlist;
output sanitization;
filesystem sandbox;
audit log;
và review cả natural-language instruction lẫn code.

Secret manager giải quyết nơi lưu secret. Agent security còn phải giải quyết ai được quyền sử dụng secret, dùng cho mục đích gì và secret có thể chảy tới đâu.

Developer cần thay đổi thói quen debug

Một trong những bài học dễ áp dụng nhất là không log toàn bộ object chứa token.

Trong phát triển API integration, developer thường in cả response để xem cấu trúc dữ liệu. Nhưng response xác thực có thể chứa access token, refresh token, session ID và metadata nhạy cảm.

Trong agent runtime, log đó có thể bị đưa vào context.

Thay vì:

console.log(authResponse)

nên log những field không nhạy cảm hoặc trạng thái tổng quát:

console.log("Authentication succeeded")

Ngoài ra, CI nên có secret scanning bắt buộc trước khi publish skill, giống cách repository hiện đại quét API key trước merge.

Người dùng agent có thể tự bảo vệ bằng nguyên tắc least privilege

Không phải mọi người dùng đều có thể audit hàng nghìn dòng code. Nhưng một số nguyên tắc giúp giảm blast radius nếu skill có vấn đề.

Không chạy agent bằng tài khoản có quyền admin nếu không cần.
Dùng API key riêng cho agent thay vì key dùng chung với production.
Giới hạn scope của token ở mức tối thiểu.
Tách credential theo project và environment.
Dùng token ngắn hạn khi dịch vụ hỗ trợ.
Chạy skill chưa tin cậy trong container hoặc sandbox.
Giới hạn outbound network tới những domain thực sự cần thiết.
Không cài skill chỉ dựa trên mô tả hoặc số lượt tải; kiểm tra publisher, source và lịch sử thay đổi.

Mục tiêu không phải giả định mọi skill đều malicious. Mục tiêu là đảm bảo một skill bị lỗi không thể tự động biến thành chìa khóa cho toàn bộ workstation.

Marketplace cần chuyển từ “app store” sang “software supply-chain infrastructure”

Khi agent skill còn là vài file cộng đồng chia sẻ với nhau, review thủ công có thể đủ.

Khi số lượng skill tăng lên hàng trăm nghìn hoặc hàng triệu, mô hình đó không còn scale.

Marketplace cần những lớp kiểm soát tương tự registry phần mềm:

publisher identity và provenance;
ký artifact;
static scanning;
dynamic sandbox execution;
secret detection;
permission manifest;
reputation;
vulnerability disclosure;
revocation;
và phân phối bản vá tới downstream fork.

Nhưng với agent skill, scanner còn phải hiểu semantics của natural language.

Một hàm gửi HTTP request không tự động là malicious. Nếu skill được quảng cáo là gửi báo cáo tới Slack, network call là cần thiết. Nhưng nếu phần mô tả chỉ nói “xem thời tiết” mà code lại đọc .env và gửi sang webhook, mismatch đó mới là tín hiệu mạnh.

Security scanner thế hệ mới vì vậy cần đọc ý định khai báo lẫn hành vi thực thi.

Đây không chỉ là vấn đề của một framework

Nghiên cứu dùng Claude Code làm runtime sandbox vì đây là một môi trường native của Agent Skills trong dataset được khảo sát. Wake Forest University cũng nhắc tới các coding agent phổ biến như Claude Code, Codex và Cursor để minh họa xu hướng skill đang lan rộng.

Nhưng vấn đề kiến trúc không phụ thuộc vào một thương hiệu duy nhất.

Bất kỳ agent nào có thể:

đọc hướng dẫn từ bên thứ ba;
thực thi code hoặc tool;
truy cập credential;
và đưa tool output trở lại context của model

đều phải giải quyết bài toán tương tự.

Càng nhiều autonomy, càng nhiều quyền được cấp cho agent, blast radius của một skill lỗi càng lớn.

Prompt injection chỉ là một phần của bức tranh

Trong những năm đầu của agent security, prompt injection thường chiếm phần lớn thảo luận: một trang web chứa instruction độc hại có thể khiến agent làm điều ngoài ý muốn.

Nghiên cứu này cho thấy credential leak rộng hơn prompt injection.

Chỉ 3,1% skill bị ảnh hưởng nằm hoàn toàn ở natural-language layer. Phần lớn vấn đề xuất hiện khi instruction, code, runtime credential và output stream tương tác với nhau.

Một skill không cần bị “hack” bởi prompt injection mới nguy hiểm. Nó có thể tự rò token trong quá trình hoạt động bình thường chỉ vì developer để một câu debug.

Ngược lại, một codebase tưởng sạch có thể trở thành nguy hiểm nếu natural-language instruction khiến agent truyền credential vào một function không đáng tin.

Threat model mới vì vậy phải bao phủ toàn chuỗi agent → skill → tool → credential → output → model.

Rủi ro thật sự là agent đang đứng ngay cạnh chìa khóa

Phần mềm truyền thống cũng có secret leak. Developer đã hardcode API key từ rất lâu trước khi LLM xuất hiện.

Cái mới không phải sự tồn tại của credential leak.

Cái mới là agent gom nhiều thành phần trước đây tách rời vào cùng một execution loop.

Nó có thể đọc code, truy cập repository, chạy shell, gọi cloud API, đọc email, tương tác database và nhìn kết quả của tất cả những công cụ đó trong cùng một phiên làm việc.

Điều này khiến agent trở thành một “điểm tập trung quyền lực” rất hữu ích — và vì thế cũng là một target hấp dẫn.

Một skill nhỏ có thể không cần exploit kernel hay bypass sandbox nếu agent vốn đã được trao credential và network access cần thiết để hoàn thành công việc.

Kẻ tấn công chỉ cần tìm cách lái luồng dữ liệu đúng lúc.

520 skill không có nghĩa 3,1% mọi skill trên Internet đều nguy hiểm

Cũng cần đọc con số của nghiên cứu đúng cách.

Nhóm lấy mẫu 17.022 skill từ snapshot SkillsMP và tìm thấy 520 trường hợp bị ảnh hưởng, tương đương khoảng 3,1% mẫu.

Con số này không nên được áp dụng cơ học cho mọi marketplace, mọi framework hay mọi skill hiện tồn tại. Dataset có phạm vi, thời điểm và hệ sinh thái cụ thể.

Ngoài ra, sau responsible disclosure, nhiều vấn đề đã được khắc phục và toàn bộ malicious skill được nhóm báo cáo đã bị gỡ khỏi nền tảng.

Giá trị lớn nhất của nghiên cứu không phải để nói “cứ 32 skill thì có một skill đánh cắp key”. Nó là bằng chứng rằng credential leakage trong agent skill là một lớp rủi ro có thể đo được, xảy ra cả vô ý lẫn cố ý và có những cơ chế khác phần mềm truyền thống.

AI agent cần một mô hình quyền giống smartphone hơn là shell mở

Smartphone hiện đại không cho mọi ứng dụng tự do đọc toàn bộ dữ liệu của ứng dụng khác. Camera, microphone, location và photo library đều có permission boundary.

AI agent trên desktop hiện vẫn thường hoạt động trong môi trường gần với developer shell: nếu process có quyền đọc file, tool hoặc skill bên trong có thể thừa hưởng phần lớn quyền đó.

Một hướng phát triển tự nhiên là agent runtime phải tiến tới permission model chi tiết hơn.

Skill cần database có thể được cấp một credential proxy chỉ cho database đó. Skill cần GitHub có thể chỉ nhận token read-only cho một repository. Tool cần network có thể chỉ gọi allowlist domain. Secret có thể được inject ở transport layer mà không bao giờ trở thành plaintext trong context của LLM.

Đây là nguyên tắc capability security: không cấp “quyền làm mọi thứ rồi hy vọng skill cư xử tốt”, mà cấp đúng một khả năng đủ để hoàn thành nhiệm vụ.

“Skill” đang trở thành một executable format mới

Phần thú vị nhất của câu chuyện có thể không nằm ở một API key bị lộ.

Nó nằm ở việc ngành phần mềm đang tạo ra một dạng artifact mới: một gói vừa chứa code, vừa chứa câu chữ có khả năng điều khiển model.

Trong software supply chain cổ điển, executable và documentation là hai thế giới tương đối tách biệt.

Với AI agent, ranh giới đó mờ đi. Markdown có thể thay đổi hành vi. Console output có thể trở thành memory. Trang web có thể trở thành instruction. Một file icon có thể trở thành active content nếu được render sai cách.

Security tool được xây cho source code đơn thuần vì thế chỉ nhìn thấy một nửa hệ thống.

Bài học từ nghiên cứu: đừng chỉ hỏi “skill này làm gì?”

Khi cài một skill cho agent, câu hỏi quen thuộc là:

“Nó giúp tôi làm được gì?”

Nghiên cứu mới cho thấy cần thêm ít nhất ba câu hỏi:

“Nó được quyền nhìn thấy gì?”

“Nó được quyền gửi dữ liệu đi đâu?”

“Output nào của nó sẽ được đưa trở lại context của model?”

Một skill tạo slide, lấy thời tiết hay kiểm tra tài liệu không tự nhiên cần quyền đọc mọi secret trong home directory. Nếu runtime không tạo boundary, sự tiện lợi của agent có thể âm thầm biến thành ambient authority.

AI agent đang tiến rất nhanh từ công cụ trả lời sang hệ thống có khả năng hành động. Khi đó, những file nhỏ mở rộng khả năng của agent không còn nên được xem như “plugin nhẹ” hoặc “vài dòng hướng dẫn”.

Chúng là một phần của software supply chain — nhưng là supply chain đặc biệt, nơi code và ngôn ngữ tự nhiên cùng có thể trở thành bề mặt thực thi.

Và như nghiên cứu ASE 2026 cho thấy, đôi khi chỉ một skill trông vô hại và một dòng debug chưa được xóa cũng đủ để credential bước qua ranh giới mà developer tưởng vẫn còn an toàn.