కోడింగ్ agent పై prompt injection: ముప్పులు, రక్షణలు

కోడింగ్ agent పై prompt injection అంటే ఏమిటి

కోడింగ్ agent చదివే text ను agent అనుసరించాల్సిన instruction గా పరిగణించినప్పుడు జరిగేదే coding agent పై prompt injection. Agent ఒక file, pull request comment, web page లేదా tool call ఫలితాన్ని తెరుస్తుంది. ఇవన్నీ మీ స్వంత request వచ్చిన text రకానికే చెందినవిగా agent కు అందుతాయి. ఆ text లో ఏదైనా భాగాన్ని attacker నియంత్రిస్తే, attacker మీ session లోకి text రాస్తున్నట్టే.

ప్రస్తుతం అందుబాటులో ఉన్న ప్రతి agent product లో ఈ లక్షణం ఉంది. Model కు tokens యొక్క ఒకే sequence అందుతుంది. మీ request, system prompt, file contents, tool results అన్నీ కలిపి ఉంటాయి; తరువాత ఏమి రావాలో model అంచనా వేస్తుంది. ఏ token పైన privilege bit ఉండదు. మీరు అనుమతించిన భాగం ఏది, మరొకరి README file నుంచి వచ్చిన భాగం ఏది అనే విషయాన్ని format ద్వారా గుర్తించే విధానం లేదు.

ఈ పేజీ threat model ను వివరిస్తుంది: server పై నడుస్తున్న agent కు attacker నియంత్రించే text ఎక్కడ చేరుతుంది, ప్రతి దశలో attacker ఏమి పొందగలడు, అలాగే ఏ defences కోసం కృషి చేయడం విలువైనది. Agent ను ఏదినుంచి contain చేస్తున్నారో తెలుసుకున్న తర్వాతే మా ఇతర guides లోని containment సలహా అర్థవంతంగా ఉంటుంది.

మోడల్ కంటెంట్‌ను సూచనల నుంచి ఎందుకు వేరు చేయలేడు

Training సహాయపడుతుంది, కానీ సమస్యను పూర్తిగా పరిష్కరించదు. ప్రస్తుత models retrieved text ను అనుమానంతో పరిశీలించేలా train చేయబడ్డాయి. అవి అనేక సాధారణ దాడి ప్రయత్నాలను తిరస్కరిస్తాయి. అయితే refusal అనేది probability మాత్రమే, నియమం కాదు. దాడి చేసేవారు వాక్యాన్ని మళ్లీ రాయవచ్చు, తిరిగి ప్రయత్నించవచ్చు, ఎవరూ ఊహించని format లో ఆ text ను దాచవచ్చు. వారు ప్రయత్నించే wordings సంఖ్యను పరిమితం చేసే విషయం ఏదీ లేదు.

OWASP GenAI project దీన్ని LLM01:2025 Prompt Injectionగా నమోదు చేసి, రెండు రకాలుగా విభజిస్తుంది. Direct injection అంటే user ఇచ్చిన prompt model ప్రవర్తనను మార్చడం. Indirect injection అంటే website లేదా file వంటి బాహ్య content ను model process చేస్తున్నప్పుడు, ఆ content model ప్రవర్తనను మార్చడం. Server సందర్భంలో indirect injection ముఖ్యమైనది, ఎందుకంటే agent మీరు type చేసే text కంటే చాలా ఎక్కువ content ను చదువుతుంది.

మొదటి systematic study ను Greshake మరియు సహచరులు Not what you've signed up for (2023)లో ప్రచురించారు. గుర్తుంచుకోవాల్సిన ప్రధాన నిర్ధారణ ఇదే: ఒక application retrieved text ను tools ను call చేయగల model కు అందిస్తే, ఆ text ను process చేయడం arbitrary code execution కు సమీపంగా ఉంటుంది.

చదవడాన్ని breach గా మార్చే పరిస్థితి

విరోధభరితమైన పాఠ్యాన్ని చదవడం మాత్రమే స్వయంగా నష్టం కలిగించదు. ఆ నష్టం యంత్రం నుంచి బయటకు వెళ్లే మార్గం అవసరం.

