AI agentలకు API keys ఇవ్వకుండా secrets‌ను రక్షించండి

AI agents నుంచి secrets ను బయట ఉంచడం అంటే ఏమిటి

AI agent అనేది commands నడిపే సాధారణ Linux process. ఆ process లో ఉన్న ప్రతి environment variable ను అది అమలు చేసే code చదవగలదు. అందువల్ల agent environment లో ఉన్న API key ను agent చేరుకోగల ఏ host కు అయినా పంపగలదు. Agent నుంచి secrets ను బయట ఉంచడం అంటే key ను నేరుగా ఇవ్వకుండా దాని స్థానంలో ఒక handle ఇవ్వడం. ఇది స్వల్పకాలం మాత్రమే చెల్లే, పరిమిత పరిధి కలిగిన token కావచ్చు. లేదా network boundary వద్ద మరొక భాగం నిజమైన విలువతో మార్చే placeholder కావచ్చు.

ఇది model hostile గా మారే విషయం కాదు. వాస్తవ mechanism మరింత సాధారణమైనది. Instructions ఉన్న web page, README లేదా issue comment ను agent చదివి, వాటిని అనుసరిస్తుంది. Language model కు మీరు రాసిన text మరియు అది పొందిన text మధ్య తేడా ఉండదు. దీనినే prompt injection అంటారు. ఇది జరిగిన తర్వాత నష్టం ఎంతవరకు పరిమితం అవుతుందో నిర్ణయించేది ఒక్కటే: ఆ process ఏదిని చదవగలదో అది. మీరు ఇంకా boundary ఏర్పాటు చేయకపోతే, serverలో coding agent ను సురక్షితంగా నడపడం ఈ guide ఆధారపడే isolation స్థాయిలను వివరిస్తుంది.

ముప్పు నమూనాను సులభంగా అర్థం చేసుకోవడం

మీ agent ఏ user గా నడుస్తుందో, అదే 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 ఆ data ను బయటకు పంపడానికి సంక్లిష్టమైన exploit అవసరం లేదు. సాధారణంగా ఉపయోగించే నాలుగు మార్గాలు సరిపోతాయి. Log లో ఈ నాలుగూ సాధారణ పనిలా కనిపిస్తాయి:

• ఏ host కైనా outbound curl లేదా fetch పంపడం; value ను query string లో ఉంచడం.
• agent write చేయగల repository కు git commit మరియు git push చేయడం.
• package install script ను అమలు చేయడం; ఇది agent user గా arbitrary code నడుపుతుంది.
• value ను కలిగి ఉన్న hostname కోసం DNS lookup చేయడం; HTTP egress నిరోధించినా ఈ data బయటకు వెళ్తుంది.

Review చేయడం ద్వారా మాత్రమే ఈ సమస్యను పరిష్కరించలేరు. అందుబాటులో విలువైన data ఏదీ లేకుండా చేయడమే పరిష్కారం.

వర్కింగ్ treeలోని secret, context windowలో కూడా secret‌గా ఉంటుంది

ఒక agent filesను చదువుతుంది. అది పనిచేస్తున్న repositoryలోని ఒక .env file చదవబడుతుంది. చదివిన వెంటనే అది 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

తర్వాత, ఆ fileను అందుబాటులో లేకుండా తరలించినప్పుడు:

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లో file లేకపోవడంతో agent యొక్క user ఇక దాన్ని తెరవలేరు. Agent స్వంత configలోని deny rules రెండో రక్షణ పొర మాత్రమే; మొదటి పొర కాదు. Claude Code projectలోని .claude/settings.json నుంచి permission rulesను చదువుతుంది:

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

