Coding agent-ல் Prompt injection தடுப்பது எப்படி?

Coding agent-க்கு எதிரான prompt injection என்றால் என்ன

Coding agent-க்கு எதிரான prompt injection-ஐ எளிமையாகச் சொல்லலாம்: agent வாசிக்கும் உரை, அது பின்பற்ற வேண்டிய கட்டளையாகக் கருதப்படுகிறது. Agent ஒரு கோப்பை, pull request கருத்து, இணையப் பக்கம் அல்லது tool call-ன் முடிவை திறக்கும்போது, அவை அனைத்தும் உங்கள் கோரிக்கையைப் போலவே அதே வகை உரையாகவே வந்து சேரும். அந்த உரையின் ஏதேனும் ஒரு பகுதியைத் தாக்குபவர் கட்டுப்படுத்தினால், அவர் உங்கள் session-க்குள் எழுதுகிறார் என்று அர்த்தம்.

தற்போதுள்ள ஒவ்வொரு agent தயாரிப்பிலும் இந்தத் தன்மை உள்ளது. மாதிரி (model) ஒரே வரிசையிலான tokens-ஐப் பெறுகிறது. உங்கள் கோரிக்கை, system prompt, கோப்பின் உள்ளடக்கம் மற்றும் tool-ன் முடிவுகள் அனைத்தும் ஒன்றாக இணைக்கப்படுகின்றன; அடுத்து என்ன வரும் என்பதை மாதிரி கணிக்கிறது. Token-ல் எந்தவிதமான privilege bit-ம் இல்லை. நீங்கள் அங்கீகரித்த பகுதி எது, அந்நியரின் README கோப்பிலிருந்து வந்த பகுதி எது என்று பிரித்துக் காட்டும் அம்சம் அந்த வடிவமைப்பில் இல்லை.

இந்தப் பக்கம் அச்சுறுத்தல் மாதிரியை (threat model) விளக்குகிறது: தாக்குபவர் கட்டுப்படுத்தும் உரை server-ல் இயங்கும் agent-ஐ எப்படி அடைகிறது, ஒவ்வொரு நிலையிலும் தாக்குபவர் என்ன பெறுகிறார், எந்தெந்த தற்காப்பு நடவடிக்கைகள் பயனுள்ளவை என்பதை இது விவரிக்கிறது. எதிலிருந்து agent-ஐப் பாதுகாக்கிறீர்கள் என்பதைத் தெரிந்தால் மட்டுமே, எமது பிற வழிகாட்டிகளில் உள்ள containment ஆலோசனைகள் அர்த்தமுள்ளதாக இருக்கும்.

ஏன் மாதிரியால் உள்ளடக்கத்தையும் அறிவுறுத்தல்களையும் பிரிக்க முடிவதில்லை

பயிற்சி இதற்கு தீர்வாகாது. தற்போதைய மாதிரிகள், பெறப்பட்ட உரையை (retrieved text) சந்தேகத்துடன் அணுகுமாறு பயிற்றுவிக்கப்படுகின்றன, இதனால் பல மேலோட்டமான முயற்சிகளை அவை நிராகரிக்கின்றன. ஆனால், இந்த நிராகரிப்பு என்பது ஒரு நிகழ்தகவு (probability) மட்டுமே, விதியல்ல. ஒரு தாக்குபவர் உரையை மாற்றி அமைப்பதன் மூலமோ, மீண்டும் முயற்சிப்பதன் மூலமோ அல்லது யாரும் எதிர்பாராத வடிவத்தில் மறைப்பதன் மூலமோ இதைத் தவிர்க்க முடியும்; எத்தனை முறை வேண்டுமானாலும் முயற்சி செய்ய எந்தக் கட்டுப்பாடும் இல்லை.

