Coding agents पर prompt injection हमला कैसे रोकें

Coding agent के खिलाफ prompt injection क्या है

Coding agent के खिलाफ prompt injection को समझना सरल है: agent जो भी text पढ़ता है, उसे एक निर्देश मानकर उसका पालन करता है। Agent कोई file, pull request comment, web page या tool call का परिणाम खोलता है। यह सब आपके अपने अनुरोध (request) की तरह ही text के रूप में आता है। यदि कोई हमलावर (attacker) इस text के किसी भी हिस्से को नियंत्रित करता है, तो वह आपके session में कुछ भी लिख रहा है।

वर्तमान में उपलब्ध हर agent product में यह गुण मौजूद है। Model को tokens का एक ही sequence प्राप्त होता है। आपका अनुरोध, system prompt, file की सामग्री और tool के परिणाम सब एक साथ जुड़ जाते हैं, और model यह अनुमान लगाता है कि आगे क्या आएगा। किसी भी token पर कोई privilege bit नहीं होता। Format में ऐसा कुछ नहीं है जो यह बताए कि कौन सा हिस्सा आपने अधिकृत (authorize) किया है और कौन सा किसी अजनबी की README file से आया है।

यह पृष्ठ threat model है: यह बताता है कि हमलावर द्वारा नियंत्रित text सर्वर पर चल रहे agent तक कैसे पहुँचता है, हर चरण पर हमलावर को क्या हासिल होता है, और कौन से बचाव के उपाय सार्थक हैं। हमारी अन्य मार्गदर्शिकाओं (guides) में दी गई containment सलाह तभी समझ में आती है जब आप यह जान लें कि आप agent को किस चीज से सुरक्षित रखने का प्रयास कर रहे हैं।

मॉडल कंटेंट और निर्देशों को अलग क्यों नहीं कर पाता है

ट्रेनिंग इसमें मदद करती है, लेकिन यह समस्या का समाधान नहीं है। वर्तमान मॉडल्स को इस तरह ट्रेन किया जाता है कि वे रिट्रीव किए गए टेक्स्ट को संदेह की दृष्टि से देखें, और वे कई कच्चे प्रयासों को अस्वीकार कर देते हैं। एक रिफ्यूजल (अस्वीकृति) केवल एक संभावना है, कोई नियम नहीं। एक हमलावर टेक्स्ट को फिर से लिख सकता है, दोबारा प्रयास कर सकता है, और उसे ऐसे फॉर्मेट में छिपा सकता है जिसकी किसी ने कल्पना भी न की हो, और वे कितनी बार शब्दों को बदल कर प्रयास करेंगे, इसकी कोई सीमा नहीं है।

OWASP GenAI प्रोजेक्ट इसे LLM01:2025 Prompt Injection के रूप में ट्रैक करता है और इसे दो भागों में विभाजित करता है। डायरेक्ट इंजेक्शन एक यूजर का अपना प्रॉम्प्ट है जो मॉडल के व्यवहार को बदल देता है। इनडायरेक्ट इंजेक्शन बाहरी कंटेंट है, जैसे कि कोई वेबसाइट या फाइल, जो मॉडल द्वारा प्रोसेस किए जाने पर उसके व्यवहार को बदल देती है। सर्वर पर इनडायरेक्ट इंजेक्शन ही मायने रखता है, क्योंकि एक एजेंट आपके द्वारा टाइप किए गए टेक्स्ट की तुलना में कहीं अधिक टेक्स्ट पढ़ता है।

पहला व्यवस्थित अध्ययन Greshake और उनके सहयोगियों द्वारा किया गया है, Not what you've signed up for (2023)। उनका निष्कर्ष वह वाक्य है जिसे याद रखना चाहिए: जब कोई एप्लिकेशन रिट्रीव किए गए टेक्स्ट को ऐसे मॉडल में फीड करती है जो टूल्स को कॉल कर सकता है, तो उस टेक्स्ट को प्रोसेस करना आर्बिट्रेरी कोड एक्जीक्यूशन (arbitrary code execution) के समान है।

वह स्थिति जो एक read को breach में बदल देती है

