Panduan Keamanan Claude Code: Permissions, MCP, Sandboxing

Chatbot tradisional dikonfigurasikan di balik API, sehingga risiko terburuknya adalah halusinasi. Namun agen pengodean AI ditempatkan di dalam repo, terminal, dan (sering kali) kredensial cloud Anda, yang membuatnya jauh lebih dekat dengan lingkungan pengembangan berprivileg daripada apa pun yang dulu kita sebut chatbot.

Pertanyaannya adalah bagaimana menggunakan Claude Code dengan aman tanpa memperlambat pekerjaan Anda. Permissions, kontrol MCP, dan sandboxing dengan penyesuaian yang tepat akan membawa Anda ke sana.

Dalam artikel ini, saya akan memandu Anda memahami bagaimana model keamanan Claude Code benar-benar bekerja, bagian mana yang perlu diperhatikan, dan praktik yang menjaganya tetap berguna tanpa memberinya akses lebih dari yang Anda maksudkan.

Jika Anda benar-benar baru dengan Claude dan Claude Code, daftarlah di kursus gratis Claude Code 101 untuk mempelajari dasar-dasarnya dalam satu sore.

Memahami Model Keamanan Claude Code

Sebelum menyetel satu aturan pun, Anda perlu model mental tentang apa yang sebenarnya dikendalikan Claude Code.

Ada lima komponen yang bergerak: sistem permissions yang menentukan apa yang diizinkan, kontrol akses alat yang membatasi kemampuan per alat, permissions MCP untuk integrasi eksternal, sandboxing untuk isolasi tingkat OS, dan auditabilitas untuk tinjauan pascakejadian. Masing-masing memecahkan masalah berbeda, tetapi saling melengkapi.

Sistem permissions

Sistem permissions adalah lapisan statis.

Anda mendeklarasikan apa yang boleh dilakukan Claude di settings.json, menggunakan tiga daftar: allow, ask, dan deny. Aturan dievaluasi dengan urutan deny terlebih dahulu, lalu ask, kemudian allow, dan kecocokan pertama yang menang. Aturan deny memblokir pemanggilan meski ada aturan allow yang lebih luas yang seharusnya mencocokkannya.

Jika tidak ada aturan yang cocok, Claude kembali ke defaultMode sesi (lebih lanjut tentang mode di bagian berikutnya).

Kontrol akses alat

Permissions melekat pada alat, bukan pada agen secara keseluruhan.

Claude Code memiliki serangkaian alat bawaan, misalnya Bash untuk perintah shell, Read dan Edit serta Write untuk operasi filesystem, WebFetch untuk permintaan HTTPS, WebSearch untuk kueri, dan beberapa lainnya. Setiap aturan menyebutkan alat dan (opsional) penentu dalam tanda kurung, seperti Bash(git commit:*) atau Read(./.env).

Inilah yang membuat prinsip least-privilege berjalan. Anda bisa mengizinkan Bash(npm run:*) untuk pengujian tanpa memberi Claude akses shell penuh.

Permissions MCP

Server MCP memperluas Claude Code dengan alat yang awalnya tidak dirancang untuknya.

Setiap server membawa serangkaian alatnya sendiri (server GitHub menambahkan alat pull request, server basis data menambahkan alat kueri, dan seterusnya). Sistem permission mencakupnya juga, tetapi dengan sintaks berbeda — aturan menggunakan bentuk mcp__servername__toolname alih-alih penentu bertanda kurung.

Poin yang perlu diingat adalah MCP kira-kira menggandakan pertanyaan karena Anda tidak hanya memutuskan apa yang bisa dilakukan Claude dengan shell Anda, melainkan juga apa yang bisa dilakukannya dengan setiap sistem eksternal yang Anda hubungkan.

Sandboxing

Sandboxing adalah pengaman tingkat OS di bawah alat Bash.

Aturan permission memberi tahu Claude apa yang seharusnya dilakukan. Sandboxing menegakkan apa yang bisa dilakukan, dengan membatasi akses filesystem dan panggilan jaringan keluar di tingkat sistem operasi. Di macOS, ini berfungsi langsung melalui Seatbelt. Di Linux dan WSL2, Anda perlu memasang bubblewrap dan socat terlebih dahulu.

