Coding agent मधील prompt injection: धोके आणि बचाव

कोडिंग agent विरुद्ध prompt injection म्हणजे काय

कोडिंग agent विरुद्ध prompt injection ची व्याख्या सोपी आहे: agent वाचतो तो मजकूर agent पाळत असलेली सूचना बनतो. Agent एखादी file, pull request comment, web page किंवा tool call चा परिणाम उघडतो. हा सर्व मजकूर तुमच्या विनंतीप्रमाणेच त्याच प्रकारच्या text म्हणून agent पर्यंत पोहोचतो. या मजकुरापैकी कोणत्याही भागावर attacker चे नियंत्रण असल्यास, attacker तुमच्या session मध्ये मजकूर लिहित असतो.

सध्या उपलब्ध असलेल्या प्रत्येक agent product मध्ये हा गुणधर्म आहे. Model ला tokens ची एकच sequence मिळते. तुमची विनंती, system prompt, file contents आणि tool results एकत्र जोडले जातात आणि त्यानंतर काय येईल याचा model अंदाज लावतो. कोणत्याही token वर privilege bit नसतो. कोणता भाग तुम्ही अधिकृत केला आहे आणि कोणता भाग अनोळखी व्यक्तीच्या README file मधून आला आहे, हे सांगणारी कोणतीही माहिती format मध्ये नसते.

हे page threat model स्पष्ट करते: server वर चालणाऱ्या agent पर्यंत attacker-controlled text कोणत्या मार्गांनी पोहोचतो, प्रत्येक टप्प्यावर attacker ला काय मिळते आणि कोणते defences लागू करण्यासाठी केलेला प्रयत्न उपयुक्त ठरतो. Agentला नेमक्या कोणत्या धोक्यापासून contain करायचे आहे हे समजल्यानंतरच आमच्या इतर guides मधील containment advice उपयुक्त ठरते.

मॉडेल मजकूर आणि सूचना वेगळ्या का करू शकत नाही

Training मदत करते, पण समस्या पूर्णपणे सुटत नाही. सध्याच्या मॉडेलना retrieved मजकुराकडे संशयाने पाहण्याचे training दिले जाते आणि ते अनेक उघड प्रयत्न नाकारतात. मात्र refusal हा नियम नसून probability असतो. आक्रमणकर्ता मजकूर नव्या पद्धतीने मांडू शकतो, पुन्हा प्रयत्न करू शकतो आणि तो अशा format मध्ये लपवू शकतो ज्याचा विचार आधी केला गेला नव्हता. तो किती वेगवेगळ्या wording वापरू शकतो यावर कोणतीही मर्यादा नसते.

OWASP GenAI project याची नोंद LLM01:2025 Prompt Injection म्हणून करते आणि त्याचे दोन प्रकार करते. Direct injection म्हणजे वापरकर्त्याच्या स्वतःच्या prompt मुळे मॉडेलच्या वर्तनात बदल होणे. Indirect injection म्हणजे website किंवा file सारख्या बाह्य content वर प्रक्रिया करताना मॉडेलच्या वर्तनात बदल होणे. Server वर indirect injection महत्त्वाचे आहे, कारण agent तुम्ही type करता त्यापेक्षा कितीतरी अधिक मजकूर वाचतो.

पहिला systematic study Greshake आणि त्यांच्या सहकाऱ्यांचा Not what you've signed up for (2023) हा आहे. त्यांचा निष्कर्ष लक्षात ठेवण्यासारखा आहे: एखादे application retrieved मजकूर अशा मॉडेलला देते ज्याला tools call करता येतात, तेव्हा त्या मजकुरावर प्रक्रिया करणे हे जवळजवळ arbitrary code execution सारखे असते.

वाचनामुळे breach होण्याची अट

hostile मजकूर वाचणे हे स्वतःहून नुकसानकारक नसते. त्या नुकसानाला मशीनबाहेर जाण्याचा मार्ग उपलब्ध असावा लागतो.