hostile text को पढ़ना अपने आप में नुकसान नहीं है। नुकसान के लिए मशीन से बाहर निकलने का एक रास्ता चाहिए।

Simon Willison ने जून 2025 में इस संयोजन को the 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 में print हुआ कोई link है जिस पर आप click करते हैं।

आप दूसरी स्थिति को नहीं हटा सकते, क्योंकि untrusted text को पढ़ना ही वह काम है जिसके लिए आपने agent को रखा है। इसलिए हर व्यावहारिक बचाव बाकी दो स्थितियों पर काम करता है।

जहाँ अविश्वसनीय टेक्स्ट सर्वर पर कोडिंग एजेंट तक पहुँचता है

वह रिपॉजिटरी जिसमें एजेंट काम कर रहा है

चेकआउट की प्रत्येक फाइल इनपुट है। सोर्स कमेंट्स, README.md, चेंजलॉग्स, टेस्ट फिक्स्चर, वेंडर्ड कोड, और स्वयं एजेंट की इंस्ट्रक्शन फाइलें: CLAUDE.md, AGENTS.md और उनके समकक्ष। जिस एजेंट को कोडबेस समझने के लिए कहा जाता है, वह इन्हें पढ़ता है, क्योंकि आपने यही करने के लिए कहा है।

यहाँ हमलावर को यह लाभ मिलता है कि वह उन सभी लोगों तक पहुँच बना सकता है जो रिपॉजिटरी को क्लोन करते हैं और उस पर एजेंट को पॉइंट करते हैं। इंस्ट्रक्शन फाइलें सबसे सीधा रास्ता हैं, क्योंकि वे निर्देशों के रूप में पढ़े जाने के लिए ही मौजूद होती हैं। एक पुल रिक्वेस्ट जो CLAUDE.md में चार उपयोगी लाइनें जोड़ती है और एक लाइन ऐसी जोड़ती है जो एजेंट को रीडायरेक्ट करती है, वह ऐसा बदलाव है जिसे मानव समीक्षक सरसरी तौर पर देखकर छोड़ देते हैं।

इश्यूज, पुल रिक्वेस्ट और कोड रिव्यू कमेंट्स

कोई भी अजनबी आपके ट्रैकर में जो कुछ भी टाइप कर सकता है, वह उस क्षण एजेंट तक पहुँच जाता है जब आप उसे ट्राइएज (triage) करने के लिए कहते हैं। मई 2025 में, Invariant Labs ने इसी तरह का एक GitHub MCP finding प्रकाशित किया था। एक डेवलपर के एजेंट की पहुँच एक पब्लिक रिपॉजिटरी और कुछ प्राइवेट रिपॉजिटरीज तक थी। एक हमलावर ने पब्लिक रिपॉजिटरी में एक इश्यू फाइल किया। जब डेवलपर ने एजेंट को ओपन इश्यूज देखने के लिए कहा, तो एजेंट ने प्राइवेट रिपॉजिटरी की सामग्री पढ़ ली और उसे पब्लिक साइड पर एक पुल रिक्वेस्ट में लिख दिया।

वह रिपोर्ट MCP सर्वर में किसी कोड डिफेक्ट के बजाय एक आर्किटेक्चरल समस्या का वर्णन करती है। एजेंट के पास एक व्यापक एक्सेस टोकन था, उसने पब्लिक इनबॉक्स से पढ़ा, और उसके पास लिखने की अनुमति थी। सामान्य अर्थों में कुछ भी गलत कॉन्फ़िगर नहीं था, इसीलिए इसका समाधान पैचिंग नहीं, बल्कि स्कोपिंग (scoping) है।

वेब पेज जिन्हें एजेंट फेच करता है

डॉक्यूमेंटेशन, फोरम के उत्तर, वेंडर पेज, सर्च रिजल्ट। इनमें से कोई भी आपके बजाय एजेंट के लिए लिखा गया टेक्स्ट ले जा सकता है। टेक्स्ट में बदला गया HTML हमलावर को अतिरिक्त जगह देता है, क्योंकि जो कंटेंट ब्राउज़र कभी प्रदर्शित नहीं करता, वह भी मॉडल तक पहुँच जाता है।

