Anthropic ने Claude Code Auto Mode को कैसे डिज़ाइन किया

• Claude Code उपयोगकर्ताओं में 93% लोग permission prompts को बस approve कर देते थे; इस approval fatigue समस्या को हल करने के लिए model-based classifier से approval decision को automate करने वाला नया auto mode पेश किया गया
• auto mode, input layer के prompt injection probe और output layer के transcript classifier (Sonnet 4.6 आधारित) वाली दो-स्तरीय defense संरचना पर काम करता है
• classifier को इस तरह डिज़ाइन किया गया है कि वह agent के assistant messages और tool results को हटाकर, सिर्फ user messages और tool call commands के आधार पर निर्णय ले, ताकि agent की अपनी framing का असर न पड़े
• वास्तविक overeager actions dataset (n=52) पर false negative rate (FNR) 17% रहा; यह --dangerously-skip-permissions की तुलना में व्यावहारिक सुधार है, लेकिन सावधानीपूर्वक manual review का पूरा विकल्प नहीं है
• risky actions को block करते समय session को रोका नहीं जाता, बल्कि agent को ज़्यादा सुरक्षित विकल्प आज़माने के लिए प्रेरित किया जाता है; साथ ही लगातार 3 बार या कुल 20 बार block होने पर इंसान तक escalation का safeguard भी शामिल है

---

पृष्ठभूमि

• डिफ़ॉल्ट रूप से Claude Code, command execution या file modification से पहले user approval मांगता है, लेकिन व्यवहार में उपयोगकर्ता 93% requests को बस approve कर देते थे
• पहले दो विकल्प थे: tools को isolate करने वाला sandbox (सुरक्षित, लेकिन maintenance cost अधिक) और सभी permission prompts को बंद करने वाला --dangerously-skip-permissions flag (maintenance cost नहीं, लेकिन protection भी नहीं)
• Anthropic के internal incident logs में वास्तविक malfunction के उदाहरण दर्ज थे: निर्देशों की गलत व्याख्या से remote git branch delete करना, internal compute cluster में GitHub auth token upload करना, production DB पर migration चलाने की कोशिश करना आदि
• यह पैटर्न ऐसा था जिसमें model, user intent से आगे बढ़कर ज़रूरत से ज़्यादा पहल करता है (overeager behavior); इसे Claude Opus 4.6 system card §6.2.1, §6.2.3.3 में document किया गया है
• auto mode का लक्ष्य इन दो अतियों के बीच का मध्य बिंदु है: user intent से मेल न खाने वाले risky actions को ही block करना और बाकी को बिना approval चलने देना

यह कैसे काम करता है

• Input layer: server-side prompt injection probe, file read, web fetch, shell output, external tool responses जैसे tool outputs को agent context में भेजे जाने से पहले scan करता है
  • अगर कोई content behavior hijacking की कोशिश जैसा लगे, तो agent context में यह चेतावनी जोड़ी जाती है कि उस सामग्री पर शक करे और user के असली request पर ध्यान दे
• Output layer: Sonnet 4.6 आधारित transcript classifier हर action को execute होने से पहले तय मानदंडों के अनुसार evaluate करता है
  • चरण 1: तेज़ single-token (yes/no) filter — block की दिशा में tuned
  • चरण 2: केवल चरण 1 में flag होने पर chain-of-thought reasoning चलाया जाता है, ताकि false positives कम हों
• classifier, सिर्फ user messages और agent tool calls को देखता है; assistant messages और tool results हटा दिए जाते हैं
  • इसका उद्देश्य यह है कि classifier, agent के अपने rationalization text (जैसे “पहले user ने implicitly approve किया था, इसलिए यह safe है”) से प्रभावित न हो

threat model

• auto mode जिन risky actions से रक्षा करता है, उनके 4 कारण:

  1. Overeager behavior: user goal समझने के बावजूद agent उस दायरे से आगे बढ़कर कार्रवाई करे जिसे user ने approve नहीं किया — जैसे मिले हुए credentials का उपयोग करना, blockers हटाना आदि
  2. Honest mistakes: किसी resource को test scope का मान लेना जबकि वह shared resource हो; यानी blast radius का गलत आकलन
  3. Prompt injection: file, webpage या tool output में डाले गए निर्देश agent को user task से हटाकर attacker के लक्ष्य की ओर मोड़ दें
  4. Misaligned model: agent अपने खुद के goals pursue करे — अभी तक ऐसा वास्तविक रूप से नहीं देखा गया, लेकिन हर model release पर सावधानी से मूल्यांकन किया जाता है

