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 ఏదీ లేకుండా చేయడమే పరిష్కారం.

వర్కింగ్ ట్రీలో ఉన్న 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 ను agent కు అందకుండా తరలించినప్పుడు:

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)"]
  }
}

దీంతో agent అన్వేషిస్తున్నప్పుడు పొరపాటున file తెరవడాన్ని అడ్డుకోవచ్చు. కానీ injected instruction base64 .env ను అమలు చేయకుండా ఇది ఆపదు. ఎందుకంటే అది shell command, file read కాదు. ఆ command అమలు కావడానికి ముందు మీ అనుమతి అడుగుతుందా లేదా అనేది session యొక్క permission mode పై ఆధారపడి ఉంటుంది. August 2026లో auto mode Claude Code యొక్క default అవుతుంది, కాబట్టి మీరు monitor చేయని server మరిన్ని commands ను prompt లేకుండా అమలు చేస్తుంది. Agent permissions కంటే దాని అలవాట్లను ప్రభావితం చేసే వాటికీ ఇదే పరిమితి వర్తిస్తుంది. పనిచేసే అతి చిన్న మార్పుకే agent ను పరిమితం చేసే skill run ను agent తెరవకూడని files వైపు వెళ్లకుండా అడ్డుకుంటుంది. కానీ అది model ను ఒప్పించి మార్చగల సలహా మాత్రమే. Config ను రక్షణ కంచెగా, filesystem permission ను గోడగా పరిగణించండి. Containers లోపల కూడా ఇదే విభజన వర్తిస్తుంది: Docker Compose లోని env files మరియు secrets ఈ సమస్యను ఒక layer దిగువన వివరించే భాగం.

ప్రతి agent కు ప్రత్యేక unprivileged user ఇవ్వండి

agent మీ user గా నడిస్తే, అది మీ SSH keys, cloud credentials మరియు shell history ను వారసత్వంగా పొందుతుంది. ప్రత్యేక user ను సృష్టించడానికి ఒక command మాత్రమే అవసరం. దీంతో ఇవన్నీ agent కు అందుబాటులో ఉండవు.

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

చివరి line cat: /home/you/.ssh/id_ed25519: Permission denied తో fail కావాలి. దాని బదులుగా key కనిపిస్తే, మీ home directory group లేదా world-readable గా ఉంది. chmod 700 ~ దాన్ని సరిచేస్తుంది. agent user ను sudo కు చేర్చవద్దు. దానికి నిజంగా అవసరమైన ఒక command కంటే విస్తృతమైన NOPASSWD rule ఇవ్వవద్దు. VPSలో కనిష్ఠ అనుమతులున్న users group మరియు sudoers వివరాలను వివరిస్తుంది. box పై ఒకటి కంటే ఎక్కువ sessions నడిపినప్పుడు కూడా ఈ విభజనను కొనసాగించండి. ఎందుకంటే ఒక Claude Code session నేరుగా మరొక session కు text పంపగలదు. మొదటి session వద్ద ఉన్న ఏదైనా ఒకే message ద్వారా ఆ channel దాటవచ్చు.

cloud VPS పై మరొక isolation boundary ను జోడించడం మంచిది. instance metadata service ఒక fixed 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/ ఏ output లేకుండా print చేసి non-zero status తో exit కావాలి. ఎందుకంటే packet box ను విడిచిపెట్టకముందే reject అవుతుంది.

సరిహద్దు వద్ద credential ను inject చేయండి

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

OneCLI దీనికి ఒక open source implementation. ఇది Apache-2.0 license కింద అందుబాటులో ఉంటుంది. ఇది agent పక్కనే container గా నడుస్తుంది. July 2026 నాటికి project ఈ setup ను documentation లో వివరించింది:

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 ను ఒక్కసారి store చేసి, ప్రతి agent కు key స్థానంలో placeholder value ను ఇస్తారు. అలాగే దానికి ప్రత్యేకంగా scope చేసిన access token ను కూడా ఇస్తారు. Agent ఆ token ను Proxy-Authorization header లో పంపుతుంది. Gateway host మరియు path ఆధారంగా outbound request కు సరిపోలే credential ను గుర్తిస్తుంది. తరువాత సరిపోలిన credential ను decrypt చేసి, placeholder స్థానంలో ఉంచుతుంది. Agent environment లో దొంగిలించడానికి ఉపయోగపడే విలువ ఏదీ ఉండదు.

ఇక్కడ ముఖ్యమైనది encryption కాదు. “ఈ agent ఏమి ఉపయోగించింది, ఎప్పుడు ఉపయోగించింది?” అనే ప్రశ్నకు log query ద్వారా సమాధానం దొరకడమే ముఖ్యమైన విషయం. Key యొక్క copy ఏ ఆరు environments లో ఉందో ఊహించాల్సిన అవసరం లేకుండా, ఒకే 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 లేదా ఆ తరువాతి 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 ను చదవడం తాత్కాలిక చర్య. 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 ఆధారంగా పరిమితి విధించండి.

ధృవీకరించండి, ఆపై నిరంతరం ధృవీకరిస్తూ ఉండండి

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

మొదటి కమాండ్ ఎలాంటి outputను చూపకూడదు. రెండవది ls: cannot open directory '/home/you/': Permission denied ను చూపాలి. మూడవది agent network path ద్వారా ఏ identity కనిపిస్తుందో తెలియజేస్తుంది. Gateway pattern ఉద్దేశం ఇదే ప్రశ్నకు సమాధానం ఇవ్వడం. 401 కనిపిస్తే agent వద్ద స్వంత GitHub credential లేదని అర్థం. 200 కనిపిస్తే ఒక credential ఉందని అర్థం. అప్పుడు అది ఏ tokenో మీకు తెలుసుండాలి. మీరు agentsను 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 ను సురక్షితంగా నడపడం కూడా ఉంది.