हमलावर को उस क्षण नियंत्रण मिलता है जब एजेंट पर सबसे कम निगरानी होती है। एजेंट द्वारा किसी जानकारी को खोजते समय फेच किए गए पेज का पूरा टेक्स्ट कोई नहीं पढ़ता।

MCP टूल आउटपुट

MCP (model context protocol) एजेंटों के बाहरी टूल्स से जुड़ने का सामान्य तरीका है। परिणाम टेक्स्ट के रूप में वापस आते हैं और सीधे कॉन्टेक्स्ट विंडो में चले जाते हैं। यहाँ एक नहीं, बल्कि दो सरफेस हैं। टूल द्वारा लौटाया गया डेटा स्पष्ट है। टूल का अपना नाम और विवरण, जिसे मॉडल यह तय करने के लिए पढ़ता है कि उसे कब कॉल करना है, दूसरा सरफेस है, और जिस सर्वर को आप कंट्रोल नहीं करते, वह कॉल के बीच में इनमें से किसी को भी बदल सकता है।

एक हमलावर जो किसी टूल के आउटपुट में टेक्स्ट डाल देता है, वह एजेंट के पास मौजूद हर दूसरे टूल तक पहुँच जाता है। इसी तरह कम महत्व वाली चीज में इंजेक्शन, अंततः उच्च महत्व वाली चीज को संचालित करने का कारण बनता है।

CI लॉग्स, बिल्ड आउटपुट और डिपेंडेंसी मेटाडेटा

npm install उन पैकेजों से टेक्स्ट प्रिंट करता है जिन्हें आपने नहीं लिखा है। एक टेस्ट फेलियर किसी लाइब्रेरी से एक असर्शन मैसेज प्रिंट करता है। एक कंटीन्यूअस इंटीग्रेशन (CI) जॉब लॉग थर्ड-पार्टी आउटपुट की हजारों लाइनें होती हैं। किसी एजेंट को फेल हो रहे बिल्ड को ठीक करने के लिए कहें और वह यह सब पढ़ लेता है।

यहाँ हमलावर को बिल्ड मशीन का एक्सेस मिल जाता है, जिसमें आमतौर पर डिप्लॉय क्रेडेंशियल्स और रजिस्ट्री टोकन होते हैं और जिस पर लैपटॉप की तुलना में कम ध्यान दिया जाता है।

हमलावर को वास्तव में क्या मिलता है

चार परिणाम ऐसे हैं जिनके लिए योजना बनाना सार्थक है।

Credential की चोरी। एजेंट प्रोसेस जो कुछ भी पढ़ सकती है, वह दायरे में है: environment variables, ~/.aws/credentials, ~/.ssh, एक gh टोकन, या एक Docker config फ़ाइल। उन्हें बाहर भेजने के लिए curl की आवश्यकता नहीं होती है। किसी branch में commit, pull request का विवरण, registry में पब्लिश किया गया पैकेज, या हमलावर द्वारा नियंत्रित नाम के लिए DNS lookup, ये सभी डेटा को सर्वर से बाहर ले जाते हैं।

आपके द्वारा स्वीकृत कोड परिवर्तन। कोड लिखना ही एजेंट का काम है, इसलिए उससे एक सूक्ष्म रूप से गलत लाइन लिखवाना सबसे आसान परिणाम है। एक जोड़ी गई dependency, या एक logging कॉल जो किसी टोकन को उस लॉग में ले जाती है जिसे आप कहीं और भेजते हैं।

Persistence (स्थायित्व)। एक बार लिखी गई फ़ाइल बिना किसी मॉडल के काम करती रहती है: .git/hooks में एक hook, package.json में एक postinstall स्क्रिप्ट, shell स्टार्टअप फ़ाइल में जोड़ी गई एक लाइन, या CLAUDE.md में एक अतिरिक्त लाइन। अगली कमांड इसे चला देती है।

आपके नेटवर्क के भीतर मूवमेंट। एजेंट वहीं चलता है जहाँ आप उसे रखते हैं। यदि वह सर्वर loopback पर किसी database, किसी आंतरिक admin service, आपके cloud provider की metadata service, या private network पर किसी अन्य host तक पहुँच सकता है, तो एजेंट को नियंत्रित करने वाली कोई भी चीज़ भी वहाँ तक पहुँच सकती है।