Simon Willison ఈ కలయికను June 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లో ముద్రితమై మీరు click చేసే link కావచ్చు.

రెండవ పరిస్థితిని మీరు తొలగించలేరు, ఎందుకంటే untrusted text చదవడమే మీరు agentను నియమించిన పని. కాబట్టి ప్రతి ఆచరణాత్మక రక్షణ మిగిలిన రెండు పరిస్థితులపై పనిచేయాలి.

సర్వర్‌లో 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 ను దారి మళ్లించే ఒక line జోడించే pull request ను human reviewer త్వరగా చూసి దాటవేయవచ్చు.

Issues, pull requests మరియు code review comments

మీ tracker లో అపరిచితుడు type చేయగల ఏదైనా, మీరు triage చేయమని agent ను అడిగిన వెంటనే దానికి చేరుతుంది. May 2025లో, Invariant Labs ఇదే నిర్మాణంతో కూడిన GitHub MCP finding ను ప్రచురించింది. ఒక developer agent కు ఒక public repositoryతో పాటు private repositoriesకూ access ఉంది. Attacker public repositoryలో issue నమోదు చేశాడు. Open issues చూడమని developer agent ను అడిగినప్పుడు, అది private repositoryల contents చదివి public వైపు ఉన్న pull requestలో రాసింది.

ఆ report MCP serverలో code defect కంటే architectural problem ను వివరిస్తుంది. Agent వద్ద విస్తృత access ఉన్న ఒక token ఉంది, అది public inbox నుంచి చదవగలిగింది మరియు రాయగలిగింది. సాధారణ అర్థంలో ఏదీ misconfigured కాలేదు. అందుకే పరిష్కారం patching కాదు, access scoping.

agent fetch చేసే web pages

Documentation, forum answers, vendor page, search result. వీటిలో ఏదైనా మీ కోసం కాకుండా agent కోసం రాసిన text ను కలిగి ఉండవచ్చు. Browser ఎప్పుడూ చూపించని content కూడా model కు చేరుతుంది కాబట్టి, HTML ను text గా మార్చడం attacker కు అదనపు స్థలాన్ని ఇస్తుంది.

Agent పర్యవేక్షణలో అత్యల్పంగా ఉన్న సమయంలో attacker నియంత్రణ పొందుతాడు. Agent ఏదైనా వెతుకుతున్నప్పుడు fetch చేసిన page యొక్క పూర్తి text ను ఎవరూ చదవరు.

MCP tool output

MCP (model context protocol) అనేది agentలు external tools కు అనుసంధానమయ్యే సాధారణ మార్గం. Results text రూపంలో తిరిగి వచ్చి నేరుగా context windowలోకి వెళ్తాయి. ఇక్కడ ఒకటి కాదు, రెండు surfaces ఉన్నాయి. Tool తిరిగి ఇచ్చే data స్పష్టమైనది. Model tool ను ఎప్పుడు call చేయాలో నిర్ణయించుకునేందుకు చదివే tool పేరు మరియు description మరొకటి. మీరు నియంత్రించని server calls మధ్య వీటిలో దేనినైనా మార్చగలదు.

ఒక tool outputలో text ను చొప్పించిన attacker, agent వద్ద ఉన్న మిగతా tools అన్నింటినీ చేరుకోగలడు. తక్కువ విలువైన పనిలోని 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 ను అడిగితే, అది మొత్తం output ను చదువుతుంది.

ఇక్కడ 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 publish చేయడం లేదా దాడి చేసేవాడు నియంత్రించే పేరు కోసం DNS lookup చేయడం ద్వారా డేటా ఆ సిస్టమ్‌ నుంచి బయటకు వెళ్తుంది.

మీరు ఆమోదించే code మార్పులు. agent చేసే పని code రాయడం. అందువల్ల అది స్వల్పంగా తప్పు ఉన్న ఒక line రాసేలా చేయడం సులభంగా సాధించగల ఫలితం. ఉదాహరణకు, ఒక dependency చేర్చడం లేదా token ను మీరు మరెక్కడికో పంపే log లోకి తీసుకెళ్లే logging call జోడించడం.