Kedua lapisan bekerja serupa tetapi mencakup skenario yang berbeda. Permissions menghentikan Claude mencoba sesuatu, dan sandboxing menghentikan upaya itu berhasil jika prompt injection membujuk Claude untuk mencobanya.

Auditabilitas

Bagian terakhir adalah kemampuan melihat apa yang terjadi.

Perintah /permissions mencantumkan setiap aturan aktif dan file pengaturan asalnya, sehingga Anda bisa menjawab "mengapa Claude menjalankan itu?" Hooks (PreToolUse, PostToolUse, dan lainnya) memungkinkan Anda mencatat setiap pemanggilan alat ke sistem Anda sendiri. Untuk tim, eksportir OpenTelemetry mengirim data penggunaan dan pemanggilan alat ke tumpukan observabilitas apa pun yang sudah Anda jalankan.

Permissions dan Kontrol Akses Claude Code

Sebagian besar keamanan berasal dari pengaturan permission, jadi inilah area yang paling sering akan Anda sesuaikan.

Akses file

Secara default, Claude dapat membaca dan mengedit file di direktori tempat Anda meluncurkannya.

Pembacaan dikendalikan oleh alat Read, dan pengeditan oleh Edit dan Write. Masing-masing menerima pola path dalam tanda kurung, menggunakan sintaks gaya gitignore, misalnya Read(**/.env) cocok dengan setiap file .env pada kedalaman apa pun, dan Edit(src/**) cocok dengan semua yang ada di bawah src/.

Deny pada Read mencakup alat file milik Claude Code sendiri (Read, Grep, Glob, LS), tetapi itu hanyalah upaya terbaik. Skrip Python atau Node yang dijalankan melalui Bash masih bisa membuka file, karena pembacaan terjadi lewat shell alih-alih melalui alat Read milik Claude. Jika sebuah rahasia penting, gabungkan deny Read dengan deny Bash pada cat, head, dan tail untuk path tersebut.

Untuk memperluas akses di luar direktori kerja, gunakan additionalDirectories di settings.json. Ini adalah cara memberi Claude akses ke library bersama di luar repo Anda atau file konfigurasi di direktori home, tanpa sepenuhnya menghapus batas direktori kerja.

Eksekusi perintah

Alat Bash adalah yang harus Anda batasi dengan paling hati-hati.

Aturan Bash tanpa batas mengizinkan setiap perintah. Aturan terbatas seperti Bash(npm run:*) hanya mengizinkan pemanggilan yang cocok. Pola colon-star adalah yang perlu Anda gunakan di sini, dan Claude Code memahami operator shell, sehingga aturan seperti Bash(safe-cmd:*) tidak akan cocok dengan safe-cmd && rm -rf /.

Beberapa perintah berjalan tanpa prompt di setiap mode, karena secara default dianggap hanya-baca. Daftar ini mencakup ls, cat, echo, pwd, head, tail, grep, find, wc, which, diff, stat, du, cd, dan bentuk git hanya-baca. Anda tidak dapat memperkecil daftar ini secara manual, tetapi Anda bisa menambahkan aturan ask atau deny untuk salah satunya guna menimpa default.

Untuk apa pun yang tidak disetujui sebelumnya, Claude akan memunculkan prompt dalam mode default. Prompt menampilkan perintah persisnya dan memungkinkan Anda menyetujuinya sekali, menyetujui semua pemanggilan berikutnya yang cocok dengan pola, atau menolak.

Mode permission

Aturan permission bersifat statis, tetapi mode permission mengubah bagaimana panggilan yang tidak cocok diperlakukan.

Ada lima:

• default: memunculkan prompt pada penggunaan pertama setiap alat.

• acceptEdits: otomatis menyetujui pengeditan file di direktori kerja, dan tetap mengendalikan perintah shell. Berguna saat Anda memercayai pengeditan tetapi tidak shell.

• plan: Claude membaca dan menganalisis, tetapi tidak bisa mengedit file atau menjalankan perintah. Mode yang tepat untuk code review atau sesi perencanaan.

• dontAsk: otomatis menolak apa pun yang tidak secara eksplisit ada dalam daftar allow.

• bypassPermissions: melewati setiap prompt. Hanya aman di lingkungan yang sepenuhnya terisolasi seperti container atau VM.

Anda dapat mengganti tiga mode utama dengan Shift+Tab di tengah sesi, atau memilih salah satunya sebagai default di settings.json:

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "deny": ["Read(**/.env)", "Read(**/.env.*)"]
  }
}