OWASP GenAI திட்டம் இதை LLM01:2025 Prompt Injection என வகைப்படுத்தி, இரண்டாகப் பிரிக்கிறது. நேரடி ஊசி (Direct injection) என்பது பயனர் தனது சொந்த prompt மூலம் மாதிரியின் செயல்பாட்டை மாற்றுவது. மறைமுக ஊசி (Indirect injection) என்பது இணையதளம் அல்லது கோப்பு போன்ற வெளிப்புற உள்ளடக்கத்தை மாதிரி செயலாக்கும்போது அதன் செயல்பாட்டை மாற்றுவது. ஒரு server-ல் மறைமுக ஊசிதான் முக்கியமானது, ஏனெனில் நீங்கள் தட்டச்சு செய்வதை விட அதிகப்படியான உரையை ஒரு agent வாசிக்கிறது.

இதன் மீதான முதல் முறையான ஆய்வு Greshake மற்றும் குழுவினரின் Not what you've signed up for (2023) ஆகும். அவர்களின் முடிவை நாம் கவனத்தில் கொள்ள வேண்டும்: ஒரு application, கருவிகளை (tools) இயக்கக்கூடிய ஒரு மாதிரிக்கு பெறப்பட்ட உரையை உள்ளீடாக அளிக்கும்போது, அந்த உரையைச் செயலாக்குவது என்பது தன்னிச்சையான நிரல் செயலாக்கத்திற்கு (arbitrary code execution) இணையானது.

ஒரு வாசிப்பை மீறலாக மாற்றும் நிபந்தனை

விரோதமான உரையை வாசிப்பது மட்டுமே பாதிப்பை ஏற்படுத்தாது. அந்தப் பாதிப்பு கணினியிலிருந்து வெளியேற ஒரு வழி தேவைப்படுகிறது.

ஜூன் 2025-ல் சைமன் வில்லிசன் (Simon Willison) இந்த இணைப்பை கொடிய மும்மை என்று அழைத்தார். தனிப்பட்ட தரவுகளைக் கொண்ட ஒரு முகவர் (agent), நம்பகத்தன்மையற்ற உள்ளடக்கத்திற்கு வெளிப்படுத்தப்பட்டு, தரவை வெளியே அனுப்பும் திறன் கொண்டிருந்தால், முதல் தரவை மூன்றாவதன் மூலம் வெளியேற்றும்படி அதைத் தூண்ட முடியும்.

உங்கள் VPS-ல் உள்ள ஒரு கோடிங் ஏஜென்ட், முதல் நாளிலேயே இவை அனைத்தையும் கொண்டுள்ளது. தனிப்பட்ட தரவு என்பது உங்கள் source code, உங்கள் .env கோப்பு, உங்கள் SSH keys மற்றும் உங்கள் shell history ஆகும். நம்பகத்தன்மையற்ற உள்ளடக்கம் என்பது அது வாசிக்கும் ஒவ்வொரு repository, பக்கம் மற்றும் கருவியின் முடிவுகள் ஆகும். வெளியேறும் வழி என்பது git push, curl, npm publish, ஒரு pull request-ன் உள்ளடக்கம் அல்லது உங்கள் terminal-ல் அச்சிடப்பட்டு நீங்கள் கிளிக் செய்யும் ஒரு link ஆகும்.

இரண்டாவது நிபந்தனையை உங்களால் நீக்க முடியாது, ஏனெனில் நம்பகத்தன்மையற்ற உரையை வாசிப்பதுதான் அந்த ஏஜென்ட்டை நீங்கள் பணியமர்த்தியதற்கான வேலை. எனவே, ஒவ்வொரு நடைமுறை தற்காப்பு நடவடிக்கையும் மற்ற இரண்டு நிபந்தனைகளின் மீதுதான் செயல்படுகிறது.

நம்பகத்தன்மையற்ற உரை server-ல் உள்ள coding agent-ஐ அடையும் இடங்கள்

agent பணிபுரியும் repository

checkout-ல் உள்ள ஒவ்வொரு கோப்பும் ஒரு உள்ளீடு (input) ஆகும். source comments, README.md, changelogs, test fixtures, vendored code மற்றும் agent-ன் அறிவுறுத்தல் கோப்புகள் (instruction files) என அனைத்தும் இதில் அடங்கும்: CLAUDE.md, AGENTS.md மற்றும் அவற்றிற்கு இணையானவை. ஒரு codebase-ஐப் புரிந்துகொள்ளுமாறு agent-இடம் கேட்கும்போது, அது இவற்றை வாசிக்கும், ஏனெனில் நீங்கள் அதையே கோரியுள்ளீர்கள்.

