AI agents-ல் API keys பாதுகாப்பாக பயன்படுத்துவது எப்படி?

AI agents-ல் ரகசியங்களை ஏன் வைத்திருக்கக்கூடாது என்பதன் பொருள்

AI agent என்பது கட்டளைகளை இயக்கும் ஒரு சாதாரண Linux process ஆகும். அந்த process-ல் உள்ள ஒவ்வொரு environment variable-ஐயும் அது இயக்கும் code-ஆல் வாசிக்க முடியும். எனவே, ஒரு agent-ன் environment-ல் உள்ள API key-ஐ, அந்த agent தான் தொடர்பு கொள்ளக்கூடிய எந்தவொரு host-க்கும் அனுப்பிவிட முடியும். ரகசியங்களை agent-ல் வைத்திருக்கக்கூடாது என்பதன் பொருள், அதற்கு நேரடியாக key-ஐ வழங்குவதற்குப் பதிலாக ஒரு handle-ஐ வழங்குவதாகும்: அதாவது, குறுகிய காலத்திற்கு மட்டும் செல்லுபடியாகும் scoped token அல்லது network எல்லையில் உண்மையான மதிப்பால் மாற்றப்படும் ஒரு placeholder-ஐப் பயன்படுத்த வேண்டும்.

இது ஒரு model தீயதாக மாறுவது பற்றிய கதை அல்ல. இதன் செயல்முறை மிகவும் எளிமையானது. ஒரு agent இணையப்பக்கம், README, அல்லது issue comment ஆகியவற்றில் உள்ள அறிவுறுத்தல்களை வாசித்து, அதன்படி செயல்படுகிறது. ஏனெனில், ஒரு language model-க்கு நீங்கள் எழுதிய உரைக்கும், அது இணையத்திலிருந்து பெற்ற உரைக்கும் எந்த வித்தியாசமும் தெரியாது. இதுவே prompt injection ஆகும். இது நிகழ்ந்தவுடன், ஏற்படும் பாதிப்பு ஒரே ஒரு விஷயத்தால் மட்டுமே கட்டுப்படுத்தப்படுகிறது: அந்த process எதை வாசிக்க முடியும் என்பதுதான். நீங்கள் இன்னும் ஒரு எல்லையை (boundary) உருவாக்கவில்லை என்றால், server-ல் coding agent-ஐ பாதுகாப்பாக இயக்குவது என்ற பகுதி, இந்த வழிகாட்டிக்கு அடிப்படையாக உள்ள isolation முறைகளை விளக்குகிறது.

அச்சுறுத்தல் மாதிரியின் எளிய விளக்கம்

உங்கள் agent எந்த பயனர் கணக்கில் இயங்குகிறதோ, அதே கணக்கில் இதை இயக்கவும்.

tr '\0' '\n' < /proc/self/environ | grep -iE 'key|token|secret|password'

இது அச்சிடும் ஒவ்வொரு வரியும், அந்நியர் ஒருவரின் server-க்கு அனுப்பப்படும் ஒரு HTTP கோரிக்கைக்குச் சமம். இப்போது, agent-க்கு அருகில் வட்டில் (disk) என்னென்ன கோப்புகள் உள்ளன என்று கவனியுங்கள்.

grep -rIl --exclude-dir=.git -e 'API_KEY' -e 'SECRET' ~/projects
find ~ -maxdepth 3 -name '.env' -o -name 'credentials' -o -name '*.pem'

Shell அணுகல் கொண்ட ஒரு agent-க்கு, தரவுகளை வெளியேற்ற எந்தவொரு சிக்கலான exploit-ம் தேவையில்லை. சாதாரணமான நான்கு வழிகள் இதற்குப் போதுமானவை; இவை அனைத்தும் log-ல் சாதாரண வேலைகளைப் போலவே தோன்றும்:

