AI agent पासून API keys सुरक्षित कशा ठेवाव्यात

AI agents पासून secrets दूर ठेवण्याचा अर्थ

AI agent हा commands चालवणारा सामान्य Linux process असतो. त्या process कडे असलेला प्रत्येक environment variable तो चालवत असलेल्या code ला वाचता येतो. त्यामुळे agent च्या environment मध्ये असलेली API key ही agent पोहोचू शकणाऱ्या कोणत्याही host कडे पाठवता येणारी key असते. Agent पासून secrets दूर ठेवणे म्हणजे त्याला key ऐवजी एक handle देणे: अल्पकालीन, मर्यादित scope असलेला token किंवा network boundary वर दुसरी यंत्रणा वास्तविक value ने बदलणारा 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 म्हणून चालतो, त्याच 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 म्हणून कोणताही code चालवते.
• value असलेले hostname शोधण्यासाठी केलेला DNS lookup; HTTP egress अवरोधित असले तरी तो बाहेर जातो.

फक्त review करून तुम्ही या समस्येतून बाहेर पडू शकत नाही. उपाय म्हणजे agent च्या आवाक्यात कोणतीही मौल्यवान माहिती राहणार नाही याची खात्री करणे.

कार्यरत ट्रीतील गुप्त माहिती संदर्भ विंडोमध्येही गुप्त राहत नाही

एजंट फाइल्स वाचतो. तो ज्या repository मध्ये काम करत आहे, त्यातील .env फाइल वाचली जाईल. एकदा ती वाचली की ती संदर्भ विंडोमध्ये येते. याचा अर्थ ती transcript मध्ये, तुम्ही ठेवलेल्या कोणत्याही log मध्ये आणि एजंट पुढे लिहित असलेल्या मजकुरातही येते.

पूर्वी, एजंट ज्या ट्रीमध्ये काम करत होता त्यात 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

काम करणाऱ्या ट्रीमध्ये फाइल नसल्यामुळे एजंटचा वापरकर्ता ती फाइल आता उघडू शकत नाही. एजंटच्या स्वतःच्या config मधील deny rules हा दुसरा स्तर आहे; पहिला नाही. Claude Code प्रकल्पातील .claude/settings.json मधून permission rules वाचतो:

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

अन्वेषण करताना एजंटने चुकून फाइल उघडणे यामुळे थांबते. परंतु injected instruction ला base64 .env चालवण्यापासून हे थांबवत नाही, कारण तो shell command आहे, file read नाही. Config ला guardrail आणि filesystem permission ला भिंत समजा. हाच विभाजन containers मध्येही लागू होतो: Docker Compose मधील env files आणि secrets या समस्येच्या एका स्तराखालील आवृत्तीचे स्पष्टीकरण देते.

प्रत्येक एजंटसाठी स्वतंत्र अनprivileged वापरकर्ता द्या

एजंट तुमच्या वापरकर्त्याच्या अधिकारांखाली चालल्यास, त्याला तुमच्या SSH keys, cloud credentials आणि shell history चा वारसा मिळतो. स्वतंत्र वापरकर्ता तयार करण्यासाठी एकच 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 ~ ती दुरुस्त करते. एजंट वापरकर्त्याला sudo मध्ये जोडू नका आणि त्याला आवश्यक असलेल्या एकमेव command पेक्षा व्यापक NOPASSWD rule देऊ नका. VPS वरील किमान-अधिकार वापरकर्ते यामध्ये group आणि sudoers संबंधी तपशील दिले आहेत.

Cloud VPS वर आणखी एक सुरक्षा-सीमा जोडणे आवश्यक आहे. Instance metadata service एका निश्चित link local address वर प्रतिसाद देते आणि विनंती करणाऱ्या कोणत्याही घटकाला role credentials देते.

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

एजंटच्या बाजूने ते तपासा. sudo -u agent-review curl -s --max-time 3 http://169.254.169.254/ ने काहीही छापू नये आणि non zero exit status द्यावा, कारण packet मशीनच्या बाहेर जाण्यापूर्वीच नाकारला जातो.

सीमेवर क्रेडेन्शियल समाविष्ट करा