Untuk tim, managed settings memberi Anda lapisan yang tidak bisa ditimpa pengguna. File mengikuti format JSON yang sama dan berada di path sistem:

• /Library/Application Support/ClaudeCode/managed-settings.json di macOS

• /etc/claude-code/managed-settings.json di Linux

• C:\ProgramData\ClaudeCode\managed-settings.json di Windows

Aturan deny di managed settings berlaku di setiap proyek pada mesin tersebut, yang memungkinkan Anda menegakkan aturan seperti "tidak ada yang membaca file .env" atau "tidak ada yang menjalankan bypassPermissions" di seluruh organisasi.

Prinsip di balik semua ini adalah least-privilege, sama seperti yang Anda terapkan pada akun layanan mana pun. 

Anda harus mulai dengan set permission sekecil mungkin yang memungkinkan pekerjaan berjalan, dan melebarkannya hanya saat menemui hambatan. Panduan Anthropic sendiri mengarah ke sana — tinjau perubahan yang dibuat Claude, audit aturan Anda dengan /permissions, dan simpan pengaturan spesifik proyek dalam version control agar tim menyepakati apa yang bisa dikerjakan Claude.

Sandboxing Claude Code

Semakin banyak Anda mengizinkan Claude berjalan secara otonom, semakin masuk akal sandboxing.

Alat Bash memiliki paparan paling luas karena perintah shell dapat membaca file apa pun yang bisa Anda baca dan memodifikasi apa pun yang memiliki izin tulis. Sandboxing memaksa batas tingkat OS pada setiap perintah Bash dan turunannya, sehingga Claude dapat berjalan lebih bebas di dalam batas tersebut tanpa Anda menyetujui setiap pemanggilan. Anthropic membangun ini khusus untuk mendukung run otonom yang lebih aman.

Detail yang perlu dipahami adalah sandbox hanya mencakup Bash dan proses anaknya. Ini tidak membatasi alat Read, Edit, atau Write, dan alat-alat itu tetap melalui sistem permission.

Sandboxing native

Sandbox native terpasang di Claude Code dan diaktifkan dengan /sandbox.

Di macOS, sandboxing menggunakan framework Seatbelt bawaan dan tidak ada yang perlu dipasang. Di Linux dan WSL2, Anda memasang bubblewrap untuk isolasi filesystem dan socat untuk proxy jaringan. Windows native tidak didukung, jadi jalankan Claude Code di dalam distribusi WSL2.

Batas filesystem mudah dipahami. Pembacaan berfungsi di mana saja kecuali path yang ditolak, dan penulisan hanya berfungsi di dalam direktori kerja dan path tambahan yang Anda izinkan. Jika Anda mencoba menulis ke ~/.bashrc dari dalam sandbox Anda akan mendapatkan "Operation not permitted" sebelum Claude tahu itu gagal.

Batas jaringan agak berbeda. Lalu lintas keluar dirutekan melalui server proxy di luar sandbox, yang memeriksa setiap permintaan terhadap daftar allowedDomains Anda. Domain baru memicu prompt permission, sehingga Anda melihat persis apa yang dicoba dijangkau Claude.

Konfigurasi yang berfungsi terlihat seperti ini:

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "filesystem": {
      "allowWrite": ["/workspace", "/tmp"],
      "denyRead": ["~/.aws", "~/.ssh"]
    },
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

Dalam penggunaan internal Anthropic, sandboxing mengurangi prompt permission sebesar 84%.

Container pengembangan

Dev container adalah langkah berikutnya dalam isolasi.

Anthropic memiliki devcontainer referensi untuk Claude Code yang menyiapkan lingkungan Ubuntu, me-mount repo Anda, dan memberi agen shell untuk bekerja. Keuntungannya dibanding sandboxing native adalah reproduktibilitas, karena semua anggota tim mendapatkan lingkungan yang sama, dengan alat dan setup yang sama.

Tetapi kekurangannya adalah overhead. 

