Laporan Ancaman Anthropic September 2026: Pelajaran DevOps

Angka yang membuat saya berhenti membaca laporan Anthropic bukan yang terbesar. Angkanya 34 jam: waktu yang disebut laporan untuk dump session store berisi lebih dari 2.100 set token Azure AD dari lebih dari 40 tenant perusahaan, dengan AI agent mengerjakan hampir semuanya. Kebersihan token di tempat kita biasanya diukur dalam kuartal, bukan jam.

Tulisan ini adalah pembacaan dari sudut pandang defender atas laporan yang diterbitkan Anthropic pada 10 September 2026, yang mencakup aktivitas yang mereka hentikan antara Desember 2025 dan Agustus 2026. Saya membaca sendiri bagian cyber-nya; setiap klaim soal penyerang saya atribusikan ke laporan dan saya tidak menambah detail operasional. Mitigasinya bersumber dari dokumentasi Microsoft, GitHub, dan TruffleHog yang juga saya baca, dan opini saya sendiri diberi label.

Apa yang sebenarnya dikatakan laporan tentang tiga kasus cyber

Klaim utama laporan ini: AI telah menggeser serangan dari kerja manual yang padat tenaga menjadi eksekusi yang didelegasikan dan berjalan secepat mesin, sehingga tingkat kecanggihan tidak lagi memberi tahu siapa pelakunya. Laporan menyebut Claude Haiku, Sonnet, dan Opus dipakai di semua kasus cyber-nya. Tiga kasus paling relevan bagi siapa pun yang menjalankan infrastruktur, dan tabel memisahkan apa yang dinyatakan laporan dari pelajaran yang saya tarik.

Dua batasan untuk semua ini. Ini temuan Anthropic sendiri atas platformnya sendiri, jadi menggambarkan apa yang bisa mereka lihat, bukan seluruh lanskap ancaman. Dan laporan tidak menyebut jenis token Azure AD apa yang ada dalam set tersebut, jadi saya tidak menebak.

Dibangun ulang sampai tak terdeteksi: signature adalah indikator yang terlambat

Pada kasus GTG-20006 laporan menyebut agent pemantau mengawasi apakah malware yang di-deploy ditandai, dan agent terus mengiterasi sampai tidak ditandai lagi. Kesimpulannya lugas: AI telah membalik biaya kembali ke defender, dan deteksi statis menjadi kurang efektif karena penyerang bisa menutup loop lebih cepat daripada respons defender.

Saya membacanya sebagai pernyataan soal waktu, bukan soal satu produk tertentu. Aturan berbasis hash atau string ditulis setelah sampel terlihat, dan loop uji ulang yang membangun ulang sampel bisa selesai sebelum aturan dirilis. Laporan tidak menyebut berapa lama satu loop berjalan, jadi saya tidak mengklaim angka.

Yang bertahan setelah dibangun ulang adalah perilaku dan identitas: service account yang tiba-tiba membaca email yang tak pernah dibacanya, token yang dipakai dari perangkat yang tak pernah terdaftar, build job yang memanggil API cloud baru. Karena itu sisa tulisan ini membahas credential, bukan signature malware. Ini inferensi saya dari argumen laporan, dan tim deteksi Anda mungkin menimbangnya berbeda.

Session store sebagai jarahan: token terikat perangkat dan revocation cepat

Anthropic menyebut 2.100 set token berasal dari dump session store, dan itu bagian yang layak ditindaklanjuti: session store adalah tumpukan credential yang bisa di-replay. Token Protection dari Microsoft menyasar tepat replay itu. Dokumentasinya menyebut ia mengurangi serangan token replay dengan memastikan hanya sign-in session token yang terikat perangkat, seperti Primary Refresh Token, yang diterima, sehingga token curian tidak bisa dipakai dari perangkat lain.

Continuous access evaluation menangani separuh lainnya, yaitu masa pakai. Halaman Microsoft menyebut access token secara default berlaku satu jam, critical event ditegakkan hampir real time dengan latensi hingga 15 menit, dan sesi CAE-aware bisa membawa token yang berlaku hingga 28 jam karena revocation digerakkan oleh event. Kedua kontrol punya batas nyata, diringkas di bawah dari dua halaman Microsoft tersebut.

