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

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

AI agent ही commands चालवणारी सामान्य Linux process असते. त्या process कडे असलेले प्रत्येक environment variable ती चालवत असलेल्या code ला वाचता येते. त्यामुळे agent च्या environment मध्ये API key असल्यास, agent ती key ज्या host पर्यंत पोहोचू शकतो त्या कोणत्याही host कडे पाठवू शकतो. Agent पासून secrets दूर ठेवणे म्हणजे त्याला key ऐवजी तिचा handle देणे. हा handle अल्पकाळ वैध असलेला scoped token असू शकतो किंवा network boundary वर दुसरी यंत्रणा खऱ्या value ने बदलणारा placeholder असू शकतो.

हा model hostile होण्याबद्दलचा विषय नाही. यामागची प्रक्रिया अधिक साधी आहे. Agent instructions असलेले web page, README किंवा issue comment वाचतो आणि त्या पाळतो. कारण language model साठी तुम्ही लिहिलेला मजकूर आणि त्याने fetch केलेला मजकूर यांच्यात फरक नसतो. याला prompt injection म्हणतात. हे घडल्यानंतर होणारे नुकसान नेमके एका गोष्टीने मर्यादित होते: process काय वाचू शकते. तुम्ही अद्याप boundary निश्चित केली नसेल, तर server वर coding agent सुरक्षितपणे चालवणे या मार्गदर्शकाचा आधार असलेल्या isolation स्तरांचे वर्णन करते.

धोका-प्रतिमान सोप्या भाषेत

तुमचा agent ज्या user म्हणून चालतो, त्या user म्हणून हे चालवा.

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

यातून छापली जाणारी प्रत्येक ओळ एखाद्या अनोळखी सर्व्हरला पाठवलेल्या एका 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 block केलेले असले तरी तो value बाहेर पाठवतो.

फक्त review करून ही समस्या सुटणार नाही. योग्य उपाय म्हणजे agent च्या आवाक्यात कोणताही मौल्यवान 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 आता ती file उघडू शकत नाही. Agent च्या स्वतःच्या config मधील deny rules हा दुसरा स्तर आहे; पहिला स्तर नाही. Claude Code project मधील .claude/settings.json येथून permission rules वाचतो:

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

यामुळे Agent exploration करताना चुकून एखादी file उघडण्यापासून रोखला जातो. मात्र injected instruction ला base64 .env चालवण्यापासून हे रोखत नाही, कारण तो shell command आहे, file read नाही. तो command चालण्यापूर्वी तुमची परवानगी मागितली जाईल की नाही, हे session च्या permission mode वर अवलंबून असते. auto mode ऑगस्ट 2026 मध्ये Claude Code चे default बनते, त्यामुळे तुम्ही देखरेख करत नसलेल्या server वर अशा अधिक commands विनापरवानगी चालतील. Agent च्या permissions ऐवजी त्याच्या सवयी घडवणाऱ्या कोणत्याही गोष्टीला हीच मर्यादा लागू होते: Agent ला कार्य करणारा सर्वात लहान बदल करण्यास बांधून ठेवणारे skill run ला त्याने उघडू नयेत अशा files कडे वळण्यापासून रोखते; पण तरीही ते असे advice आहे, ज्यापासून model ला वेगळ्या कृतीसाठी प्रवृत्त करता येते. Config ला सुरक्षा-कठडा आणि 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 सह fail झाली पाहिजे. त्याऐवजी key दिसल्यास, तुमची home directory group किंवा world readable आहे. chmod 700 ~ याचे निराकरण करते. agent user ला sudo मध्ये add करू नका. तसेच, त्याला प्रत्यक्षात आवश्यक असलेल्या एकाच command पेक्षा व्यापक NOPASSWD rule देऊ नका. VPS वरील Least privilege users मध्ये group आणि sudoers संबंधी तपशील दिले आहेत. सर्व्हरवर एकापेक्षा जास्त session चालवल्यानंतर हे separation लक्षात ठेवा, कारण एक Claude Code session थेट दुसऱ्या session कडे text पाठवू शकतो, आणि पहिल्या session कडे असलेली कोणतीही माहिती एका message मध्ये त्या channel मधून जाऊ शकते.

cloud VPS वर आणखी एक boundary लागू करणे उपयुक्त आहे. 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

agent च्या बाजूने ते तपासा. sudo -u agent-review curl -s --max-time 3 http://169.254.169.254/ ने काहीही print करू नये आणि non zero exit करावा, कारण packet box सोडण्यापूर्वीच reject केला जातो.

सीमेवर credential injection करा

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