స్థిరపడటం. ఒకసారి రాసిన file model లేకుండానే పనిచేస్తూనే ఉంటుంది: .git/hooks లో ఒక hook, package.json లోని postinstall script, shell startup file కు జోడించిన ఒక line, లేదా CLAUDE.md లోని అదనపు line. తదుపరి command దాన్ని అమలు చేస్తుంది.

మీ network లోని ఇతర సిస్టమ్‌లకు చేరడం. agent ను మీరు ఎక్కడ నడిపితే అక్కడే అది పనిచేస్తుంది. ఆ సిస్టమ్ loopback పై ఉన్న database, internal admin service, మీ cloud provider యొక్క metadata service లేదా private network లోని మరొక host కు చేరుకోగలిగితే, agent ను నడిపించే ఏదైనా కూడా అక్కడికి చేరుకోగలదు.

ఆటో-ఆమోద మోడ్‌లు చివరి తనిఖీని తొలగిస్తాయి

డిఫాల్ట్ మోడ్‌లో Claude Code కమాండ్‌ను అమలు చేయడానికి లేదా ఫైల్‌ను సవరించడానికి ముందు అనుమతి అడుగుతుంది. పై పేర్కొన్న ప్రతి ప్రమాద మార్గం మరియు వాస్తవ చర్య మధ్య ఉండే మానవ తనిఖీ అదే prompt. ఆ prompt ను తొలగించే మోడ్‌లు ఈ తనిఖీని కూడా తొలగిస్తాయి.

bypassPermissions గురించి documentation స్పష్టంగా చెబుతుంది: Claude Code నష్టం కలిగించలేని containers లేదా VMs వంటి వేరుచేసిన environments లో మాత్రమే దీన్ని ఉపయోగించాలి. Auto mode కొంత సురక్షితమైనది. ఇది మీ అభ్యర్థనకు చర్యలు అనుగుణంగా ఉన్నాయో లేదో తనిఖీ చేసే background safety checks తో tool calls ను స్వయంచాలకంగా ఆమోదిస్తుంది. ఈ తనిఖీలు చాలా సమస్యలను గుర్తిస్తాయి. అయినప్పటికీ అవి model output పై model judgement మాత్రమే. కాబట్టి వాటిని boundary గా కాకుండా filter గా పరిగణించండి.

నిర్వాహకుడు ఈ రెండింటినీ తొలగించవచ్చు. Settings file లో permissions.disableBypassPermissionsMode లేదా permissions.disableAutoMode ను "disable" కు సెట్ చేసి, ఆ file ను managed settings లో ఉంచండి. అప్పుడు checkout చేసిన project దాన్ని override చేయలదు. ప్రతి rule ఎక్కడ అమలవుతుందో మా Claude Code auto mode మరియు permission rules మార్గదర్శకంలో వివరించాం.

లభించే ప్రయోజనం ఆధారంగా రక్షణల క్రమం

వీటిలో ఏదీ పూర్తి పరిష్కారం కాదు. ప్రతి రక్షణ agent వద్ద ఉండే సమాచారాన్ని లేదా దానితో agent చేయగల పనులను పరిమితం చేస్తుంది.

1. మీరు తొలగించి మళ్లీ నిర్మించగల machine. దాంతో compromise వల్ల incident కాకుండా ఒక గంట సమయం మాత్రమే నష్టం కావచ్చు.
2. మీ స్వంత credentials కు వేరు అయిన, ఒక repository కు మాత్రమే పరిమితమైన, తక్కువకాలం చెల్లే credentials.
3. agent commands పొందే environment లో long-lived secrets లేకపోవడం.
4. network egress మరియు file access పై operating system enforcement. ఇది agent ప్రారంభించే ప్రతి process కు వర్తిస్తుంది.
5. writes మరియు network calls కోసం approval prompts ఆన్‌లో ఉంచడం.
6. మీరు స్పష్టంగా పేర్కొనగల నిర్దిష్ట చర్యలకు deterministic backstop గా hooks ఉపయోగించడం.
7. merge చేయడానికి ముందు diff చదవడం.