• ஏதேனும் ஒரு host-க்கு அனுப்பப்படும் curl அல்லது fetch கோரிக்கை; இதில் தரவு query string-ல் இருக்கும்.
• agent-ஆல் எழுதக்கூடிய repository-க்கு செய்யப்படும் git commit மற்றும் git push.
• ஒரு package install script; இது agent-ன் பயனர் உரிமையுடன் தன்னிச்சையான குறியீடுகளை (arbitrary code) இயக்கும்.
• தரவை உள்ளடக்கிய hostname-க்கான DNS lookup; HTTP egress தடுக்கப்பட்டிருந்தாலும் இது செயல்படும்.

இவற்றை ஆய்வு செய்வதன் மூலம் மட்டும் நீங்கள் தப்பிக்க முடியாது. முக்கியமான தரவுகள் எதுவும் agent-ன் அணுகலுக்குள் இல்லை என்பதை உறுதிப்படுத்துவதே இதற்கான தீர்வாகும்.

வேலை செய்யும் கோப்பகத்தில் (working tree) உள்ள ஒரு ரகசியம், context window-விலும் ஒரு ரகசியமே

ஒரு agent கோப்புகளை வாசிக்கும். அது வேலை செய்யும் repository-ல் உள்ள ஒரு .env கோப்பு வாசிக்கப்படும். அது வாசிக்கப்பட்டவுடன், அது context window-விற்குள் வந்துவிடும். அதாவது, அது transcript-ல் இருக்கும், நீங்கள் வைத்திருக்கும் எந்தவொரு log-லும் இருக்கும், மேலும் அந்த agent அடுத்து என்ன எழுதுகிறதோ அதிலும் இருக்கும்.

முன்பு, அந்த agent வேலை செய்யும் கோப்பகத்திலேயே key இருந்தபோது:

cd ~/projects/billing
cat .env
# STRIPE_SECRET_KEY=sk_live_...
# DATABASE_URL=postgres://app:hunter2@db.internal:5432/billing

பிறகு, அந்த கோப்பு எட்டாத தூரத்திற்கு நகர்த்தப்பட்ட பிறகு:

sudo install -d -m 750 -o root -g agent-review /etc/agent-review
sudo install -m 640 -o root -g agent-review ~/projects/billing/.env /etc/agent-review/billing.env
rm ~/projects/billing/.env

அந்த agent-ன் பயனர் இனி அந்த கோப்பைத் திறக்க முடியாது, ஏனெனில் வேலை செய்யும் கோப்பகத்தில் அது இல்லை. அந்த agent-ன் சொந்த config-ல் உள்ள Deny விதிகள் இரண்டாவது அடுக்கு பாதுகாப்பு, முதல் அடுக்கு அல்ல. Claude Code, திட்டத்தில் உள்ள .claude/settings.json-லிருந்து அனுமதி விதிகளை வாசிக்கும்:

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

இது, agent கோப்புகளை ஆராயும்போது தவறுதலாகத் திறப்பதைத் தடுக்கும். ஆனால், இது base64 .env-ஐ இயக்குவதிலிருந்து தடுக்காது, ஏனெனில் அது ஒரு shell command, கோப்பு வாசிப்பு அல்ல. அந்த command இயங்குவதற்கு முன்பு உங்களிடம் அனுமதி கேட்கப்படுமா என்பது அந்த session-ன் permission mode-ஐப் பொறுத்தது. ஆகஸ்ட் 2026-ல் auto mode என்பது Claude Code-ன் இயல்புநிலை அமைப்பாக மாறும், எனவே நீங்கள் கவனிக்காத ஒரு server-ல், கேட்கப்படாமலேயே இதுபோன்ற பல command-கள் இயங்கும். agent-ன் அனுமதிகளை விட அதன் பழக்கவழக்கங்களை வடிவமைக்கும் எதற்கும் இதே வரம்பு பொருந்தும்: வேலை செய்யும் மிகச்சிறிய மாற்றத்தை மட்டும் செய்ய agent-ஐக் கட்டுப்படுத்தும் திறன், அந்த agent தேவையில்லாமல் கோப்புகளைத் திறப்பதைத் தடுக்கும். ஆனால், இது வெறும் அறிவுரை மட்டுமே, இதை மீறும்படி அந்த model-ஐ வற்புறுத்த முடியும். config-ஐ ஒரு தடுப்பு வேலியாகவும் (guardrail), filesystem அனுமதியை ஒரு சுவராகவும் கருதுங்கள். இதே பிரிவினை containers-க்கும் பொருந்தும்: Docker Compose-ல் உள்ள env கோப்புகள் மற்றும் ரகசியங்கள் இந்தச் சிக்கலின் ஒரு அடுக்கு கீழே உள்ள பதிப்பைப் பற்றி விளக்குகிறது.