இங்கு ஒரு தாக்குதல் நடத்துபவர் பெறும் லாபம் என்னவென்றால், அந்த repository-ஐ clone செய்து, அதன் மீது ஒரு agent-ஐப் பயன்படுத்தும் அனைவரையும் சென்றடையும் வாய்ப்புதான். அறிவுறுத்தல் கோப்புகள் (instruction files) மிகவும் நேரடியான வழியாகும், ஏனெனில் அவை அறிவுறுத்தல்களாகவே வாசிக்கப்பட வேண்டும் என்ற நோக்கத்துடன் இருப்பவை. CLAUDE.md-ல் நான்கு பயனுள்ள வரிகளைச் சேர்த்து, agent-ஐத் திசைதிருப்பும் ஒரு வரியைச் சேர்க்கும் pull request-ஐ, ஒரு மனித மதிப்பாய்வாளர் கவனக்குறைவாகக் கடந்து செல்லக்கூடும்.

Issues, pull requests மற்றும் code review கருத்துகள்

ஒரு அந்நியர் உங்கள் tracker-ல் தட்டச்சு செய்யும் எதையும், நீங்கள் அதைத் தரம் பிரிக்க (triage) agent-இடம் கேட்கும் தருணத்தில் அது சென்றடையும். மே 2025-ல், Invariant Labs இதே போன்ற ஒரு GitHub MCP கண்டுபிடிப்பை வெளியிட்டது. ஒரு developer-ன் agent-க்கு ஒரு public repository மற்றும் சில private repository-களுக்கான அணுகல் இருந்தது. ஒரு தாக்குதல் நடத்துபவர் அந்த public repository-ல் ஒரு issue-ஐ உருவாக்கினார். அந்த developer திறந்திருக்கும் issue-களைப் பார்க்குமாறு agent-இடம் கேட்டபோது, அந்த agent private repository-ன் உள்ளடக்கங்களை வாசித்து, அவற்றை public பக்கத்தில் ஒரு pull request-ஆக எழுதியது.

அந்த அறிக்கை, MCP server-ல் உள்ள ஒரு code குறைபாட்டை விட, ஒரு கட்டடக்கலை சிக்கலையே விவரிக்கிறது. அந்த agent ஒரு பரந்த அணுகல் டோக்கனை (wide access token) வைத்திருந்தது, public inbox-லிருந்து வாசித்தது, மேலும் எழுதுவதற்கான அனுமதியையும் பெற்றிருந்தது. வழக்கமான அர்த்தத்தில் எதுவும் தவறாக உள்ளமைக்கப்படவில்லை, அதனால்தான் இதற்குத் தீர்வு patching அல்ல, மாறாக scoping ஆகும்.

agent fetches செய்யும் இணையப் பக்கங்கள்

ஆவணங்கள் (documentation), forum பதில்கள், vendor பக்கம், தேடல் முடிவு என எதுவாக இருந்தாலும், அது உங்களுக்காக அல்லாமல் agent-க்காக எழுதப்பட்ட உரையைத் தாங்கி வரக்கூடும். HTML உரையாக மாற்றப்படும்போது, தாக்குதல் நடத்துபவருக்கு கூடுதல் இடம் கிடைக்கிறது, ஏனெனில் browser-ல் காட்டப்படாத உள்ளடக்கம் கூட model-ஐச் சென்றடையும்.

agent மிகக் குறைவாகக் கண்காணிக்கப்படும் தருணத்தில், தாக்குதல் நடத்துபவர் கட்டுப்பாட்டைப் பெறுகிறார். ஏதேனும் ஒன்றைத் தேடும்போது agent fetch செய்த பக்கத்தின் முழு உரையையும் யாரும் வாசிப்பதில்லை.

MCP tool வெளியீடு