ही समस्या प्रत्यक्षात सोडवणारी पद्धत म्हणजे क्रेडेन्शियल इंजेक्शन. एजंटकडे वास्तविक key कधीही राहत नाही. तो आपली विनंती स्थानिक gateway मार्फत पाठवतो आणि gateway बाहेर पाठवताना placeholder च्या जागी वास्तविक secret ठेवतो. Secret gateway च्या storage मध्ये, वेगळ्या process मध्ये आणि वेगळ्या user च्या मालकीचे राहते.

OneCLI ही या पद्धतीची एक open source अंमलबजावणी आहे. ती Apache-2.0 परवान्याखाली उपलब्ध आहे आणि agent च्या शेजारी container म्हणून चालते. July 2026 पर्यंत प्रकल्पाच्या दस्तऐवजांमध्ये ही मांडणी दिली आहे:

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

dashboard port 10254 वर आणि gateway port 10255 वर requests स्वीकारते. वास्तविक credential एकदाच साठवा. त्यानंतर प्रत्येक agent ला key ऐवजी placeholder value आणि त्याचा स्वतंत्र scoped access token द्या. agent हा token Proxy-Authorization header मध्ये पाठवतो. gateway host आणि path यांच्या आधारे बाहेर जाणारी request जुळवतो, संबंधित credential decrypt करतो आणि त्याच्या जागी ते credential ठेवतो. agent च्या environment मध्ये चोरी करण्यासारखी कोणतीही माहिती राहत नाही.

येथील महत्त्व encryption मध्ये नाही. महत्त्वाचे हे आहे की “या agent ने काय वापरले आणि केव्हा?” हा प्रश्न log query ने सोडवता येतो. सहा environment पैकी कोणत्या environment मध्ये key ची प्रत होती याचा अंदाज घेण्याऐवजी तुम्ही एक audit trail वाचता.

गुपित पर्यावरणाला नव्हे, प्रक्रियेला द्या

तुम्ही agent systemd अंतर्गत चालवत असल्यास, environment variables ची अजिबात गरज नाही. LoadCredential= हे गुपित केवळ त्या सेवेलाच वाचता येईल अशा खाजगी directory मध्ये ठेवते. ते unit file मध्ये %d आणि process मध्ये $CREDENTIALS_DIRECTORY म्हणून उपलब्ध असते. हे मूल्य /proc/<pid>/environ मध्ये कधीही दिसत नाही. त्यामुळे ps eww ते दाखवू शकत नाही. सेवा थांबल्यावर directory नाहीशी होते.

प्रथम credential मशीनसाठी 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 print करते. यावरून 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 process मध्येही उपलब्ध असते.

दीर्घकाळ वैध असलेल्या कीजऐवजी अल्पकालीन टोकन वापरा

कधीही कालबाह्य न होणारी की काही महिन्यांनंतर लॉग किंवा ट्रान्स्क्रिप्टमध्ये आढळली, तरी वैध राहते. सेवा सत्र टोकन पुरवत असल्यास, सत्र टोकन वापरा आणि कामासाठी शक्य तितका कमी कालावधी सेट करा.

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 मिनिटे स्वीकारते. एका एजंटच्या कामासाठी हा कालावधी सहसा पुरेसा असतो. GitHub साठी एजंट वापरकर्त्याच्या नावाने स्वतंत्र gh लॉगिन तयार करा आणि तो ज्या एकाच repository वर काम करतो, त्यापुरता मर्यादित fine grained token द्या. त्यामुळे त्या सत्रातील gh auth token मधून इतर कोणत्याही संसाधनाला स्पर्श करू न शकणारी माहिती मिळेल. आधी resource नुसार, त्यानंतर कालावधीनुसार मर्यादा ठरवा.

पडताळा करा आणि त्यानंतरही पडताळत राहा