ஒவ்வொரு agent-க்கும் தனிப்பட்ட unprivileged user-ஐ ஒதுக்குதல்

Agent உங்கள் பயனர் கணக்கில் இயங்கினால், அது உங்கள் SSH keys, cloud credentials மற்றும் shell history ஆகியவற்றை அணுகும். ஒரு தனி பயனர் கணக்கை உருவாக்குவது ஒரு கட்டளை மட்டுமே, ஆனால் அது இந்த அபாயங்கள் அனைத்தையும் நீக்குகிறது.

sudo adduser --disabled-password --gecos "" agent-review
sudo chmod 700 /home/agent-review
sudo -u agent-review cat ~/.ssh/id_ed25519

கடைசி வரி cat: /home/you/.ssh/id_ed25519: Permission denied பிழையுடன் தோல்வியடைய வேண்டும். அது ஒரு key-ஐ வெளியிட்டால், உங்கள் home directory மற்றவர்கள் வாசிக்கும் வகையில் (group or world readable) உள்ளது என்று அர்த்தம்; அதை chmod 700 ~ மூலம் சரிசெய்யலாம். Agent பயனரை sudo குழுவில் சேர்க்க வேண்டாம், மேலும் அதற்குத் தேவையான ஒரு கட்டளைக்கு மேல் எதற்கும் NOPASSWD அனுமதியை வழங்க வேண்டாம். VPS-ல் குறைந்தபட்ச அதிகாரமுள்ள பயனர்கள் பகுதியில் group மற்றும் sudoers குறித்த விவரங்கள் உள்ளன. ஒரு box-ல் ஒன்றுக்கு மேற்பட்ட session-களை இயக்கும்போது இந்த பிரிவினையை நினைவில் கொள்ளுங்கள், ஏனெனில் ஒரு Claude Code session மற்றொரு session-க்கு நேரடியாக உரையை அனுப்ப முடியும், மேலும் முதல் session-ல் உள்ள தகவல்கள் அந்த channel வழியாக ஒரே செய்தியில் பரிமாறப்படலாம்.

Cloud VPS-ல் கூடுதலாக ஒரு பாதுகாப்பு எல்லையைச் சேர்ப்பது அவசியம். Instance metadata service ஒரு நிலையான link local முகவரியில் இயங்குகிறது, இது கோரும் எதற்கும் role credentials-ஐ வழங்கும்.

sudo iptables -A OUTPUT -m owner --uid-owner agent-review -d 169.254.169.254 -j REJECT

இதை agent-ன் பக்கத்திலிருந்து சரிபார்க்கவும். sudo -u agent-review curl -s --max-time 3 http://169.254.169.254/ எந்த வெளியீட்டையும் காட்டாமல், non-zero status-உடன் வெளியேற வேண்டும், ஏனெனில் அந்த packet box-ஐ விட்டு வெளியேறும் முன்பே நிராகரிக்கப்பட வேண்டும்.

எல்லையில் நற்சான்றிதழைச் செலுத்துதல் (Inject the credential at the boundary)

