AI agents के लिए SSH access: private keys के बिना remote commands

किसी AI coding agent को SSH की प्राइवेट कुंजी देना गलत abstraction है। एजेंट को ऐसे स्थायी credential की ज़रूरत नहीं है जो किसी भी मशीन से, किसी भी समय authenticate कर सके। उसे किसी खास remote action को करने की अनुमति चाहिए, जबकि आप उस कार्रवाई को देख, रोक और समझा सकें।

Architecture में यह छोटा बदलाव लग सकता है, लेकिन ऐसा नहीं है। इससे हमेशा यात्रा कर सकने वाले secret और ऐसे SSH request के बीच फर्क साफ़ होता है जिसमें caller, destination, command, result और owner मौजूद हों।

मैंने teams को एजेंट के prompt rules कड़े करने में कई दिन लगाते देखा है, फिर भी उसी process को ~/.ssh/id_ed25519 पढ़ने की अनुमति रहती है। Private key उपलब्ध हो तो prompt rules केवल दिखावा हैं। Shell command उस file को copy, print या archive कर सकती है, या ऐसी जगह भेज सकती है जहाँ आपको कई हफ्तों तक पता न चले।

Private key छोटे नाम वाला API token नहीं है। यह हर उस SSH server के लिए reusable authority token है जो उसके public half को स्वीकार करता है।

एजेंट को identity नहीं, action दें

एजेंट को SSH operation माँगना चाहिए, जबकि अलग trusted component identity अपने पास रखकर connection बनाए। इस component को destination, remote account, command, arguments और timeout जैसी structured input मिले। यह request की जाँच करे, server से authenticate करे, result capture करे और केवल result एजेंट को लौटाए।

Secret एक ही मशीन पर रहता है। इससे भी महत्वपूर्ण बात यह है कि उसे इस्तेमाल करने का अधिकार अब एजेंट process के साथ हर जगह नहीं घूमता।

यह अंतर failure mode बदल देता है। अगर एजेंट compromise हो जाए या repository से मिली hostile instructions का पालन करे, तो वह अब भी गलत command माँग सकता है। लेकिन वह चुपचाप private key export करके अगले महीने किसी disposable VM से उसका इस्तेमाल नहीं कर सकता। आपने open-ended credential theft problem को authorization और command-control problem में बदल दिया है।

दूसरी problem अब भी गंभीर है। फर्क इतना है कि इसे operate और control किया जा सकता है।

एक उपयोगी request shape जानबूझकर साधारण होनी चाहिए:

{
  "host": "deploy-01.internal.example",
  "user": "release",
  "command": "/usr/local/libexec/release-service",
  "args": ["api", "2025.03.08-4f2c1a7"],
  "timeout_seconds": 120
}

ssh deploy-01 'cd /srv/api && git pull && sudo systemctl restart api' जैसी shell string को पाँच layers से भेजकर इसे control न समझें। Shell parsing rules आपकी security boundary का हिस्सा बन जाती हैं, जबकि लगभग कोई उन्हें उस तरह review नहीं करता। Command path को fixed रखें, arguments को अलग values के रूप में भेजें और remote wrapper से expected grammar के बाहर की values reject करवाएँ।

मैं ऐसे action contract को प्राथमिकता देता हूँ जिसे इस्तेमाल करना थोड़ा मुश्किल हो, बजाय ऐसे flexible remote terminal के जिसे कोई सीमित न कर सके। परेशानी setup के समय होती है। Unrestricted terminal से होने वाला नुकसान बाद में सामने आता है।

Broker को इतना structured result लौटाना चाहिए कि एजेंट अनुमान लगाए बिना काम जारी रख सके:

{
  "exit_code": 0,
  "stdout": "released api version 2025.03.08-4f2c1a7\n",
  "stderr": "",
  "duration_ms": 1842
}

Credentials, agent sockets, known_hosts contents या interactive TTY वापस न भेजें। ये trusted side के implementation details हैं।

Possession, signing और execution अलग-अलग अधिकार हैं

Teams अक्सर «SSH access» को एक ही चीज़ समझती हैं। असल में इसमें कम से कम तीन अलग अधिकार होते हैं: private key अपने पास रखना, agent से signature बनवाना और broker से नामित remote command चलवाना।