Agent च्या सेटअपमध्ये कोणताही बदल केल्यानंतर या तीन तपासण्या करणे उपयुक्त ठरते. त्या स्वतःच्या वापरकर्त्याच्या नावाने नव्हे, तर Agent च्या वापरकर्त्याच्या नावाने चालवा.

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 च्या नेटवर्क मार्गावर कोणती ओळख सादर केली जाते ते सांगते. Gateway pattern चा उद्देश याच प्रश्नाचे उत्तर देणे आहे: 401 असल्यास Agent कडे स्वतःचे GitHub credential नसते, तर 200 असल्यास त्याच्याकडे एक credential असते. त्यामुळे कोणता token वापरला जात आहे हे तुम्हाला माहीत असले पाहिजे. Agents unattended पद्धतीने चालवत असल्यास, VPS वरील AI Agent च्या खर्चाचे नियंत्रण या प्रवेशमर्यादांसोबत लागू होणाऱ्या budget limits चे वर्णन करते.

FAQ

माझ्या keys उघड होणार नाहीत, असा model वर विश्वास ठेवता येईल का?

नाही. कारण या threat model मध्ये attacker model नसतो. Agent वेब पृष्ठे, repositories आणि issue trackers मधून text वाचतो. त्या text मध्ये instructions असू शकतात. त्याने fetch केलेल्या text मधून तुमच्या instructions वेगळ्या ओळखण्याचा model कडे विश्वसनीय मार्ग नसतो. Model योग्य निर्णय घेईल यावर अवलंबून असलेले कोणतेही control convincing injected instruction प्रथमच आल्यावर अपयशी ठरते. त्यामुळे control operating system किंवा network मध्ये असणे आवश्यक आहे.

Agent secrets साठी environment variables खरोखर इतके धोकादायक आहेत का?

एका विशिष्ट कारणामुळे ते धोकादायक आहेत: ते inherited असतात. Agent ने सुरू केलेल्या प्रत्येक child process ला त्यांची copy मिळते. यामध्ये build script, test runner आणि कोणताही package install hook यांचा समावेश होतो. त्याच user कडून variables /proc/<pid>/environ द्वारेही वाचता येतात. त्यामुळे agent जे काही run करतो ते agent ने variables पुढे न पाठवता त्यांना वाचू शकते. वापराच्या क्षणी LoadCredential= किंवा gateway द्वारे file वाचल्यास exposure त्या क्षणापुरते मर्यादित राहते.

Secrets vault मध्ये ठेवल्याने ही समस्या आपोआप सुटते का?

फक्त काही अंशी. Vault storage ची समस्या सोडवतो. पण शेवटची पायरी सुटत नाही. त्या पायरीवर काहीतरी vault मधून secret काढून तो agent ला environment variable म्हणून देते. त्यामुळे तुम्ही पुन्हा सुरुवातीच्या स्थितीत जाता. Substitution कोण करतो हे महत्त्वाचे आहे. Agent ने secret fetch केला, तर secret agent कडे असतो. Gateway किंवा init system ने agent च्या process बाहेर substitution केली, तर agent कडे तो कधीच येत नाही.

Agent ने आधीच काही leak केले आहे की नाही हे मला कसे कळेल?

सामान्यतः नंतर हे निश्चितपणे कळत नाही. म्हणून gateway वापरणे आवश्यक ठरते. Gateway नसल्यास तुमचे evidence shell history, agent चा transcript आणि बहुधा तुम्ही जतन न केलेले outbound connection logs यांमध्ये विखुरलेले असते. Credential gateway असल्यास credential चा प्रत्येक वापर agent identity आणि timestamp असलेल्या एका line मध्ये नोंदवला जातो. Leak झाल्याचा संशय असल्यास प्रथम key rotate करा आणि नंतर तपास करा. Rotation स्वस्त आहे; निश्चितता नाही.

आज मी किमान काय करावे?

तुमचे सर्व .env files agents ज्या directories मध्ये काम करतात त्यांमधून बाहेर हलवा आणि प्रत्येक agent साठी एक unprivileged user तयार करा. या दोन बदलांना सुमारे 10 minutes लागतात. त्यामुळे सर्वसामान्य मार्ग बंद होतो: code च्या शेजारी ठेवण्याचे कोणतेही कारण नसलेली credential file agent ने वाचणे. Gateway आणि short lived tokens हे पुढचे पाऊल आहे; पहिले नाही. हीच सुरुवातीची पद्धत कोणत्याही agent runtime ला लागू होते. यामध्ये VPS वर autonomous agent सुरक्षितपणे चालवणे याचाही समावेश आहे.