जब सही security controls भी लीक करते हैं: AI agents पर CONTINUITY का सबक

7 सितंबर 2026 · PlayCISO

आप एक provenance tracker, एक authorization layer, एक policy engine, protocol adapters और execution guards इकट्ठा कर सकते हैं — हर एक अकेले में सही — और फिर भी ऐसा system भेज सकते हैं जो किसी AI agent को वह काम करने दे जिसकी उसे कभी अनुमति नहीं थी। यही CONTINUITY नामक research framework की असहज खोज है, और यही बताता है कि "हमारे पास सारे controls हैं" का मतलब "हम सुरक्षित हैं" नहीं होता।

खामी जोड़ों में छिपी होती है

किसी agent की कार्रवाई एक ही जगह नहीं होती। वह यात्रा करती है: एक instruction आता है, provenance टैग होती है, authorization जाँची जाती है, policy लागू होती है, एक adapter उसका अनुवाद करता है, और अंत में असली दुनिया में कुछ execute होता है। हर component boundary पर वह security-critical context — कार्रवाई का कौन और क्यों — खो या बिगड़ सकता है। लेखक इसे security-context discontinuity कहते हैं।

हर control अकेले में अपने ही tests पास कर सकता है। कमज़ोरी किसी एक box के अंदर नहीं, बल्कि उनके बीच के जोड़ों में रहती है।

Context टूटने के चार तरीके

  • Dropped: कौन और क्यों गायब हो जाते हैं, और आगे का component बिना देखे मंज़ूरी दे देता है।
  • Widened: एक सीमित दायरे वाली अनुमति को उससे ज़्यादा व्यापक मान लिया जाता है।
  • Rebound: कार्रवाई अधिकृत target की जगह किसी और target से जोड़ दी जाती है।
  • Reinterpreted: layers के बीच अनुवाद में request का अर्थ बदल जाता है।

समाधान: context जो कार्रवाई के साथ चले

CONTINUITY composition को एक प्रमुख समस्या मानता है। यह हर component को assume-guarantee contract से model करता है और हर transition पर एक authenticated security context ले जाता है — signed root grants, provenance commitments, role-bound transition receipts और effect-bound execution permits के ज़रिए। जो गुण यह देता है वह है consequence integrity: कोई भी असली बाहरी असर तब तक नहीं होता जब तक उसके पीछे एक पूर्ण, सत्यापन-योग्य और वर्तमान authorization की श्रृंखला न हो।

आँकड़े मायने रखते हैं

128 fault classes में फैली 2,560 parameterized attack instances पर, पूर्ण configuration ने एक भी नुकसानदेह बाहरी असर नहीं किया, सभी 700 benign tasks पूरे किए, और सभी 200 अस्पष्ट मामलों को अनुमान लगाने के बजाय एक इंसान तक escalate किया। जो control सब कुछ रोक दे वह बेकार है; इसने असली काम को गुज़रने दिया।

एक security लीडर के लिए सबक

इस सबक को अपनाने के लिए आपको CONTINUITY लागू करने की ज़रूरत नहीं: controls को अलग-अलग आँकना बंद करें और instruction से लेकर effect तक का पूरा रास्ता जाँचें। किसी agent को अपने systems से जोड़ने से पहले, model का जोखिम model risk scanner से मापें और हर connector को MCP server risk जाँच से govern करें। सही controls का ढेर सुरक्षित system नहीं है: security उनके बीच के contracts में रहती है।

अक्सर पूछे जाने वाले प्रश्न

Security-context discontinuity क्या है?

यह वह failure mode है जिससे CONTINUITY को नाम मिला: जब किसी agent की कार्रवाई component boundaries पार करती है, तो security-critical context dropped, widened, किसी और target पर rebound, या reinterpreted हो सकता है। हर control अलग से सही हो सकता है, फिर भी पूरा system एक नुकसानदेह कार्रवाई की अनुमति दे देता है।

यह CISOs के लिए क्यों मायने रखता है?

ज़्यादातर agent security programs अच्छे components जोड़ते हैं और मान लेते हैं कि योग सुरक्षित है। खामियाँ जोड़ों में रहती हैं। किसी agent platform का मूल्यांकन करते समय पूछें कि boundaries के पार security context कैसे संरक्षित रहता है, न कि सिर्फ़ यह कि हर control अकेले काम करता है या नहीं।

क्या इसने असली काम रोक दिया?

नहीं। पूर्ण configuration ने सभी नुकसानदेह असर टाले, सभी 700 benign tasks पूरे किए, और 200 अस्पष्ट मामलों को एक व्यक्ति तक escalate किया। असली काम गुज़रने देना और संदिग्ध को आगे भेजना ही एक वास्तव में deploy होने योग्य control का रूप है।

Read the full English version →सभी टूल देखें
जब सही security controls भी लीक करते हैं: AI agents पर CONTINUITY का सबक · PlayCISO · PlayCISO