Exploration సమయంలో agent పొరపాటున fileను తెరవకుండా ఇది నిరోధిస్తుంది. ఈ నియమాలు file toolsకే పరిమితం కావు. Bashలో agent గుర్తించే file commandsకు, ఉదాహరణకు cat మరియు headకు, అలాగే < .env వంటి redirection targetsకు కూడా Claude Code ఈ నియమాలను తనిఖీ చేస్తుంది. అయితే project directoryలో grep -r KEY .ను అమలు చేసే injected instructionను ఇది ఆపదు. అలాగే .envను తానే తెరిచే చిన్న Python scriptను కూడా ఆపదు. ఎందుకంటే file పేరును పేర్కొనకుండా filesను చదివే commandsకు లేదా స్వయంగా filesను తెరిచే subprocessesకు deny rules వర్తించవని permissions documentation చెబుతుంది. ఇలాంటి సందర్భాలకు Claude Code యొక్క sandboxను docs సూచిస్తున్నాయి. అది operating system స్థాయిలో blockను అమలు చేస్తుంది. అలాంటి command అమలుకు ముందు మీ అనుమతి కోరాలా లేదా అనేది session యొక్క permission modeపై ఆధారపడి ఉంటుంది. interactive Claude Code sessions కోసం auto mode ఇప్పుడు built-in starting modeగా ఉంది. అందువల్ల మీరు పర్యవేక్షించని serverలో ఇలాంటి మరిన్ని commands prompt లేకుండానే అమలవుతాయి. Agent permissionsకన్నా దాని అలవాట్లను ప్రభావితం చేసే విషయాలకు కూడా ఇదే పరిమితి వర్తిస్తుంది: పనిచేసే అతి చిన్న మార్పుకే agentను పరిమితం చేసే skill అవసరం లేని filesలోకి run వెళ్లకుండా అడ్డుకుంటుంది. అయితే modelను ఒప్పించి దాని నుంచి తప్పించుకోవచ్చు, ఎందుకంటే అది ఇంకా సూచన మాత్రమే. Configను guardrailగా, filesystem permissionను గోడగా పరిగణించండి. ఇదే విభజన containersలో కూడా ఉంటుంది: Docker Composeలోని env files మరియు secrets ఈ సమస్యను ఒక పొర దిగువన వివరించుతుంది.

ప్రతి 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 తో విఫలమవ్వాలి. దాని బదులుగా ఒక key ముద్రితమైతే, agent user ఆ file ను చేరుకోగలదు. ఒక file ను పేరు ద్వారా తెరవడానికి, దాని పైనున్న ప్రతి directory పై search (x) permission అవసరం. read permission అవసరం లేదు. అందువల్ల mode 711 ఉన్న home directory ను ఇతరులు list చేయలేకపోయినా, key file స్వయంగా readable గా ఉంటే ఆ key ను చేరుకోవచ్చు. chmod 700 ~ path ను మూసివేస్తుంది. chmod 600 ~/.ssh/id_ed25519 key ను సరిచేస్తుంది. agent user ను sudo లో చేర్చవద్దు. అది నిజంగా అవసరమైన ఒక్క command కంటే విస్తృతమైన NOPASSWD rule ఇవ్వవద్దు. VPSలో కనీస అనుమతులున్న users group మరియు sudoers వివరాలను వివరిస్తుంది. ఒకే host పై ఒకటి కంటే ఎక్కువ sessions నడిపినప్పుడు ఈ వేర్పాటును గుర్తుంచుకోండి. ఒక Claude Code session మరొక session కు నేరుగా text పంపగలదు. మొదటి session వద్ద ఉన్న ఏదైనా విషయం ఒకే message లో ఆ channel దాటి వెళ్లవచ్చు.

cloud VPS పై మరో పరిమితిని కూడా జోడించడం మంచిది. Instance metadata service ఒక స్థిరమైన link-local address పై సమాధానం ఇస్తుంది. అడిగే ఏ ప్రక్రియకైనా అది తరచుగా role credentials అందిస్తుంది. స్థానికంగా ఏ user request పంపుతున్నాడో endpoint పరిశీలించదు. EC2 విషయంలో, IMDSv1 calls కు token అవసరం లేదని AWS documentation చెబుతుంది. ఒక user ను ఈ service నుంచి దూరంగా ఉంచడానికి AWS సూచించే విధానం, ఆ user ID ఆధారంగా local firewall rule ఏర్పాటు చేయడం.

sudo iptables -I OUTPUT 1 -p tcp -m owner --uid-owner agent-review -d 169.254.169.254 -j REJECT