క్రమం ముఖ్యం. Items 1 నుంచి 4 వరకు model పూర్తిగా attacker నియంత్రణలో ఉన్నా పనిచేస్తాయి. Items 5 నుంచి 7 వరకు ఒక మనిషి శ్రద్ధగా పరిశీలించడంపై ఆధారపడతాయి. దీర్ఘకాలం agent run జరుగుతున్నప్పుడు సాధారణంగా మొదట ఆ శ్రద్ధే ఆగిపోతుంది.

agent ను మీరు పారేసి వేయగల machine పై ఉంచండి

checkout మరియు ఒక scoped token ఉన్న VPS, మీ keys ఉన్న laptop కంటే చాలా చిన్న బహుమతి. agent ను మీ login account గా లేదా root గా కాకుండా, ప్రత్యేక unprivileged user గా నడపండి. coding agents కోసం disposable VM మరియు VPS పై least-privilege users పై ఉన్న మా guides setup ను వివరిస్తాయి. VPS పై Claude Code ను సురక్షితంగా నడపడం రోజువారీ విధానాన్ని వివరిస్తుంది.

secrets ను environment నుంచి తొలగించండి

Environment variable ను ప్రతి child process చదవగలదు. అంటే agent నడిపే ప్రతి command దాన్ని చదవగలదు. ప్రతి sandboxed command కు ముందు పేర్కొన్న variables ను unset చేయగల సామర్థ్యం Claude Code sandbox లో ఉంది. Linux లో sandbox కు ముందుగా రెండు 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 లేదా ఆ తరువాతి version అవసరం; ఇది August 2026 నాటికి నిర్ధారించబడింది. ఏ layers active గా ఉన్నాయో, ఏ dependencies లేవో చూడటానికి session లో /sandbox నడపండి. ఆ machine పై అసలు ఏ secrets ఉండాలో నిర్ణయించడం ఈ పనిలో పెద్ద భాగం. secrets ను AI agent చేరుకోలేని విధంగా ఉంచడం ఈ అంశాన్ని వివరిస్తుంది.

operating system స్థాయిలో network egress ను నిలిపివేయండి

Firewall rule కు model ఏమి నిర్ణయించిందో సంబంధం లేదు. agent ను ప్రత్యేక 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 అదే machine పై మీరు నడిపే proxy ద్వారా వెళ్లాలి. Hostname allowlist ను proxy నిర్వహిస్తుంది. https_proxy ను ఆ proxy వైపు చూపిస్తే client ఒక CONNECT request పంపుతుంది, ఆపై proxy name lookup చేస్తుంది. కాబట్టి agent కు స్వంత outbound DNS (domain name system) అవసరం ఉండదు. మీ మార్పులను sudo nft list ruleset తో తనిఖీ చేయండి. Agent కొత్తదాన్ని చేరుకోవడానికి ప్రయత్నిస్తున్నప్పుడు drop rule counter పెరుగుతుందో గమనించండి.

Firewall మార్పులు అమలు చేస్తున్నప్పుడు రెండవ SSH session ను తెరిచి ఉంచండి. మీ container runtime ఈ rules తో ఎలా పనిచేస్తుందో కూడా తనిఖీ చేయండి. Docker తన స్వంత chains ను రాస్తుంది. published Docker ports ufw ను దాటిపోతాయి అనే guide ఈ సమస్యను వివరిస్తుంది.

Hooks: model మాటలతో దాటలేని తనిఖీ

Permission rules మరియు hooks ను model కాదు, Claude Code అమలు చేస్తుంది. Documentation లో ఇది స్పష్టంగా ఉంది: మీ prompt లేదా CLAUDE.md లోని instructions Claude ప్రయత్నించే పనులను ప్రభావితం చేస్తాయి. అవి Claude Code అనుమతించే పనులను మార్చవు. ఈ తేడానే మొత్తం ప్రయోజనం. CLAUDE.md లోని "never run curl" అనే line ను injected paragraph వాదించి మార్చగలదు. Hook మాత్రం exit code ను తిరిగి ఇచ్చే process.