இந்தச் சிக்கலைத் தீர்க்கும் முறை நற்சான்றிதழ் செலுத்துதல் (credential injection) ஆகும். முகவர் (agent) ஒருபோதும் உண்மையான சாவியை (key) வைத்திருக்காது. அது தனது கோரிக்கையை ஒரு உள்ளூர் நுழைவாயில் (local gateway) வழியாக அனுப்புகிறது; அந்த நுழைவாயில் வெளியேறும் வழியில் ஒரு தற்காலிக அடையாளத்திற்குப் (placeholder) பதிலாக உண்மையான ரகசியத்தை (secret) மாற்றுகிறது. இந்த ரகசியம் நுழைவாயிலின் சேமிப்பகத்தில், வேறொரு பயனர் உரிமையிலுள்ள, வேறொரு செயல்முறையில் (process) பாதுகாக்கப்படுகிறது.

OneCLI என்பது இதன் ஒரு திறந்த மூல (open source) செயலாக்கம் ஆகும். இது Apache-2.0 உரிமம் பெற்றது மற்றும் முகவருக்கு அருகில் ஒரு container-ஆக இயங்குகிறது. ஜூலை 2026 நிலவரப்படி, இந்தத் திட்டம் இந்த அமைப்பை இவ்வாறு ஆவணப்படுத்துகிறது:

git clone https://github.com/onecli/onecli.git
cd onecli
docker compose -f docker/docker-compose.yml up -d --wait

இந்த dashboard 10254 port-லும், நுழைவாயில் 10255 port-லும் கேட்கின்றன (listen). நீங்கள் உண்மையான நற்சான்றிதழை ஒருமுறை சேமிக்கிறீர்கள்; பின்னர் ஒவ்வொரு முகவருக்கும் சாவியின் இடத்திற்கு ஒரு தற்காலிக அடையாள மதிப்பையும், அதனுடன் அதன் சொந்த அணுகல் டோக்கனையும் (scoped access token) வழங்குகிறீர்கள். முகவர் அதை ஒரு Proxy-Authorization header-ல் அனுப்புகிறது. நுழைவாயில், வெளியேறும் கோரிக்கையை host மற்றும் path மூலம் பொருத்தி, தொடர்புடைய நற்சான்றிதழை மறைகுறியாக்கம் (decrypt) செய்து, அதை மாற்றீடு செய்கிறது. முகவரின் சூழலில் திருடுவதற்குத் தகுந்த மதிப்புள்ள தகவல்கள் எதுவும் இருக்காது.

இங்குள்ள முக்கிய அம்சம் மறைகுறியாக்கம் அல்ல. "இந்த முகவர் எதைப் பயன்படுத்தியது, எப்போது பயன்படுத்தியது" என்ற கேள்வி ஒரு log query-ஆக மாறுவதே இதன் பயன். ஆறு வெவ்வேறு சூழல்களில் எதில் சாவி இருந்தது என்று ஊகிப்பதற்குப் பதிலாக, ஒரே ஒரு தணிக்கைப் பாதையை (audit trail) நீங்கள் வாசிக்கலாம்.

ரகசியத்தை environment-க்கு வழங்காமல், process-க்கு நேரடியாக வழங்கவும்

நீங்கள் systemd-ன் கீழ் agent-ஐ இயக்கினால், environment variables உங்களுக்குத் தேவையில்லை. LoadCredential= ரகசியத்தை அந்த service மட்டுமே படிக்கக்கூடிய ஒரு private directory-ல் வைக்கிறது. இது unit file-ல் %d ஆகவும், process-க்குள் $CREDENTIALS_DIRECTORY ஆகவும் வெளிப்படுத்தப்படுகிறது. இந்த மதிப்பு ஒருபோதும் /proc/<pid>/environ-ல் தோன்றாது, எனவே ps eww-ஆல் அதைக் காட்ட முடியாது. service நிறுத்தப்படும்போது அந்த directory மறைந்துவிடும்.

