AI agent-களிடம் API keys இல்லாமல் பாதுகாப்பது எப்படி

AI agents இடமிருந்து ரகசியங்களை விலக்கி வைத்திருப்பதன் பொருள்

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

இது model hostile ஆக மாறுவது பற்றிய கதை அல்ல. இதன் செயல்முறை மிகவும் எளிமையானது. Agent ஒரு web page, README, அல்லது instructions கொண்ட issue comment-ஐப் படித்து அவற்றைப் பின்பற்றுகிறது. Language model-க்கு நீங்கள் எழுதிய text-க்கும் அது fetch செய்த text-க்கும் வேறுபாடு இல்லை. இதுவே prompt injection. அது நடந்ததும், சேதத்தின் வரம்பை நிர்ணயிப்பது ஒரே ஒரு விஷயம்: process எதைப் படிக்க முடியும் என்பதே. நீங்கள் இன்னும் ஒரு boundary அமைக்கவில்லை என்றால், server-ல் coding agent-ஐப் பாதுகாப்பாக இயக்குதல் இந்த வழிகாட்டி சார்ந்திருக்கும் isolation படிநிலைகளை விளக்குகிறது.

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

உங்கள் agent இயக்கப்படும் user ஆக இதை இயக்கவும்.

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

அது வெளியிடும் ஒவ்வொரு வரியும், தெரியாத ஒருவரின் server-க்கு அனுப்பப்படும் ஒரு HTTP request ஆகும். இப்போது 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-க்கும் query string-ல் அந்த value-ஐ வைத்து அனுப்பப்படும் outbound curl அல்லது fetch.
• agent எழுதக்கூடிய repository-க்கு செய்யப்படும் git commit மற்றும் git push.
• package install script; இது agent-ன் user ஆக arbitrary code-ஐ இயக்கும்.
• அந்த value-ஐ கொண்ட hostname-ஐ தேடும் DNS lookup; HTTP egress தடுக்கப்பட்டிருந்தாலும் இது வெளியேறும்.

இதிலிருந்து review செய்வதன் மூலம் மட்டும் தப்பிக்க முடியாது. அணுகக்கூடிய இடத்தில் மதிப்புமிக்க தரவு எதுவும் இல்லாதபடி அமைப்பதே தீர்வு.

working tree-ல் உள்ள ரகசியம் context window-லும் இருக்கும்

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

முன்பு, agent செயல்படும் tree-ல் 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

working tree-ல் அந்தக் கோப்பு இல்லாததால், agent-ன் user இனி அந்தக் கோப்பைத் திறக்க முடியாது. agent-ன் சொந்த config-ல் உள்ள deny rules இரண்டாவது பாதுகாப்பு அடுக்கு மட்டுமே. அவை முதல் பாதுகாப்பு அடுக்கு அல்ல. Claude Code, project-ல் உள்ள .claude/settings.json-லிருந்து permission rules-ஐப் படிக்கும்:

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

ஆய்வு செய்யும்போது agent தவறுதலாக ஒரு கோப்பைத் திறப்பதை இது தடுக்கிறது. ஆனால் injected instruction base64 .env-ஐ இயக்குவதை இது தடுக்காது. காரணம், அது file read அல்ல; அது shell command. config-ஐ ஒரு guardrail ஆகவும், filesystem permission-ஐ தடுப்புச் சுவராகவும் கருதுங்கள். இதே பிரிப்பு containers-க்குள்ளும் பொருந்தும்: Docker Compose-ல் உள்ள env files மற்றும் secrets இந்தச் சிக்கலின் ஒரு layer கீழுள்ள பதிப்பை விளக்குகிறது.

ஒவ்வொரு agent-க்கும் தனி unprivileged user வழங்கவும்

agent உங்கள் user-ஆக இயங்கினால், அது உங்கள் SSH keys, cloud credentials மற்றும் shell history-ஐப் பெறும். தனி user-ஐ உருவாக்க ஒரு command போதுமானது; இதனால் இவை அனைத்தும் நீக்கப்படும்.

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 உடன் fail ஆக வேண்டும். அதற்குப் பதிலாக அது ஒரு key-ஐ அச்சிட்டால், உங்கள் home directory-க்கு group அல்லது world read permission உள்ளது. chmod 700 ~ இதைச் சரிசெய்யும். agent user-ஐ sudo-க்கு சேர்க்க வேண்டாம். அதற்கு உண்மையில் தேவைப்படும் ஒரே command-ஐ விட விரிவான NOPASSWD rule-ஐ வழங்க வேண்டாம். VPS-ல் குறைந்தபட்ச privilege கொண்ட users group மற்றும் sudoers விவரங்களை விளக்குகிறது.