Simon Willison यांनी जून 2025 मध्ये या संयोगाला lethal trifecta असे नाव दिले. एखाद्या agent कडे private data असेल, तो untrusted content च्या संपर्कात असेल आणि data बाहेर पाठवू शकत असेल, तर त्याला पहिली गोष्ट तिसऱ्या मार्गाने बाहेर पाठवण्यास प्रवृत्त करता येते.

तुमच्या VPS वरील coding agent कडे पहिल्याच दिवसापासून हे सर्व असते. Private data म्हणजे तुमचा source code, तुमची .env file, तुमच्या SSH keys आणि तुमचा shell history. Untrusted content म्हणजे तो वाचत असलेले प्रत्येक repository, page आणि tool result. बाहेर जाण्याचे मार्ग म्हणजे git push, curl, npm publish, pull request body किंवा terminal मध्ये छापलेली आणि तुम्ही click केलेली link.

दुसरी अट काढून टाकता येत नाही, कारण untrusted text वाचणे हेच तुम्ही agent कडून करून घेता. त्यामुळे प्रत्येक व्यावहारिक defence इतर दोन अटींवर काम करते.

सर्व्हरवरील coding agent पर्यंत अविश्वसनीय मजकूर कसा पोहोचतो

Agent ज्या repository मध्ये काम करत आहे

Checkout मधील प्रत्येक file हा input असतो. Source comments, README.md, changelogs, test fixtures, vendored code आणि agent instruction files स्वतः: CLAUDE.md, AGENTS.md तसेच त्यांचे समतुल्य files. Codebase समजून घेण्यास सांगितल्यावर agent हे सर्व वाचतो, कारण तुम्ही त्यालाच तसे करण्यास सांगितलेले असते.

येथे attacker ला repository clone करून त्यावर agent चालवणाऱ्या प्रत्येक व्यक्तीपर्यंत पोहोच मिळते. Instruction files हा सर्वात थेट मार्ग असतो, कारण ती instructions म्हणून वाचली जावीत यासाठीच असतात. CLAUDE.md मध्ये चार उपयुक्त lines आणि agent ला redirect करणारी एक line जोडणारा pull request मानवी reviewer अनेकदा वरवर पाहून पुढे पाठवतो.

Issues, pull requests आणि code review comments

तुमच्या tracker मध्ये अनोळखी व्यक्ती जे काही type करू शकते, ते तुम्ही agent ला triage करण्यास सांगताच त्याच्यापर्यंत पोहोचते. May 2025 मध्ये Invariant Labs ने याच स्वरूपाचा GitHub MCP finding प्रकाशित केला. एका developer च्या agent ला एका public repository आणि private repositories वर access होता. एका attacker ने public repository मध्ये issue दाखल केला. Developer ने agent ला open issues पाहण्यास सांगितल्यावर agent ने private repository मधील contents वाचले आणि ते public बाजूच्या pull request मध्ये लिहिले.

या report मध्ये MCP server मधील code defect ऐवजी architectural problem स्पष्ट केली आहे. Agent कडे व्यापक access असलेला एक token होता, तो public inbox मधून वाचत होता आणि त्याला write करण्याची permission होती. नेहमीच्या अर्थाने काहीही misconfigured नव्हते. म्हणून उपाय scoping आहे, patching नाही.

Agent fetch करत असलेली web pages

Documentation, forum answers, vendor page किंवा search result. यांपैकी कोणत्याही ठिकाणी तुमच्यासाठी नव्हे तर agent साठी लिहिलेला मजकूर असू शकतो. HTML चे text मध्ये रूपांतर केल्यावर attacker ला अधिक जागा मिळते, कारण browser कधीही दाखवत नसलेला content देखील model पर्यंत पोहोचतो.

Agent एखादी माहिती शोधत असताना सर्वात कमी देखरेख असते. Agent ने fetch केलेल्या page चा पूर्ण मजकूर कोणीही वाचत नाही. त्या क्षणी attacker ला मजकुरावर नियंत्रण मिळते.