ఈ rule ను -I తో పైభాగంలో చేర్చండి. -A తో చివరికి append చేయవద్దు. Default allow outgoing policy తో ufw నడుస్తున్న host పై, ufw యొక్క చివరి OUTPUT chain ప్రతి కొత్త TCP connection ను accept చేస్తుంది. అందువల్ల చివరికి append చేసిన rule కు ఎప్పటికీ చేరదు. iptables rules ను persist చేయకపోతే reboot సమయంలో అవి తొలగిపోతాయి. Metadata service యొక్క IPv6 endpoint ను enable చేసి ఉంటే, [fd00:ec2::254], అదే rule ను ip6tables తో కూడా చేర్చండి.

దీన్ని agent వైపు నుంచి తనిఖీ చేయండి. sudo -u agent-review curl -s --max-time 3 http://169.254.169.254/ ఏ output లేకుండా non-zero status తో ముగియాలి. కారణం, packet host ను విడిచిపెట్టకముందే reject అవుతుంది. అది listing ముద్రిస్తే, rule కు చేరడం లేదని అర్థం.

అంచున credential injection

ఈ సమస్యను నిజంగా పరిష్కరించే విధానం credential injection. Agent వద్ద అసలు key ఎప్పుడూ ఉండదు. అది తన request ను local gateway ద్వారా పంపుతుంది. Gateway బయటకు పంపే సమయంలో placeholder స్థానంలో అసలు secret ను ఉంచుతుంది. Secret gateway storage లో, వేరే process లో, వేరే user ఆధీనంలో ఉంటుంది.

OneCLI దీనికి ఒక open source implementation. దీని ee/ directories మినహా మిగిలిన భాగం Apache-2.0 license కింద ఉంటుంది. ee/ directories కు production వినియోగానికి subscription అవసరమయ్యే ప్రత్యేక enterprise license ఉంటుంది. ఇది agent పక్కనే containers లో నడుస్తుంది. October 2026 నాటికి, compose file పక్కన ఉన్న .env file నుంచి మూడు generated secrets ను చదివే ఈ Docker Compose setup ను project documentation అందిస్తుంది:

git clone https://github.com/onecli/onecli.git && cd onecli/docker
cat > .env <<EOF
SECRET_ENCRYPTION_KEY=$(head -c 32 /dev/urandom | base64)
GATEWAY_INTERNAL_SECRET=$(head -c 32 /dev/urandom | base64)
BETTER_AUTH_SECRET=$(head -c 32 /dev/urandom | base64)
COMPOSE_PROFILES=runner
EOF
chmod 600 .env
docker compose up -d --wait

ఆ .env file కు backup తీసుకోండి. ఎందుకంటే SECRET_ENCRYPTION_KEY ను కోల్పోతే, దానితో నిల్వ చేసిన ప్రతి secret కు సంబంధం తెగిపోతుంది. Dashboard port 10254 పై, gateway port 10255 పై listen చేస్తాయి. Default గా రెండూ 127.0.0.1 కు bind అవుతాయి. అసలు credential ను ఒకసారి నిల్వ చేయండి. తరువాత ప్రతి agent కు key స్థానంలో placeholder value ఇవ్వండి. దానికి సంబంధించిన scoped access token ను కూడా ఇవ్వాలి. Agent దాన్ని Proxy-Authorization header లో పంపుతుంది. Gateway host మరియు path ఆధారంగా outbound request ను సరిపోల్చి, సంబంధిత credential ను decrypt చేసి, దాని స్థానంలో ఉంచుతుంది. Agent environment లో దొంగిలించడానికి విలువైనది ఏదీ ఉండదు.

ఇక్కడ ముఖ్యమైనది encryption కాదు. “ఈ agent ఏమి ఉపయోగించింది, ఎప్పుడు ఉపయోగించింది?” అనే ప్రశ్నకు log query ద్వారా సమాధానం లభించడమే ముఖ్యమైనది. Key యొక్క copy ఏ ఆరు environments లో ఉందో ఊహించాల్సిన బదులు, ఒక audit trail ను పరిశీలిస్తే సరిపోతుంది.

రహస్యాన్ని environment కు కాకుండా process కు అందించండి