Private key अपने पास रखना सबसे व्यापक अधिकार है। File पढ़ सकने वाला व्यक्ति उसकी अनगिनत copies बना सकता है और हर reachable server पर उसे आज़मा सकता है। File permissions, disk encryption और passphrases मदद करते हैं, लेकिन मूल सवाल का जवाब नहीं देते: AI process को portable credential की ज़रूरत ही क्यों थी?

ssh-agent से हर client को private-key file पढ़ने की ज़रूरत नहीं रहती। Process SSH_AUTH_SOCK के ज़रिए signature माँग सकता है। यह local workstation hygiene के लिए सुधार है, लेकिन signing अब भी authentication power देता है। OpenSSH के ssh-agent(1) manual के अनुसार forwarding के दौरान agent private keys को network transit से बाहर रखता है, जबकि forwarded requester को identity operations का result मिलता है। यह उपयोगी property है, पूरी authorization model नहीं।

Action execution को सीमित बनाया जाए तो यह अधिक narrow होता है। Broker unknown host को रोक सकता है, अलग remote account को मना कर सकता है, human decision माँग सकता है, execution time सीमित कर सकता है, PTY रोक सकता है और call का record रख सकता है। हर operation class के लिए अलग SSH identity भी इस्तेमाल की जा सकती है।

यह आखिरी बात teams की अपेक्षा से अधिक महत्वपूर्ण है। Logs पढ़ सकने, code deploy करने, /etc/sudoers बदलने और tunnels खोलने वाली एक identity आपके पूरे fleet जितनी बड़ी authorization boundary बनाती है। चार narrow server-side restrictions वाली identities चार छोटे problems बनाती हैं।

गलती के बाद चार सीमित identities rotate करना मेरे लिए उस पूरे weekend से बेहतर है जिसमें यह साबित करना पड़े कि एक administrator identity हर host तक नहीं पहुँची।

यह pattern harmful command को harmless नहीं बनाता। यह उसे पकड़ने के लिए कई जगह देता है: connection से पहले, server authentication के समय, forced remote command के भीतर और बाद के record में।

SSH agent forwarding अलग समस्या हल करता है

SSH agent forwarding jump host पर private key copy करने से बचाता है, लेकिन इससे remote machine को एजेंट को सौंपना सुरक्षित नहीं हो जाता। Remote host को socket तक access मिलता है जो आपके local authentication agent से operations माँग सकता है।

OpenSSH इसे ssh_config(5) में स्पष्ट रूप से कहता है: agent forwarding सावधानी से enable करें, क्योंकि remote host की permissions bypass कर सकने वाला user forwarded connection के ज़रिए local agent का इस्तेमाल कर सकता है। Attacker इस interface से private-key bytes निकाल नहीं सकता, लेकिन loaded identities से authenticate करने को कह सकता है।

Autonomous tools के साथ यह जोखिम और स्पष्ट हो जाता है। कोई task agent से log देखने के लिए host से connect करने को कह सकता है। Malicious repository instruction, compromised remote account या poorly contained command फिर SSH_AUTH_SOCK खोजकर forwarded signing capability इस्तेमाल कर सकता है। Private key तकनीकी रूप से secret रहती है, जबकि authentication authority का दुरुपयोग हो जाता है। इस फर्क से पीड़ित को ज्यादा राहत नहीं मिलेगी।

ForwardAgent yes को globally enable न करें। Baseline client configuration में ForwardAgent no रखें और केवल ऐसे नामित human workflow के लिए explicit exception दें जिसे इसकी सचमुच ज़रूरत हो।

Host *
    ForwardAgent no
    AddKeysToAgent no
    IdentitiesOnly yes
    StrictHostKeyChecking yes

Host legacy-bastion
    HostName bastion.internal.example
    User ops
    ForwardAgent yes

ऊपर दिए exception के लिए भी reason, owner और removal date चाहिए। Permanent forwarding exception अक्सर अदृश्य हो जाता है, क्योंकि SSH उसे इतनी आसानी से काम करने देता है।

Destination-constrained identities इस स्थिति को बेहतर बनाती हैं, लेकिन action boundary का विकल्प नहीं हैं। OpenSSH का ssh-add(1) manual बताता है कि cooperating client और server agent forwarding के दौरान destination constraints पूरी connection path को जाँचती हैं। यह भी चेतावनी दी गई है कि remote SSH_AUTH_SOCK वाला व्यक्ति उस socket को फिर forward कर सकता है, हालांकि उसका इस्तेमाल permitted destinations तक सीमित रहता है।