முதலில் credential-ஐ அந்த machine-க்கு encrypt செய்யவும். இந்த commands systemd ஆவணங்களிலிருந்து பெறப்பட்டவை. இவை systemd 250 அல்லது அதற்குப் பிந்தைய பதிப்புகளில் வேலை செய்யும்; இது Ubuntu 24.04 மற்றும் Debian 13 ஆகியவற்றை உள்ளடக்கியது:

echo -n 'sk-example-value' > /tmp/plain.txt
sudo systemd-creds encrypt --name=api_key /tmp/plain.txt /etc/credstore/api_key.cred
shred -u /tmp/plain.txt
sudo systemd-run -P --wait -p LoadCredentialEncrypted=api_key:/etc/credstore/api_key.cred \
  systemd-creds cat api_key

கடைசி command sk-example-value-ஐ அச்சிடுகிறது. அந்த encrypted file இந்த host-ல் decrypt ஆகிறது என்பதை இது உறுதிப்படுத்துகிறது. பிறகு, அதை unit file-ல் இவ்வாறு குறிப்பிடவும்:

[Service]
User=agent-review
LoadCredentialEncrypted=api_key:/etc/credstore/api_key.cred
Environment=AGENT_KEY_FILE=%d/api_key
ExecStart=/usr/local/bin/agent-worker

உங்கள் agent code-க்கு அந்த மதிப்பு தேவைப்படும்போது, அது $AGENT_KEY_FILE-ல் உள்ள கோப்பைத் திறக்கும். கோப்பைப் படிப்பது ஒரு கணநேரச் செயல். ஆனால், environment variable என்பது process இருக்கும் காலம் முழுவதும், அது உருவாக்கும் ஒவ்வொரு child process-லும் நீடித்திருக்கும்.

நீண்ட கால பயன்பாட்டு விசைகளை விட குறுகிய கால டோக்கன்களை முன்னுரிமைப்படுத்துங்கள்

காலாவதி தேதி இல்லாத ஒரு விசை, பல மாதங்களுக்குப் பிறகு log அல்லது transcript-ல் வெளிப்பட்டாலும், அது இன்னும் செல்லுபடியாகும். ஒரு சேவை session token-ஐ வழங்கினால், அதைப் பயன்படுத்தி, உங்கள் பணிக்குத் தேவையான மிகக் குறைந்த கால அளவை (lifetime) அமைக்கவும்.

aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/agent-readonly \
  --role-session-name agent-review \
  --duration-seconds 900

AWS STS (security token service) ஏற்கும் குறைந்தபட்ச கால அளவு 15 நிமிடங்கள் ஆகும்; இது ஒரு agent பணிக்கு பொதுவாக போதுமானது. GitHub-ஐப் பொறுத்தவரை, அந்த agent பயனருக்குத் தனிப்பட்ட gh login-ஐ வழங்கவும். அது பணிபுரியும் ஒரு குறிப்பிட்ட repository-க்கு மட்டும் கட்டுப்படுத்தப்பட்ட fine grained token-ஐப் பயன்படுத்தவும். இதன் மூலம், அந்த session-க்குள் இருக்கும் gh auth token, மற்ற எதையும் அணுக முடியாதவாறு இருக்கும். முதலில் resource அடிப்படையிலும், பிறகு கால அடிப்படையிலும் கட்டுப்பாடுகளை (scope) விதிக்கவும்.

சரிபார்த்தல், மீண்டும் சரிபார்த்தல்

