[ Otomatisasi agen ]

Atur agen AI yang mengirim email atas nama organisasi

Mengontrol penerima, konten, dan identitas pengirim agen secara independen apakah suratnya lolos autentikasi.

Oleh tim peneliti EmailAuth · 3 menit membaca

[Poin-poin penting]

  • Mengontrol penerima, konten, dan identitas pengirim agen secara independen apakah suratnya lolos autentikasi.
  • Pengirim yang diautentikasi masih memerlukan penerima, tujuan, dan konten yang disetujui.
Di halaman ini

Agen AI yang dapat mengirim email dapat menimbulkan konsekuensi bisnis bahkan ketika setiap pesan lolos SPF, DKIM Dan DMARC. Otentikasi menangani aspek identitas domain pengirim; itu tidak menetapkan bahwa pesan tersebut sah, akurat atau sesuai. Atur tindakan pengiriman sebagai kemampuan terpisah dengan tujuan dan cakupan penerima yang ditentukan.

Tentukan apa yang dapat dikomunikasikan oleh agen

Tentukan kasus penggunaan yang disetujui, akun pengirim, sumber penerima, batas volume, aturan lampiran, dan persyaratan peninjauan. Ringkasan status internal rutin dan komitmen kontrak tidak boleh memiliki jalur persetujuan otonom yang sama. Batasi penerima eksternal dan konten sensitif sesuai dengan kebijakan organisasi, dan tentukan siapa yang dapat mengubah kebijakan tersebut.

Dapatkan identitas penerima dari direktori tepercaya atau alamat yang disetujui secara eksplisit, bukan dari instruksi yang tertanam dalam email yang sedang dianalisis. Pesan yang mengatakan pengiriman laporan ke alamat baru ini adalah bukti untuk dievaluasi, bukan otorisasi otomatis. Injeksi Cepat OWASP menjelaskan mengapa teks eksternal dapat memanipulasi perilaku agen jika diperlakukan sebagai instruksi.

Pisahkan otoritas pengiriman dari membaca

Gunakan identitas pengirim hanya dengan kotak surat dan izin API yang diperlukan. Integrasi pembacaan laporan tidak boleh secara diam-diam mendapatkan otoritas pengiriman atau pengiriman atas nama. Pertahankan pembuatan draf, persetujuan, dan penyerahan sebagai peristiwa log yang terpisah. Sebelum diserahkan, periksa kembali penerima, subjek, isi dan lampiran terhadap versi yang disetujui.

Keagenan OWASP yang Berlebihan merekomendasikan untuk membatasi fungsi dan izin yang terbuka serta menerapkan otorisasi di bagian hilir. Terapkan kontrol tersebut di gateway pengiriman sehingga model tidak dapat melewatinya dengan alat HTTP umum atau API email alternatif. Batasan kapasitas dan tombol pemutus mengurangi dampak namun tidak menggantikan otorisasi penerima dan konten.

Uji alur kerja pengiriman terbatas

Untuk rencana tertulis SEND-01, asumsikan kotak surat penyewa-A/layanan, Dari status@example.invalid , penerima ops@example.invalid , status Rutin subjek, isi Tinjauan selesai; tidak ada perubahan yang diusulkan, tidak ada lampiran, status internal tujuan. Semua identitas bersifat ilustratif dan tidak ada kredensial atau persetujuan aktual yang diberikan.

Berdasarkan aturan gateway yang diusulkan, objek persis dengan persetujuan terlindungi yang valid dan ID operasi yang tidak digunakan dapat memenuhi syarat untuk dikirimkan. Penerima eksternal baru, lampiran, tujuan kontrak, perubahan isi, perubahan Dari, akun berbeda, atau ID operasi yang digunakan kembali harus menghentikannya. Rute HTTP umum tidak boleh melewati batas otorisasi yang sama. Ini adalah keputusan yang diharapkan, bukan pengujian yang dilaksanakan.

Dalam produksi, bedakan permintaan yang diterima penyedia dari pengiriman penerima. Jika respons pengiriman hilang, periksa pesan yang tersedia atau pengidentifikasi operasi sebelum mencoba lagi untuk menghindari duplikat email. Dukungan idempotensi penyedia bervariasi; penjaga replay lokal saja tidak dapat membuktikan pengiriman tepat satu kali melalui kegagalan jaringan.

Pertahankan rantai tindakan yang dapat diperiksa

Urutan yang diusulkan adalah pengambilan laporan yang disetujui, pembuatan draf, keputusan manusia yang berwenang, validasi gerbang eksekusi, penyerahan penyedia, dan observasi pengiriman terpisah. Catat komponen mana yang memiliki setiap langkah. ID permintaan penyedia, tanda terima persetujuan, stempel waktu pengiriman, dan hasil pengiriman tidak tersedia dalam contoh ini. Tidak ada adaptor penyedia, penjaga lokal, atau pengujian ulangan yang dijalankan, dan tidak ada pesan yang dikirim.

Otentikasi dan audit jalur email sebenarnya

Konfigurasikan autentikasi terdokumentasi layanan pengirim untuk domain Dari yang dipilih dan verifikasi pesan pengujian resmi pada penerima. RFC 9989 menjelaskan penyelarasan, ketika DKIM memisahkan tanggung jawab penandatangan dari penulis yang diakui. Tidak ada protokol yang mengesahkan kebenaran pernyataan yang dibuat oleh AI.