जहाँ उपयुक्त हो वहाँ destination constraints इस्तेमाल करें। उन्हें command policy न समझें। वे बताते हैं कि identity कहाँ authenticate कर सकती है, यह नहीं कि वहाँ पहुँचने के बाद rm -rf /srv/release-cache चलना चाहिए या नहीं।

Command path के साथ failure को अंत तक देखें

एक plausible incident अच्छे इरादे वाले shortcut से शुरू होता है: developer deployment private key को environment variable में रख देता है, क्योंकि coding agent को एक release command चलानी है। Agent ऐसी repository issue पढ़ता है जिसमें diagnostic command दी गई है। Troubleshooting के लिए command environment print करती है और execution transcript local session log में पहुँच जाता है।

पहला नुकसान SSH से पहले ही हो गया। Private key ऐसे process में पहुँच गई जिसे उसे रखना ही नहीं चाहिए था।

अब एजेंट के पास इसे leak या reuse करने के कई रास्ते हैं। वह value को temporary file में लिख सकता है, scp से remote host पर भेज सकता है, Git commit में रख सकता है या ऐसी subprocess को दे सकता है जो आपकी कल्पित boundaries से बाहर हो। एक बार copy की गई private key केवल इसलिए expire नहीं होती कि आपने agent run रोक दिया।

मान लें कि team ने agent forwarding इस्तेमाल किया। Repository instruction एजेंट से build-02 connect करने को कहती है और फिर ऐसा command चलाती है जो forwarded socket को उस remote machine के local process के लिए उपलब्ध कराता है। Attacker private key print नहीं कर सकता, लेकिन developer के agent में loaded identity से किसी दूसरे host पर authenticate करने को socket से कह सकता है। Forward को general delegation mechanism बनाने का इरादा नहीं था, फिर भी वह बन गया।

अब brokered design देखें। Agent deploy-01 पर release-service api 2025.03.08-4f2c1a7 का request भेजता है। Broker देखता है कि यह नए agent process का पहला request है और authorization माँगता है। मंज़ूरी देने वाले व्यक्ति को calling process की code-signing authority, remote identity और target दिखता है। Broker केवल नामित host से connect करता है। Server केवल restricted deployment identity स्वीकार करता है और एक server-side wrapper चलाता है।

Hostile instruction अब भी release का अनुरोध कर सकती है। वह request को login shell, port forward, copied private key या unrelated servers के रास्ते में नहीं बदल सकती।

यह blast radius को काफी घटाता है, लेकिन flexibility की कीमत पर। Generic agent production की असामान्य स्थितियों के अनुसार improvisation कर सकता है। Constrained action interface नहीं कर सकता। Logs, service status, rollback, migration checks और artifact cleanup के लिए आपको जानबूझकर operations जोड़ने होंगे। इन interfaces का owner भी चाहिए। यह काम optional नहीं है; unrestricted SSH इसे केवल छिपा देता है।

सही तरीका है कि safe path में वे काम शामिल किए जाएँ जो लोग सचमुच करते हैं, न कि हर बार safe path में किसी एक feature की कमी होने पर raw shell फिर खोल दिया जाए।

SSH client को local decision point के पीछे रखें

Local decision point को तीन चीज़ों का owner होना चाहिए: encrypted private identity, उसे इस्तेमाल करने की अनुमति और उससे बना evidence। Agent के पास इनमें से कोई नहीं होना चाहिए।

Sallyport macOS agents के लिए इसी pattern का पालन करता है: इसका bundled sp mcp shim सामान्य MCP calls स्वीकार करता है, जबकि menu-bar app SSH identities को encrypted vault में रखता है और connection के लिए sp-ssh इस्तेमाल करता है। Agent को credential के बजाय command result मिलता है।

Implementation से ज्यादा महत्वपूर्ण उसका shape है:

AI agent process
    -> local action request
        -> authorization decision
            -> SSH helper using protected identity
                -> remote sshd and restricted account
                    -> stdout, stderr, exit status

जब human को काम supervise करना हो, decision point developer की managed machine पर रखें। इसे ऐसा network proxy न बनाएँ जो हर process के हर request पर चुपचाप sign करता रहे। Local process boundary caller की पहचान बताती है और network connection शुरू होने से पहले unexpected executable को reject कर सकती है।

