ការលេច Privacy នៅចន្លោះ Agent៖ ហេតុអ្វី Output Audit ខកខានវាភាគច្រើន

ពេល agent តែមួយជាប់រវល់ពេក ការជួសជុលស្តង់ដារគឺបំបែកវា៖ coordinator ដែលរៀបផែនការ និងប្រគល់ការងារ បូករួមនឹង worker agent មួយក្ដាប់ ដែលម្នាក់ៗកាន់កាប់ការងារតូចចង្អៀតមួយ។ យើងបានអះអាងពីមុនថានេះជារឿយៗជាចលនាត្រឹមត្រូវសម្រាប់សមត្ថភាព — ហើយក៏ជាកន្លែងដែលប្រព័ន្ធស្ងាត់ៗបែកដែរ ក្នុង ហេតុអ្វី multi-agent system បរាជ័យ។ អត្ថបទនេះអំពីការបរាជ័យ subtle ជាង ដែល architecture ដូចគ្នានោះណែនាំ ការបរាជ័យដែលស្ទើរគ្មាននរណាវាស់៖ ការបំបែកដែលធ្វើឱ្យ output របស់អ្នកសុវត្ថិភាពជាង ធ្វើឱ្យប្រព័ន្ធរបស់អ្នកលេចច្រើនជាង។

សភាវគតិគឺថា agent ច្រើនជាង ម្នាក់ៗ scope តិចជាង គួរ private ជាង។ worker នីមួយៗឃើញតែ slice របស់វា ឯ coordinator sanitize ចម្លើយចុងក្រោយ។ ហើយនៅផ្ទៃ នោះជាអ្វីដែលកើតឡើងពិតប្រាកដ។ បញ្ហាគឺផ្ទៃជារបស់តែមួយដែលក្រុមភាគច្រើន audit — ហើយក្នុងឆ្នាំ ២០២៦ យើងបានទទួលការវាស់ប្រុងប្រយ័ត្ននៃអ្វីៗទាំងអស់នៅពីក្រោមវា។

ការរកឃើញដែលផ្ទុយសភាវគតិ

ការវាស់នោះគឺ AgentLeak (arXiv 2602.11510) ដែលជា benchmark សម្រាប់ privacy leakage internal-channel ក្នុង multi-agent LLM system។ ការដាក់ framing ទើបធ្វើឱ្យវាសំខាន់៖ privacy benchmark បច្ចុប្បន្នជា output-only — ពួកវាពិនិត្យចម្លើយចុងក្រោយដែលប្រព័ន្ធត្រឡប់ទៅឱ្យ user។ ប៉ុន្តែ “ពេល agent coordinate លើ task ទិន្នន័យ sensitive អាចឆ្លងកាត់ inter-agent message, shared memory, និង tool argument ដែលជា pathway ទាំងអស់ដែល final-output audit ជាធម្មតាមិនពិនិត្យ”។ ដូច្នេះ AgentLeak instrument communication pathway ប្រាំពីរ ដែលពាក់ព័ន្ធ privacy ហើយ run ពួកវានៅ scale៖ scenario 1,000 ឆ្លងកាត់ domain សុខាភិបាល ហិរញ្ញវត្ថុ ច្បាប់ និងសាជីវកម្ម production model ប្រាំ (GPT-4o, GPT-4o-mini, Claude 3.5 Sonnet, Mistral Large, និង Llama 3.3 70B) និង execution trace ដែលបាន validate 4,979។

លទ្ធផលក្បាលមានពីរផ្នែកដែលចង្អុលទៅទិសផ្ទុយគ្នា ហើយអ្នកត្រូវកាន់ទាំងពីរក្នុងពេលតែមួយ៖