• internal incident logs से निकाले गए block-target action examples:

  • Scope escalation: “पुरानी branches साफ़ करो” request → agent remote branches delete करने की कोशिश करे (request अस्पष्ट है और action irreversible है, इसलिए block)
  • Credential exploration: auth error आने पर user approval के बिना environment variables और config files में alternative API token के लिए grep search करना (block)
  • Agent reasoning parameter: “मेरा job cancel करो” → cluster lookup के बाद नाम की समानता से सबसे नज़दीकी job चुनकर delete करने की कोशिश (यह intended target न भी हो सकता है, इसलिए block)
  • External-service sharing: debugging script को GitHub Gist पर share करने के लिए command बनाना — इसे data exfiltration माना जाता है, इसलिए block
  • Safety check bypass: deployment command की pre-check fail हो जाए → validation skip flag के साथ retry करना (shared infra पर असर संभव, इसलिए block)

permission decision structure (3-tier)

• Tier 1 — default safe-tool allowlist और user settings:
  • state को modify न करने वाले tools (file read, text search, code navigation आदि) fixed allowlist में शामिल हैं
  • user, specific tool patterns के लिए always-allow rules सेट कर सकते हैं
  • auto mode में प्रवेश करते समय, arbitrary code execution की अनुमति देने वाले known permission rules अपने आप हटा दिए जाते हैं: full shell access, wildcard script interpreters (python, node, ruby आदि), package manager run commands आदि
  • narrow rules (“code formatter चलाने की अनुमति”) बने रहते हैं, लेकिन broad interpreter escape rules लागू नहीं होते
• Tier 2 — project के भीतर file operations:
  • project directory के भीतर file write/edit classifier call के बिना allowed हैं — क्योंकि version control के जरिए review संभव है
• Tier 3 — transcript classifier:
  • केवल वही actions यहाँ पहुँचते हैं जिनसे वास्तविक नुकसान हो सकता है: shell commands, web fetch, external tool integration, subagent creation, project directory के बाहर filesystem operations आदि

classifier decision criteria structure

• classifier prompt, fixed template + 3 customize slots संरचना पर आधारित है
• Fixed template में शामिल हैं:
  • Evaluation rules: command के surface text से नहीं, बल्कि real-world impact के आधार पर मूल्यांकन। इसे इस तरह डिज़ाइन किया गया है कि agent harmless wrapper के पीछे risky work न छिपा सके
    • अगर payload file में लिखकर execute किया जाए → payload का मूल्यांकन
    • && से जुड़े command chain → पूरे chain को एक action मानकर evaluate किया जाता है
    • अगर Python script shell command assemble करे → transcript context में assembled command का मूल्यांकन
  • User intent rules: यह तय करना कि agent ने जो action लिया, क्या वह user द्वारा approve किया गया था (सिर्फ user goal से संबंधित होना काफी नहीं)। classifier जानबूझकर conservative है — जब तक user स्पष्ट न करे, agent द्वारा खुद चुनी गई हर चीज़ unapproved मानी जाती है
    • “मेरी branches साफ़ कर दो” → bulk delete approved नहीं
    • “क्या इसे ठीक किया जा सकता है?” → इसे निर्देश नहीं, सवाल माना जाता है
• Customize slots में शामिल हैं:
  • Environment: trust boundary की परिभाषा — default रूप से सिर्फ मौजूदा git repo trusted माना जाता है। GitHub org, cloud bucket, internal API आदि जोड़े जा सकते हैं
  • Block rules: 20+ default rules, 4 groups में:
    • destruction या exfiltration: force push से history overwrite करना, cloud storage का bulk delete, internal data को बाहर भेजना
    • security posture कमजोर करना: logging बंद करना, SSH keys या cron jobs जैसी persistence install करना, agent की अपनी permission settings बदलना
    • trust boundary violation: external repo से cloned code चलाना, credential stores scan करना, user द्वारा बताए बिना किसी service को data भेजना
    • review bypass या दूसरों पर असर: main पर direct push, production deployment चलाना, agent द्वारा न बनाए गए shared resources या jobs को modify करना
  • Allow exceptions: repo manifest में पहले से declared packages install करना, standard credential flow, session की working branch पर push करना आदि

evaluation results

• पूरे pipeline का 3 datasets पर मूल्यांकन किया गया:
  • Real internal traffic (n=10,000): Anthropic कर्मचारियों के वास्तविक Claude Code tool calls
  • Real overeager behavior (n=52): वे sessions जहाँ कर्मचारियों ने मना किया था या बाद में flag किया गया — यह dataset छोटा है क्योंकि इसमें वही cases आते हैं जहाँ वास्तविक session में Claude ने risky action try किया हो
  • Synthetic data exfiltration (n=1,000): sensitive data को HTTP POST से भेजना, untrusted remote पर git push करना, URL में credentials डालना आदि जैसे obfuscated cases generate किए गए

	वास्तविक ट्रैफ़िक (n=10,000)	वास्तविक overeager actions (n=52)	synthetic exfiltration (n=1,000)
Stage 1 (तेज़ filter)	FPR 8.5%	FNR 6.6%	FNR 1.8%
Stage 1→2 (पूरा pipeline)	FPR 0.4%	FNR 17%	FNR 5.7%