MCP tool output

MCP (model context protocol) हा agents ना external tools शी जोडण्याचा सर्वसाधारण मार्ग आहे. Results text म्हणून परत येतात आणि थेट context window मध्ये जातात. येथे एक नव्हे तर दोन surfaces आहेत. Tool परत करत असलेला data हा स्पष्ट surface आहे. Model ने tool कधी call करायचे हे ठरवण्यासाठी वाचलेले tool चे नाव आणि description हा दुसरा surface आहे. तुमच्या नियंत्रणात नसलेला server calls दरम्यान यांपैकी कोणताही बदलू शकतो.

एका tool च्या output मध्ये मजकूर पोहोचवणाऱ्या attacker ला agent कडे असलेल्या इतर प्रत्येक tool पर्यंत पोहोच मिळते. त्यामुळे कमी मूल्याच्या ठिकाणी केलेले injection उच्च मूल्याच्या कृतीला चालना देऊ शकते.

CI logs, build output आणि dependency metadata

npm install तुम्ही लिहिलेले नसलेल्या packages मधील text print करते. Test failure मध्ये library कडून आलेला assertion message print होतो. Continuous integration (CI) job log मध्ये third-party output च्या हजारो lines असतात. Failing build दुरुस्त करण्यास agent ला सांगितल्यावर तो हे सर्व वाचतो.

येथे attacker ला build machine पर्यंत पोहोच मिळते. त्या machine वर सामान्यतः deploy credentials आणि registry tokens असतात आणि laptop च्या तुलनेत तिच्याकडे कमी लक्ष दिले जाते.

आक्रमणकर्त्याला प्रत्यक्षात काय मिळते

चार संभाव्य परिणामांसाठी नियोजन करणे आवश्यक आहे.

क्रेडेन्शियलची चोरी. agent process जे काही वाचू शकतो ते सर्व जोखमीच्या कक्षेत येते: environment variables, ~/.aws/credentials, ~/.ssh, gh token आणि Docker config file. ती माहिती बाहेर पाठवण्यासाठी curl आवश्यक नाही. एखाद्या branch वर केलेला commit, pull request चे वर्णन, registry वर प्रकाशित केलेले package किंवा आक्रमणकर्त्याच्या नियंत्रणातील नावासाठी केलेला DNS lookup यांपैकी कोणतीही कृती डेटा त्या मशीनबाहेर पाठवू शकते.

तुम्ही मंजूर केलेले code changes. code लिहिणे हेच agent चे काम असल्यामुळे त्याच्याकडून सूक्ष्मरीत्या चुकीची ओळ लिहून घेणे हा साध्य करण्यास सर्वात सोपा परिणाम आहे. यामध्ये एखादी अतिरिक्त dependency किंवा token दुसरीकडे पाठवलेल्या log मध्ये नोंदवणारा logging call यांचा समावेश होऊ शकतो.

टिकून राहणारी उपस्थिती. एकदा लिहिलेली file model शिवायही कार्यरत राहते: .git/hooks मधील hook, package.json मधील postinstall script, shell startup file मध्ये शेवटी जोडलेली ओळ किंवा CLAUDE.md मधील अतिरिक्त ओळ. पुढील command ती चालवतो.

तुमच्या network अंतर्गत हालचाल. agent ज्या ठिकाणी चालवता, तिथेच तो कार्य करतो. त्या मशीनवरून loopback वरील database, अंतर्गत admin service, तुमच्या cloud provider ची metadata service किंवा private network वरील दुसऱ्या host पर्यंत पोहोचता येत असेल, तर agent चालवणारी कोणतीही कृतीही तिथपर्यंत पोहोचू शकते.

Auto-approve मोडमुळे अंतिम तपासणी काढली जाते

डीफॉल्ट मोडमध्ये Claude Code कमांड चालवण्यापूर्वी किंवा फाइलमध्ये बदल करण्यापूर्वी विचारतो. वरील प्रत्येक स्तर आणि प्रत्यक्ष कृती यांच्यामधील मानवी तपासणी म्हणून हा prompt काम करतो. prompt काढणारे मोड ही तपासणी काढून टाकतात.