Anda menambah proses pembuatan container, mounting file, dan (terkadang) siklus umpan balik yang lebih lambat saat menggunakan container. Untuk pengembang tunggal, sandbox native biasanya cukup. Untuk penggunaan tim atau CI, setup ini sepadan.

Isolasi berbasis Docker

Untuk sesi agen otonom jangka panjang, Docker dapat semakin memperluas batas sandboxing.

Biasanya setup-nya seperti ini:

• Citra dasar minimal: hapus manajer paket dan alat jaringan yang tidak dibutuhkan tugas.
• Pengguna non-root: Claude tidak pernah berjalan sebagai root, sehingga tidak bisa memodifikasi file sistem atau memasang paket global.
• Filesystem root hanya-baca: mount root container sebagai hanya-baca, dengan hanya direktori output tertentu yang dapat ditulis.
• Proxy egress: rute lalu lintas keluar melalui proxy yang mengizinkan registry paket (npm, PyPI) dan menolak yang lainnya, sehingga perintah seperti npm install berfungsi tetapi curl sembarang tidak.
• Batas sumber daya: tetapkan batas CPU, memori, dan I/O agar sebuah proses tidak bisa melumpuhkan host.

Docker Sandboxes memberi setiap sandbox microVM sendiri dengan daemon Docker privat. Daemon host bahkan tidak bisa melihat sandbox di docker ps. Batasnya mendekati VM daripada container, yang menutup sebagian besar jalur pelarian container yang dikhawatirkan developer.

Strategi sandboxing tingkat enterprise

Bagi organisasi, pertanyaannya adalah bagaimana melapiskan teknik sandbox, bukan apakah akan menggunakannya.

Berikut cara sebagian besar dari mereka mendekatinya:

• Aturan permission ditempatkan di managed-settings.json dan tidak dapat ditimpa oleh pengembang individual.

• Sandboxing native berjalan di bawah lapisan permission.

• Dev container atau Docker berjalan di bawah itu.

• Untuk skenario kepercayaan tertinggi (akses produksi, penanganan rahasia), VM khusus tanpa mount filesystem host adalah lapisan terakhir.

Claude Code di web adalah versi terkelola dari gagasan yang sama. Setiap sesi berjalan di VM yang dikelola Anthropic, kredensial sensitif seperti token git ditempatkan di luar sandbox dalam proxy, dan batas ditegakkan oleh infrastruktur.

Keamanan MCP di Claude Code

MCP adalah bagian dari Claude Code yang tumbuh paling cepat.

Setiap server MCP yang Anda sambungkan kira-kira melipatgandakan apa yang bisa dilakukan Claude, tetapi juga melipatgandakan permukaan yang bisa dijangkau prompt injection atau dependensi yang terkompromi. 

Contohnya:

• Server MCP GitHub memberi Claude akses pull request.
• Server MCP basis data memberinya skema dan kueri Anda.
• Server Slack memberinya kanal Anda.

Semua itu bukan masalah, tetapi berarti MCP memerlukan tata kelola tersendiri. Konten yang diambil melalui alat MCP (halaman web atau respons API) dapat berisi instruksi tersuntik yang dieksekusi Claude seolah-olah Anda yang mengetiknya. Selain itu, setiap server menambah kredensial dan jalur autentikasi yang harus dikelola secara terpisah.

Permissions alat

Alat MCP menggunakan konvensi penamaan yang berbeda dari alat bawaan.

Format aturan adalah mcp__servername__toolname, tanpa penentu bertanda kurung. Misalnya, mcp__github__create_pull_request memungkinkan Claude memanggil tepat alat itu, dan deny pada mcp__github__delete_repo memblokir yang berbahaya. Daftar allow, ask, dan deny bekerja sama seperti untuk Bash atau Read.

Aturan prioritasnya sama juga — deny dulu, lalu ask, kemudian allow. Deny di managed-settings pada mcp__github__delete_* berlaku di setiap proyek pada mesin tersebut.

Permissions sumber daya

Server MCP dapat mengekspos sumber daya selain alat.

Sumber daya adalah potongan data yang disediakan server untuk dibaca Claude (file di server manajemen proyek atau baris di server basis data). Akses sumber daya melalui pemeriksaan kepercayaan yang sama seperti pemanggilan alat, dan koneksi server MCP pertama kali menjalankan langkah verifikasi kepercayaan sebelum alat atau sumber dayanya dapat dijangkau.