MCP (model context protocol) என்பது agent-கள் வெளிப்புறக் கருவிகளுடன் இணையும் பொதுவான வழியாகும். முடிவுகள் உரையாகத் திரும்பி வந்து நேரடியாக context window-க்குள் செல்கின்றன. இங்கு ஒன்று அல்ல, இரண்டு மேற்பரப்புகள் உள்ளன. ஒரு கருவி (tool) வழங்கும் தரவு என்பது வெளிப்படையானது. மற்றொன்று, அந்தக் கருவியின் பெயர் மற்றும் விளக்கம்; எப்போது அதை அழைக்க வேண்டும் என்று தீர்மானிக்க model இதைப் படிக்கிறது. நீங்கள் கட்டுப்படுத்தாத ஒரு server, அழைப்புகளுக்கு இடையில் இவற்றை மாற்ற முடியும்.

ஒரு கருவியின் வெளியீட்டில் உரையைச் செலுத்தும் தாக்குதல் நடத்துபவர், அந்த agent-க்கு உள்ள மற்ற அனைத்துக் கருவிகளையும் சென்றடைகிறார். குறைந்த மதிப்புள்ள ஒன்றில் செய்யப்படும் injection, எவ்வாறு அதிக மதிப்புள்ள ஒன்றைக் கட்டுப்படுத்தும் நிலைக்குச் செல்கிறது என்பது இதுதான்.

CI logs, build output மற்றும் dependency metadata

npm install நீங்கள் எழுதாத packages-லிருந்து உரையை அச்சிடுகிறது. ஒரு test தோல்வியடையும்போது, அது ஒரு library-லிருந்து assertion செய்தியை அச்சிடுகிறது. ஒரு continuous integration (CI) job log என்பது ஆயிரக்கணக்கான வரிகளைக் கொண்ட மூன்றாம் தரப்பு வெளியீடாகும். தோல்வியடைந்த build-ஐச் சரிசெய்யுமாறு ஒரு agent-இடம் கேட்டால், அது அனைத்தையும் வாசிக்கும்.

இங்கு ஒரு தாக்குதல் நடத்துபவர் build machine-ன் கட்டுப்பாட்டைப் பெறுகிறார். இது பொதுவாக deploy credentials மற்றும் registry tokens-ஐக் கொண்டிருக்கும், மேலும் இது ஒரு laptop-ஐ விடக் குறைவான கவனத்தையே பெறுகிறது.

தாக்குதல் நடத்துபவர் உண்மையில் பெறுபவை

நான்கு விளைவுகளைக் கருத்தில் கொண்டு திட்டமிடுவது அவசியம்.

அங்கீகாரச் சான்றுகள் திருட்டு (Credential theft). agent process எதைப் படிக்க முடியுமோ அது தாக்குதலுக்கு உள்ளாகலாம்: environment variables, ~/.aws/credentials, ~/.ssh, ஒரு gh token, அல்லது ஒரு Docker config file. இவற்றை வெளியே அனுப்ப curl தேவையில்லை. ஒரு branch-க்கு செய்யப்படும் commit, pull request விவரம், registry-க்கு வெளியிடப்படும் package, அல்லது தாக்குதல் நடத்துபவர் கட்டுப்பாட்டில் உள்ள பெயருக்கான DNS lookup என எதுவாக இருந்தாலும் தரவுகளை server-லிருந்து வெளியேற்றிவிடும்.

நீங்கள் அங்கீகரிக்கும் code மாற்றங்கள். code எழுதுவதே agent-ன் பணி என்பதால், நுணுக்கமாகத் தவறான ஒரு வரியை எழுத வைப்பதே மிக எளிதான விளைவாகும். சேர்க்கப்படும் ஒரு dependency, அல்லது நீங்கள் வேறொரு இடத்திற்கு அனுப்பும் log-ல் ஒரு token-ஐக் கொண்டு செல்லும் logging call போன்றவை இதில் அடங்கும்.