Auto-approve मोड अंतिम जांच को हटा देते हैं

डिफ़ॉल्ट मोड में, Claude Code किसी कमांड को चलाने या फ़ाइल को एडिट करने से पहले अनुमति मांगता है। वह प्रॉम्प्ट ही वह मानवीय जांच है जो ऊपर बताए गए हर कार्य और वास्तविक क्रिया के बीच मौजूद होती है। जो मोड इस प्रॉम्प्ट को हटा देते हैं, वे उस जांच को भी हटा देते हैं।

दस्तावेज़ीकरण bypassPermissions के बारे में स्पष्ट है: इसका उपयोग केवल कंटेनरों या VM जैसे अलग-थलग वातावरण में करें जहाँ Claude Code कोई नुकसान न पहुँचा सके। Auto मोड थोड़ा कम सख्त है, और यह बैकग्राउंड सुरक्षा जांच के साथ टूल कॉल्स को ऑटो-अप्रूव करता है, जो यह सत्यापित करते हैं कि क्रियाएं आपके अनुरोध के अनुरूप हैं। वे जांचें बहुत कुछ पकड़ लेती हैं। वे अभी भी मॉडल आउटपुट के बारे में मॉडल का निर्णय ही हैं, इसलिए उन्हें एक सीमा (boundary) के बजाय एक फ़िल्टर के रूप में मानें।

एक एडमिनिस्ट्रेटर दोनों को हटा सकता है। सेटिंग्स फ़ाइल में permissions.disableBypassPermissionsMode या permissions.disableAutoMode को "disable" पर सेट करें, और उस फ़ाइल को मैनेज्ड सेटिंग्स में रखें ताकि कोई चेक-आउट किया गया प्रोजेक्ट उसे ओवरराइड न कर सके। Claude Code auto mode and permission rules के लिए हमारी गाइड में बताया गया है कि प्रत्येक नियम कहाँ प्रभावी होता है।

Defences, ranked by what they buy you

None of these is a fix. Each one either narrows what the agent holds or narrows what it can do with it.

1. A machine you can destroy and rebuild, so a compromise costs you an hour instead of an incident.
2. Credentials that are separate from your own, scoped to one repository, and short lived.
3. No long-lived secrets in the environment the agent's commands inherit.
4. Operating system enforcement on network egress and file access, which applies to every process the agent starts.
5. Approval prompts kept on for writes and network calls.
6. Hooks as a deterministic backstop for the specific actions you can name.
7. Reading the diff before you merge it.

The order matters. Items 1 through 4 hold even when the model is fully under an attacker's control. Items 5 through 7 depend on a human paying attention, which is exactly what stops happening on a long agent run.

Put the agent on a machine you can throw away

A VPS that holds a checkout and one scoped token is a much smaller prize than a laptop with your keys on it. Run the agent as its own unprivileged user, not as your login account and not as root. Our guides on a disposable VM for coding agents and least-privilege users on a VPS cover the setup, and running Claude Code safely on a VPS covers the daily shape of it.

Take the secrets out of the environment

An environment variable is readable by every child process, which means every command the agent runs. Claude Code's sandbox can unset named variables before each sandboxed command. On Linux the sandbox needs two packages first:

sudo apt-get install bubblewrap socat

Then in ~/.claude/settings.json:

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

A deny entry unsets that variable before each sandboxed command runs, and allowedDomains holds sandboxed commands to the hosts you list. The credentials block needs Claude Code v2.1.187 or later, checked August 2026. Run /sandbox in a session to see which layers are active and which dependencies are missing. Deciding which secrets need to exist on that box at all is the larger half of the job, and keeping secrets out of an AI agent's reach works through it.

Cut network egress at the operating system

A firewall rule does not care what the model decided. Run the agent as a dedicated agent user, then drop what that user sends:

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
  }
}