# Incident lever: kill every refresh token for one account, then let CAE-aware
# apps (Exchange, SharePoint, Teams) be challenged on their next request.
# Cmdlet named in Microsoft's CAE page; needs the Microsoft Graph PowerShell SDK.
Connect-MgGraph -Scopes "User.RevokeSessions.All"
Revoke-MgUserSignInSession -UserId "dev@example.com"

# Caution from the same page: a Conditional Access policy or group change can
# take up to a day to reach resource providers (some policy updates, about two
# hours). Revoking sessions is the way to make it bite now.

# Rollout order for Token Protection, per Microsoft's deployment advice:
#   1. pilot group first
#   2. Conditional Access policy in report-only mode
#   3. capture interactive AND non-interactive sign-in logs
#   4. read the logs for long enough to cover normal app use
#   5. only then enforce

Satu token developer jadi admin cloud dalam sekitar tiga jam

Laporan menyatakan satu intrusi naik dari satu token developer curian menjadi kendali administratif penuh atas lingkungan cloud korban dalam sekitar tiga jam. Laporan tidak menjelaskan langkahnya dan saya tidak akan merekonstruksinya. Temuannya adalah jaraknya, bukan jalurnya: tiga jam adalah jendela yang pendek bagi anomali yang senyap untuk disadari dan dieskalasi manusia.

Jadi pertanyaan bagi defender adalah apa yang bisa dijangkau identitas developer pada hari yang buruk. Audit saya dimulai dengan tiga pertanyaan: apakah identitas ini bisa meng-assign role, apakah bisa membaca secrets store, dan apakah ada jalur dari credential CI ke role break-glass. Jika salah satu jawabannya ya, itulah garis yang dipotong sebelum membeli tool baru.

API key AI kini jadi jarahan, dan Anda butuh register

Laporan merekomendasikan agar organisasi memperlakukan key AI dan integrasi agent dengan keseriusan yang sama seperti credential production, dan menyebut satu key curian dipakai sekitar tiga minggu. Dalam setiap kasus yang dijelaskan, key berasal dari lingkungan pelanggan, bukan dari sistem Anthropic. Tiga minggu tanpa disadari adalah kegagalan inventaris sebelum menjadi kegagalan deteksi.

Template di bawah adalah buatan saya, bukan dari laporan. Tugasnya membuat setiap credential AI bisa dipertanggungjawabkan ke seseorang: siapa pemiliknya, lingkungan mana yang dilayani, kapan kedaluwarsa, dan apa yang harus memicu alert saat melonjak. Batas biaya sendiri diatur di console provider, jadi file ini hanya mencatat bahwa batas itu ada, bukan mengarang nilainya.

# ai-key-register.yaml -- MY template, not something the report prescribes.
# One row per AI credential. The point is that every key has an owner and an
# end date, so "stolen and used for three weeks" cannot go unnoticed for three weeks.
- name: ci-eval-harness
  provider: anthropic
  environment: ci-eval          # never a production workload
  owner: platform-team
  scope: eval-only workspace    # a workspace with no production traffic
  spend_cap: set-in-provider-console
  created: 2026-10-01
  rotate_by: 2026-10-31         # short on purpose
  stored_in: secrets-manager    # never in the repo, the image or the sandbox image
  injected_as: per-run env var  # minted per job, gone when the job ends
  alert_on: spend spike, new source IP, use outside CI window

# Wrong: one long-lived production key shared by the app, the eval sandbox
# and a developer laptop. One leak spends every environment's budget.
# Right: one key per environment, per job where the provider allows it.

Sandbox, reseller, dan proxy adalah bagian dari attack surface

Panduan laporan: integrasi yang dibangun di sekitar AI, seperti sandbox, proxy, reseller, dan agent, masuk ke dalam threat model Anda. Kasus-kasusnya memberi bentuk konkret pada tiap integrasi, dan tabel memasangkan pola yang dilaporkan dengan kontrol yang akan saya cek lebih dulu.

Tidak ada kontrol di atas yang eksotis. Yang diubah laporan adalah hitungannya: jika agent bisa mencoba jalur serangan yang sama ke tiga puluh target dalam empat hari, seperti GTG-50020 menurut laporan, maka integrasi Anda yang terlemah akan ditemukan lewat pengulangan, bukan kecerdikan.