మీరు agent ను systemd కింద నడిపితే environment variables అసలు అవసరం లేదు. LoadCredential= రహస్యాన్ని service user మాత్రమే చదవగలిగే private directory లో ఉంచుతుంది. Unit file లో అది %d గా, process లో $CREDENTIALS_DIRECTORY గా అందుబాటులో ఉంటుంది. ఈ పరిమితి service ఆధారంగా కాకుండా user ఆధారంగా ఉంటుంది. అందువల్ల ప్రతి agent service కు ప్రత్యేక user ఇవ్వండి. అదే user గా నడుస్తున్న ఇతర process ఏదైనా ఆ directory ను తెరవగలదు. Unit లో PrivateMounts=yes వంటి filesystem namespacing ను కూడా ఉపయోగిస్తే ఈ ప్రమాదం తగ్గుతుంది. అప్పుడు ఆ directory ఇతర services కు కనిపించదు. ఆ విలువ /proc/<pid>/environ లో ఎప్పుడూ కనిపించదు. కాబట్టి ps eww దాన్ని చూపించలేదు. Service ఆగినప్పుడు directory కూడా తొలగిపోతుంది.

ముందుగా credential ను machine కోసం encrypt చేయండి. ఈ commands systemd documentation నుంచి వచ్చాయి. ఇవి systemd 250 లేదా తరువాతి versions లో పనిచేస్తాయి. ఇందులో 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 నుంచి reference చేయండి:

[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 ను open చేస్తుంది. File read కొద్దిసేపు మాత్రమే ఉంటుంది. Environment variable మాత్రం process మొత్తం lifetime పాటు, అది ప్రారంభించే ప్రతి child process లో కూడా ఉంటుంది.

తక్కువ కాలం చెల్లుబాటయ్యే tokens ను ఎక్కువ కాలం చెల్లుబాటయ్యే keys కంటే ప్రాధాన్యంగా ఉపయోగించండి

ఎప్పటికీ గడువు ముగియని key, నెలల తర్వాత 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) అంగీకరించే కనిష్ఠ వ్యవధి Fifteen minutes. సాధారణంగా ఇది ఒక agent task కు సరిపోతుంది. GitHub కోసం, agent user కు ప్రత్యేకమైన gh login ఇవ్వండి. అది పనిచేసే single repository కు మాత్రమే పరిమితమైన fine grained token ను ఉపయోగించండి. అప్పుడు ఆ session లో gh auth token అమలు చేసినా, ఇతర వనరులను తాకలేని ఫలితం వస్తుంది. ముందుగా resource ఆధారంగా పరిమితి విధించండి. తరువాత time ఆధారంగా పరిమితి విధించండి.

ధృవీకరించండి, తరువాత కూడా ధృవీకరిస్తూ ఉండండి

ఏజెంట్ setup లో మార్పు చేసిన తర్వాత మూడు తనిఖీలు చేయడం మంచిది. వాటిని మీ ఖాతాతో కాకుండా ఏజెంట్ 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

మొదటి కమాండ్ ఎలాంటి output ఇవ్వకూడదు. రెండవది ls: cannot open directory '/home/you/': Permission denied ను చూపాలి. అయితే దీని ద్వారా ఆ directory ను list చేయలేమని మాత్రమే తెలుస్తుంది; దాని లోపల ఉన్న file ను read చేయలేమని నిర్ధారించేది ముందుగా అమలు చేసిన cat test. మూడవది ఏజెంట్ network path ఏ identity ని చూపిస్తుందో తెలియజేస్తుంది. Gateway pattern ఉద్దేశం కూడా ఇదే విషయాన్ని నిర్ధారించడం. 401 అంటే GitHub అంగీకరించే credential లేకుండానే request GitHub కు చేరిందని అర్థం. Credential అసలు లేకపోవచ్చు లేదా అది invalid లేదా expired అయి ఉండవచ్చు. 200 అంటే valid credential పంపబడుతోందని అర్థం. అందువల్ల ఏ token ఉపయోగించబడుతుందో మీకు తెలుసు ఉండాలి. ఏజెంట్లను unattended గా అమలు చేస్తే, VPS పై AI agent ఖర్చులను నియంత్రించడం ఈ access limits కు అనుసంధానమైన budget limits ను వివరిస్తుంది.

FAQ

నేను నా keys ను leak చేయకుండా model ను నమ్మవచ్చా?

