AI agents سے secrets محفوظ رکھنے کا طریقہ

AI agents سے secrets باہر رکھنے کا مطلب

AI agent ایک عام Linux process ہوتا ہے جو commands چلاتا ہے۔ اس process کے پاس موجود ہر environment variable اس کے چلائے ہوئے code کے لیے قابلِ مطالعہ ہوتا ہے۔ اس لیے agent کے environment میں موجود API key ایسی key ہے جسے agent اپنے قابلِ رسائی کسی بھی host کو بھیج سکتا ہے۔ Agent سے secrets باہر رکھنے کا مطلب یہ ہے کہ اسے key کے بجائے ایک handle دیا جائے: محدود مدت کا scoped token، یا ایسا placeholder جسے network boundary پر کوئی دوسرا component اصل value سے بدل دے۔

یہ کسی model کے hostile ہونے کی کہانی نہیں ہے۔ طریقۂ کار اس سے کہیں زیادہ معمولی ہے۔ Agent کسی web page، README یا issue comment کو پڑھتا ہے جس میں instructions شامل ہوتی ہیں، اور ان پر عمل کرتا ہے، کیونکہ language model کے لیے آپ کے لکھے ہوئے text اور اس کے fetch کیے ہوئے text میں کوئی فرق نہیں ہوتا۔ اسے prompt injection کہتے ہیں۔ ایسا ہونے کے بعد نقصان کی حد بالکل ایک چیز متعین کرتی ہے: process کیا پڑھ سکتا ہے۔ اگر آپ نے ابھی تک boundary مقرر نہیں کی، تو server پر coding agent کو محفوظ طریقے سے چلانا ان isolation levels کی وضاحت کرتا ہے جن پر یہ guide مبنی ہے۔

خطرے کے ماڈل کو سادہ الفاظ میں

اسے اسی user کے طور پر چلائیں جس کے طور پر آپ کا agent چلتا ہے۔

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

اس سے نکلنے والی ہر line کسی اجنبی 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 میں شامل ہو۔
• کسی ایسے repository کو git commit اور git push جس میں agent لکھ سکتا ہو۔
• package install script، جو agent کے user کے طور پر arbitrary code چلاتی ہے۔
• ایسے hostname کا DNS lookup جس میں value شامل ہو؛ یہ اس وقت بھی باہر نکل جاتا ہے جب HTTP egress blocked ہو۔

آپ صرف review کے ذریعے اس مسئلے سے نہیں نکل سکتے۔ اصلاح یہ ہے کہ agent کی رسائی میں کوئی قیمتی data موجود نہ ہو۔

ورکنگ ٹری میں موجود secret، context window میں موجود secret ہوتا ہے

Agent فائلیں پڑھتا ہے۔ جس repository میں وہ کام کر رہا ہو، اس میں موجود .env فائل پڑھی جائے گی۔ فائل پڑھ لیے جانے کے بعد وہ context window میں شامل ہو جاتی ہے۔ اس کا مطلب ہے کہ وہ transcript، آپ کے رکھے ہوئے کسی بھی log، اور agent کی اگلی تحریر میں موجود ہو سکتی ہے۔

پہلے، جب key اس tree میں موجود تھی جس میں agent کام کر رہا تھا:

cd ~/projects/billing
cat .env
# STRIPE_SECRET_KEY=sk_live_...
# DATABASE_URL=postgres://app:hunter2@db.internal:5432/billing

بعد میں، جب فائل کو 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

اب agent کا user فائل نہیں کھول سکتا، کیونکہ working tree میں وہ فائل موجود نہیں رہی۔ Agent کی اپنی config میں موجود deny rules دوسری حفاظتی تہہ ہیں، پہلی نہیں۔ Claude Code project میں .claude/settings.json سے permission rules پڑھتا ہے:

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

اس سے agent کے exploration کے دوران غلطی سے فائل کھولنے کا امکان رک جاتا ہے۔ لیکن یہ کسی injected instruction کو base64 .env چلانے سے نہیں روکتا، کیونکہ یہ shell command ہے، file read نہیں۔ یہی حد ہر اس چیز پر بھی لاگو ہوتی ہے جو agent کی permissions کے بجائے اس کی عادات کو تشکیل دیتی ہے: ایسا skill جو agent کو کام کرنے والی کم سے کم تبدیلی تک محدود رکھتا ہے run کو ان فائلوں تک بھٹکنے سے روکتا ہے جنہیں اسے کھولنے کا اختیار نہیں تھا، لیکن پھر بھی یہ صرف ایک ہدایت ہے جس سے model کو قائل کیا جا سکتا ہے کہ وہ اس سے ہٹ جائے۔ config کو حفاظتی رکاوٹ اور filesystem permission کو دیوار سمجھیں۔ یہی تقسیم containers کے اندر بھی لاگو ہوتی ہے: Docker Compose میں env files اور secrets اس مسئلے کے ایک درجے نچلے ورژن کا احاطہ کرتا ہے۔

