AI ఏజెంట్లకు API keys ఇవ్వకుండా సురక్షితంగా ఉంచడం

AI ఏజెంట్లకు రహస్యాలను అందించకుండా ఉండటం అంటే ఏమిటి

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

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

ముప్పు నమూనా: సులభమైన వివరణ

మీ agent నడిచే userగా దీన్ని అమలు చేయండి.

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

ఇది ప్రింట్ చేసే ప్రతి లైన్, మీ server నుంచి ఒక HTTP request దూరంలో ఉన్న అపరిచితుడి serverకు చేరవచ్చు. ఇప్పుడు 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కైనా 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 నిరోధించబడినా ఇది బయటకు వెళ్లవచ్చు.

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

పని చేస్తున్న 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 ప్రాజెక్ట్‌లోని .claude/settings.json నుంచి permission rules ను చదువుతుంది:

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

దీంతో agent పరిశీలిస్తున్నప్పుడు పొరపాటున ఫైల్ తెరవడాన్ని నిరోధించవచ్చు. కానీ injected instruction base64 .env ను అమలు చేయడాన్ని ఇది నిరోధించదు. ఎందుకంటే అది shell command, ఫైల్ read కాదు. 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ను ప్రింట్ చేస్తే, మీ home directory group లేదా worldకి readableగా ఉంది. chmod 700 ~ దాన్ని సరిచేస్తుంది. agent userను sudoకు చేర్చవద్దు. agentకు నిజంగా అవసరమైన ఒక్క commandకంటే విస్తృతమైన NOPASSWD rule ఇవ్వవద్దు. VPSలో కనీస అనుమతుల usersలో group మరియు sudoers వివరాలు ఉన్నాయి.

cloud VPSలో మరో పరిమితిని కూడా జోడించడం మంచిది. 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/ ఏ outputను ప్రింట్ చేయకుండా non-zeroతో ముగియాలి. కారణం, packet ఈ machineను విడిచిపెట్టే ముందే reject అవుతుంది.

సరిహద్దు వద్ద ఆధారాన్ని ఇంజెక్ట్ చేయండి

ఈ సమస్యను వాస్తవంగా పరిష్కరించే విధానం ఆధార ఇంజెక్షన్. Agent వద్ద నిజమైన cryptographic key ఎప్పుడూ ఉండదు. అది తన అభ్యర్థనను స్థానిక gateway ద్వారా పంపుతుంది. gateway బయటకు పంపే సమయంలో placeholder స్థానంలో నిజమైన secret‌ను ఉంచుతుంది. secret gateway storage‌లో, వేరే process‌లో, వేరే user యాజమాన్యంలో ఉంటుంది.

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

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

Dashboard port 10254 పై listening చేస్తుంది. Gateway port 10255 పై listening చేస్తుంది. మీరు నిజమైన credential‌ను ఒక్కసారి store చేసి, ఆ తర్వాత ప్రతి agent‌కు key స్థానంలో ఒక placeholder valueతో పాటు దానికి మాత్రమే పరిమితమైన access token‌ను ఇస్తారు. Agent ఆ token‌ను Proxy-Authorization header‌లో పంపుతుంది. Gateway host మరియు path ఆధారంగా outbound request‌ను సరిపోల్చుతుంది. సరిపోలే credential‌ను decrypt చేసి, దాని స్థానంలో ఉంచుతుంది. 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 లేదా అంతకంటే కొత్త version లో పనిచేస్తాయి. ఇది 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 పాటు ఉంటుంది. 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) అంగీకరించే కనిష్ఠ వ్యవధి Fifteen minutes. సాధారణంగా ఇది ఒక agent task‌కు సరిపోతుంది. GitHub కోసం, agent user‌కు ప్రత్యేకమైన gh login‌ను ఇవ్వండి. అది పనిచేసే single repository‌కే పరిమితమైన fine grained token‌ను ఉపయోగించండి. అప్పుడు ఆ session‌లోని gh auth token మరే ఇతరదానినీ తాకలేని సమాచారాన్ని అందిస్తుంది. ముందుగా resource ఆధారంగా, తర్వాత time ఆధారంగా పరిధిని పరిమితం చేయండి.

ధృవీకరించి, తరువాత కూడా నిరంతరం తనిఖీ చేయండి

ఏజెంట్ సెటప్‌లో మార్పు చేసిన తర్వాత ఈ మూడు తనిఖీలు చేయడం ఉపయోగకరం. వీటిని మీ ఖాతాతో కాకుండా, ఏజెంట్ యూజర్‌గా అమలు చేయండి.

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 ను చూపాలి. మూడవది ఏజెంట్ నెట్‌వర్క్ మార్గం ఏ గుర్తింపును ప్రదర్శిస్తుందో తెలియజేస్తుంది. గేట్‌వే నమూనా ఉద్దేశం ఇదే ప్రశ్నకు సమాధానం ఇవ్వడం. 401 ఉంటే, ఏజెంట్ తన స్వంత GitHub క్రెడెన్షియల్‌ను తీసుకెళ్లడం లేదని అర్థం. 200 ఉంటే, అది ఒకదాన్ని తీసుకెళ్తోందని అర్థం. అందువల్ల అది ఏ token అనేది మీకు తెలిసి ఉండాలి. మీరు agents ను unattended గా అమలు చేస్తే, ఈ యాక్సెస్ పరిమితులకు అనుగుణమైన బడ్జెట్ పరిమితుల కోసం VPSలో AI agent ఖర్చులను నియంత్రించడం చూడండి.

FAQ

నా keys‌ను leak చేయకుండా model‌ను పూర్తిగా నమ్మవచ్చా?

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

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

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

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

పాక్షికంగా మాత్రమే. Vault storage సమస్యను పరిష్కరిస్తుంది. కానీ చివరి దశను పరిష్కరించదు. ఆ దశలో ఏదో ఒకటి vault నుంచి secret‌ను తీసుకుని, environment variable‌గా agent‌కు అందిస్తుంది. దీంతో మీరు మళ్లీ మొదటి పరిస్థితికే వస్తారు. Substitution ఎవరు చేస్తారనేదే ముఖ్యం. Agent secret‌ను fetch చేస్తే, secret agent వద్ద ఉంటుంది. Gateway లేదా init system agent process‌కు బయట substitution చేస్తే, agent దాన్ని ఎప్పుడూ తన వద్ద ఉంచుకోదు.

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

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

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

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