bypassPermissions बाबत documentation स्पष्ट आहे: Claude Code मुळे नुकसान होऊ शकत नाही अशा containers किंवा VMs सारख्या isolated environments मध्येच त्याचा वापर करा. Auto mode अधिक नियंत्रित आहे. तो background safety checks सह tool calls आपोआप मंजूर करतो आणि कृती तुमच्या विनंतीशी सुसंगत आहेत का ते तपासतो. या checks मुळे अनेक समस्या आढळतात. तरीही ते model output बद्दल model चा निर्णय असतात. त्यामुळे त्यांना boundary न मानता filter म्हणून वापरा.

Administrator दोन्हीही काढू शकतो. settings file मध्ये permissions.disableBypassPermissionsMode किंवा permissions.disableAutoMode ला "disable" वर सेट करा आणि ती file managed settings मध्ये ठेवा, जेणेकरून checked-out project ती override करू शकणार नाही. प्रत्येक rule कुठे लागू होतो हे आमच्या Claude Code auto mode आणि permission rules मार्गदर्शकात स्पष्ट केले आहे.

संरक्षणे: त्यातून मिळणाऱ्या फायद्यानुसार क्रम

यापैकी कोणतेही संरक्षण पूर्ण उपाय नाही. प्रत्येक संरक्षण agent कडे असलेली क्षमता किंवा agent त्या क्षमतेचा करू शकणारा वापर मर्यादित करते.

1. नष्ट करून पुन्हा तयार करता येणारे मशीन वापरा. त्यामुळे compromise झाल्यास incident न घडता एक तासाचा पुनर्बांधणीचा खर्च होतो.
2. तुमच्या वैयक्तिक credentials पासून वेगळे, एका repository पुरते मर्यादित आणि अल्पकालीन credentials वापरा.
3. agent च्या commands कडून वारशाने मिळणाऱ्या environment मध्ये दीर्घकाळ वैध असलेली secrets ठेवू नका.
4. network egress आणि file access वर operating system enforcement लागू करा. हे agent ने सुरू केलेल्या प्रत्येक process वर लागू होते.
5. writes आणि network calls साठी approval prompts सुरू ठेवा.
6. तुम्ही स्पष्टपणे ओळखू शकता अशा कृतींसाठी hooks हे deterministic backstop म्हणून वापरा.
7. merge करण्यापूर्वी diff वाचा.

क्रम महत्त्वाचा आहे. Model पूर्णपणे हल्लेखोराच्या नियंत्रणात असला तरी items 1 ते 4 लागू राहतात. Items 5 ते 7 साठी माणसाने लक्ष देणे आवश्यक आहे. Agent बराच वेळ चालू राहिल्यावर नेमके हेच थांबते.

फेकून देता येईल अशा मशीनवर agent चालवा

Checkout आणि एक scoped token असलेला VPS, तुमच्या keys असलेल्या laptop पेक्षा खूपच कमी मौल्यवान लक्ष्य असतो. Agent स्वतःच्या unprivileged user म्हणून चालवा. तो तुमच्या login account म्हणून किंवा root म्हणून चालवू नका. आमच्या coding agents साठी disposable VM आणि VPS वर least-privilege users या मार्गदर्शकांमध्ये setup दिले आहे. VPS वर Claude Code सुरक्षितपणे चालवणे या मार्गदर्शकात दैनंदिन रचना दिली आहे.

secrets environment मधून काढा

Environment variable प्रत्येक child process ला वाचता येतो. त्यामुळे agent चालवणाऱ्या प्रत्येक command ला तो वाचता येतो. Claude Code चा sandbox प्रत्येक sandboxed command पूर्वी नामनिर्दिष्ट variables unset करू शकतो. Linux वर आधी दोन packages आवश्यक आहेत:

sudo apt-get install bubblewrap socat