ہر ایجنٹ کے لیے اپنا غیر مراعات یافتہ user بنائیں

اگر ایجنٹ آپ کے 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 ~ اسے درست کرتا ہے۔ ایجنٹ user کو sudo میں شامل نہ کریں، اور اسے NOPASSWD کا ایسا rule نہ دیں جو اس ایک command سے زیادہ وسیع ہو جس کی اسے واقعی ضرورت ہے۔ 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

اسے ایجنٹ کے جانب سے check کریں۔ sudo -u agent-review curl -s --max-time 3 http://169.254.169.254/ کو کچھ بھی print نہیں کرنا چاہیے اور اسے non-zero exit status کے ساتھ ختم ہونا چاہیے، کیونکہ packet box سے باہر جانے سے پہلے ہی reject ہو جاتا ہے۔

حدِ اتصال پر credential شامل کریں

اس مسئلے کا مؤثر حل credential injection ہے۔ agent کے پاس کبھی اصل key نہیں ہوتی۔ یہ اپنی request مقامی gateway کے ذریعے بھیجتا ہے، اور gateway باہر جاتے وقت placeholder کو اصل secret سے بدل دیتا ہے۔ secret gateway کے storage میں، ایک مختلف process کے اندر اور ایک مختلف user کی ملکیت میں رہتا ہے۔

OneCLI اس طریقے کی ایک open source implementation ہے۔ یہ Apache-2.0 کے تحت licensed ہے اور agent کے ساتھ والے container میں چلتی ہے۔ July 2026 تک project اس setup کو دستاویز کرتا ہے:

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

dashboard پورٹ 10254 پر اور gateway پورٹ 10255 پر listening کرتے ہیں۔ آپ اصل credential ایک بار store کرتے ہیں۔ پھر ہر agent کو key کی جگہ ایک placeholder value اور اپنا scoped access token دیتے ہیں، جسے یہ Proxy-Authorization header میں بھیجتا ہے۔ gateway host اور path کی بنیاد پر outbound request کو match کرتا ہے، متعلقہ credential کو decrypt کرتا ہے اور اسے placeholder کی جگہ رکھ دیتا ہے۔ agent کے environment میں چوری کے قابل کوئی secret موجود نہیں رہتا۔

یہاں اصل فائدہ encryption نہیں ہے۔ فائدہ یہ ہے کہ سوال "اس agent نے کیا استعمال کیا، اور کب استعمال کیا؟" ایک log query بن جاتا ہے۔ آپ اس بات کا اندازہ لگانے کے بجائے ایک audit trail پڑھتے ہیں کہ key کی copy چھ environments میں سے کس میں موجود تھی۔

راز کو process کے حوالے کریں، environment کو نہیں

اگر آپ agent کو systemd کے تحت چلاتے ہیں تو environment variables کی بالکل ضرورت نہیں رہتی۔ LoadCredential= راز کو ایک private directory میں رکھتا ہے جسے صرف وہ service پڑھ سکتی ہے۔ یہ unit file میں %d اور process کے اندر $CREDENTIALS_DIRECTORY کے طور پر دستیاب ہوتا ہے۔ یہ value /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 کھولتا ہے۔ File read صرف ایک لمحے کے لیے ہوتی ہے۔ Environment variable process کی پوری مدت تک موجود رہتا ہے، اور اس کے شروع کیے گئے ہر child process میں بھی دستیاب ہوتا ہے۔

مختصر مدت کے tokens کو طویل مدت کی keys پر ترجیح دیں

ایسی key جو کبھی expire نہ ہو، کئی ماہ بعد بھی اس وقت valid رہتی ہے جب وہ کسی 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) کم از کم 15 منٹ قبول کرتا ہے، اور عموماً ایک agent task کے لیے یہ کافی ہوتا ہے۔ GitHub کے لیے agent user کو اپنا gh login دیں، جس کے ساتھ fine-grained token ہو اور جو صرف اسی repository تک محدود ہو جس پر وہ کام کرتا ہے، تاکہ اس session کے اندر gh auth token ایسی چیز واپس کرے جو کسی اور resource تک رسائی نہ دے سکے۔ پہلے resource کے لحاظ سے scope محدود کریں، پھر time کے لحاظ سے۔