Default yang tepat adalah memperlakukan sumber daya sebagai alat lain. Jika Anda tidak akan memberikan kredensialnya, jangan berikan akses sumber dayanya.

Server MCP yang disetujui

Direktori Anthropic mencantumkan konektor yang telah ditinjau Anthropic terhadap kriteria pencantuman mereka.

Untuk organisasi, pola yang baik adalah menggunakan allowlist internal. Ada dua pengaturan yang memberi Anda kontrol:

• allowedMcpServers: pola glob server yang dapat ditambahkan developer ke proyek mereka (misalnya, company-* untuk hanya mengizinkan server yang dipelihara internal).

• deniedMcpServers: pola server yang tidak bisa ditambahkan, bahkan jika developer mencoba.

Untuk server wajib yang harus ada di setiap sesi, file managed-mcp.json yang ditempatkan di managed settings adalah cara untuk mendistribusikannya. Developer tidak bisa menghapus atau memodifikasi entri.

Satu pengaturan yang perlu dihindari di repo bersama adalah enableAllProjectMcpServers, yang secara otomatis menyetujui setiap server MCP yang didefinisikan di .mcp.json. Itu nyaman untuk pekerjaan solo dan berbahaya untuk apa pun yang di-commit, karena PR berbahaya dapat menambahkan server baru ke .mcp.json dan menjalankannya tanpa prompt.

Akses alat dengan least-privilege

Prinsipnya sama seperti permissions Bash, hanya diterapkan pada MCP.

Pertanyaan awalnya adalah kredensial apa yang dimiliki setiap server. Server MCP basis data harus terhubung ke read-replica dengan akses hanya-baca, bukan primary dengan hak tulis. Server MCP API harus menggunakan token yang dibatasi ke set endpoint terkecil yang diperlukan, bukan token personal dengan akses penuh ke organisasi. Dan seterusnya.

Subagent adalah cara lain untuk membatasi akses MCP. Definisi subagent di .claude/agents/ dapat mendeklarasikan alat mana saja yang boleh diaksesnya (menggunakan sintaks mcp:<server>:<tool>), sehingga "deploy-agent" mendapatkan server infrastruktur dan "review-agent" hanya mendapatkan Read, Grep, dan Glob. Agen tidak bisa memanggil alat yang tidak diberi akses.

Tata kelola MCP

Untuk tim atau organisasi yang menjalankan Claude Code dalam skala besar, MCP membutuhkan bentuk tata kelola yang sama seperti integrasi produksi lainnya.

Itu berarti registry server yang disetujui dengan penanggung jawab yang ditunjuk, jejak audit end-to-end dari pemanggilan alat (alat MCP mana yang dipanggil, oleh siapa, dengan parameter apa), dan tinjauan berkala terhadap daftar persetujuan. Eksportir OpenTelemetry di Claude Code memberi Anda data audit dalam format yang dapat langsung masuk ke tumpukan observabilitas yang sudah Anda jalankan.

Untuk organisasi yang lebih besar, gateway MCP terpusat adalah versi yang paling bersih. 

Developer terhubung ke gateway alih-alih mendaftarkan server satu per satu. Gateway menangani autentikasi, menegakkan akses berbasis peran di tingkat alat, dan menghasilkan satu jejak audit. Ini juga menyelesaikan penyebaran kredensial, karena satu set kredensial di gateway menggantikan setiap developer yang memegang salinan setiap kunci API.

Manajemen Secrets dan Data Sensitif

Claude Code dapat membaca apa pun yang bisa Anda baca, yang membuat secrets dapat dijangkau.

Secara default, Claude Code dapat membaca setiap file yang dapat dibaca akun pengguna Anda. Itu termasuk file .env di proyek Anda, kredensial AWS di ~/.aws/, kunci privat SSH di ~/.ssh/, token GitHub di file rc shell Anda, dan variabel lingkungan di proses turunan mana pun yang dibuat Claude. Itu sepenuhnya normal dan sesuai desain.

Jauhkan secrets dari workspace

Langkah pertama adalah memastikan secrets tidak berada di direktori yang dibaca Claude.