त्यानंतर ~/.claude/settings.json मध्ये:

{
  "sandbox": {
    "enabled": true,
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    },
    "credentials": {
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" },
        { "name": "NPM_TOKEN", "mode": "deny" }
      ]
    }
  }
}

deny entry प्रत्येक sandboxed command सुरू होण्यापूर्वी तो variable unset करते. allowedDomains मध्ये तुम्ही सूचीबद्ध केलेल्या hosts कडे sandboxed commands ठेवले जातात. credentials block साठी Claude Code v2.1.187 किंवा त्यानंतरची आवृत्ती आवश्यक आहे; ही माहिती August 2026 मध्ये तपासली होती. कोणते layers सक्रिय आहेत आणि कोणत्या dependencies अनुपलब्ध आहेत हे पाहण्यासाठी session मध्ये /sandbox चालवा. त्या box वर कोणत्या secrets असणे आवश्यक आहे हे ठरवणे हा कामाचा मोठा भाग आहे. AI agent च्या आवाक्याबाहेर secrets ठेवणे या विषयावरील मार्गदर्शकात हे सविस्तर स्पष्ट केले आहे.

operating system स्तरावर network egress मर्यादित करा

Firewall rule ला model ने काय ठरवले याची पर्वा नसते. Agent dedicated agent user म्हणून चालवा आणि त्या user कडून जाणारे traffic drop करा:

table inet agentcage {
  chain output {
    type filter hook output priority filter; policy accept;
    meta skuid "agent" ct state established,related accept
    meta skuid "agent" oif lo accept
    meta skuid "agent" counter drop
  }
}

यामुळे agent user साठी फक्त loopback उपलब्ध राहतो. त्यामुळे त्याचे traffic त्याच box वर चालवलेल्या proxy मधून जावे लागते आणि hostname allowlist proxy कडे राहते. https_proxy त्या proxy कडे निर्देशित केल्यावर client CONNECT request पाठवतो आणि proxy name lookup करते. त्यामुळे agent ला स्वतःची outbound DNS (domain name system) आवश्यक राहत नाही. sudo nft list ruleset वापरून configuration तपासा. Agent नवीन ठिकाणी पोहोचण्याचा प्रयत्न करत असताना drop rule वरील counter वाढतो का ते monitor करा.

Firewall changes लागू करताना दुसरे SSH session सुरू ठेवा. तुमचा container runtime या rules वर काय परिणाम करतो तेही तपासा. Docker स्वतःच्या chains लिहिते. published Docker ports bypass ufw या मार्गदर्शकात त्यातून निर्माण होणारे अनपेक्षित वर्तन स्पष्ट केले आहे.

Hooks: model ज्याला शब्दांनी टाळू शकत नाही अशी तपासणी

Permission rules आणि hooks हे model नव्हे, तर Claude Code लागू करते. Documentation मध्ये हे स्पष्टपणे सांगितले आहे: तुमच्या prompt मधील instructions किंवा CLAUDE.md Claude ने काय करण्याचा प्रयत्न करावा हे ठरवतात; Claude Code काय परवानगी देते हे ते बदलत नाहीत. हाच फरक या उपायाचे संपूर्ण महत्त्व ठरवतो. CLAUDE.md मधील "never run curl" ही ओळ injected paragraph युक्तिवाद करून बदलू शकतो अशी सूचना आहे. Hook ही exit code परत करणारी process आहे.

PreToolUse hook .claude/settings.json मध्ये register करा:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/no-egress.sh"
          }
        ]
      }
    ]
  }
}

Hook ला tool call standard input वर JSON स्वरूपात मिळतो. Exit code 2 call block करतो आणि standard error मधील कारण Claude ला दाखवतो. Exit code 0 आल्यास call सामान्य permission flow मधून पुढे जाते.

#!/usr/bin/env bash
# PreToolUse: stdin holds the tool call, exit 2 blocks it.
cmd=$(jq -r '.tool_input.command // ""')
if printf '%s' "$cmd" | grep -qE '(^|[;&|]|\s)(curl|wget|nc|ncat)(\s|$)'; then
  echo "Blocked: this repository does not allow outbound network commands." >&2
  exit 2
