localhost؟خلني أشرح لك مثال شائع. الـ agent يبني لك صفحة أو تطبيق ويشغله على جهازك، ويعطيك عنوان اسمه localhost — ومعناه حرفيًا: جهازك نفسه.
عشان كذا ما أحد غيرك يشوف اللي بنيته. وتخيل الجهاز عمارة، والـ port هو رقم الشقة اللي يشتغل فيها البرنامج.
طيب، تبي تورّي أحد الصفحة. هنا تدخل أدوات الـ tunnel. أشهرها الحين Cloudflare Quick Tunnel: أمر واحد، بدون حساب، ويعطيك رابط عام.
الفكرة إن جهازك ما يفتح باب لأحد، بل هو اللي يتصل للخارج بشركة وسيطة ويخلي الخط مفتوح:
مثل مكتب استقبال: الزوار يكلمون الاستقبال، والاستقبال يوصلهم لك.
الأداة موجودة من 2021، لكنها رجعت للواجهة في سبتمبر 2026 لما Cloudflare سوّت لها صفحة تعريف جديدة، وصارت أدوات الـ agents تستخدمها لمشاركة اللي تسويه.
وهنا الخطر — وهو مو في الـ tunnel نفسه.
الـ tunnel ما يفتح جهازك كله؛ يكشف بس التطبيق اللي وجهته له. لكن هالتطبيق صار قدام الإنترنت كله، وهو ما انبنى لكذا.
الـ agent غالبًا يعتبر إن جهازك بيئة آمنة، فما يحط تسجيل دخول ولا حماية، لأن الكود مكتوب على فكرة إن اللي يستخدمه أنت وبس. وأي أحد عنده الرابط — وحتى لو ما شاركته أنت — يقدر يجرب عليه.
وفيه نقطة أدق: التطبيق ما يقدر يفرق بين الزائر الغريب وبينك، لأن كل الطلبات توصله عن طريق جهازك نفسه. فأي كود يقول «الطلبات اللي من نفس الجهاز موثوقة» يصير يثق بالإنترنت كله.
لو سمعت عن هروب الحاويات (container escape) في Docker فالفكرة قريبة، لكن هنا أسوأ:
| Docker | تطبيق على جهازك مباشرة | |
|---|---|---|
| العزل | فيه جدار عزل (الحاوية) | ما فيه جدار أصلاً |
| ماذا يحتاج المهاجم؟ | يكسر العزل عشان يوصل للجهاز | يدخل التطبيق ويشتغل بصلاحياتك أنت |
| ماذا يصل إليه؟ | بعد كسر العزل فقط | ملفاتك، مفاتيح SSH، كلمات السر، حسابات الكلاود، وشبكة بيتك |
وأخطر منها أدوات الـ agents نفسها: كثير منها يقدر يشغّل أوامر ويقرأ ملفات. فلو انكشفت لغيرك، ما يشوف صفحة بس — يستعمل صلاحياتها.
هذا مو تلقائي. لازم تجتمع شروط:
وموقع ثابت يعرض ملفات بس أقل خطرًا بكثير من تطبيق ديناميكي له backend.
وأنا ما وجدت حالات موثقة لهالسلسلة بالذات من تطبيقات بناها agent — فأنا أتكلم عن خطر ناتج من طريقة التصميم، مو عن موجة هجمات شفتها.
لأنه مبني من الأساس عشان يستقبل الناس:
جهازك فيه بريدك وصورك وكلمات السر — وما هو مصمم يستقبل الغرباء.
The paper is AuditBench (Anand et al., 2026). What stood out to me wasn't the leaderboard of which model scored highest — it's how they built the benchmark.
They didn't invent arbitrary tasks. They grounded everything in four things incident-response teams actually do:
Then, for three of those, they tied the scenarios directly to MITRE ATT&CK techniques, executed them for real using Atomic Red Team on live VMs, and captured the resulting telemetry through auditd and ProcMon.
So the ground truth isn't synthetic — it's "we ran this technique, here's what it actually looked like in the logs."
That framework-to-telemetry pipeline is the part I keep coming back to. It's a specific, hard problem: taking a behavior described at the ATT&CK level and turning it into something observable and gradable in raw system data.
That's a step I think about a lot in my own work right now, which has been moving toward using ATT&CK-style frameworks to reason about behavior — including in settings where LLMs are involved on either side of that reasoning, not just as the thing being evaluated. I'm not sharing specifics on that yet, but this paper is a useful reference point for anyone thinking about the same gap: getting from "described attacker behavior" to "something a model can actually be evaluated against."
The other thing worth flagging: AuditBench also tests whether raw logs are even the right input format for an LLM, comparing them against a more compact, provenance-based representation. That's a systems question as much as a model question — and it's one that gets skipped in a lot of "let's just throw logs at an LLM" work.
Anand et al., Benchmarking and Exploring the Capabilities of LLMs for Attack Investigations, arXiv:2606.10281, 2026.
→ Read on arXiv · PDF
]]>