.claude/settings.json లో PreToolUse hook ను register చేయండి:

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

Hook tool call ను JSON రూపంలో standard input పై స్వీకరిస్తుంది. Exit code 2 call ను block చేసి, standard error నుంచి reason ను 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. Shell strings పై denylist లు సులభంగా తప్పించబడతాయి. python3 -c అనే పదాన్ని ఉపయోగించకుండా curl socket ను తెరవగలదు. ఒక make deploy target అదే call ను మరొక స్థాయి లోపల దాచగలదు. మీరు గుర్తించగల mistakes కోసం hooks రాయండి. మీరు నిజంగా ఆధారపడే boundary ను 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 *)"
    ]
  }
}

బయటకు వెళ్లే సమాచారాన్ని గమనించి, diff చదవండి

Agent run ఒక diff మరియు network calls సముదాయాన్ని ఉత్పత్తి చేస్తుంది. ఏదైనా merge లేదా deploy చేయడానికి ముందు రెండింటినీ పరిశీలించాలి. Diff పై self-hosted security review pass మనిషి త్వరగా చదవడం ద్వారా గుర్తించలేని వేరే రకమైన మార్పులను గుర్తిస్తుంది. coding agent machine బయటకు ఏమి పంపుతుందో తెలుసుకోవడం సాధారణ traffic ఎలా ఉంటుందో చూపిస్తుంది. అందువల్ల అసాధారణ request వెంటనే కనిపిస్తుంది.

ఇంకా పరిష్కారం కానివి

ప్రస్తుతం కంటెంట్ మరియు సూచనల మధ్య నమ్మదగిన విభజన లేదు. ప్రస్తుతం విడుదలయ్యే ప్రతి రక్షణలోనూ విఫలమయ్యే అవకాశం ఉన్న filter ఉంటుంది లేదా పరిణామాలను పరిమితం చేస్తుంది. Text లోని ఒక భాగాన్ని ఎట్టి పరిస్థితుల్లోనూ పాటించకూడని data గా గుర్తించే వ్యవస్థలోని ఏ భాగమూ లేదు.

Filters సహాయపడతాయి, కానీ అవి విఫలమవుతాయి కూడా. Injection ప్రయత్నాల్లో చాలా వరకు గుర్తించే classifier అయినా ప్రతిసారీ సరిగ్గా పనిచేయాలి. దాడి చేసేవారికి మాత్రం ఒక్కసారి సరిగ్గా పనిచేస్తే చాలు. అందుకే రక్షణకు ప్రచురించిన success rate తదుపరి ప్రయత్నానికి ప్రారంభ బిందువు మాత్రమే; అది హామీ కాదు.

అత్యంత ఆశాజనకమైన పని model స్థాయిలో కాకుండా design స్థాయిలో జరుగుతోంది. Defeating Prompt Injections by Design లోని CaMeL (Debenedetti మరియు సహచరులు, 2025), ముందుగా విశ్వసనీయ request నుంచి control flow మరియు data flow ను వెలికితీస్తుంది. అందువల్ల untrusted data ప్రోగ్రామ్ చేసే పనిని మార్చలేరు. తరువాత tools ను call చేసినప్పుడు capability checks ను అమలు చేస్తుంది. దీనికి అవసరమైన వ్యయాన్ని AgentDojo benchmark పై paper లోని స్వంత గణాంకాలు చూపిస్తున్నాయి.

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

రక్షణ లేని agent 84 శాతం tasks ను పరిష్కరించింది. Security guarantee తో CaMeL 77 శాతం tasks ను పరిష్కరించింది. ఇవి ఒక benchmark పై paper లో ప్రచురించిన గణాంకాలు మాత్రమే; మీ workload పై చేసిన కొలతలు కావు. ఈ రెండింటి మధ్య తేడా ప్రస్తుతం నిజమైన guarantee కోసం చెల్లించాల్సిన వ్యయానికి సుమారుగా సమానం.