.env adalah yang paling umum. File-file ini berada di root proyek, dimuat oleh setiap alat dev, dan berisi persis nilai yang tidak Anda inginkan dalam konteks Claude (URL basis data dan kunci API). 

Berikut beberapa pola yang bisa Anda gunakan:

• Pindahkan secrets ke direktori di luar pohon kerja, misalnya ~/.config/myapp/secrets.env, dan muat melalui manajer lingkungan atau setup direnv yang menunjuk ke file eksternal.

• Untuk pekerjaan ter-container, simpan folder .secrets/ di luar bind mount sehingga file tidak terlihat dari dalam container.

• Tambahkan Read(**/.env) dan Read(**/.env.*) ke daftar permissions.deny Anda, dan pasangkan dengan deny Bash(cat:*/.env) sehingga skrip shell tidak bisa membaca apa yang tidak bisa dibaca alat Read.

Gunakan secret manager

Untuk apa pun selain proyek demo, tempat yang tepat untuk secrets adalah secret manager.

Polanya sama terlepas dari vendornya (1Password, AWS Secrets Manager, HashiCorp Vault, Doppler, Infisical). Secrets ditempatkan di manager. Shell atau runtime Anda mengambilnya sesuai permintaan dan mengeksposnya hanya ke proses yang membutuhkannya. Claude tidak pernah melihat nilainya secara langsung.

Khusus untuk Claude Code, ini berarti menyetel CLAUDE_CODE_SUBPROCESS_ENV_SCRUB untuk menghapus kredensial Anthropic dan penyedia cloud dari subprocess, atau menggunakan sandbox.credentials untuk menghapus variabel tertentu untuk perintah yang disandbox. Yang pertama mencegah Claude meneruskan ANTHROPIC_API_KEY ke skrip build Anda, dan yang kedua mencakup kasus lebih luas dari variabel lingkungan sensitif apa pun yang masuk ke perintah shell.

Batasi akses repositori

Opsi ketiga ada di tingkat repo.

Jika seorang developer tidak memerlukan akses tulis ke konfigurasi khusus produksi, sesi Claude Code mereka juga tidak. Itu terdengar jelas, tetapi default untuk sebagian besar tim adalah developer memiliki akses yang lebih luas daripada yang rutin mereka gunakan, dan Claude mewarisi semuanya.

Berikut dua langkah yang dapat Anda ambil:

• Pisahkan konfigurasi produksi ke repo terpisah dengan akses lebih ketat, sehingga lingkungan dev tempat Claude bekerja tidak memiliki secrets produksi sejak awal.

• Gunakan token yang dibatasi cakupannya untuk layanan apa pun yang berinteraksi dengan Claude. Misalnya, token GitHub untuk pekerjaan code review tidak membutuhkan repo:delete.

Keamanan Claude Code untuk Tim

Seorang developer tunggal dapat mengubah settings.json sesuka hati. Tim tidak bisa, karena keamanan keseluruhan hanya sebaik konfigurasi terlemah pada mesin terlemah. Untuk penerapan tim dan organisasi, Claude Code memiliki lapisan kontrol terpisah yang didorong oleh admin dan tidak dapat ditimpa pengguna individual.

Managed settings

Managed settings adalah fondasinya.

File ini berada di path sistem yang memerlukan akses admin untuk menulisnya:

• /Library/Application Support/ClaudeCode/managed-settings.json di macOS

• /etc/claude-code/managed-settings.json di Linux

• C:\ProgramData\ClaudeCode\managed-settings.json di Windows

Pengaturan dalam file ini memiliki prioritas di atas pengaturan tingkat pengguna dan tingkat proyek. Aturan deny yang ditempatkan di sini berlaku sebagai deny di setiap proyek pada mesin tersebut, dan developer tidak dapat menghapusnya dengan mengedit settings.json mereka sendiri. Sebagian besar organisasi mendistribusikan file ini melalui MDM (Mobile Device Management) atau saluran konfigurasi yang sama yang mereka gunakan untuk alat dev lainnya.

Berikut beberapa pengaturan yang perlu diketahui pada lapisan terkelola:

• permissions.deny untuk path sensitif dan perintah berbahaya

• defaultMode disetel ke default atau plan (jangan pernah bypassPermissions)

• allowManagedPermissionRulesOnly: true untuk mengunci set permission