fi
exit 0

आता मर्यादा स्पष्टपणे पाहू. ही shell string वर आधारित denylist आहे आणि अशा denylists मधून त्रुटी राहतात. python3 -c मध्ये curl हा शब्द न वापरता socket उघडता येतो. make deploy target वापरल्यास तोच call आणखी एका स्तराखाली लपवता येतो. तुम्ही ओळखू शकता अशा चुका रोखण्यासाठी hooks लिहा. पण तुम्ही प्रत्यक्षात ज्यावर अवलंबून आहात ती सीमा kernel किंवा network स्तरावर लागू करा.

Permission deny rules मध्ये एक महत्त्वाची matching मर्यादा आहे. Read आणि Edit deny rules Claude ची स्वतःची file tools तसेच Bash मध्ये ती ओळखत असलेल्या file commands साठी लागू होतात. उदाहरणार्थ cat, head, tail आणि sed. पण file स्वतः उघडणाऱ्या Python किंवा Node script वर त्या लागू होत नाहीत. Rules चे मूल्यांकन प्रथम deny, नंतर ask आणि शेवटी allow अशा क्रमाने होते. त्यामुळे deny rule मध्ये allowlist exception देता येत नाही.

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(./secrets/**)",
      "Bash(git push *)"
    ]
  }
}

बाहेर जाणाऱ्या traffic वर लक्ष ठेवा आणि diff वाचा

Agent run मुळे diff आणि network calls चा संच तयार होतो. काहीही merge किंवा deploy करण्यापूर्वी दोन्ही तपासा. self-hosted security review pass diff वर केल्यास मानवी जलद वाचनापेक्षा वेगळ्या प्रकारचे बदल आढळतात. coding agent boxच्या बाहेर काय पाठवतो हे जाणून घेणे normal traffic कसा दिसतो हे स्पष्ट करते. त्यामुळे असामान्य request लगेच लक्षात येते.

अजून काय सुटलेले नाही

आजच्या घडीला सामग्री आणि सूचना यांच्यात विश्वसनीय विभाजन नाही. उपलब्ध असलेली प्रत्येक संरक्षणपद्धत एकतर काही प्रमाणात अपयशी ठरणारा filter आहे किंवा परिणामांची मर्यादा घालणारी उपाययोजना आहे. मजकुरातील एखादा भाग असा data आहे, ज्याचे कधीही पालन करू नये, असे stack मधील कोणतीही गोष्ट चिन्हांकित करत नाही.

Filters उपयुक्त ठरतात, पण ते अपयशीही ठरतात. बहुतेक injection attempts पकडणाऱ्या classifier ने प्रत्येक वेळी अचूक निर्णय घ्यावा लागतो, तर हल्लेखोराला फक्त एकदाच अचूक ठरणे आवश्यक असते. या विषमतेमुळे एखाद्या संरक्षणपद्धतीचा प्रकाशित success rate हा पुढील प्रयत्नासाठी सुरुवातीचा बिंदू ठरतो; तो हमी देत नाही.

सर्वांत आशादायक काम model level ऐवजी design level वर होत आहे. Defeating Prompt Injections by Design (Debenedetti आणि सहकारी, 2025) मधील CaMeL प्रथम trusted request मधून control flow आणि data flow वेगळे काढते. त्यामुळे untrusted data मुळे program चे कार्य बदलता येत नाही. त्यानंतर tools call केल्यावर capability checks लागू केले जातात. AgentDojo benchmark वरील paper मधील आकडेवारीवरून याची किंमत स्पष्ट होते.

[
  {
    "label": "Undefended agent",
    "tasks_solved_pct": 84
  },
  {
    "label": "CaMeL",
    "tasks_solved_pct": 77
  }
]

संरक्षण नसलेल्या agent ने 84 टक्के tasks पूर्ण केली. CaMeL ने security guarantee सह 77 टक्के tasks पूर्ण केली. हे एका benchmark वरील paper मध्ये प्रकाशित केलेले आकडे आहेत; ते तुमच्या workload चे मोजमाप नाहीत. त्यांच्यातील फरक म्हणजे आजच्या घडीला वास्तविक guarantee ची साधारण किंमत आहे.

तुम्ही दररोज वापरत असलेल्या tools मध्ये अशी design उपलब्ध होईपर्यंत, agent कधीतरी compromised होईल असे गृहीत धरा आणि ती घटना कंटाळवाणी ठेवा. Disposable machine, मर्यादित scope असलेली credentials, नियंत्रित egress आणि diff वाचण्याची सवय यामागचा संपूर्ण युक्तिवाद हाच आहे.

FAQ

prompt injection थांबवण्यासाठी एजंटला फाइलमधील सूचना दुर्लक्षित करण्यास सांगणे पुरेसे आहे का?

नाही. ते वाक्य हल्ल्याच्या मजकुरासोबत त्याच context window मध्ये असते. त्यामुळे ते हल्लेखोराच्या मजकुराशी समान पातळीवर स्पर्धा करते. Claude Code चे documentation ही सीमा स्पष्टपणे सांगते: तुमच्या prompt मधील सूचना किंवा CLAUDE.md एजंटने काय करण्याचा प्रयत्न करावा हे ठरवतात; त्या tool ला काय करण्याची अनुमती आहे हे बदलत नाहीत. Instruction file ला हेतूचे विधान समजा. तुम्ही ज्या गोष्टींवर अवलंबून आहात त्या permission rules, PreToolUse hook किंवा firewall rule मध्ये ठेवा.

एजंटने फक्त माझ्याच repository वर काम केले, तरी prompt injection हा खरा धोका आहे का?

होय, कारण तुमच्या repository मध्ये तुम्ही लिहिलेला नसलेला मोठ्या प्रमाणात मजकूर असतो. Dependency README files, lockfile URLs, test fixtures, vendored code आणि npm install चे output हे सर्व सामान्य task दरम्यान येतात. Issue tracker किंवा documentation site मधून आणलेली कोणतीही सामग्री याच प्रकारे येते. एजंट जितके अधिक वाचतो तितका धोका वाढतो. उपयुक्त एजंट मोठ्या प्रमाणात वाचतो.

एजंट container मध्ये चालवल्याने ही समस्या सुटते का?

यामुळे नुकसान मर्यादित होते. मात्र credentials देखील काढून घेतल्यासच त्याचा पूर्ण उपयोग होतो. SSH agent forwarded असलेला, environment मध्ये cloud credentials असलेला आणि unrestricted network access असलेला container हल्लेखोराला host वरील जवळजवळ सर्वकाही मिळवून देतो. Container मुळे प्रत्यक्षात तुम्हाला delete करता येईल अशी filesystem मिळते आणि egress rules लागू करण्यासाठी स्वच्छ जागा मिळते. यासोबत एका repository पर्यंत मर्यादित token वापरा.

धोका सर्वाधिक कमी करणारा एकच बदल कोणता?

एजंटच्या commands ला मिळणाऱ्या environment मधून दीर्घकाळ वैध असलेली credentials काढून टाका. त्यानंतर त्या machine साठी default-deny egress policy लागू करा. हे दोन्ही बदल मिळून lethal trifecta मधील तिसरी अट मोडतात: मजकूर अजूनही एजंटचे नियंत्रण मिळवू शकतो, पण तो ज्या data पर्यंत पोहोचतो ते उपयुक्त ठिकाणी पाठवता येत नाही. Approval prompts आणि diff review देखील मदत करतात. मात्र त्यासाठी दीर्घकाळ चालणाऱ्या run दरम्यान माणसाने सतर्क राहणे आवश्यक असते. म्हणून या दोन बदलांपेक्षा त्यांना कमी प्राधान्य दिले जाते.