Kecerdasan buatan mendorong perubahan besar dalam produktivitas perusahaan, dari penyelesaian kode GitHub Copilot ke chatbots yang menambang basis pengetahuan internal untuk jawaban instan. Setiap agen baru harus mengautentikasi untuk layanan lain, diam -diam bengkak populasi identitas non -manusia (NHI) di seluruh awan perusahaan.
Populasi itu sudah membanjiri perusahaan: setidaknya banyak perusahaan juggle 45 identitas mesin untuk setiap pengguna manusia. Akun layanan, bot CI/CD, wadah, dan agen AI semuanya membutuhkan rahasia, paling umum dalam bentuk kunci API, token, atau sertifikat, untuk terhubung dengan aman ke sistem lain untuk melakukan pekerjaan mereka. Laporan Secrets Secrets Splets 2025 Gitguardian mengungkapkan biaya sprawl ini: over 23,7 juta rahasia muncul di github publik pada tahun 2024 saja. Dan alih -alih membuat situasi lebih baik, repositori dengan kopilot memungkinkan kebocoran rahasia 40 persen lebih sering.
Nhis bukan manusia
Tidak seperti manusia masuk ke dalam sistem, NHI jarang memiliki kebijakan untuk mengamanatkan rotasi kredensial, izin lingkup yang erat, atau dekomisi akun yang tidak digunakan. Dibiarkan tidak dikelola, mereka menenun jaring yang padat dan buram dari koneksi berisiko tinggi yang dapat dieksploitasi oleh penyerang lama setelah siapa pun ingat rahasia itu ada.
Adopsi AI, terutama model bahasa besar dan generasi pengambilan-pengambilan (RAG), telah secara dramatis meningkatkan kecepatan dan volume di mana gulungan yang mendorong risiko ini dapat terjadi.
Pertimbangkan chatbot dukungan internal yang ditenagai oleh LLM. Ketika ditanya cara terhubung ke lingkungan pengembangan, bot dapat mengambil halaman Confluence yang berisi kredensial yang valid. Chatbot tanpa disadari dapat mengekspos rahasia kepada siapa saja yang mengajukan pertanyaan yang tepat, dan log dapat dengan mudah membocorkan info ini kepada siapa pun yang memiliki akses. Lebih buruk lagi, dalam skenario ini, LLM memberi tahu pengembang Anda untuk menggunakan kredensial plaintext ini. Masalah keamanan dapat menumpuk dengan cepat.
Situasinya tidak putus asa. Faktanya, jika model tata kelola yang tepat diimplementasikan di sekitar NHIS dan Manajemen Rahasia, maka pengembang benar -benar dapat berinovasi dan menyebarkan lebih cepat.
Lima kontrol yang dapat ditindaklanjuti untuk mengurangi risiko NHI terkait AI
Organisasi yang ingin mengendalikan risiko NHI yang digerakkan oleh AI harus fokus pada lima praktik yang dapat ditindaklanjuti ini:
- Audit dan Bersihkan Sumber Data
- Memusatkan manajemen NHIS Anda yang ada
- Cegah Rahasia Kebocoran di Penempatan LLM
- Tingkatkan keamanan penebangan
- Batasi akses data AI
Mari kita lihat lebih dekat masing -masing area ini.
Audit dan Bersihkan Sumber Data
LLM pertama hanya terikat pada set data spesifik yang dilatih, menjadikannya hal baru dengan kemampuan terbatas. Rekayasa Retrieval-Augmented Generation (RAG) mengubah ini dengan memungkinkan LLM untuk mengakses sumber data tambahan sesuai kebutuhan. Sayangnya, jika ada rahasia yang ada dalam sumber -sumber ini, identitas terkait sekarang berisiko disalahgunakan.
Sumber data, termasuk platform manajemen proyek JIRA, platform komunikasi seperti Slack, dan KnowledgeBase seperti Confluence, tidak dibangun dengan AI atau rahasia dalam pikiran. Jika seseorang menambahkan kunci API Plaintext, tidak ada perlindungan untuk mengingatkan mereka bahwa ini berbahaya. Chatbot dapat dengan mudah menjadi mesin bocor rahasia dengan dorongan yang tepat.
Satu -satunya cara yang pasti untuk mencegah LLM Anda membocorkan rahasia internal itu adalah dengan menghilangkan rahasia yang ada atau setidaknya mencabut akses apa pun yang mereka bawa. Kredensial yang tidak valid tidak membawa risiko langsung dari penyerang. Idealnya, Anda dapat menghapus contoh rahasia apa pun ini sebelum AI Anda dapat mengambilnya. Untungnya, ada alat dan platform, seperti GitGuardian, yang dapat membuat proses ini tidak menyakitkan mungkin.
Memusatkan manajemen NHIS Anda yang ada
Kutipan “Jika Anda tidak dapat mengukurnya, Anda tidak dapat memperbaikinya” paling sering dikaitkan dengan Lord Kelvin. Ini sangat berlaku untuk tata kelola identitas non-manusia. Tanpa mengambil stok dari semua akun layanan, bot, agen, dan pipa yang Anda miliki saat ini, ada sedikit harapan bahwa Anda dapat menerapkan aturan dan ruang lingkup yang efektif di sekitar NHIS baru yang terkait dengan AI agen Anda.
Satu hal yang sama-sama dimiliki oleh semua jenis identitas non-manusia adalah bahwa mereka semua memiliki rahasia. Tidak peduli bagaimana Anda mendefinisikan NHI, kita semua mendefinisikan mekanisme otentikasi dengan cara yang sama: Rahasia. Ketika kami memfokuskan inventaris kami melalui lensa ini, kami dapat meruntuhkan fokus kami pada penyimpanan dan pengelolaan rahasia yang tepat, yang jauh dari kekhawatiran baru.
Ada banyak alat yang dapat membuat ini dapat dicapai, seperti Hashicorp Vault, Cyberark, atau AWS Secrets Manager. Begitu mereka semua dikelola dan diperhitungkan secara terpusat, maka kita dapat beralih dari dunia kredensial berumur panjang ke arah yang di mana rotasi otomatis dan ditegakkan oleh kebijakan.
Cegah Rahasia Kebocoran di Penempatan LLM
Server Model Context Protocol (MCP) adalah standar baru untuk bagaimana AI agen mengakses layanan dan sumber data. Sebelumnya, jika Anda ingin mengkonfigurasi sistem AI untuk mengakses sumber daya, Anda perlu menyatukannya sendiri, mencari tahu saat Anda pergi. MCP memperkenalkan protokol bahwa AI dapat terhubung ke penyedia layanan dengan antarmuka standar. Ini menyederhanakan hal -hal dan mengurangi peluang bahwa pengembang akan menggunakan kode kredensial agar integrasi berfungsi.
Dalam salah satu makalah yang lebih mengkhawatirkan yang telah dirilis oleh para peneliti keamanan Gitguardian, mereka menemukan bahwa 5,2% dari semua server MCP yang dapat mereka temukan mengandung setidaknya satu rahasia hardcoded. Ini terutama lebih tinggi dari tingkat kejadian 4,6% dari rahasia yang terpapar yang diamati di semua repositori publik.
Sama seperti teknologi lain yang Anda gunakan, satu ons perlindungan di awal siklus pengembangan perangkat lunak dapat mencegah satu pon insiden di kemudian hari. Menangkap rahasia hardcoded ketika masih ada di cabang fitur berarti tidak akan pernah bisa digabungkan dan dikirim ke produksi. Menambahkan Deteksi Rahasia ke Alur Kerja Pengembang melalui Git Hooks atau Ekstensi Editor Kode dapat berarti kredensial plaintext bahkan tidak pernah berhasil ke repo bersama.
Tingkatkan keamanan penebangan
LLMS adalah kotak hitam yang menerima permintaan dan memberikan jawaban probabilistik. Meskipun kami tidak dapat menyetel vektorisasi yang mendasarinya, kami dapat memberi tahu mereka jika output seperti yang diharapkan. Insinyur AI dan tim pembelajaran mesin mencatat semuanya dari prompt awal, konteks yang diambil, dan respons yang dihasilkan untuk menyetel sistem untuk meningkatkan agen AI mereka.
Jika sebuah rahasia diekspos pada salah satu dari langkah-langkah yang dicatat dalam proses tersebut, sekarang Anda memiliki banyak salinan dari rahasia bocor yang sama, kemungkinan besar dalam alat atau platform pihak ketiga. Sebagian besar tim menyimpan log di ember cloud tanpa kontrol keamanan yang merdu.
Jalur teraman adalah menambahkan langkah sanitasi sebelum log disimpan atau dikirim ke pihak ketiga. Ini memang membutuhkan upaya rekayasa untuk mengatur, tetapi sekali lagi, alat -alat seperti GGShield GitGuardian ada di sini untuk membantu pemindaian rahasia yang dapat dipanggil secara terprogram dari skrip apa pun. Jika rahasianya digosok, risikonya sangat berkurang.
Batasi akses data AI
Haruskah LLM Anda memiliki akses ke CRM Anda? Ini adalah pertanyaan yang rumit dan sangat situasional. Jika itu adalah alat penjualan internal yang terkunci di belakang SSO yang dapat dengan cepat mencari catatan untuk meningkatkan pengiriman, mungkin baik -baik saja. Untuk chatbot layanan pelanggan di halaman depan situs web Anda, jawabannya adalah perusahaan no.
Sama seperti kita perlu mengikuti prinsip hak istimewa terkecil ketika menetapkan izin, kita harus menerapkan prinsip serupa dari akses terkecil untuk AI apa pun yang kita gunakan. Godaan untuk hanya memberikan agen AI akses penuh ke segala sesuatu atas nama mempercepat hal -hal yang sangat hebat, karena kami tidak ingin kotak dalam kemampuan kami untuk berinovasi terlalu dini. Menghasilkan terlalu sedikit kekalahan akses dari tujuan model kain. Menghasilkan terlalu banyak akses mengundang penyalahgunaan dan insiden keamanan.
Meningkatkan kesadaran pengembang
Meskipun tidak ada dalam daftar kami mulai, semua panduan ini tidak berguna kecuali Anda mendapatkannya ke orang yang tepat. Orang -orang di garis depan membutuhkan bimbingan dan pagar untuk membantu mereka bekerja lebih efisien dan aman. Meskipun kami berharap ada solusi teknologi ajaib untuk ditawarkan di sini, kenyataannya adalah membangun dan menggunakan AI dengan aman pada skala masih membutuhkan manusia pada halaman yang sama dengan proses dan kebijakan yang tepat.
Jika Anda berada di sisi pengembangan dunia, kami mendorong Anda untuk berbagi artikel ini dengan tim keamanan Anda dan mengambil pendapat mereka tentang cara membangun AI dengan aman di organisasi Anda. Jika Anda seorang profesional keamanan yang membaca ini, kami mengundang Anda untuk membagikan ini dengan pengembang dan tim DevOps Anda untuk memajukan percakapan bahwa AI ada di sini, dan kami harus aman saat kami membangunnya dan membangunnya.
Mengamankan identitas mesin sama dengan penyebaran AI yang lebih aman
Fase selanjutnya dari adopsi AI akan menjadi milik organisasi yang memperlakukan identitas non-manusia dengan kekakuan dan perawatan yang sama seperti yang mereka lakukan pengguna manusia. Pemantauan berkelanjutan, manajemen siklus hidup, dan tata kelola rahasia yang kuat harus menjadi prosedur operasi standar. Dengan membangun fondasi yang aman sekarang, perusahaan dapat dengan percaya diri mengukur inisiatif AI mereka dan membuka janji penuh otomatisasi cerdas, tanpa mengorbankan keamanan.