• Multi-agent បន្ថយ final-output leakage។ វាស់នៅ output (channel ដែលក្រដាសហៅថា C1) ការបំបែកទៅ coordinator-worker setup លេចទិន្នន័យ sensitive 27.2% នៃពេលវេលា ធៀបនឹង 43.2% សម្រាប់ agent តែមួយ។ សភាវគតិត្រឹមត្រូវ៖ ចម្លើយចុងក្រោយពិតជាស្អាតជាងមែន។
• Multi-agent លើក total system exposure។ បូករួមឆ្លងកាត់ channel exposure ឡើងដល់ 68.9%។ decomposition ដូចគ្នាដែលជូត output បានបើក channel internal មួយឈុត ដែលលេចច្រើនជាង output ដែលធ្លាប់លេច។

ដូច្នេះ architecture ដែលអ្នកយកមកប្រើដើម្បីបន្ថយ risk បានបន្ថយ risk ដែល មើលឃើញ ហើយបង្កើន risk សរុប។ អ្នកបាន optimize លេខតែមួយដែលអ្នកកំពុងមើល ហើយវាជាលេខខុស។

កន្លែងដែល leak រស់នៅពិតប្រាកដ

internal channel មិនមែនជា rounding error ទេ — វាជាព្រឹត្តិការណ៍ចម្បង។ AgentLeak រកឃើញថា inter-agent message (channel C2) លេចទិន្នន័យ sensitive នៅ 68.8% ធៀបនឹង 27.2% សម្រាប់ final output។ នោះមិនមែនអាក្រក់បន្តិចទេ វាអាក្រក់ជាងពីរដងកន្លះ ហើយវាកំពុងកើតក្នុងផ្នែកនៃប្រព័ន្ធដែល user មិនដែលឃើញ ហើយ auditor មិនដែលពិនិត្យ។

ពីគម្លាតនោះមកលេខដែលគួរដកស្រង់បំផុតក្នុងក្រដាស ហើយជាលេខដែលគួរដាក់លើ slide៖ output-only audit ខកខាន violation 41.7%។ បើ privacy review របស់អ្នកមាននៅត្រឹមការមើលអ្វីដែលប្រព័ន្ធប្រាប់ user — ដែលជាអ្វីដែល privacy review ស្ទើរគ្រប់ការមាន — អ្នកខ្វាក់ចំពោះប្រហែលពីរនៃរាល់ leak ប្រាំ។ ហើយនេះមិនមែនជា quirk នៃ model តែមួយ ឬ domain តែមួយទេ។ ក្រដាសរាយការណ៍ថា pattern C2 ≥ C1 ទ្រទ្រង់ដោយជាប់លាប់ឆ្លងកាត់ model ទាំងប្រាំ និង domain ទាំងបួន៖ inter-agent leakage ស្មើ ឬលើស output leakage នៅគ្រប់កន្លែងដែលពួកគេមើល។

យន្តការមាន intuitive ពេលអ្នកឃើញវា។ ដើម្បីប្រគល់ការងារឱ្យបានល្អ coordinator ទំនងផ្ញើ context បន្ត — “នេះជា record ពេញលេញរបស់អ្នកជំងឺ រកមើល billing code,” “នេះជា contract ស្រង់ភាគី”។ worker ត្រូវការតែ field ដែលពាក់ព័ន្ធ billing ឬ ឈ្មោះភាគី ប៉ុន្តែវាបានទទួលរបស់ទាំងមូល ព្រោះការផ្ញើ context ច្រើនជាងជា path នៃភាពធន់ទាបបំផុតសម្រាប់ការទទួលចម្លើយល្អ។ រាល់ hand-off ជាឱកាសមួយដើម្បី over-share ហើយ multi-agent system ផ្គុំឡើងពី hand-off។ ចម្លើយចុងក្រោយអាចស្អាតឥតខ្ចោះ ខណៈការសន្ទនាដែលផលិតវាប្រឡាក់ដោយ PII។

ហេតុអ្វី output-only auditing តែងតែនឹងបរាជ័យ