• enableAllProjectMcpServers: false untuk memerlukan persetujuan MCP eksplisit

• Konfigurasi eksportir OpenTelemetry untuk pencatatan

Kebijakan permission bersama

Tim yang sepakat tentang apa yang boleh dilakukan Claude sebaiknya menaruh kesepakatan itu dalam version control.

Pengaturan tingkat proyek berada di .claude/settings.json pada root repo. Apa pun yang di-commit di sini berlaku untuk siapa pun yang menjalankan Claude di repo tersebut. File ini adalah tempat yang tepat untuk allow dan deny spesifik proyek.

Dengan itu, ada pembagian antara managed settings dan pengaturan proyek yang perlu Anda ketahui:

• Managed settings memuat kebijakan organisasi (tidak ada yang menjalankan bypassPermissions, tidak ada yang membaca .env).

• Pengaturan proyek memuat konvensi alur kerja (tes repo ini dijalankan dengan npm test; skrip deploy repo ini tidak boleh disentuh).

Tata kelola tim

Untuk peluncuran tim, lapisan kebijakan membutuhkan penanggung jawab.

Sebagian besar tim yang menjalankan Claude Code dalam skala besar akhirnya memiliki kelompok kecil, biasanya keamanan dan rekayasa platform, yang memiliki managed settings, allowlist MCP, skrip hook, dan pipeline OpenTelemetry. Kelompok yang sama meninjau permintaan pengecualian dan menyesuaikan kebijakan saat use case baru muncul.

Anda sebaiknya memiliki hal-hal ini secara tertulis:

• Repo mana yang termasuk cakupan dan mana yang tidak, dengan mode berdasar tingkat risiko (repo yang menangani data teregulasi kemungkinan menjalankan Claude dalam mode plan, sementara repo situs pemasaran dapat berjalan dalam acceptEdits).
• Siapa yang bisa memberikan pengecualian dan bagaimana pengecualian tersebut dilacak.
• Irama tinjauan (triwulanan umum) saat tim meninjau ulang aturan permission, server MCP, dan data insiden.

Pencatatan audit

Claude Code memancarkan event OpenTelemetry untuk setiap keputusan alat, koneksi server MCP, perubahan mode permission, dan permintaan API. Tidak ada data yang mengalir sampai admin mengonfigurasi endpoint OTLP di managed settings.

Berikut blok managed settings minimal untuk telemetry:

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "http://collector.internal:4317"
  }
}

Secara default, konten prompt dan parameter alat dikecualikan dari ekspor, jadi event yang Anda kumpulkan adalah metadata, bukan percakapan penuh. Untuk menyertakan teks prompt, setel OTEL_LOG_USER_PROMPTS=1. Untuk menyertakan argumen alat (yang biasanya Anda inginkan untuk audit), setel OTEL_LOG_TOOL_DETAILS=1. Keduanya memiliki implikasi privasi, jadi sebagian besar tim memperlakukannya sebagai pilihan kebijakan yang disengaja dan mengonfigurasi backend telemetry untuk memfilter atau meredaksi sebelum penyimpanan.

Pemantauan penggunaan

Aliran OpenTelemetry yang sama di balik audit juga digunakan untuk pemantauan penggunaan.

Claude Code mengekspor metrik untuk penggunaan token, biaya per permintaan, jumlah sesi, dan tingkat keputusan alat. Saat diagregasi, metrik ini memberi tahu tim mana yang mendapatkan nilai paling besar, alur kerja mana yang menghasilkan penolakan terbanyak, dan model mana yang mendorong biaya. Backend seperti Datadog, Honeycomb, SigNoz, Elastic, dan Splunk semuanya menerima format standar OTLP.

Lonjakan event permission_decision dengan decision=deny bisa berarti Claude mencoba terlalu banyak, tetapi juga bisa berarti aturan allow tim terlalu ketat.

Kesalahan Umum Keamanan Claude Code

Sejumlah kecil salah konfigurasi sering muncul di sebagian besar insiden Claude Code. Berikut apa saja dan cara menanganinya.

Permissions yang terlalu luas

Cara tercepat untuk menumpulkan sistem permission adalah mengizinkan terlalu banyak.

Prompt per perintah menambah friksi, dan perbaikan mudahnya adalah allow Bash(*) yang luas atau pengaturan defaultMode: bypassPermissions. Keduanya membatalkan sebagian besar fungsi sistem permission.