ஏஜென்ட் அமைப்பில் ஏதேனும் மாற்றம் செய்த பிறகு, மூன்று சோதனைகளை மேற்கொள்வது அவசியம். இவற்றை நீங்களாகச் செய்யாமல், ஏஜென்ட்டின் பயனர் கணக்கின் (agent's user) மூலம் இயக்கவும்.

sudo -u agent-review env | grep -iE 'key|token|secret'
sudo -u agent-review ls -la /home/you/ 2>&1 | head -3
sudo -u agent-review curl -s -o /dev/null -w '%{http_code}\n' --max-time 5 https://api.github.com/user

முதல் சோதனை எதையும் அச்சிடக்கூடாது. இரண்டாவது சோதனை ls: cannot open directory '/home/you/': Permission denied என்பதை அச்சிட வேண்டும். மூன்றாவது சோதனை, ஏஜென்ட்டின் நெட்வொர்க் பாதை எந்த அடையாளத்தை வெளிப்படுத்துகிறது என்பதைக் காட்டும்; இதுவே கேட்வே பேட்டர்ன் (gateway pattern) தீர்க்கும் கேள்வியாகும்: 401 என்பது ஏஜென்ட்டிடம் சொந்தமாக GitHub நற்சான்றிதழ் (credential) இல்லை என்பதைக் குறிக்கிறது, 200 என்பது அது ஒரு நற்சான்றிதழை வைத்திருக்கிறது என்பதைக் குறிக்கிறது, எனவே எந்த டோக்கன் பயன்படுத்தப்படுகிறது என்பதை நீங்கள் அறிந்திருக்க வேண்டும். நீங்கள் ஏஜென்ட்களைக் கவனிக்கப்படாத நிலையில் (unattended) இயக்கினால், VPS-ல் AI ஏஜென்ட் செலவுகளைக் கட்டுப்படுத்துதல் என்ற பகுதி, இந்த அணுகல் வரம்புகளுடன் இணைந்து செயல்படும் பட்ஜெட் வரம்புகளைப் பற்றி விளக்குகிறது.

FAQ

எனது ரகசியக் குறியீடுகளை (keys) கசியவிடாது என்று இந்த மாடலை நான் நம்பலாமா?

முடியாது. ஏனெனில், இந்த அச்சுறுத்தல் மாதிரியில் (threat model) மாடல் ஒரு தாக்குதல் நடத்துபவர் அல்ல. இந்த ஏஜென்ட் இணையப் பக்கங்கள், repositories மற்றும் issue trackers ஆகியவற்றிலிருந்து உரையை வாசிக்கும்; அந்த உரையில் கட்டளைகள் இருக்கலாம். தான் பெற்றுக்கொண்ட உரையில் எது உங்கள் கட்டளை, எது மற்றவை என்பதைப் பிரித்தறியும் நம்பகமான வழி மாடலுக்கு இல்லை. ஊடுருவப்பட்ட கட்டளை (injected instruction) நம்பும்படியாக இருக்கும்போது, மாடலின் முடிவைச் சார்ந்திருக்கும் எந்தவொரு கட்டுப்பாடும் தோல்வியடையும். எனவே, அத்தகைய கட்டுப்பாடுகள் operating system அல்லது network மட்டத்திலேயே இருக்க வேண்டும்.

ஏஜென்ட் ரகசியங்களுக்கு environment variables பயன்படுத்துவது உண்மையிலேயே மோசமானதா?

அவை ஒரு குறிப்பிட்ட வகையில் மோசமானவை: அவை மரபுரிமையாக (inherited) கிடைக்கின்றன. ஏஜென்ட் உருவாக்கும் ஒவ்வொரு child process-க்கும், build script, test runner மற்றும் package install hook உட்பட, அந்த variables-ன் நகல் கிடைத்துவிடும். அதே பயனரால் /proc/<pid>/environ மூலமாகவும் அந்த variables-ஐ வாசிக்க முடியும். எனவே, ஏஜென்ட் எதையும் பகிராமலேயே, அது இயக்கும் எந்தவொரு நிரலும் அவற்றை வாசிக்க முடியும். பயன்படும் தருணத்தில் மட்டும் LoadCredential= அல்லது ஒரு gateway மூலம் வாசிக்கப்படும் கோப்பு, அந்தத் தருணத்தில் மட்டுமே வெளிப்பாட்டை (exposure) கட்டுப்படுத்துகிறது.

ரகசியங்களை ஒரு vault-ல் வைப்பது மட்டும் இதற்குத் தீர்வாகுமா?

பகுதியளவு மட்டுமே. ஒரு vault சேமிப்பகத்தைச் சரிசெய்கிறது. நீங்கள் அந்த vault-ஐ நீங்களே host செய்தால், அதற்குத் தனிப்பட்ட பாதுகாப்பு நடவடிக்கைகள் தேவை. ஏனெனில், ஒரு Vaultwarden server பொதுவாக அதன் admin token அல்லது backup file மூலமே உடைக்கப்படுகிறது, அதில் உள்ள encrypted பொருட்கள் மூலம் அல்ல. இது இறுதிப் படியைச் சரிசெய்யாது; அதாவது, vault-லிருந்து ரகசியத்தை எடுத்து ஏஜென்டிடம் environment variable-ஆகக் கொடுக்கும்போது, நீங்கள் மீண்டும் பழைய நிலைக்கு வந்துவிடுவீர்கள். ரகசியத்தை யார் மாற்றீடு (substitution) செய்கிறார்கள் என்பதே முக்கியம். ஏஜென்ட் ரகசியத்தைப் பெற்றால், ஏஜென்டிடம் ரகசியம் இருக்கும். ஒரு gateway அல்லது init system ஏஜென்ட்டின் process-க்கு வெளியே மாற்றீடு செய்தால், ஏஜென்ட் ஒருபோதும் ரகசியத்தைக் கொண்டிருக்காது.

ஒரு ஏஜென்ட் ஏற்கனவே எதையாவது கசியவிட்டுவிட்டதா என்பதை நான் எப்படி அறிவது?

பொதுவாக, நடந்த பிறகு இதைக் கண்டறிய முடியாது; இதனால்தான் gateway பயன்படுத்தப் பரிந்துரைக்கப்படுகிறது. அது இல்லையென்றால், உங்கள் ஆதாரங்கள் shell history, ஏஜென்ட்டின் transcript மற்றும் நீங்கள் பெரும்பாலும் பராமரிக்காத outbound connection logs ஆகியவற்றில் சிதறிக்கிடக்கும். ஒரு credential gateway இருந்தால், ஒவ்வொரு முறை credential பயன்படுத்தப்படும்போதும், ஏஜென்ட்டின் அடையாளம் மற்றும் நேர முத்திரையுடன் (timestamp) ஒரு வரி பதிவாகும். கசிவு இருப்பதாகச் சந்தேகித்தால், முதலில் key-ஐ மாற்றிவிட்டு (rotate), பிறகு விசாரணையைத் தொடங்குங்கள். key-ஐ மாற்றுவது எளிது, ஆனால் உறுதித்தன்மை கிடைப்பது கடினம்.

இன்று நான் செய்ய வேண்டிய குறைந்தபட்ச நடவடிக்கை என்ன?

ஒவ்வொரு .env கோப்பையும் உங்கள் ஏஜென்ட்கள் வேலை செய்யும் directories-லிருந்து வெளியேற்றுங்கள். ஒவ்வொரு ஏஜென்ட்டுக்கும் ஒரு unprivileged user-ஐ உருவாக்குங்கள். இந்த இரண்டு மாற்றங்களும் சுமார் பத்து நிமிடங்களில் முடிந்துவிடும். இவை மிகவும் பொதுவான பாதையை அடைத்துவிடும்; அதாவது, குறியீட்டிற்கு (code) அருகில் இருக்க வேண்டிய அவசியமே இல்லாத ஒரு credential கோப்பை ஏஜென்ட் வாசிப்பதைத் தடுக்கும். Gateway மற்றும் குறுகிய கால tokens (short lived tokens) அடுத்தகட்ட நடவடிக்கைகள், முதல் கட்டம் அல்ல. இதே தொடக்கப் புள்ளி எந்தவொரு ஏஜென்ட் runtime-க்கும் பொருந்தும், ஒரு VPS-ல் தன்னாட்சி ஏஜென்ட்டைப் பாதுகாப்பாக இயக்குவது உட்பட.