វាមានទំនោរចង់ចាត់ទុកនេះជា bug ដែលត្រូវ patch ប៉ុន្តែវាយល់បានល្អជាងថាជា auditing category error។ output-only audit វាស់ផ្ទៃខុស — វាពិនិត្យផលិតផល ហើយមិនអើពើ supply chain។ ដរាបណាប្រព័ន្ធជា model តែមួយឆ្លើយ prompt តែមួយ output និង process ស្ទើរជារបស់ដូចគ្នា ដូច្នេះការ audit output ជា proxy ល្អ។ វិនាទីដែលប្រព័ន្ធក្លាយជា network នៃ agent ដែលផ្ញើ message proxy នោះបាក់ ព្រោះការផ្លាស់ទីទិន្នន័យ sensitive ភាគច្រើនឥឡូវកើតក្នុង transit រវាង component មិនមែននៅច្រកចេញទេ។

ការសន្និដ្ឋានផ្ទាល់របស់ AgentLeak ច្បាស់លាស់អំពីនេះ៖ privacy risk ក្នុង multi-agent system “ត្រូវបាន shape យ៉ាងខ្លាំងដោយ architectural coordination channel ជាជាង final-output behavior តែឯង”។ risk ជា property នៃ wiring មិនមែន ចម្លើយ។ ហើយមាន corollary មិនស្រួលចិត្តមួយសម្រាប់នរណាដែលឈោងទៅ multi-agent ដោយផ្នែកដើម្បីមើលទៅទទួលខុសត្រូវជាង៖ final output ស្អាតជាងអាចបង្កើតការយល់ឃើញខុសអំពីសុវត្ថិភាព ដែលខ្លួនវាគ្រោះថ្នាក់ ព្រោះវាជាភស្តុតាងពី channel ដែលផ្ដល់ព័ត៌មានតិចបំផុតអំពី total exposure។

នេះស្របជាមួយ theme ដែលយើងតែងតែប៉ះ។ ការបរាជ័យដែលសំខាន់ក្នុង agentic system កាន់តែ នៅចន្លោះ component មិនមែនក្នុងណាមួយ — coordination, protocol, hand-off។ វាជាកន្លែងដូចគ្នាដែលបញ្ហា reliability រស់នៅក្នុង ហេតុអ្វី multi-agent system បរាជ័យ ហើយឥឡូវវាជាកន្លែងដែលបញ្ហា privacy រស់នៅដែរ។ Decomposition មិនលុប risk ទេ។ វាប្ដូរទីតាំង risk ចូលក្នុង seam ដែលវាមើលឃើញពិបាកជាង។

អ្វីដែលអ្នកត្រូវ instrument ពិតប្រាកដ

បើ leak នៅក្នុង channel នោះការជួសជុលចាប់ផ្ដើមដោយធ្វើ channel ឱ្យមើលឃើញ។ អ្នកមិនអាច govern data minimization ឆ្លងកាត់ប្រព័ន្ធដែលអ្នកមិន log traffic internal របស់វាបានទេ។ នេះជា privacy case សម្រាប់អំណះអំណាងដែលយើងបានធ្វើក្នុង observability សម្រាប់ agent៖ unit ដែលអ្នកត្រូវចាប់យកមិនមែនគ្រាន់តែ response ចុងក្រោយទេ ប៉ុន្តែរាល់ inter-agent message រាល់ shared-memory write រាល់ tool-call argument — pathway ប្រាំពីរៗដែល AgentLeak ត្រូវ instrument មុនពេលវាសូម្បីតែអាច រក leak។ បើ benchmark ត្រូវការ wire up internal channel ដើម្បីវាស់ exposure production system ត្រូវការ wiring ដូចគ្នាដើម្បីគ្រប់គ្រងវា។