మీరు ప్రతిరోజూ ఉపయోగించే tools లో ఇలాంటి design అందుబాటులోకి వచ్చే వరకు, ఏదో ఒక సమయంలో agent breached అవుతుందని భావించి ప్రణాళిక రూపొందించండి. ఆ సంఘటనను సాధారణమైనదిగా ఉంచండి. Disposable machine, పరిమిత పరిధి కలిగిన credentials, నియంత్రిత egress మరియు diff ను చదివే అలవాటు అవసరమని చెప్పే పూర్తి కారణం ఇదే.

FAQ

ఫైళ్లలోని సూచనలను విస్మరించమని agent కు చెబితే prompt injection ను ఆపగలనా?

లేదు. ఆ వాక్యం దాడి ఉన్న అదే context window లోని text. అందువల్ల అది దాడి చేసేవారి text తో సమాన ప్రాధాన్యంతో పోటీ పడుతుంది. Claude Code documentation ఈ తేడాను స్పష్టంగా చెబుతుంది: మీ prompt లోని సూచనలు లేదా CLAUDE.md agent చేయడానికి ప్రయత్నించే పనిని ప్రభావితం చేస్తాయి. అవి tool అనుమతించే చర్యలను మార్చవు. instruction file ను ఉద్దేశం తెలిపే ప్రకటనగా పరిగణించండి. మీరు ఆధారపడే నియమాలను permission rules, PreToolUse hook లేదా firewall rule లో ఉంచండి.

agent నా స్వంత repository ను మాత్రమే తాకితే prompt injection నిజమైన ప్రమాదమేనా?

అవును. మీ repository లో మీరు రాయని text చాలా ఉంటుంది. Dependency README files, lockfile URLs, test fixtures, vendored code మరియు npm install output సాధారణ task సమయంలోనే వస్తాయి. Issue tracker లేదా documentation site నుంచి తీసుకున్నదీ ఇదే విధంగా వస్తుంది. agent ఎంత ఎక్కువగా చదివితే ప్రమాదం అంత పెరుగుతుంది. ఉపయోగకరమైన agent ఎక్కువగా చదువుతుంది.

agent ను container లో నడిపితే ఈ సమస్య పరిష్కారమవుతుందా?

అది నష్టాన్ని పరిమితం చేస్తుంది. అయితే credentials ను కూడా తొలగించినప్పుడే ఇది ఉపయోగకరం. మీ SSH agent forwarded గా ఉండే, environment లో cloud credentials ఉండే, network access కు పరిమితి లేని container కు host పై ఉన్న దాదాపు అన్నింటినీ దాడి చేసేవారికి అందించే అవకాశం ఉంటుంది. container అందించే ప్రధాన ప్రయోజనం తొలగించగల filesystem మరియు egress rules అమలు చేయడానికి స్వచ్ఛమైన స్థలం. దీనికి ఒక repository కు మాత్రమే పరిమితమైన token ను జత చేయండి.

ప్రమాదాన్ని ఎక్కువగా తగ్గించే ఒక్క మార్పు ఏమిటి?

agent commands inherit చేసే environment నుంచి దీర్ఘకాలం చెల్లుబాటు అయ్యే credentials ను తొలగించండి. తరువాత ఆ machine కు default-deny egress policy ఇవ్వండి. ఈ రెండూ కలిసి lethal trifecta లోని మూడవ షరతును విచ్ఛిన్నం చేస్తాయి: text ఇప్పటికీ agent ను దారి మళ్లించగలదు. కానీ అది చేరుకోగల data ఉపయోగకరమైన చోటుకు వెళ్లలేను. Approval prompts మరియు diff review కూడా సహాయపడతాయి. అయితే అవి దీర్ఘ run మొత్తం మనిషి అప్రమత్తంగా ఉండటంపై ఆధారపడతాయి. అందుకే ఈ రెండు మార్పులకంటే వాటి ప్రాధాన్యం తక్కువ.