தொடர் இருப்பு (Persistence). ஒருமுறை எழுதப்படும் file, எந்த model-உம் இன்றி தொடர்ந்து இயங்கும்: .git/hooks-ல் ஒரு hook, package.json-ல் ஒரு postinstall script, shell startup file-ல் சேர்க்கப்படும் ஒரு வரி, அல்லது CLAUDE.md-ல் ஒரு கூடுதல் வரி. அடுத்த முறை command இயங்கும்போது இதுவும் இயங்கும்.

உங்கள் network-க்குள் ஊடுருவல். நீங்கள் எங்கு நிறுவுகிறீர்களோ அங்குதான் agent இயங்கும். அந்த server loopback மூலம் ஒரு database-ஐயோ, internal admin service-ஐயோ, உங்கள் cloud provider-ன் metadata service-ஐயோ, அல்லது private network-ல் உள்ள வேறொரு host-ஐயோ அணுக முடிந்தால், agent-ஐ இயக்கும் எதற்கும் அந்த அணுகல் கிடைக்கும்.

Auto-approve முறைகள் இறுதிச் சரிபார்ப்பை நீக்குகின்றன

இயல்புநிலை முறையில், ஒரு கட்டளையை இயக்குவதற்கு அல்லது கோப்பைத் திருத்துவதற்கு முன்பு Claude Code பயனரிடம் அனுமதி கேட்கும். அந்தத் தூண்டுதல் (prompt), மேலே உள்ள ஒவ்வொரு செயல்பாட்டிற்கும் மற்றும் உண்மையான செயலுக்கும் இடையே உள்ள மனிதச் சரிபார்ப்பாகும். அந்தத் தூண்டுதலை நீக்கும் முறைகள், இந்தச் சரிபார்ப்பையும் நீக்கிவிடுகின்றன.

bypassPermissions பற்றிய ஆவணங்கள் தெளிவாக உள்ளன: Claude Code பாதிப்பை ஏற்படுத்த முடியாத, containers அல்லது VMs போன்ற தனிமைப்படுத்தப்பட்ட சூழல்களில் மட்டுமே இதைப் பயன்படுத்தவும். Auto முறை சற்று மென்மையானது; இது பின்னணியில் உள்ள பாதுகாப்புச் சோதனைகள் மூலம், உங்கள் கோரிக்கைக்கு ஏற்ப அமையும் கருவி அழைப்புகளை (tool calls) தானாகவே அங்கீகரிக்கும். அந்தச் சோதனைகள் பல பிழைகளைக் கண்டறியும். இருப்பினும், அவை மாதிரி வெளியீட்டைப் பற்றிய மாதிரியின் தீர்ப்பே ஆகும், எனவே அவற்றை ஒரு எல்லையாகக் கருதாமல், ஒரு வடிகட்டியாகக் (filter) கருதவும்.

ஒரு நிர்வாகி இவை இரண்டையும் நீக்க முடியும். ஒரு settings கோப்பில் permissions.disableBypassPermissionsMode அல்லது permissions.disableAutoMode என்பதை "disable" என அமைக்கவும். அந்த கோப்பை நிர்வகிக்கப்படும் அமைப்புகளில் (managed settings) வைக்கவும், அப்போதுதான் checked-out செய்யப்பட்ட ஒரு project-ஆல் அதை மாற்றியமைக்க முடியாது. Claude Code auto முறை மற்றும் அனுமதி விதிகள் குறித்த எங்கள் வழிகாட்டி, ஒவ்வொரு விதியும் எங்கு நடைமுறைக்கு வரும் என்பதை விளக்குகிறது.

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.

இன்னும் தீர்க்கப்படாதவை

இன்று உள்ளடக்கத்திற்கும் அறிவுறுத்தலுக்கும் இடையே நம்பகமான பிரிவினை இல்லை. தற்போது பயன்பாட்டில் உள்ள ஒவ்வொரு பாதுகாப்பு நடவடிக்கையும் தோல்வி விகிதத்தைக் கொண்ட ஒரு வடிகட்டி அல்லது விளைவுகளைக் கட்டுப்படுத்தும் ஒரு வரம்பு மட்டுமே. எந்தவொரு மென்பொருள் அடுக்கிலும் (stack), ஒரு உரைப்பகுதியை ஒருபோதும் செயல்படுத்தக்கூடாத தரவு என அடையாளப்படுத்தும் வசதி இல்லை.