Anda sebaiknya membatasi aturan allow ke alat dan perintah spesifik yang benar-benar Anda gunakan (misalnya Bash(npm test:*) dan Bash(git status)), dan biarkan yang lainnya kembali ke prompt. Anda akan mendapat lebih banyak prompt pada awalnya tetapi dalam beberapa sesi, Anda telah mendaftarkan perintah yang digunakan dan prompt sebagian besar berhenti.

Akses MCP tanpa batas

Kesalahan kedua adalah menghubungkan server MCP tanpa memeriksa kredensial apa yang mereka gunakan atau apa yang bisa mereka jangkau.

Ini biasanya terjadi karena seseorang mengaktifkan enableAllProjectMcpServers, menghubungkan beberapa server dari direktori MCP publik, dan tidak pernah kembali meninjaunya. Saat sebuah server dengan kredensial lemah membocorkan sesuatu yang sensitif, koneksinya sudah cukup lama berada di konfigurasi sehingga tidak ada yang ingat menyetujuinya.

Perbaikannya sama seperti untuk permissions. Gunakan allowlist eksplisit melalui allowedMcpServers, managed-mcp.json internal untuk server yang dibutuhkan semua orang, dan ritme peninjauan pada daftarnya.

Tanpa sandboxing

Jika sandboxing dimatikan, sistem permission adalah satu-satunya penghalang antara Claude dan filesystem Anda.

Itu tidak masalah untuk sesi interaktif singkat di mana Anda menyetujui setiap perintah. Tidak aman untuk run otonom, untuk sesi di mana Anda memperluas aturan allow, atau untuk pekerjaan apa pun yang menyentuh kode dari sumber luar.

/sandbox menyalakannya. Jika dependensi belum terpasang, menu akan menunjukkan mana yang perlu dipasang untuk platform Anda. Setelah aktif, prompt permission berkurang dan OS menangkap kasus yang tidak tertangkap aturan allow Anda.

Menerima perubahan tanpa meninjau

acceptEdits sekaligus nyaman dan berbahaya.

Ketika Claude menulis ulang sebuah fungsi dan Anda memantau, auto-accept tidak masalah. Ketika Claude mengiterasi 30 file selama satu jam, Anda cenderung berhenti membaca diff dan mulai memercayai agen. Di situlah masalah dapat muncul.

Berikut dua kebiasaan yang sebaiknya Anda lakukan:

• Selalu commit sebelum membiarkan Claude berjalan secara otonom, sehingga jalur rollback hanya sejauh git reset.

• Tinjau diff sebelum setiap commit yang ditulis Claude, bukan diff kumulatif di akhir sesi.

Mengabaikan jejak audit

Tim yang menjalankan Claude Code tanpa telemetry tidak punya cara untuk menjawab pertanyaan "sesi mana yang melakukan itu?" Event menumpuk secara lokal di setiap mesin dan tetap di sana. Saat pertama kali Anda membutuhkan jejak audit juga merupakan saat terburuk untuk mengetahui bahwa Anda belum mengonfigurasinya.

Batas minimum yang berguna adalah mengekspor event tool_decision, permission_decision, dan api_request ke tumpukan observabilitas apa pun yang sudah dijalankan tim. Dari sana, Anda membuat dasbor dan peringatan sesuai kebutuhan.

Kesimpulan

Skenario terburuk untuk chatbot adalah jawaban yang buruk. Namun untuk agen pengodean, itu adalah perintah shell yang berjalan terhadap produksi dengan kredensial Anda.

Itulah mengapa tiga pilar ini penting:

• Permissions menentukan apa yang boleh dilakukan Claude
• Kontrol MCP menentukan sistem eksternal mana yang dapat dijangkaunya
• Sandboxing menentukan apa yang terjadi saat dua hal pertama tidak cukup

Masing-masing mencakup mode kegagalan yang tidak dicakup lainnya. Bersama-sama, mereka menentukan batas nyata tempat Claude bekerja.

Jika Anda ingin mendapatkan sertifikasi AI generatif, berikut perbandingan, kursus terbaik, tips persiapan, dan FAQ untuk Sertifikasi AI Generatif Terbaik pada 2026.