تصدیق کریں، پھر مسلسل تصدیق کرتے رہیں

ایجنٹ کے setup میں کسی بھی تبدیلی کے بعد تین checks ضرور چلائیں۔ انہیں اپنے اکاؤنٹ سے نہیں، بلکہ ایجنٹ کے 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

پہلے check سے بالکل کچھ بھی print نہیں ہونا چاہیے۔ دوسرے سے ls: cannot open directory '/home/you/': Permission denied print ہونا چاہیے۔ تیسرا check یہ بتاتا ہے کہ ایجنٹ کا network path کس identity کو ظاہر کرتا ہے۔ 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 شامل ہو سکتی ہیں۔ ماڈل کے پاس آپ کی instructions اور fetch کیے گئے متن میں قابلِ اعتماد فرق کرنے کا کوئی طریقہ نہیں ہے۔ ایسا ہر control جو ماڈل کے درست انتخاب پر منحصر ہو، پہلی مرتبہ کسی injected instruction کے مؤثر ثابت ہوتے ہی ناکام ہو جاتا ہے۔ اس لیے control کو operating system یا network میں ہونا چاہیے۔

کیا agent secrets کے لیے environment variables واقعی اتنے خطرناک ہیں؟

یہ ایک مخصوص وجہ سے خطرناک ہیں: یہ inherited ہوتے ہیں۔ agent جس بھی child process کو spawn کرتا ہے، اسے ان کی ایک copy مل جاتی ہے، جس میں build script، test runner اور package install hook بھی شامل ہیں۔ یہی user /proc/<pid>/environ کے ذریعے variables پڑھ بھی سکتا ہے، اس لیے agent جو کچھ بھی run کرتا ہے وہ agent کے آگے بھیجے بغیر انہیں پڑھ سکتا ہے۔ استعمال کے وقت پڑھی جانے والی file، LoadCredential= یا gateway کے ساتھ، exposure کو صرف اسی وقت تک محدود رکھتی ہے۔

کیا secrets کو vault میں رکھنے سے یہ مسئلہ خود حل ہو جاتا ہے؟

صرف جزوی طور پر۔ vault storage کا مسئلہ حل کرتا ہے۔ یہ آخری مرحلہ حل نہیں کرتا، جس میں کوئی چیز secret کو vault سے نکال کر agent کو environment variable کے طور پر دیتی ہے۔ اس طرح آپ دوبارہ اسی حالت میں پہنچ جاتے ہیں۔ اہم بات یہ ہے کہ substitution کون انجام دیتا ہے۔ اگر agent secret fetch کرتا ہے تو secret agent کے پاس ہے۔ اگر gateway یا init system agent کے process سے باہر substitution انجام دے تو agent کے پاس secret کبھی نہیں آتا۔

مجھے کیسے معلوم ہوگا کہ agent پہلے ہی کچھ leak کر چکا ہے؟

عموماً بعد میں یہ معلوم نہیں ہو سکتا، اور یہی gateway استعمال کرنے کی بنیادی وجہ ہے۔ اس کے بغیر آپ کا evidence shell history، agent کے transcript اور outbound connection logs میں بکھرا ہوتا ہے، اور غالباً آپ یہ logs رکھ بھی نہیں رہے ہوتے۔ credential gateway کے ساتھ credential کا ہر استعمال agent identity اور timestamp سمیت ایک line میں درج ہوتا ہے۔ اگر آپ کو leak کا شبہ ہو تو پہلے key rotate کریں اور بعد میں investigation کریں۔ Rotation سستی ہے، یقین دہانی نہیں۔

مجھے آج کم از کم کیا کرنا چاہیے؟

ہر .env file کو ان directories سے باہر منتقل کریں جہاں آپ کے agents کام کرتے ہیں، اور ہر agent کے لیے ایک unprivileged user بنائیں۔ ان دونوں تبدیلیوں میں تقریباً دس منٹ لگتے ہیں اور یہ سب سے عام راستہ بند کر دیتی ہیں: agent ایسی credential file پڑھ لیتا ہے جسے code کے ساتھ رکھنے کی کوئی وجہ نہیں تھی۔ Gateway اور short-lived tokens اگلا مرحلہ ہیں، پہلا نہیں۔ یہی ابتدائی طریقہ کسی بھی agent runtime پر لاگو ہوتا ہے، جس میں VPS پر autonomous agent کو محفوظ طریقے سے چلانا بھی شامل ہے۔