வடிகட்டிகள் உதவுகின்றன, ஆனால் அவை தோல்வியடைகின்றன. பெரும்பாலான ஊடுருவல் முயற்சிகளைத் தடுக்கும் ஒரு வகைப்படுத்தி (classifier) ஒவ்வொரு முறையும் சரியாகச் செயல்பட வேண்டும், ஆனால் ஒரு தாக்குதல் நடத்துபவர் ஒருமுறை சரியாகச் செயல்பட்டாலே போதுமானது. இந்த சமச்சீரற்ற தன்மையே, ஒரு பாதுகாப்பு நடவடிக்கையின் வெற்றி விகிதம் என்பது உத்தரவாதம் அல்ல, மாறாக அடுத்தகட்ட தாக்குதலுக்கான தொடக்கப்புள்ளி என்பதை உணர்த்துகிறது.

மிகவும் நம்பிக்கையூட்டும் ஆய்வுகள் மாதிரி (model) நிலையில் இல்லாமல், வடிவமைப்பு (design) நிலையில் உள்ளன. Defeating Prompt Injections by Design (Debenedetti மற்றும் குழுவினர், 2025) ஆய்வறிக்கையில் உள்ள CaMeL, நம்பகமான கோரிக்கையிலிருந்து கட்டுப்பாட்டு ஓட்டம் (control flow) மற்றும் தரவு ஓட்டத்தை (data flow) முதலில் பிரித்தெடுக்கிறது. இதனால் நம்பகத்தன்மையற்ற தரவு நிரலின் செயல்பாட்டை மாற்ற முடியாது. பின்னர், கருவிகள் அழைக்கப்படும்போது திறன் சோதனைகளை (capability checks) அமல்படுத்துகிறது. AgentDojo benchmark-ல் இந்த ஆய்வறிக்கை காட்டும் புள்ளிவிவரங்கள் இதற்கான விலையை உணர்த்துகின்றன.

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

பாதுகாப்பு இல்லாத முகவர் (agent) 84 சதவீத பணிகளை முடித்தது. CaMeL பாதுகாப்பு உத்தரவாதத்துடன் 77 சதவீத பணிகளை முடித்தது. இவை ஒரு குறிப்பிட்ட benchmark-ல் வெளியிடப்பட்ட புள்ளிவிவரங்கள் மட்டுமே; இவை உங்கள் பணிச்சுமைக்கான அளவீடு அல்ல. இவற்றுக்கு இடையேயான இடைவெளிதான், இன்றைய சூழலில் ஒரு உண்மையான பாதுகாப்பு உத்தரவாதத்திற்கான தோராயமான விலை.

நீங்கள் அன்றாடம் பயன்படுத்தும் கருவிகளில் இத்தகைய வடிவமைப்பு வரும் வரை, முகவர் ஏதோ ஒரு கட்டத்தில் சமரசம் (compromise) செய்யப்படும் என்று திட்டமிடுங்கள், மேலும் அந்த நிகழ்வை ஒரு சாதாரணமானதாக மாற்றுங்கள். இதற்காகவே தற்காலிக இயந்திரங்கள் (disposable machine), வரையறுக்கப்பட்ட நற்சான்றிதழ்கள் (scoped credentials), கட்டுப்படுத்தப்பட்ட வெளியேறும் போக்குவரத்து (controlled egress) மற்றும் மாற்றங்களைச் சரிபார்க்கும் பழக்கம் (reading the diff) ஆகியவை அவசியமாகின்றன.

FAQ

கோப்புகளில் உள்ள அறிவுறுத்தல்களைப் புறக்கணிக்குமாறு ஏஜென்டிடம் கூறுவதன் மூலம் prompt injection-ஐத் தடுக்க முடியுமா?