That leaves the agent user with loopback only, so its traffic has to go through a proxy you run on the same box, and the proxy holds the hostname allowlist. With https_proxy pointing at that proxy, the client sends a CONNECT request and the proxy performs the name lookup, so the agent needs no outbound DNS (domain name system) of its own. Check your work with sudo nft list ruleset and watch the counter on the drop rule rise while the agent tries to reach something new.

Keep a second SSH session open while you apply firewall changes. Check what your container runtime does to these rules too: Docker writes its own chains, and published Docker ports bypass ufw describes the surprise that causes.

Hooks: the check the model cannot talk its way past

Permission rules and hooks are enforced by Claude Code, not by the model. The documentation states it plainly: instructions in your prompt or CLAUDE.md shape what Claude tries to do, and they do not change what Claude Code allows. That distinction is the whole value. A line in CLAUDE.md reading "never run curl" is a suggestion an injected paragraph can argue with. A hook is a process that returns an exit code.

Register a PreToolUse hook in .claude/settings.json:

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

The hook receives the tool call as JSON on standard input. Exit code 2 blocks the call and shows Claude the reason from standard error. Exit code 0 lets the call continue through the normal 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

Now the honest part. This is a denylist over a shell string, and denylists over shell strings leak. python3 -c opens a socket without using the word curl. A make deploy target hides the same call one level further down. Write hooks for the mistakes you can name, and put the boundary you actually rely on in the kernel or on the network.

Permission deny rules carry a matching limit worth knowing. Read and Edit deny rules cover Claude's own file tools and the file commands it recognises in Bash, such as cat, head, tail and sed. They do not cover a Python or Node script that opens the file itself. Rules are evaluated deny first, then ask, then allow, so a deny rule cannot carry an allowlist exception.

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

Watch what leaves, and read the diff

An agent run produces a diff and a set of network calls. Both deserve a look before anything merges or deploys. A self-hosted security review pass over the diff catches a different class of change than a human skim does, and knowing what a coding agent sends off the box tells you what normal traffic looks like, so an odd request stands out.

क्या अभी भी अनसुलझा है

आज content और instruction के बीच कोई विश्वसनीय अलगाव नहीं है। जो भी सुरक्षा उपाय (defence) उपलब्ध हैं, वे या तो एक निश्चित failure rate वाले filter हैं या परिणामों पर लगाई गई सीमाएँ हैं। stack में ऐसा कुछ भी नहीं है जो text के किसी हिस्से को ऐसे data के रूप में चिह्नित करे जिसका पालन कभी नहीं किया जाना चाहिए।

Filters मदद जरूर करते हैं, लेकिन वे विफल भी होते हैं। एक classifier जो अधिकांश injection प्रयासों को पकड़ लेता है, उसे हर बार सही होना पड़ता है, जबकि एक हमलावर को केवल एक बार सही होने की आवश्यकता होती है। यही विषमता (asymmetry) कारण है कि किसी सुरक्षा उपाय की प्रकाशित सफलता दर (success rate) अगले हमले के लिए एक शुरुआती बिंदु है, न कि कोई गारंटी।

सबसे आशाजनक कार्य model स्तर के बजाय design स्तर पर हो रहे हैं। Defeating Prompt Injections by Design (Debenedetti और सहयोगी, 2025) से प्राप्त CaMeL, सबसे पहले trusted request से control flow और data flow को अलग करता है, ताकि untrusted data यह न बदल सके कि program क्या करता है, और फिर tools को call किए जाने पर capability checks लागू करता है। AgentDojo benchmark पर शोध पत्र के अपने आँकड़े दिखाते हैं कि इसकी कीमत क्या है।

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

बिना सुरक्षा वाले agent ने 84 प्रतिशत कार्य हल किए। CaMeL ने सुरक्षा गारंटी के साथ 77 प्रतिशत कार्य हल किए। ये एक benchmark पर शोध पत्र के प्रकाशित आँकड़े हैं, न कि आपके workload का मापन। उनके बीच का अंतर लगभग उतना ही है जितनी आज एक वास्तविक सुरक्षा गारंटी की कीमत है।