Process identity approval card का सजावटी field नहीं है। जिस signed application की आप अपेक्षा कर रहे थे उससे आया request और /tmp से चलाए गए unsigned binary का request अलग हैं, भले दोनों खुद को «coding agent» कहें। macOS पर code-signing authority approver को जाँचने के लिए कुछ ठोस देती है।

मेरी अपेक्षा है कि नया process SSH identity इस्तेमाल करने से पहले session अर्जित करे। Process exit होते ही वह session भी समाप्त हो जाना चाहिए। Long-lived grants चलाने में आसान और compromise के बाद समझाने में कठिन होते हैं।

Vault lock होने पर हर SSH action को रोक देना चाहिए। Cached private key, exported PEM file या अपनी छिपी copy रखने वाले helper process पर कोई partial fallback नहीं होना चाहिए। अगर emergency path protection को bypass करता है, तो वह अंततः normal path बन जाएगा।

Remote account को जानबूझकर साधारण रखें

Remote server को यह सीमित करना होगा कि सफल SSH authentication के बाद क्या किया जा सकता है। Protected private key control का केवल एक हिस्सा है; server को उस identity को human administrator account नहीं, बल्कि एक purpose-built account समझना चाहिए।

Action के लिए अलग Unix account बनाएँ, जैसे release, diagnostics या backup। उसे personal shell profile, broad home directory या password login न दें। उसकी public identity को engineer की unrestricted personal identity के साथ उसी authorized_keys file में रखकर accounts को अलग न समझें।

Release operation के लिए authorized_keys entry ऐसी हो सकती है:

restrict,command="/usr/local/libexec/release-service" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleOnlyReplaceThis release-broker

restrict option port, agent और X11 forwarding, PTY allocation तथा ~/.ssh/rc का execution बंद करती है। OpenSSH का sshd(8) manual इसी उद्देश्य के लिए restrict को document करता है और इसे forced command के साथ दिखाता है।

Forced command को original command line sh -c को नहीं देनी चाहिए। SSH_ORIGINAL_COMMAND को ignore करें, जब तक आपके पास narrow parser और उसके tests न हों। Wrapper को fixed protocol स्वीकार करना चाहिए, हर field validate करनी चाहिए, audit entry लिखनी चाहिए और explicit argument boundaries के साथ असली operation चलाना चाहिए।

छोटा shell wrapper ठीक है, अगर वह छोटा ही रहे:

#!/bin/sh
set -eu

service=${1:-}
version=${2:-}

case "$service" in
  api|worker) ;;
  *) echo "unsupported service" >&2; exit 64 ;;
esac

case "$version" in
  *[!0-9A-Za-z._-]*|"") echo "invalid version" >&2; exit 64 ;;
esac

exec /usr/bin/sudo /usr/local/sbin/deploy-approved-release "$service" "$version"

Broker से इस wrapper को fixed arguments के साथ call करें। Client को अपना path चुनने न दें। अधिक operations चाहिए तो और wrappers बनाएँ या छोटा command dispatcher रखें जो named subcommands स्वीकार करे और बाकी सब reject कर दे।

यहाँ मेरी स्पष्ट सीमा है: autonomous agent को shared ops account, normal shell और बेहतर prompt के भरोसे न छोड़ें। Shared shell account server-side safeguards को voluntary बना देता है।

Stateful work के लिए idempotent operations इस्तेमाल करें। Release wrapper को बदलाव से पहले जाँचना चाहिए कि requested artifact पहले से active तो नहीं, service healthy है या नहीं और rollback point मौजूद है या नहीं। Timeout के बाद एजेंट request दोहरा सकता है; remote operation को repetition को दोबारा action की अनुमति नहीं समझना चाहिए।

Host verification और command grammar पर बराबर ध्यान दें

Private identity client authentication की रक्षा करती है। यह साबित नहीं करती कि एजेंट सही server तक पहुँचा। अगर automation किसी भी नए host fingerprint को स्वीकार करती है, तो DNS mistake, poisoned hosts file या active network attacker connection को ऐसे server की ओर मोड़ सकता है जो आपकी command पाएगा और उसका output पढ़ेगा।

Automation identities के लिए StrictHostKeyChecking yes इस्तेमाल करें। Reviewed host fingerprints configuration management के ज़रिए भेजें या carefully controlled known_hosts file रखें। Host की SSH host key बदलने पर out-of-band verification के साथ स्पष्ट change करें। Agent को host-key prompt पर «yes» कहने की training न दें।