முடியாது. அந்த வாக்கியமும் தாக்குதல் நடக்கும் அதே context window-ல் உள்ள உரைதான், எனவே அது தாக்குபவரின் உரைக்கு நிகராகவே போட்டியிடும். Claude Code-ன் ஆவணங்கள் இதைத் தெளிவாகக் குறிப்பிடுகின்றன: உங்கள் prompt அல்லது CLAUDE.md-ல் உள்ள அறிவுறுத்தல்கள் ஏஜென்ட் என்ன செய்ய முயல்கிறது என்பதை மட்டுமே வடிவமைக்கின்றன, அவை கருவி (tool) எதை அனுமதிக்கிறது என்பதை மாற்றுவதில்லை. ஒரு அறிவுறுத்தல் கோப்பை (instruction file) ஒரு விருப்பத்தின் வெளிப்பாடாகக் கருதுங்கள்; நீங்கள் எதை நம்புகிறீர்களோ அதை permission rules, PreToolUse hook அல்லது firewall rule-ல் குறிப்பிடுங்கள்.

ஏஜென்ட் எனது சொந்த repository-ஐ மட்டுமே அணுகினால் prompt injection ஒரு உண்மையான ஆபத்தா?

ஆம், ஏனெனில் உங்கள் repository-ல் நீங்கள் எழுதாத உரைகள் ஏராளமாக உள்ளன. Dependency README கோப்புகள், lockfile URL-கள், test fixtures, vendored code மற்றும் npm install-ன் வெளியீடு என அனைத்தும் ஒரு சாதாரண பணியின் போது உள்ளே வருகின்றன. issue tracker அல்லது ஆவணத் தளத்திலிருந்து பெறப்படும் எதவும் அதே வழியில்தான் வருகின்றன. ஏஜென்ட் எவ்வளவு அதிகமாக வாசிக்கிறதோ, அந்த அளவுக்கு ஆபத்து அதிகரிக்கிறது; பயனுள்ள ஒரு ஏஜென்ட் நிறைய வாசிக்கும்.

ஏஜென்ட்டை ஒரு container-ல் இயக்குவது இந்தச் சிக்கலைத் தீர்க்குமா?

இது பாதிப்பைக் குறைக்கும், ஆனால் நீங்கள் அதிலிருந்து credentials-ஐயும் நீக்கினால் மட்டுமே இது சாத்தியம். உங்கள் SSH agent forwarded செய்யப்பட்ட, cloud credentials சூழலில் (environment) உள்ள மற்றும் கட்டுப்பாடற்ற network access கொண்ட ஒரு container, host கணினியில் உள்ள அனைத்தையும் தாக்குபவருக்குக் கொடுத்துவிடும். ஒரு container உங்களுக்கு உண்மையில் தருவது என்னவென்றால், நீங்கள் அழித்துவிடக்கூடிய ஒரு filesystem மற்றும் egress விதிகளை அமல்படுத்த ஒரு தெளிவான இடம் மட்டுமே. இதை ஒரு repository-க்கு மட்டும் கட்டுப்படுத்தப்பட்ட token-உடன் சேர்த்துப் பயன்படுத்துங்கள்.

எந்த ஒரு மாற்றத்தைச் செய்வது ஆபத்தை மிகக் குறைவாகக் குறைக்கும்?

ஏஜென்ட்டின் கட்டளைகள் இயங்கும் சூழலில் இருந்து நீண்ட காலம் பயன்படும் (long-lived) credentials-ஐ நீக்குங்கள், பிறகு அந்த இயந்திரத்திற்கு default-deny egress policy-ஐக் கொடுங்கள். இவை இரண்டும் சேர்ந்து ஆபத்தான மூன்றாம் காரணியை உடைக்கின்றன: உரை இன்னும் ஏஜென்ட்டைக் கடத்த (hijack) முடியும், ஆனால் அது சென்றடையும் தரவு வெளியே செல்ல வழியில்லை. Approval prompts மற்றும் diff review ஆகியவையும் உதவும், ஆனால் அவை நீண்ட நேரம் இயங்கும் பணியின் போது மனிதர் விழிப்புடன் இருப்பதைச் சார்ந்திருக்கின்றன, அதனால்தான் அவை இந்த இரண்டு மாற்றங்களுக்குக் கீழே தரவரிசைப்படுத்தப்பட்டுள்ளன.