जब तक आपके द्वारा प्रतिदिन उपयोग किए जाने वाले tools में ऐसा design शामिल नहीं हो जाता, तब तक यह मानकर चलें कि agent किसी न किसी बिंदु पर breach हो सकता है और उस घटना को सामान्य (boring) बनाएँ। disposable machine, सीमित credentials, नियंत्रित egress और diff को पढ़ने की आदत का पूरा तर्क यही है।

FAQ

क्या मैं फ़ाइलों में दिए गए निर्देशों को अनदेखा करने के लिए एजेंट को कहकर प्रॉम्प्ट इंजेक्शन को रोक सकता हूँ?

नहीं। वह वाक्य उसी कॉन्टेक्स्ट विंडो में मौजूद टेक्स्ट है जिसमें हमला (attack) है, और यह हमलावर के टेक्स्ट के साथ समान स्तर पर प्रतिस्पर्धा करता है। Claude Code का दस्तावेज़ीकरण स्पष्ट रूप से रेखांकित करता है: आपके प्रॉम्प्ट या CLAUDE.md में दिए गए निर्देश यह तय करते हैं कि एजेंट क्या करने का प्रयास करता है, और वे इसे नहीं बदलते कि टूल क्या करने की अनुमति देता है। निर्देश फ़ाइल को केवल इरादे के बयान के रूप में देखें, और जिस भी चीज़ पर आप भरोसा करते हैं उसे अनुमति नियमों (permission rules), PreToolUse हुक या फ़ायरवॉल नियम में डालें।

क्या प्रॉम्प्ट इंजेक्शन एक वास्तविक जोखिम है यदि एजेंट केवल मेरे अपने रिपॉजिटरी को छूता है?

हाँ, क्योंकि आपकी रिपॉजिटरी ऐसे टेक्स्ट से भरी है जिसे आपने नहीं लिखा है। Dependency README फ़ाइलें, lockfile URL, टेस्ट फिक्स्चर, वेंडर्ड कोड और npm install का आउटपुट, ये सभी एक सामान्य कार्य के दौरान आते हैं। इश्यू ट्रैकर या दस्तावेज़ीकरण साइट से जो कुछ भी लिया जाता है, वह भी उसी तरह आता है। जोखिम इस बात के साथ बढ़ता है कि एजेंट कितना पढ़ता है, और एक उपयोगी एजेंट बहुत कुछ पढ़ता है।

क्या एजेंट को कंटेनर में चलाने से यह समस्या हल हो जाती है?

यह नुकसान को सीमित करता है, और केवल तभी जब आप क्रेडेंशियल्स को भी हटा दें। एक कंटेनर जिसमें आपका SSH एजेंट फ़ॉरवर्ड किया गया हो, एनवायरनमेंट में क्लाउड क्रेडेंशियल्स हों और अप्रतिबंधित नेटवर्क एक्सेस हो, वह हमलावर को लगभग वह सब कुछ दे देता है जो होस्ट के पास होता है। कंटेनर वास्तव में आपको एक फ़ाइल सिस्टम देता है जिसे आप हटा सकते हैं और इग्रेस (egress) नियमों को लागू करने के लिए एक साफ़ जगह देता है। इसे एक रिपॉजिटरी तक सीमित टोकन के साथ उपयोग करें।

कौन सा एकल बदलाव जोखिम को सबसे अधिक कम करता है?

एजेंट के कमांड जिस एनवायरनमेंट से इनहेरिट करते हैं, वहां से लंबे समय तक रहने वाले क्रेडेंशियल्स को हटा दें, और फिर उस मशीन को डिफ़ॉल्ट-डिनाई (default-deny) इग्रेस पॉलिसी दें। साथ मिलकर वे घातक तिकड़ी की तीसरी शर्त को तोड़ देते हैं: टेक्स्ट अभी भी एजेंट को हाईजैक कर सकता है, लेकिन जिस डेटा तक वह पहुँचता है, उसके पास जाने के लिए कोई उपयोगी जगह नहीं होती। अप्रूवल प्रॉम्प्ट और डिफ रिव्यू भी मदद करते हैं, और वे एक लंबे रन के दौरान मानव के सतर्क रहने पर निर्भर करते हैं, यही कारण है कि वे उन दो बदलावों से नीचे आते हैं।