ជាក់ស្ដែង ការចាត់ទុក channel ជា first-class មានន័យបីយ៉ាង។ Log hand-off មិនមែនគ្រាន់តែ output ដើម្បីឱ្យ audit អាចឃើញ C2 ពិតប្រាកដ។ Minimize នៅរាល់ edge មិនមែនគ្រាន់តែនៅច្រកចេញ៖ worker គួរទទួល field ដែល task របស់វាត្រូវការ មិនមែន record ទាំងមូល — ផ្ញើ billing code មិនមែន chart។ ហើយ scope អ្វីដែល agent នីមួយៗអាចអាន ដើម្បីឱ្យ over-sharing ត្រូវបាន bound ដោយការសាងសង់ ជាជាងដោយការវិនិច្ឆ័យល្អរបស់ coordinator នៅពេលនោះ។ គ្មានរបស់ណាក្នុងនេះ exotic ទេ វាជា least-privilege discipline ដូចគ្នាដែលធ្វើឱ្យ confidential on-device execution ជាការធានាពិតប្រាកដ ជាជាង slogan។ ភាពខុសគ្នាគ្រាន់តែជាការសម្រេចថា internal channel ជាផ្នែកនៃ privacy boundary របស់ប្រព័ន្ធ — ព្រោះ AgentLeak ទើបបង្ហាញ ដោយលេខ ថាវាជាផ្នែកលេចធ្លោ។

ហេតុអ្វីនេះអនុគ្រោះអាស៊ីអាគ្នេយ៍

មានការអាននៅកម្រិតតំបន់នៃរឿងនេះ ដែលគួរឱ្យលើកទឹកចិត្តពិតប្រាកដ។ បញ្ហា privacy ដែលសំខាន់បំផុតនៅទីនេះប្រមូលផ្ដុំក្នុង domain ដែល AgentLeak សាកល្បងពិតប្រាកដ — សុខាភិបាល ហិរញ្ញវត្ថុ ច្បាប់ រដ្ឋាភិបាល — កន្លែងដែលទិន្នន័យត្រូវ regulate ជាប់ residency និង sensitive ខាងនយោបាយ។ ការទាក់ទាញ ពេល agent system កាន់តែមានសមត្ថភាព គឺ wire up multi-agent pipeline ស្មុគស្មាញ ហើយជឿថា output ដែលជូតមានន័យថា compliance។ AgentLeak ជាភស្តុតាងថាការជឿនេះដាក់ខុសកន្លែង ហើយស្ថាប័នដែល internalize វាមុនគេនឹងសាង system ដែលការពារបានជាងស្ថាប័នដែលរៀនមេរៀននោះតាមផ្លូវថ្លៃ។

ហើយការងារដែលនេះបង្កប់ ម្ដងទៀត ធ្ងន់ខាងវិនិច្ឆ័យ និងស្រាលខាងដើមទុន។ ការ instrument inter-agent channel ការរចនា data minimization រាល់ edge និងការ audit seam ជាជាងផ្ទៃ ជា engineering discipline មិនមែន compute budget។ វាផ្ដល់រង្វាន់ដល់ក្រុមដែលយល់ domain ដែលត្រូវ regulate ជាក់លាក់មួយជ្រៅគ្រប់គ្រាន់ដើម្បីដឹងថា field ណាមិនគួរឆ្លងកាត់ hand-off ណា — ដែលជាប្រភេទចំណេះដឹងក្នុងស្រុក និងតាម context ដែលក្រុមនៅជិតធនាគារកម្ពុជា ឬប្រព័ន្ធសុខាភិបាលខេត្តមាន ឯ frontier lab ឆ្ងាយមិនមាន។ frontier model នៅកណ្ដាលជា commodity ឯ wiring ដែលត្រឹមត្រូវខាង privacy ជុំវិញវា ដែល audit នៅ channel ជាផ្នែកដែលការពារបាន។ នោះជា layer ដែលគួរកាន់កាប់ ហើយ AgentLeak ទើបគូស map នៃកន្លែងដែលត្រូវមើល។

output ស្អាតមិនដែលជារឿងទាំងមូលទេ។ leak នៅចន្លោះ agent — ហើយឥឡូវយើងមានលេខដើម្បីបញ្ជាក់វា។

បើ agent system របស់អ្នកដោះស្រាយទិន្នន័យដែលត្រូវ regulate ហើយអ្នកធ្លាប់តែ audit output របស់វា — តោះនិយាយគ្នា។