Jangan asal copy skill AI agent dari GitHub cuma karena repo-nya rame. Kalau skill itu bisa nyuruh agent baca file, jalanin command, atau ubah workflow deploy, berarti skill itu bukan sekadar teks. Itu sudah mirip script kecil yang lu kasih akses ke kerja harian lu.

Artikel ini ngebahas kenapa AI agent skills mulai perlu dilihat sebagai attack surface baru buat developer dan tim kecil. Intinya sederhana: skill bikin AI coding agent lebih konsisten, tapi skill yang salah, basi, atau berbahaya bisa bikin agent ngambil aksi yang nggak lu maksud. Jadi sebelum install skill, rules, prompt pack, atau template agent dari internet, lu perlu punya checklist review yang jelas.

Apa itu AI agent skills?

AI agent skills adalah instruksi reusable yang ngajarin agent cara ngerjain tipe tugas tertentu. Bentuknya bisa file Markdown, folder rules, command template, checklist workflow, atau paket kecil yang dipakai agent seperti Claude Code, Codex CLI, Gemini CLI, Cursor, dan tool sejenis.

Bedanya dengan prompt biasa, skill biasanya disimpan dan dipakai berulang. Di workflow yang serius, skill bisa berisi trigger, langkah kerja, perintah terminal, aturan keamanan, cara verifikasi, sampai pola commit. Buat builder, ini enak banget karena agent nggak perlu diajarin dari nol tiap sesi.

Tapi di situ juga letak risikonya. Prompt sekali pakai mungkin cuma salah jawab. Skill yang dipasang permanen bisa bikin kesalahan yang sama keulang di banyak task.

Kenapa topik ini rame sekarang?

NVIDIA baru merilis SkillSpector, sebuah security scanner untuk AI agent skills. Deskripsi repo-nya cukup jelas: tool ini dibuat buat mendeteksi vulnerability, pola malicious, dan risiko keamanan sebelum skill dipasang.

Dari README SkillSpector, NVIDIA menyebut agent skills berjalan dengan implicit trust dan minim vetting. Mereka juga menulis bahwa riset mereka menemukan 26,1% skill mengandung vulnerability dan 5,2% menunjukkan indikasi intent berbahaya. Angka ini perlu dibaca hati-hati karena konteks dataset dan metodologinya tetap harus dicek, tapi sinyalnya jelas: ekosistem skill agent sudah cukup besar sampai butuh scanner khusus.

Ini nyambung dengan arah industri yang lebih luas. OWASP Top 10 for Large Language Model Applications sudah lama mengingatkan soal risiko LLM seperti prompt injection, data leakage, insecure plugin/tool design, dan excessive agency. Anthropic juga punya dokumentasi keamanan Claude Code yang menekankan permission, review, dan batas akses. Jadi isu ini bukan cuma “repo viral”, tapi bagian dari masalah nyata saat agent mulai dikasih alat dan akses ke sistem kerja.

Skill yang terlihat harmless bisa tetap berbahaya

Masalah skill bukan selalu malware terang-terangan. Kadang yang berbahaya justru instruksi kecil yang terlihat produktif.

  • Command terlalu luas: skill menyarankan command destructive tanpa konfirmasi, misalnya hapus folder, reset database, atau overwrite config.
  • Scope melebar: skill mendorong agent bikin abstraction besar padahal task cuma fix kecil.
  • Secret handling buruk: skill nyuruh agent print env, copy token, atau paste credential ke log.
  • Network call gelap: skill mengarahkan agent fetch script dari URL random lalu execute.
  • Permission creep: skill awalnya buat linting, tapi lama-lama minta akses deploy, GitHub token, atau production API.

Kalau ini terjadi di chat biasa, lu mungkin masih bisa sadar karena instruksinya kelihatan saat itu juga. Tapi kalau instruksi tersebut masuk skill yang dipanggil otomatis, risikonya lebih licin: agent bisa merasa itu prosedur resmi.

Cara gua melihatnya sebagai builder

Gua suka konsep skill karena di Hermes workflow, skill bikin agent lebih disiplin. Misalnya ada skill buat TDD, debugging sistematis, code review, atau draft Ghost. Itu ngebantu banget karena prosedur penting nggak cuma hidup di kepala.

Tapi justru karena skill efektif, skill harus diperlakukan seperti bagian dari supply chain. Kalau lu install package npm, minimal lu cek nama package, maintainer, versi, dependency, dan issue besar. Skill agent juga perlu perlakuan yang mirip, apalagi kalau isinya bisa memicu command, akses file, atau tindakan admin.