Noninteractive action के लिए client profile कुछ ऐसी हो सकती है:

Host deploy-01.internal.example
    HostName deploy-01.internal.example
    User release
    IdentityAgent /path/to/broker.sock
    IdentitiesOnly yes
    StrictHostKeyChecking yes
    UserKnownHostsFile /Library/Application Support/agent-ssh/known_hosts
    BatchMode yes
    RequestTTY no
    ForwardAgent no

IdentitiesOnly yes SSH को agent के ज़रिए उपलब्ध हर identity destination पर भेजने से रोकता है। इससे noisy authentication attempts घटते हैं और intended action identity fail होने पर personal identity के accidental इस्तेमाल से बचाव होता है। OpenSSH का ssh_config(5) manual इसे configured identity files के इस्तेमाल का तरीका बताता है, न कि agent या provider की अतिरिक्त identities का।

अगर संभव हो तो host names का चुनाव agent से न करवाएँ। Request को production-api-release जैसे approved logical target का उल्लेख करना चाहिए। Trusted side उस नाम को hostname, remote account, host fingerprint, identity और command family से map करे। यह map policy है, लेकिन इसे ऐसी human-readable data बनाएँ जिसे inspect किया जा सके, न कि ऐसी clever language जो loopholes बढ़ाए।

Command grammar को भी इसी तरह सीमित रखें। Fixed binary को arbitrary arguments देने पर भी arbitrary execution हो सकती है, अगर binary file paths, plugin names, configuration imports या --exec flags स्वीकार करती हो। वास्तविक CLI जाँचें। Allowed tokens लिखित रूप में तय करें। Malformed input, whitespace, shell metacharacters, Unicode surprises और repeated flags का test करें।

अपने wrapper को ugly arguments से abuse करने में लगाए गए बीस मिनट एक और approval prompt से अधिक चीज़ें खोज लेंगे।

Authority उपयोगी बनते ही मंज़ूरी लें

Human approval उस boundary पर होनी चाहिए जहाँ process को पहली बार SSH capability मिलती है, न कि हर harmless command के बाद और न ही destructive command server तक पहुँचने के बाद।

Agent run के लिए per-session approval व्यावहारिक default है। नए process की पहली SSH action decision trigger करे। Approval में यह बताया जाना चाहिए कि किस signed process ने अनुरोध किया, वह कौन-सी identity इस्तेमाल करना चाहता है और उसे remote access की कौन-सी class मिलेगी। मंज़ूरी के बाद वही exact process उसके exit होने तक allowed requests कर सके।

इससे routine diagnostics clicks के ढेर में नहीं बदलते। साथ ही वह खराब विकल्प भी टलता है जिसमें machine पर node, python या claude नाम वाले हर future process पर एक ही approval लागू हो।

कुछ identities हर उपयोग पर दूसरी gate की हकदार हैं। Production deploy, emergency restart, database export, infrastructure mutation और network reachability बदल सकने वाली commands इसके उचित उदाहरण हैं। इसकी कीमत interruption है। लाभ यह है कि compromised session low-risk status check की मंज़ूरी मिलने के बाद सबसे खतरनाक identity का चुपचाप इस्तेमाल नहीं कर सकता।

Sallyport किसी individual SSH identity पर per-call approval requirement लगा सकता है, जबकि सामान्य session authorization grant को किसी खास agent process से जोड़ता है। Vault gate locked होने पर actions भी रोकता है, इसलिए व्यक्ति के दूर जाने के बाद background agent काम जारी नहीं रख सकता।

Approval prompt में users से serialized JSON का paragraph पढ़ने को न कहें। संक्षिप्त action summary दिखाएँ और details उपलब्ध रखें: destination, remote account, fixed command name, supplied arguments और timeout। लोग production-db और staging-db का फर्क जल्दी देख सकते हैं। दसवें prompt के बाद full shell pipeline में छिपा खतरा वे भरोसे से नहीं पहचान सकते।

Denial भी first-class output होना चाहिए। Agent को स्पष्ट refusal result मिले, ताकि वह बता सके कि permission नहीं थी, न कि दूसरे account, host या workaround के साथ retry करे। Denial के बाद repeated attempts का visible record रखें।

Audit trail compromised caller के बाद भी बचा रहना चाहिए

Agent-generated logs पर्याप्त नहीं हैं। अगर agent process अपने SSH calls का record लिख या मिटा सकता है, तो वह history का केवल सुविधाजनक version छोड़ सकता है।