Cloud VPS-ல் மேலும் ஒரு boundary-ஐ அமைக்க வேண்டும். Instance metadata service ஒரு நிலையான link-local address-ல் பதிலளிக்கும். கேட்கும் எந்த process-க்கும் அது 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 நிலையில் exit ஆக வேண்டும். காரணம், packet அந்த machine-ஐ விட்டு வெளியேறும் முன்பே reject செய்யப்படுகிறது.

எல்லை நிலையில் credential-ஐ உட்புகுத்துதல்

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

OneCLI இதற்கான ஒரு open source implementation ஆகும். இது Apache-2.0 உரிமத்தின் கீழ் வெளியிடப்படுகிறது. இது agent-க்கு அடுத்ததாக container ஆக இயங்கும். July 2026 நிலவரப்படி, project இந்த அமைப்பை ஆவணப்படுத்துகிறது:

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

dashboard port 10254-ல் listen செய்யும். gateway port 10255-ல் listen செய்யும். உண்மையான credential-ஐ ஒருமுறை சேமித்த பிறகு, key-க்கு பதிலாக ஒவ்வொரு agent-க்கும் placeholder value-ஐ வழங்க வேண்டும். அதனுடன், அந்த agent-க்கான வரையறுக்கப்பட்ட access token-ஐயும் வழங்க வேண்டும். agent அதை Proxy-Authorization header-ல் அனுப்பும். gateway, host மற்றும் path அடிப்படையில் outbound request-ஐப் பொருத்தும். பொருந்தும் credential-ஐ decrypt செய்து, அதற்குப் பதிலாக உண்மையான credential-ஐ இடும். agent-ன் environment-ல் திருடுவதற்குத் தகுந்த எந்த மதிப்பும் இருக்காது.

இங்கே முக்கியமானது encryption அல்ல. “இந்த agent எதைப் பயன்படுத்தியது, எப்போது பயன்படுத்தியது” என்ற கேள்விக்கு log query மூலம் பதில் பெற முடிவதே முக்கியம். ஆறு environment-களில் எதில் key-ன் நகல் இருந்தது என்று ஊகிப்பதற்குப் பதிலாக, ஒரே audit trail-ஐப் படிக்கலாம்.

ரகசியத்தை environment-க்கு அல்ல, process-க்கு வழங்குங்கள்

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

முதலில் credential-ஐ அந்த machine-க்காக encrypt செய்யுங்கள். இந்த commands systemd documentation-லிருந்து பெறப்பட்டவை. இவை 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-ல் குறிப்பிடுங்கள்:

[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-ல் உள்ள file-ஐத் திறக்கும். File read என்பது ஒரு கணநேரச் செயல். Environment variable process இயங்கும் முழுக் காலமும் நீடிக்கும். அது process உருவாக்கும் ஒவ்வொரு child-க்கும் கிடைக்கும்.

நீண்ட காலம் செல்லுபடியாகும் keys-க்கு பதிலாக குறுகிய காலம் செல்லுபடியாகும் tokens-ஐப் பயன்படுத்தவும்

காலாவதியாகாத key, பல மாதங்களுக்குப் பிறகு log அல்லது transcript-ல் வெளிப்பட்டாலும் செல்லுபடியாகும். service session token-ஐ வழங்கினால், அந்த 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 minutes ஆகும். பொதுவாக, இது ஒரு agent task-க்கு போதுமானது. GitHub-க்கு, agent user-க்கு தனியான gh login-ஐ வழங்கவும். அது, agent பணிபுரியும் ஒரே repository-க்கு மட்டும் வரையறுக்கப்பட்ட fine grained token-ஐப் பயன்படுத்த வேண்டும். இதனால் அந்த session-ல் உள்ள gh auth token, வேறு எதையும் அணுக முடியாத ஒன்றைத் திருப்பி வழங்கும். முதலில் resource அடிப்படையில் வரையறுக்கவும். பின்னர் time அடிப்படையில் வரையறுக்கவும்.

சரிபார்த்து, தொடர்ந்து சரிபார்க்கவும்

ஒரு agent-ன் அமைப்பில் எந்த மாற்றத்திற்குப் பிறகும் 3 சரிபார்ப்புகளை இயக்க வேண்டும். அவற்றை நீங்கள் அல்ல, அந்த agent-ன் 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-ஐக் காட்ட வேண்டும். மூன்றாவது சரிபார்ப்பு, agent-ன் network path வெளிப்படுத்தும் identity-ஐக் காட்டும். gateway pattern இருப்பதற்கான காரணத்தைக் கூறும் கேள்வி இதுதான்: 401 என்றால், agent தன்னுடைய GitHub credential எதையும் பயன்படுத்தவில்லை. 200 என்றால், agent ஒன்று பயன்படுத்துகிறது. எனவே எந்த token பயன்படுத்தப்படுகிறது என்பதை நீங்கள் அறிந்திருக்க வேண்டும். agents-ஐ unattended முறையில் இயக்கினால், VPS-ல் AI agent செலவுகளைக் கட்டுப்படுத்துதல் என்பது இந்த access limits-க்கு இணையான budget limits பற்றி விளக்குகிறது.

FAQ

எனது keys-ஐ கசியவிடாமல் model செயல்படும் என்று நம்பலாமா?

இல்லை. இந்த threat model-ல் attacker என்பது model அல்ல. agent, web pages, repositories மற்றும் issue trackers-இலிருந்து text-ஐ படிக்கிறது. அந்த text-ல் instructions இருக்கலாம். அது பெற்ற text-ஐ உங்கள் instructions-இலிருந்து நம்பகமாக வேறுபடுத்த model-க்கு வழி இல்லை. injected instruction நம்பத்தகுந்ததாகத் தோன்றும் முதல் முறையிலேயே, model சரியான முடிவை எடுக்கும் என நம்பியிருக்கும் எந்த control-மும் தோல்வியடையும். எனவே control operating system அல்லது network-ல் இருக்க வேண்டும்.

agent secrets-க்கு environment variables உண்மையிலேயே இவ்வளவு மோசமானவையா?

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

secrets-ஐ vault-ல் வைப்பது மட்டும் இந்தச் சிக்கலைத் தீர்க்குமா?

ஒரு பகுதி மட்டுமே. vault storage-ஐச் சரிசெய்கிறது. ஆனால் இறுதி படியை அது சரிசெய்யாது. அந்தப் படியில் ஏதோ ஒன்று vault-இலிருந்து secret-ஐ எடுத்து agent-க்கு environment variable-ஆக வழங்குகிறது. இதனால் நீங்கள் தொடங்கிய அதே நிலைக்குத் திரும்புகிறீர்கள். substitution-ஐ யார் செய்கிறார்கள் என்பதே முக்கியம். agent secret-ஐ fetch செய்தால், secret agent-க்குத் தெரியும். gateway அல்லது init system, agent-ன் process-க்கு வெளியே substitution-ஐ செய்தால், agent அதை ஒருபோதும் வைத்திருக்காது.

agent ஏற்கனவே ஏதாவது கசியவிட்டதா என்பதை எப்படித் தெரிந்துகொள்வது?

பொதுவாக, சம்பவத்திற்குப் பிறகு அதைத் தெரிந்துகொள்ள முடியாது. இதுவே gateway-க்கான காரணம். gateway இல்லாமல், உங்கள் evidence shell history, agent-ன் transcript மற்றும் நீங்கள் பெரும்பாலும் சேமிக்காத outbound connection logs ஆகியவற்றில் சிதறிக் கிடக்கும். credential gateway இருந்தால், credential பயன்படுத்தப்படும் ஒவ்வொரு முறையும் agent identity மற்றும் timestamp கொண்ட ஒரு line இருக்கும். leak ஏற்பட்டிருக்கலாம் என்று சந்தேகித்தால், முதலில் key-ஐ rotate செய்து, பிறகு investigate செய்யுங்கள். Rotation மலிவானது. உறுதியான தகவல் மலிவானது அல்ல.

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

agent-கள் செயல்படும் directories-இலிருந்து ஒவ்வொரு .env file-ஐயும் வெளியே மாற்றுங்கள். ஒவ்வொரு agent-க்கும் ஒரு unprivileged user-ஐ உருவாக்குங்கள். இந்த இரண்டு மாற்றங்களுக்கும் சுமார் 10 நிமிடங்கள் ஆகும். code-க்கு அருகில் இருக்க வேண்டிய அவசியமில்லாத credential file-ஐ agent படிப்பதே பொதுவான பாதை. gateway மற்றும் short lived tokens அடுத்த கட்ட நடவடிக்கைகள். அவை முதல் நடவடிக்கைகள் அல்ல. இந்தத் தொடக்க அணுகுமுறை, VPS-ல் autonomous agent-ஐப் பாதுகாப்பாக இயக்குதல் உட்பட எந்த agent runtime-க்கும் பொருந்தும்.