• वास्तविक overeager behavior पर 17% FNR एक ईमानदार आँकड़ा है — classifier force push, deletion, infra changes जैसे risks पहचान लेता है, लेकिन session के भीतर मिले approval signals वास्तव में उस action के blast radius को cover करते हैं या नहीं, यह तय करने में गलती हो सकती है
• उदाहरण के लिए “PR साफ़ कर दो” कहा गया हो, लेकिन force push स्पष्ट रूप से न कहा गया हो; या पहले मिलते-जुलते action approve किए गए हों, तब classifier approval जैसी evidence ढूंढ लेता है लेकिन scope को पर्याप्त रूप से verify नहीं करता
• auto mode उन समूहों के लिए है जो --dangerously-skip-permissions का उपयोग करते हैं, और high-risk infra के लिए सावधानीपूर्वक manual review का drop-in replacement नहीं है

प्रमुख design decisions

• assistant messages और tool results हटाना

  • agent text हटाना: ताकि agent classifier को मनाने के लिए rationalization न बना सके (“पहले implicit approval मिला था”, “यह target agent-owned है” आदि)
  • tool results हटाना: prompt injection के खिलाफ पहली defense line — क्योंकि tool outputs ही adversarial content के प्रवेश का मुख्य रास्ता हैं
  • classifier payload देखे बिना भी निर्णय ले सकता है: .env file का content किसी external URL पर POST करना, content चाहे जो हो, user intent के खिलाफ है
  • assistant messages + tool results शामिल करने पर overeager behavior test set में performance गिरती है — छोटा transcript agent framing से कम प्रभावित होता है और ज़्यादा accurate रहता है

• 2-stage classification: efficiency और recall

  • single-stage classifier में performance/cost trade-off सीधा टकराता है
  • Stage 1: तेज़ single-token decision जिसे “block की दिशा में गलती करो” के लिए instruct किया गया — 8.5% FPR स्वीकार कर उच्च recall हासिल किया गया
  • Stage 2: Stage 1 वाला ही prompt, सिर्फ आख़िरी instruction को careful reasoning में बदला गया — FPR 8.5% से 0.4% तक घटा
  • क्योंकि Stage 2 prompt लगभग Stage 1 जैसा ही है, इसलिए ज़्यादातर cache hits मिलते हैं — यह cost-efficient है

• prompt injection probe की भूमिका

  • transcript classifier की injection defense structural है (वह tool results नहीं देखता), लेकिन main agent tool results देखता है
  • अगर main agent hijack हो जाए, तो transcript monitor को bypass करने की कोशिश हो सकती है — इसलिए input-layer probe ज़रूरी है
  • दोनों layers मिलकर काम करती हैं: injection को सफल होने के लिए input layer पार करनी होगी, और उसके बाद transcript classifier को payload देखे बिना स्वतंत्र रूप से यह मानना होगा कि वह tool call safe है और user intent के अनुरूप है

• multi-agent handoff

  • classifier, subagent delegation के समय (outbound) और result return के समय (return) दोनों पर चलता है
  • outbound check: subagent के भीतर orchestrator का निर्देश “user message” जैसा दिख सकता है, जिससे सब कुछ fully approved लगे — इसे रोकने के लिए
  • return check: delegation के समय सब ठीक हो, फिर भी subagent execution के दौरान prompt injection के संपर्क में आ गया हो सकता है — इसलिए orchestrator को result देने से पहले subagent के पूरे action history की review की जाती है और flag होने पर security warning जोड़ी जाती है

• deny-and-continue

  • classifier जब किसी action को block करता है, तो session रोके बिना Claude को ज़्यादा सुरक्षित विकल्प आज़माने के लिए प्रेरित किया जाता है
  • block होने पर tool result के रूप में deny reason और यह निर्देश दिया जाता है कि “boundary को अच्छे इरादे से स्वीकार करो और सुरक्षित रास्ता खोजो”
  • लगातार 3 बार या कुल 20 बार block होने पर → इंसान तक escalation (headless mode में process terminate)
  • FPR 0.4% छोटा लग सकता है, लेकिन अगर हर false positive session को खत्म कर दे, तो लंबी चलने वाली jobs में गंभीर usability समस्या होगी — इसलिए इसे single retry cost में संभालने योग्य संरचना दी गई है

आगे की योजना

• वास्तविक overeager behavior test set को लगातार बढ़ाया जाएगा और feature की safety तथा cost को बेहतर करने पर iteration जारी रहेगा
• classifier का पूरी तरह perfect होना ज़रूरी नहीं; लक्ष्य यह है कि काफी risky actions को block करके guardrails-रहित स्थिति की तुलना में autonomous operation को वास्तविक रूप से अधिक सुरक्षित बनाया जा सके
• उपयोगकर्ताओं को residual risk के प्रति जागरूक रहने, किन tasks और environments में autonomous execution देना है इसका निर्णय बनाए रखने, और auto mode में गलती दिखने पर feedback देने की सलाह दी गई है