Activity को agent process के बाहर record करें। कम से कम calling process identity, session identifier, time, destination, remote account, action name, redaction rules के बाद arguments, authorization result, exit code, duration और stdout तथा stderr का सीमित capture रखें। Noisy commands के लिए पहली और आखिरी 50 lines capture करें, या content hash के साथ protected full artifact रखें, अगर output में secrets हो सकते हों।

Raw private keys, bearer tokens या arbitrary environment variables log न करें। ऐसा audit system जो दूसरी credential leak पैदा करे, missing audit system से भी बदतर है, क्योंकि लोग उस पर भरोसा करेंगे।

Tamper evidence जाँच का तरीका बदल देता है। Chained log यह दिखा सकता है कि बाद में किसी ने records हटाए या क्रम बदला, जबकि सामान्य append-only text file आमतौर पर केवल file के मौजूद होने का प्रमाण देती है। Verification vault unlock किए बिना भी काम करना चाहिए, वरना system की उसी स्थिति में record नहीं देख पाएँगे जब evidence की सबसे अधिक ज़रूरत हो।

CISA की red-team assessment guidance credential containment की अहमियत का ठोस कारण देती है। उसके प्रकाशित assessment में एक team ने accessible files से दर्जनों private SSH keys हासिल कीं और Linux systems के बीच movement के लिए privileged identities इस्तेमाल कीं। सीख यह नहीं है कि हर agent intruder बन जाएगा। सीख यह है कि reusable SSH material उन जगहों तक पहुँचते ही lateral-movement inventory बन जाता है जहाँ उसकी आवश्यकता नहीं थी।

जब unexpected command दिखे, पहले agent session revoke करें। फिर server पर प्रभावित identity disable करें, verified activity record देखें और target host के sshd तथा system logs की समीक्षा करें। Protected boundary से बाहर जाने की कोई भी संभावना हो तो private identity rotate करें। Brokered model इस sequence को तेज़ बनाता है, क्योंकि session revoke करने से future action requests रुक जाती हैं और copied private key मिलने का इंतज़ार नहीं करना पड़ता।

एक general shell के बजाय चार narrow paths इस्तेमाल करें

Practical rollout के लिए उन remote actions की inventory बनाएँ जिन्हें agents पहले से आज़माते हैं और consequence के आधार पर उन्हें sort करें। शुरुआत यह पूछकर न करें कि उन्हें कौन-सी private keys चाहिए। यह सवाल गलत छोर से शुरू होता है।

अधिकांश teams को कुछ recurring operations मिलेंगे:

• सीमित service status या हाल की log excerpt पढ़ना।
• पहले से बने artifact को एक environment में deploy करना।
• ऐसा migration check चलाना जो data न बदले।
• Release के बाद नामित service restart करना।
• Failed job के लिए diagnostics इकट्ठा करना।

हर operation के लिए एक action path बनाएँ। जहाँ servers अलग हों वहाँ dedicated remote account या identity दें। Command को server-side force करें। Host identity pin करें। तय करें कि action को session approval चाहिए या हर उपयोग पर approval। Allowed और refused दोनों calls रिकॉर्ड करें।

असामान्य repair work के लिए human SSH path रखें। Incident के दौरान humans को interactive shell की ज़रूरत पड़ सकती है और इसके विपरीत दिखावा उन्हें unsafe escapes की ओर धकेलेगा। उस path में अलग personal identity, जहाँ उपलब्ध हो वहाँ MFA, उचित होने पर jump host और सामान्य incident controls होने चाहिए। Automation identity को केवल इसलिए साझा न करें कि authorized_keys में एक line कम हो जाएगी।

सुरक्षित pattern के लिए शुरुआती engineering अधिक चाहिए: wrappers को tests चाहिए, host fingerprints का owner चाहिए और action catalog का maintenance चाहिए। यह cost स्वीकार करें। विकल्प है probabilistic text generator को ऐसा credential देना जो उसके वर्तमान task के चारों ओर लगाए गए हर guardrail से अधिक समय तक जीवित रह सकता है।

Production के सबसे करीब वाली SSH private key से शुरुआत करें। उसे agent की पहुँच से हटाएँ, एक broad shell command को constrained action से बदलें और वास्तविक run के बाद record की समीक्षा करें। पहली boundary आपको साफ़ दिखा देगी कि बाकी काम कहाँ छिपा है।