Di mana saran ini mulai tidak cukup

Saya akan berlebihan jika mengklaim semua ini akan menghentikan intrusi yang dijelaskan laporan. Anthropic tidak menyebut bagaimana session store dicapai atau token apa isinya, jadi saya tidak bisa bilang Token Protection akan memblokirnya. Klaim yang jujur lebih sempit: ini kontrol terdokumentasi yang menangani kelas credential yang menurut laporan dicuri.

• Celah cakupan: dukungan browser Token Protection masih preview, dan guest user berada di luar CAE, jadi akun partner dan kontraktor butuh rencana sendiri.
• Jeda revocation: hingga 15 menit untuk critical event, dan hingga sehari untuk sebagian perubahan policy dan group, jadi revocation manual tetap harus ada di runbook.
• Sudut pandang vendor: laporan adalah catatan Anthropic atas platformnya sendiri. Ia tidak bisa melihat serangan yang tidak menyentuh Claude, sehingga tidak adanya sebuah pola di dalamnya bukan bukti pola itu tidak ada.
• Kepercayaan pada tooling: scanner dengan verifikasi hanya mengonfirmasi key yang punya detector, dan status unknown berarti verifikasi gagal, bukan berarti key aman.

Pertukaran yang saya pilih: menerima sedikit gesekan rollout dari device binding demi memperpendek jendela replay, dan menjaga fase report-only cukup lama agar saya tahu siapa yang akan terdampak. Itu pilihan saya untuk lingkungan saya sendiri, bukan rekomendasi universal.

Yang dikerjakan hari Senin

Lima langkah, diurutkan dari yang paling banyak mengurangi risiko per jam kerja. Tidak ada yang butuh produk baru.

1. Inventarisasi semua API key AI yang bisa Anda temukan dan catat di register dengan pemilik, lingkungan, dan tanggal rotasi. Mulai dari CI, eval harness, dan vault tim yang dipakai bersama.
2. Scan repository dan workspace build dengan scanner yang melakukan verifikasi, rotasi setiap temuan terverifikasi lebih dulu, baru bersihkan history.
3. Jalankan policy Token Protection dalam mode report-only untuk pilot group, kumpulkan sign-in log interaktif dan non-interaktif, dan baca sebelum enforcement.
4. Tulis dan uji runbook revoke-everything untuk satu identitas developer, termasuk cara memastikan aplikasi CAE-aware menantang sesi tersebut.
5. Audit apa yang bisa dilakukan tiap identitas developer dan CI di cloud Anda: role assignment, secrets read, dan jalur apa pun ke role administrator. Cabut yang tidak dibutuhkan harian.

# Step 1: find AI keys that are still LIVE, not merely key-shaped strings.
# TruffleHog checks each candidate against the issuing API; --results=verified
# keeps only credentials confirmed valid and active.
trufflehog git https://github.com/your-org/your-repo --results=verified

# Same idea for a build agent's workspace or a dumped container filesystem.
trufflehog filesystem /var/lib/ci/workspace --results=verified

# Read the result statuses before you trust a clean run:
#   verified   = confirmed valid and active by API testing
#   unverified = detected but not confirmed (invalid, expired, or verification off)
#   unknown    = verification failed (network or API error) -- re-run, do not ignore

# Step 2: a verified hit means rotate FIRST, clean history second.
# GitHub's own secret scanning guidance is the same: rotate the affected
# credential immediately.

Langkah 1 dan 2 cukup murah untuk selesai dalam satu sore, dan keduanya menangani satu kelas jarahan yang disebut laporan secara eksplisit. Langkah 3 sampai 5 lebih lambat karena menyentuh user, jadi jadwalkan dengan pilot dan tanggal.

Aturan yang saya bawa dari laporan ini: anggap setiap credential yang bisa dibaca agent akan dicoba pada akhirnya, lalu buat setiap credential berumur pendek, terikat perangkat bila mungkin, dimiliki orang yang jelas, dan bisa dicabut dalam hitungan menit. Malware yang bisa dibangun ulang penyerang dalam semalam bukan bagian sistem yang bisa saya kendalikan. Key dan token adalah bagiannya.