OneCLI ही याची एक open source implementation आहे. ती Apache-2.0 license अंतर्गत उपलब्ध आहे आणि agent च्या शेजारी container म्हणून चालते. July 2026 पर्यंत project मध्ये ही रचना पुढीलप्रमाणे documented आहे:

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 वर listen करतात. खरे credential एकदाच store करा. त्यानंतर प्रत्येक agent ला key च्या जागी placeholder value आणि त्याचा स्वतंत्र scoped access token द्या. Agent हा token Proxy-Authorization header मध्ये पाठवतो. Gateway host आणि path नुसार outbound request जुळवतो, संबंधित credential decrypt करतो आणि त्याच्या जागी ते credential ठेवतो. Agent च्या environment मध्ये चोरी करण्यासारखी कोणतीही माहिती राहत नाही.

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

गुप्त माहिती environment ऐवजी process ला द्या

agent systemd अंतर्गत चालवत असल्यास environment variables ची आवश्यकता नसते. LoadCredential= ही गुप्त माहिती फक्त त्या सेवेला वाचता येईल अशा private directory मध्ये ठेवते. Unit file मध्ये ती %d म्हणून आणि process मध्ये $CREDENTIALS_DIRECTORY म्हणून उपलब्ध होते. ही value /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 प्रदर्शित करतो. यावरून 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

value आवश्यक असताना तुमचा agent code $AGENT_KEY_FILE येथील file उघडतो. File read हा क्षणिक असतो. Environment variable मात्र process चालू असेपर्यंत आणि तो सुरू करत असलेल्या प्रत्येक child मध्ये उपलब्ध राहतो.

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

कधीही expire न होणारी key अनेक महिन्यांनंतर log किंवा transcript मध्ये आढळली, तरी ती वैध असते. सेवा 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) किमान पंधरा मिनिटांचा कालावधी स्वीकारते आणि एका agent task साठी तो सहसा पुरेसा असतो. GitHub साठी agent user ला स्वतःचा gh login द्या आणि तो ज्या एकाच repository वर काम करतो, त्यापुरताच मर्यादित fine grained token वापरा; त्यामुळे त्या session मध्ये gh auth token केल्यावर इतर कोणत्याही गोष्टीवर परिणाम करू न शकणारे credentials मिळतात. प्रथम resource नुसार scope निश्चित करा, त्यानंतर 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 प्रिंट करावे. तिसरी तपासणी एजंटचा network path कोणती ओळख सादर करतो ते दाखवते. Gateway pattern चा उद्देश हाच प्रश्न सोडवणे आहे: 401 म्हणजे एजंटकडे स्वतःचे GitHub credential नाही, तर 200 म्हणजे त्याच्याकडे एक credential आहे. त्यामुळे तो कोणता token वापरत आहे हे तुम्हाला माहीत असले पाहिजे. तुम्ही agents unattended चालवत असल्यास, VPS वरील AI agent खर्च नियंत्रित करणे या access limits सोबत लागू होणाऱ्या budget limits चे वर्णन करते.

FAQ

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

नाही. या threat model मध्ये attacker मॉडेल नसते. Agent web pages, repositories आणि issue trackers मधील मजकूर वाचतो आणि त्या मजकुरात instructions असू शकतात. त्याने fetch केलेल्या मजकुरातील instructions आणि तुमच्या instructions यांमध्ये फरक ओळखण्याचा मॉडेलकडे विश्वसनीय मार्ग नसतो. मॉडेल योग्य निवड करेल यावर अवलंबून असलेले कोणतेही नियंत्रण convincing injected instruction आल्यावर पहिल्याच वेळी अपयशी ठरते. त्यामुळे नियंत्रण operating system किंवा network मध्ये असणे आवश्यक आहे.

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

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

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

अंशतःच. Vault मुळे storage ची समस्या सुटते. तुम्ही तो vault self host करत असल्यास त्याचे स्वतंत्र hardening करावे लागते. कारण Vaultwarden server मध्ये साधारणपणे त्याच्या admin token किंवा backup file द्वारे breach होते, त्यात साठवलेल्या encrypted items द्वारे नाही. शेवटची पायरी मात्र यामुळे सुटत नाही. त्या पायरीवर काहीतरी vault मधून secret काढून ते agent ला environment variable म्हणून देते आणि तुम्ही पुन्हा सुरुवातीच्या स्थितीत जाता. 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 असलेल्या एका ओळीत नोंदवला जातो. Leak झाल्याचा संशय असल्यास प्रथम key rotate करा आणि नंतर तपास करा. Rotation स्वस्त आहे; खात्री स्वस्त नाही.

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

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