లేదు. ఎందుకంటే ఈ threat model లో attacker model కాదు. Agent వెబ్ పేజీలు, repositories, issue trackers నుంచి text ను చదువుతుంది. ఆ text లో instructions ఉండవచ్చు. Agent తీసుకువచ్చిన text నుంచి మీ instructions ను వేరు చేయడానికి model వద్ద నమ్మదగిన మార్గం లేదు. Model సరైన నిర్ణయం తీసుకోవడంపై ఆధారపడే ఏ control అయినా, injected instruction నమ్మదగినదిగా కనిపించిన మొదటి సందర్భంలో విఫలమవుతుంది. అందువల్ల ఆ control operating system లేదా network లో ఉండాలి.

Agent secrets కోసం environment variables నిజంగా అంత ప్రమాదకరమా?

ఒక నిర్దిష్ట కారణంతో అవి ప్రమాదకరమైనవి: అవి inherit అవుతాయి. Agent ప్రారంభించే ప్రతి child process కు వాటి copy లభిస్తుంది. ఇందులో build script, test runner, package install hook కూడా ఉంటాయి. అదే user ద్వారా /proc/<pid>/environ తో variables ను చదవవచ్చు. కాబట్టి agent నేరుగా పంపకపోయినా, agent నడిపే ఏదైనా వాటిని చదవగలదు. ఉపయోగించే సమయంలో మాత్రమే file ను చదవడం, LoadCredential= లేదా gateway తో చేయడం వల్ల exposure ఆ సమయానికి పరిమితం అవుతుంది.

Secrets ను vault లో ఉంచితే ఈ సమస్య పూర్తిగా పరిష్కారమవుతుందా?

పాక్షికంగా మాత్రమే. Vault storage సమస్యను పరిష్కరిస్తుంది. మీరు ఆ vault ను self host చేస్తే, దానికి ప్రత్యేక hardening pass అవసరం. ఎందుకంటే Vaultwarden server సాధారణంగా దానిలోని encrypted items ద్వారా కాకుండా admin token లేదా backup file ద్వారా breach అవుతుంది. Secret ను vault నుంచి తీసి environment variable గా agent కు అందించే చివరి దశను అది పరిష్కరించదు. దాంతో మీరు మళ్లీ మొదటి స్థితికే వస్తారు. Substitution ను ఎవరు నిర్వహిస్తారనేదే ముఖ్యం. Agent secret ను fetch చేస్తే, secret agent వద్ద ఉంటుంది. Gateway లేదా init system agent process బయట substitution ను నిర్వహిస్తే, agent secret ను ఎప్పుడూ తన వద్ద ఉంచుకోదు.

Agent ఇప్పటికే ఏదైనా leak చేసిందో లేదో నాకు ఎలా తెలుస్తుంది?

సాధారణంగా సంఘటన తర్వాత దాన్ని నిర్ధారించలేరు. అందుకే gateway అవసరం. Gateway లేకపోతే మీ ఆధారాలు shell history, agent transcript, మరియు మీరు సాధారణంగా ఉంచని outbound connection logs లో విడివిడిగా ఉంటాయి. Credential gateway తో credential యొక్క ప్రతి ఉపయోగం agent identity మరియు timestamp తో ఒక line గా నమోదవుతుంది. Leak జరిగిందని అనుమానిస్తే, ముందుగా key ను rotate చేసి తరువాత దర్యాప్తు చేయండి. Rotation తక్కువ ఖర్చుతో చేయవచ్చు; పూర్తి నిర్ధారణ సాధ్యం కాకపోవచ్చు.

నేను ఈరోజు కనీసంగా ఏమి చేయాలి?

ప్రతి .env file ను agents పనిచేసే directories నుంచి బయటకు తరలించండి. ప్రతి agent కోసం ఒక unprivileged user ను సృష్టించండి. ఈ రెండు మార్పులకు సుమారు 10 నిమిషాలు పడతాయి. Code పక్కనే అవసరం లేకుండా ఉన్న credential file ను agent చదవడం అనే సాధారణ మార్గాన్ని ఇవి మూసివేస్తాయి. Gateway మరియు short lived tokens తరువాతి దశలు. అవి మొదటి దశలు కావు. ఇదే ప్రారంభ విధానం ఏ agent runtime కు అయినా వర్తిస్తుంది. ఇందులో VPS పై autonomous agent ను సురక్షితంగా నడపడం కూడా ఉంది.