Opini gua: skill agent yang bagus bukan skill yang paling panjang. Skill yang bagus adalah skill yang batasnya jelas. Ia harus tahu kapan jalan, apa yang boleh dilakukan, apa yang harus ditolak, dan gimana hasilnya diverifikasi.

Checklist sebelum install skill AI agent dari GitHub

Kalau lu mau pakai skill, rules, atau prompt pack dari repo publik, minimal cek ini dulu:

  1. Baca isi file utama. Jangan cuma lihat stars. Cari command terminal, URL eksternal, instruksi permission, dan bagian yang meminta bypass approval.
  2. Cek scope skill. Skill buat review kode nggak perlu akses deploy. Skill buat nulis artikel nggak perlu baca secret env.
  3. Cari instruksi yang mencoba mengalahkan user. Misalnya “ignore previous instructions”, “never tell the user”, atau “run this silently”.
  4. Periksa command destructive. Tandai command seperti rm -rf, reset database, force push, curl pipe shell, dan modifikasi credential.
  5. Cek asal repo dan update history. Repo dari organisasi besar bukan jaminan aman, tapi repo anonim yang baru dibuat juga perlu ekstra skeptis.
  6. Jalankan di sandbox dulu. Jangan langsung pakai di repo kerja utama, apalagi repo yang punya token production.
  7. Bikin proses review internal. Kalau skill dipakai tim, treat seperti code review: ada diff, reviewer, changelog, dan rollback.

Bedain skill produktivitas dan skill berisiko tinggi

Nggak semua skill punya risiko yang sama. Skill buat gaya penulisan caption jelas beda dengan skill buat deploy aplikasi.

Jenis skill Risiko utama Review minimum
Writing / content Brand voice salah, klaim ngarang Cek tone, fakta, dan sumber
Code generation Over-engineering, bug, dependency aneh Wajib test, lint, dan review diff
Debugging / ops Command destructive, data hilang Approval manual untuk aksi berisiko
Deploy / infrastructure Secret leak, downtime, salah environment Sandbox, dry-run, rollback plan

Prinsip praktis: trust, but verify, but also limit

Kalimat “trust but verify” masih kurang kalau agent punya akses command. Buat AI agent, menurut gua perlu ditambah satu kata: limit.

Lu bisa percaya tool tertentu, tapi tetap batasi ruang geraknya. Lu bisa pakai skill dari repo publik, tapi tetap review isinya. Lu bisa kasih agent tugas panjang, tapi tetap minta artifact yang bisa dicek: diff, test output, log, screenshot, atau link draft.

Di workflow kecil, aturan sederhananya bisa begini:

  • Skill baru masuk folder review dulu, belum langsung aktif.
  • Skill yang menjalankan command harus punya bagian “pitfalls” dan “verification”.
  • Skill deploy atau infra wajib punya langkah rollback.
  • Skill yang menyentuh secret harus ditolak kecuali ada alasan kuat dan approval manual.
  • Skill lama harus dihapus atau diperbarui kalau prosedurnya sudah basi.

Takeaway buat developer

AI agent skills bisa bikin workflow developer jauh lebih rapi. Tapi begitu skill mulai dipakai buat mengarahkan agent, skill itu berubah dari “catatan bantuan” menjadi bagian dari sistem operasional.

Jadi jangan cuma tanya, “skill ini bikin agent lebih pintar nggak?” Tanya juga:

  • Skill ini bisa nyuruh agent melakukan apa?
  • Apa efek terburuk kalau instruksinya salah?
  • Apakah ada command, URL, atau permission yang mencurigakan?
  • Apakah output-nya bisa diverifikasi?
  • Apakah skill ini masih relevan bulan depan?

Kalau jawaban pertanyaan itu nggak jelas, jangan buru-buru install. Produktivitas dari AI agent memang menarik, tapi workflow yang aman tetap dimulai dari batas yang jelas.

FAQ singkat

Apakah semua AI agent skills berbahaya?

Nggak. Banyak skill justru membantu agent lebih aman karena prosedurnya eksplisit. Yang berbahaya adalah skill yang dipakai tanpa dibaca, tanpa scope, dan tanpa verifikasi.

Apakah stars GitHub cukup buat menilai skill aman?

Nggak cukup. Stars cuma sinyal popularitas. Tetap baca isi skill, cek command, cek permission, dan uji di sandbox.

Apakah scanner seperti SkillSpector menggantikan review manual?

Belum. Scanner bisa membantu nemuin pola risiko, tapi review manusia tetap penting karena konteks repo, workflow, dan akses tiap tim beda.

Referensi / Bacaan Lanjut