Simpan otorisasi pengguna atau layanan, versi konten yang disetujui, resolusi penerima, hasil pengiriman, dan bukti pengiriman berikutnya di bawah kendali penyimpanan yang sesuai. Berikan cara untuk segera menangguhkan pengiriman tanpa menonaktifkan diagnosis hanya-baca. Jika pesan yang tidak sah dikirim, perlakukan itu sebagai insiden komunikasi; memperbaiki DNS tidak akan menarik kembali isinya.

[ Membawa pergi ]

Pengirim yang diautentikasi masih memerlukan penerima, tujuan, dan konten yang disetujui.

[ Berdasarkan peran ]

Apa artinya ini bagi Anda

Pilih peran Anda untuk langkah praktis selanjutnya.

Admin TI / Surat

Kontrol gateway pengiriman

Pemeriksaan penerima dan muatan dilakukan pada waktu eksekusi.

Langkah selanjutnya

  1. Catat versi konten yang disetujui.
  2. Uji duplikat dan hasil yang tidak pasti.
  3. Rekonsiliasi pengiriman yang tidak pasti sebelum mencoba lagi.

CISO / Detik

Perlakukan otoritas email sebagai kemampuan istimewa

Otentikasi saja tidak mencegah penyalahgunaan.

Langkah selanjutnya

  1. Audit cakupan pengiriman.
  2. Pertahankan jalur suspensi yang cepat.
  3. Verifikasi otentikasi identitas pengirim.

Pendiri / Non-teknis

Pisahkan kenyamanan dari komitmen

Agen ringkasan yang berguna tidak boleh memperoleh suara perusahaan yang tidak dibatasi.

Langkah selanjutnya

  1. Tentukan tujuan yang diizinkan.
  2. Memerlukan peninjauan untuk komitmen konsekuensial.
  3. Bedakan pembaruan status dari komitmen bisnis.

[ FAQ ]

Pertanyaan yang sering diajukan

Apakah DMARC pass berarti pesan telah diotorisasi?

Tidak. Otentikasi domain tidak menetapkan izin bisnis atau kebenaran konten.

Haruskah membaca surat memberikan izin pengiriman?

Tidak. Perlakukan baca, buat draf, dan kirim sebagai kemampuan terpisah.

Bisakah penerima diambil dari email yang dianalisis?

Hanya setelah otorisasi tepercaya dan pemeriksaan identitas; teks email itu sendiri tidak dapat memberikan otoritas.

Apa saja yang harus dicakup dalam persetujuan?

Kumpulan penerima, tujuan, identitas pengirim, dan konten atau cakupan lampiran yang relevan.

Apakah contohnya mengirim email?

Tidak. Ini menentukan kebijakan pengiriman tertulis tanpa gateway atau pengiriman pesan yang dijalankan.

Bagaimana jika waktu pengiriman panggilan habis?

Periksa penyedia dan bukti operasi sebelum mencoba lagi; hasilnya mungkin tidak pasti.

Apakah penjaga replay memastikan pengiriman tepat satu kali?

Tidak. Perilaku jaringan dan penyedia memerlukan penanganan dan verifikasi terpisah.

Apa yang harus dihentikan oleh kendali darurat?

Mengirim otoritas, sambil menjaga akses baca-saja yang aman jika diperlukan untuk penyelidikan.

[ Sumber ]

Sumber

  1. Keagenan OWASP yang Berlebihan

    Bagian Strategi pencegahan dan mitigasi

  2. Injeksi Cepat OWASP

    Bagian Strategi pencegahan dan mitigasi

  3. RFC 9989 DMARC

    Bagian §4.4 · §5.3.5 · §5.4 · §7.4 · §8

  4. RFC 6376 DKIM

    Bagian §3.4 · §3.5 · §3.6 · §3.7 · §6.1 · §6.3

[ Glosarium ]

Glosarium

Kirim sebagai otoritas
Izin mengirimkan surat dengan menggunakan akun atau identitas lain sebagai pengirim.
Putar ulang penjaga
Kontrol yang menolak penggunaan berulang dari pengidentifikasi operasi yang diproses sebelumnya.

Asal perusahaan

Mengapa lembaga keuangan dan pemerintah terkemuka menghentikan dasbor keamanan email mereka.

Platform autentikasi email tradisional menjual dasbor kepada Anda dan meminta teknisi Anda melakukan pekerjaannya. Di lingkungan berisiko tinggi, pengawasan manual berarti penegakan yang tertunda, penyimpangan konfigurasi, dan domain bayangan yang tidak dipantau.

EmailAuth adalah platform asal email agen. Agen kami menegakkan p=reject, jaga agar pengirim pihak ketiga tetap selaras dan pindahkan domain Anda ke kapasitas penuh RFC 9989 kepatuhan, standar DMARC baru, dengan kemampuan audit yang dapat dilakukan secara langsung oleh manusia.

Pemerintah Perusahaan besar Lembaga keuangan tingkat 1

SaaS · Penyewaan khusus · On-prem dengan celah udara · Enkripsi BYOK

Basis Pengetahuan