Agent tool की अस्थायी फ़ाइलें: सीक्रेट के निशान खोजें और साफ़ करें

एजेंट टूल की अस्थायी फ़ाइलों की जाँच source repository जितनी ही गंभीरता से करनी चाहिए। कोई coding agent अनुरोध का body बना सकता है, कमांड चला सकता है, verbose logging के साथ उसे दोबारा चला सकता है, output को cache में कॉपी कर सकता है और मूल working directory को साफ़ छोड़ सकता है। संवेदनशील सामग्री फिर भी मशीन पर रहती है, अक्सर ऐसी जगहों पर जिन्हें किसी ने review में शामिल ही नहीं किया।

यह मान लेना गलत है कि सीक्रेट तभी लीक होता है जब एजेंट उसे chat transcript में दिखाए। आम तौर पर लीक का ज़्यादा साधारण तरीका यह होता है कि किसी credential वाले अनुरोध को helper के लिए temp file में कॉपी किया जाता है, या पिछले हफ्ते debug mode चालू रहने के कारण असफल कमांड लॉग में दर्ज हो जाती है। सफ़ाई ज़रूरी है, लेकिन रोकथाम उससे भी ज़्यादा महत्वपूर्ण है: अगर कोई दूसरा प्रोसेस कार्रवाई कर सकता है, तो एजेंट को raw credentials न दें।

एजेंट टूल working tree के बाहर कॉपियाँ बनाते हैं

एजेंट रन कई स्तरों पर डेटा छोड़ सकता है, भले ही project directory में कोई स्पष्ट निशान न दिखे। Working tree केवल एक write location है और डेवलपर अक्सर उसी को देखते हैं क्योंकि वह परिचित होती है। एजेंट, उसका runtime, shell, package manager, editor, terminal और operating system, सभी के पास लिखने की अपनी जगहें होती हैं।

सबसे पहले सामग्री को तीन श्रेणियों में बाँटें। Payload files में वह सामग्री होती है जिसे एजेंट भेजना चाहता था, जैसे JSON request body, SQL batch, prompt export, patch file या SSH configuration। Output files में remote system का लौटाया हुआ डेटा होता है, जैसे API response, command output, database export और error page। Diagnostic material आसपास का सबूत रखता है: command arguments, environment details, stack traces, retries और traces।

तीनों में संवेदनशील डेटा हो सकता है। Script भेजने से पहले token जोड़ दे तो payload में वह शामिल हो सकता है। Output में customer record या deployment secret आ सकता है। Diagnostics में दोनों एक ही पंक्ति में दर्ज हो सकते हैं। इसी वजह से debug log कभी-कभी असफल कमांड से भी अधिक नुकसान करता है।

एक उपयोगी inventory में ये जगहें शामिल हैं:

• macOS की process temporary directory और /private/tmp।
• ~/Library के अंदर application support, cache और log directories।
• Shell history, terminal scrollback export और command wrappers।
• Project-local folders जैसे .cache, tmp, logs, .agent और test fixture directories।
• Container writable layers, bind mounts, CI workspaces और uploaded build artifacts।

यह न मानें कि एजेंट एक ही तय directory इस्तेमाल करता है। अलग-अलग versions, plugins, language runtimes और error paths अलग विकल्प चुन सकते हैं। कोई tool TMPDIR में बताई गई directory इस्तेमाल कर सकता है, उसके द्वारा चलाया गया helper /tmp इस्तेमाल कर सकता है और कोई library current project के अंदर cache रख सकती है। भरोसेमंद उत्तर अपने run को देखकर ही मिलेगा।

यही बात command output पर भी लागू होती है। command > result.txt जैसी shell redirection साफ़ दिखाई देती है। कम स्पष्ट उदाहरण हैं terminal multiplexer logs, package-manager debug archives, HTTP client trace files और agent द्वारा document बदलने के बाद लिखी गई editor recovery files। अगर एजेंट कई tools चला सकता है, तो test करने तक मानें कि हर tool डेटा रखने की अपनी अलग आदत रखता है।

सफ़ाई से पहले वास्तविक write locations का नक्शा बनाएँ

जिस path का आपने गलत अनुमान लगाया हो, उसे साफ़ नहीं कर सकते। किसी harmless, unique marker के साथ एजेंट चलाएँ और फिर उन सभी जगहों में marker खोजें जहाँ run लिख सकता है। ऐसा fake data इस्तेमाल करें जो असली data जैसा हो और उन्हीं code paths से गुज़रे, लेकिन इस अभ्यास में production token कभी न इस्तेमाल करें।

macOS पर सबसे पहले उस shell को मिली temp directory दर्ज करें जिससे एजेंट launch होता है:

echo "TMPDIR=$TMPDIR"
ls -ld "$TMPDIR" /private/tmp /tmp

macOS आम तौर पर हर user को /var/folders के नीचे एक directory देता है और /tmp /private/tmp की ओर point करता है। बनाया गया path security boundary नहीं है और बदल सकता है। Cleanup script में path hard-code करने के बजाय उसका मान दर्ज करें।

ऐसा marker बनाएँ जिसे ढूँढना आसान हो, फिर एजेंट से ऐसी representative action करवाएँ जो उसे request body, command argument और command output से गुज़ारे। यह उदाहरण जानबूझकर non-secret string इस्तेमाल करता है:

export AGENT_TRACE_MARKER='TEMP-PAYLOAD-CANARY-9f2a7c'
printf '%s\n' "$AGENT_TRACE_MARKER" > /tmp/agent-canary.txt

Run के बाद संभावित per-user locations खोजें। grep binary files और permission errors का सामना कर सकता है, इसलिए इसे discovery tool समझें, इस बात का प्रमाण नहीं कि कुछ भी मौजूद नहीं है।

grep -RIl --exclude='*.sqlite*' \
  'TEMP-PAYLOAD-CANARY-9f2a7c' \
  "$TMPDIR" /private/tmp \
  "$HOME/Library/Caches" \
  "$HOME/Library/Logs" \
  "$HOME/Library/Application Support" 2>/dev/null

Output में file paths की सूची आनी चाहिए। हर path के लिए चार सवालों के जवाब दें: इसे किस process ने लिखा, इसमें किस तरह की सामग्री है, इसे कौन पढ़ सकता है और यह कब गायब होगा। अगर किसी file को process से जोड़ नहीं पा रहे हैं, तो उसका modification time देखें और नए marker के साथ test दोहराएँ। पहले अस्पष्ट files delete न करें। हो सकता है आप वह सुराग मिटा दें जो बताता कि किस component को फिर से configure करना है।

जब file थोड़ी देर के लिए ही दिखाई दे, तो fs_usage इस्तेमाल करें। Agent चलने के दौरान यह किसी process की filesystem activity दिखा सकता है:

sudo fs_usage -w -f filesystem | grep -iE 'agent|tmp|cache|log'

यह command बहुत अधिक output देती है। इसे छोटे test के दौरान चलाएँ, देखे गए paths को shared project directory से बाहर save करें और बाद में रोक दें। जो process एक सेकंड के भीतर file लिखकर हटा देता है, वह बाद की directory listing में नहीं दिखेगा, फिर भी उसकी सामग्री backup, watcher या किसी दूसरे log collector तक पहुँच सकती है।

Credentials अक्सर request तैयार करते समय लीक होते हैं

सबसे खतरनाक temporary file अक्सर network call से पहले बनती है। कई scripts file में request तैयार करती हैं क्योंकि shell में JSON की quoting असुविधाजनक होती है। File शुरुआत में harmless होती है, फिर request चलाने के लिए कोई Authorization field, cookie या पूरा connection string जोड़ देता है। इस तरह वह अनजाने में स्थायी secret container बन जाती है।

इस pattern से बचें:

cat > /tmp/request.json <<'EOF'
{"endpoint":"https://api.example.invalid/export","token":"$PRODUCTION_TOKEN"}
EOF

ऊपर दिया गया single-quoted heredoc variable को expand नहीं करता, इसलिए यह सुरक्षित लग सकता है। बाद में कोई delimiter बदल सकता है या अलग construction method इस्तेमाल कर सकता है। इससे भी महत्वपूर्ण बात यह है कि यह design लोगों को credential को request artifact में रखने की आदत सिखाता है। पूरे request का debug dump उसे उजागर कर देगा।

जहाँ protocol अनुमति दे, credentials को transport layer में रखें और यह सुनिश्चित करें कि transport headers को log न करे। HTTP authorization headers query string में token रखने से बेहतर हैं, लेकिन वे अपने-आप सुरक्षित नहीं हो जाते। Verbose clients, proxy settings, exception handlers और custom retry code फिर भी उन्हें रिकॉर्ड कर सकते हैं।

HTTP Semantics specification, RFC 9110, कहती है कि user agents को sensitive information वाला URI Referer header में नहीं भेजना चाहिए। यह चेतावनी एक व्यापक तथ्य दिखाती है: URLs लोगों की अपेक्षा से कहीं अधिक जगहों तक पहुँचते हैं। वे access logs, browser history, copied terminal commands, support tickets और analytics systems में जा सकते हैं। Bearer tokens, व्यापक अधिकार वाले signed URLs, passwords या database connection strings को URL में न रखें, जब तक protocol कोई दूसरा विकल्प न दे और credential का जीवनकाल बहुत छोटा न हो।

Shell arguments के साथ भी यही सावधानी रखें। Unix-जैसे systems में permissions और platform settings के आधार पर कोई दूसरा local process arguments देख सकता है। Arguments shell history में भी आ सकते हैं, अगर कोई इंसान उन्हें कॉपी करे, task runner के log में और agent के tool transcript में भी। Environment variables कुछ रास्ते कम करते हैं, लेकिन inherited child processes और diagnostic reports जैसे दूसरे रास्ते बनाते हैं। इनमें से कोई भी सुरक्षित vault नहीं है।

बेहतर boundary सरल है: एजेंट destination और non-sensitive inputs का नाम देकर operation का अनुरोध करे। अलग credential holder call से ठीक पहले authentication जोड़े। एजेंट को credential नहीं, केवल response या redacted error मिले।

Sallyport HTTP और SSH actions के लिए इसी boundary का पालन करता है: credential उसके encrypted vault में रहता है और एजेंट local app से action करने को कहता है। इससे raw secret agent context से बाहर रहता है, लेकिन response bodies या एजेंट द्वारा बनाई गई debug files harmless नहीं हो जातीं। आपको अब भी नियंत्रित करना होगा कि action क्या लौटाता है और एजेंट उसे कहाँ लिखता है।

Debug mode सामान्य failures को सीक्रेट के रिकॉर्ड में बदल देता है

टूटी हुई integration की जाँच करते समय debug logging उपयोगी है। यह उस evidence को सुरक्षित रखने के लिए बनी होती है जिसे सामान्य logging छोड़ देती है। इसमें अक्सर headers, पूरे request और response bodies, command lines, environment से आई settings, retry state और stack traces शामिल होते हैं।

गलती यह है कि समस्या एक बार आने के बाद broad debug flag चालू छोड़ दिया जाए। फिर वही flag कई सप्ताह बाद किसी असंबंधित job पर लागू हो जाता है, जब कोई real authority के साथ export या deployment चलाता है। बनी हुई file ऐसे cache directory में पड़ी रह सकती है जिसके बारे में किसी को पता ही न हो कि वह tool की है।

Diagnostics को कम और स्पष्ट lifetime वाली अलग data class मानें। Trace चालू करने से पहले तय करें कि उसे किस सवाल का जवाब देना है। अगर सवाल DNS resolution का है, तो resolver output लें। अगर server किसी JSON field को अस्वीकार कर रहा है, तो status code और redacted response excerpt log करें। Full wire logging अपवाद होना चाहिए, क्योंकि यह ऐसा data दर्ज करती है जिसकी समस्या हल करने के लिए आपको ज़रूरत नहीं थी।

Redaction writer के स्तर पर बनाएँ, बाद में नहीं। Logs में Authorization: खोजने वाला cleanup job custom headers, JSON fields, URL parameters, multiline values, base64 blobs और secrets वाली response content को छोड़ देगा। Log collector या backup service unredacted file कॉपी कर ले, तो बाद में मूल file साफ़ करने से बहुत कम लाभ होगा।

एक सुरक्षित diagnostic wrapper में उन fields की allowlist होनी चाहिए जिन्हें वह लिख सकता है। उदाहरण के लिए HTTP method, host, query parameters के बिना path, status code, duration, response byte count और request identifier दर्ज करें। हर header दर्ज करके बाद में गलत ones mask करने पर भरोसा न करें। Credential formats cleanup scripts की तुलना में तेज़ी से बदलते हैं।

यह अंतर उन tools में महत्वपूर्ण है जो command चलाने से पहले उसे दिखाते हैं। Command दिखाना, command के effective environment को log करना और packet trace लेना, तीन अलग बातें हैं। पूछें कि tool कौन-सा representation save करता है। Tool console display को redact कर सकता है, लेकिन verbose log को नहीं।

Failure paths को जानबूझकर जाँचें। Request को बीच में cancel करें। Malformed JSON भेजें। Synthetic credential से authentication failure कराएँ। Retry आज़माने के लिए timeout पैदा करें। ये paths ऐसी temporary files और exceptions बना सकते हैं जो successful calls नहीं बनाते। हमलावर भी system से सामान्य operation की तुलना में अधिक जानकारी निकलवाने के लिए इन्हीं paths को उकसा सकता है।

macOS पर deletion का मतलब containment है, जादुई shredding नहीं

आधुनिक macOS storage में secure deletion का मतलब filename को बार-बार overwrite करना नहीं है। SSD wear leveling, copy-on-write behavior, snapshots, cloud synchronization और backups के कारण software यह भरोसा नहीं दे सकता कि overwrite ने हर physical remnant को छुआ है। Shred utility चलाने की पुरानी आदत लोगों को काम पूरा होने का एहसास देती है, लेकिन महत्वपूर्ण copies का समाधान नहीं करती।

Live और accessible files हटाने के लिए deletion का उपयोग करें। शुरुआत से sensitive material की जगह सीमित रखने के लिए containment अपनाएँ। Exposure का संदेह हो तो encryption और credential rotation करें।

Agent-specific temporary directory के लिए run से पहले restrictive permissions लगाएँ और run के बाद उसे हटा दें:

run_dir="$(mktemp -d "${TMPDIR%/}/agent-run.XXXXXX")" || exit 1
chmod 700 "$run_dir"
trap 'rm -rf "$run_dir"' EXIT HUP INT TERM
export TMPDIR="$run_dir"

# launch the agent from this same shell
# agent-command

इससे run को एक ज्ञात scratch area मिलता है और सामान्य exit paths पर वह हट जाती है। इससे हर dependency को TMPDIR मानने के लिए मजबूर नहीं किया जा सकता और न ही दूसरी directory में कॉपी की गई सामग्री हटती है। इसलिए discovery exercise पहले करनी चाहिए।

rm -rf /tmp/* जैसी व्यापक cleanup commands से बचें। वे दूसरे processes को तोड़ सकती हैं, जाँच के लिए ज़रूरी material हटा सकती हैं और यह गलत भरोसा दे सकती हैं कि /tmp ही देखने की एकमात्र जगह थी। केवल वही directories हटाएँ जिन्हें launcher ने बनाया हो और जिनके ownership को आपका cleanup code साबित कर सके।

अगर कोई secret बाहर निकल गया हो सकता है, तो लंबे cleanup अभियान से पहले उसे rotate या revoke करें। Unknown log में कॉपी किया गया live API token अभी भी access path है। उसका filename उस authority की तुलना में कम महत्वपूर्ण है जो वह देता है। फिर backup tooling, shared drives, CI artifacts, log aggregation और endpoint search systems में downstream copies खोजें। Copies का समाधान किए बिना मूल file हटाने से exposure बना रहता है।

Encrypted local storage खोए हुए device से जोखिम घटाता है, लेकिन उसी unlocked user account के अंतर्गत चल रहे किसी दूसरे process से सुरक्षा नहीं देता। File permissions अब भी महत्वपूर्ण हैं। 700 directory mode कहता है कि दूसरे local accounts उसे browse न करें। यह उस agent process को नहीं रोकता जो पहले से आपके रूप में चल रहा है और न ही उस sync client को रोकता है जिसे आपने अपने home directory को पढ़ने की अनुमति दी है।

Credential boundary सबसे खतरनाक payload हटाती है

Cleanup की एक सीमा होती है। अगर agent को prompt, environment variable, config file या command output में production token मिल गया, तो वह उसे लिख सकने वाली किसी भी file में रख सकता है। आप नुकसान घटा सकते हैं, लेकिन केवल सावधानीपूर्वक housekeeping से architecture को सुरक्षित नहीं बना सकते।

Secret ownership agent process से बाहर रखें। Agent को केवल इतना कहना चाहिए, जैसे «इस approved endpoint पर यह deployment request भेजें» या «इस named connection का इस्तेमाल करके यह SSH command चलाएँ»। Local credential holder यह तय करे कि action को अनुमति देनी है या नहीं, credential जोड़े, action करे और result record करे। अगर agent को token की ज़रूरत ही नहीं है, तो उसे placeholder token की भी आवश्यकता नहीं।

इससे temporary-file review भी अधिक स्पष्ट हो जाता है। आप agent scratch directories में user inputs, generated code और returned data देख सकते हैं। आपको यह मानकर नहीं चलना पड़ेगा कि हर file में agent को उपलब्ध हर production secret हो सकता है।

Custom rules के ढेर की तुलना में fixed approval model का operational लाभ है। Incident के दौरान लोग इसे समझा सकते हैं। Sallyport local authentication से vault खुलने तक locked रहता है, नए agent process के पहली बार action करने पर authorization माँगता है और चुने हुए credentials के हर इस्तेमाल के लिए approval माँग सकता है। यह authority पर स्पष्ट नियंत्रण है, न कि यह अनुमान लगाने की कोशिश कि कोई generated command संदिग्ध दिखती है या नहीं।

Action authorization को data minimization न समझें। Approved call भी sensitive response body लौटा सकती है और agent उसे project file, cache या transcript में लिख सकता है। Responses को सबसे छोटे उपयोगी परिणाम के लिए design करें। अगर task को केवल deployment identifier और status चाहिए, तो पूरा configuration document न लौटाएँ। API server-side filtering देती हो तो उसका इस्तेमाल करें।

SSH पर विशेष ध्यान दें क्योंकि remote command output की कोई निश्चित सीमा नहीं होती। Configuration file पढ़ने वाली command, error के बाद environment variables दिखाने वाली command या verbose deployment utility सीक्रेट एजेंट को वापस भेज सकती है। SSH output को ऐसा data मानें जिसके लिए destination, retention period और review rule तय हों। Credential सुरक्षित हो सकती है, लेकिन लौटाया गया output फिर भी खतरनाक हो सकता है।

हर run को owner, directory और expiry दें

Cleanup policy तब सफल होती है जब files को किसी specific run से जोड़ा जा सके। Generic nightly script यह नहीं बता सकती कि temporary directory active process की है, जाँच योग्य failed job की है या किसी unrelated application की। Agent launcher यह बता सकता है।

Scratch directory के नाम में run identifier रखें, start time दर्ज करें और scratch directory के बाहर केवल non-sensitive metadata वाला छोटा manifest रखें। Manifest में launcher द्वारा बनाई गई directory, उसके owner process, expiry time और run पूरा हुआ या नहीं, यह लिखा होना चाहिए। उसमें command arguments, request bodies या environment values न रखें।

एक व्यावहारिक lifecycle में चार actions हैं:

1. Agent शुरू होने से पहले private scratch directory बनाएँ।
2. Agent और अपने नियंत्रण वाले helpers के लिए temporary-path environment variables सेट करें।
3. सामान्य exit पर directory हटाएँ और manifest को complete mark करें।
4. Scheduled job से उन abandoned directories को human review के लिए flag करें जो तय threshold से अधिक समय तक बची रहें।

Scheduled job को incomplete runs की directories flag करनी चाहिए, अपने-आप मिटाना नहीं। कोई process अब भी लिख रहा हो सकता है। Failed deployment के लिए evidence ज़रूरी हो सकता है। जब इंसान पुष्टि कर दे कि directory abandoned है और incident के लिए आवश्यक नहीं, तभी उसी ownership rule के अनुसार उसे हटाएँ।

Scratch directory को repository के अंदर न रखें। Project search, version control status commands, IDE indexing, file watchers और backup clients repositories पर ध्यान देते हैं। User-controlled temporary location के अंदर sibling directory आम तौर पर development tooling से अलग रखना और एक unit के रूप में हटाना आसान होता है।

Agent द्वारा खुद शुरू की गई automatic cleanup से सावधान रहें। Arbitrary cleanup paths चुन सकने वाला agent source files या evidence हटा सकता है। Launcher को path खुद बनाना चाहिए, उसे अपनी state में रखना चाहिए और canonicalize करने के बाद केवल उसी naming pattern से मेल खाने वाले paths हटाने चाहिए। Cleanup code में shell interpolation पहले ही पर्याप्त दुर्घटनाएँ कराती है, उसमें autonomous text generation जोड़ने की ज़रूरत नहीं।

उद्देश्य यह नहीं कि कुछ भी retained न रहे। आपको इतना operational evidence चाहिए कि पता चल सके किस run ने request की और वह सफल हुई या नहीं। इस record को raw payloads और full output से अलग रखें और इसके fields जानबूझकर साधारण रखें।

Logs और backups के लिए retention decision ज़रूरी है

जैसे ही कोई दूसरा system temporary file की कॉपी बनाता है, वह retained record बन जाती है। Backup software, cloud sync folders, endpoint protection tools, crash reporting, CI artifact upload और centralized logging उसका जीवन बढ़ा सकते हैं। मूल path गायब हो सकता है, लेकिन उपयोगी copy कहीं और रह सकती है।

उन सभी processes की सूची बनाएँ जो agent runs द्वारा इस्तेमाल की गई directories पढ़ सकते हैं। Development machine पर इसमें backup client, editor indexer, source control interface, terminal recorder और malware scanner शामिल हो सकते हैं। कुछ copies उपयोगी हैं। लक्ष्य यह है कि उन्हें चुनकर उनकी retention तय की जाए, न कि restore archive में token दिखने के बाद उनका पता चले।

Raw diagnostic output को अपने-आप sync होने वाली directories से बाहर रखें। इसमें desktop folders, shared project folders और वे workspaces शामिल हैं जिन्हें CI client artifact के रूप में package करता है। अगर review के लिए किसी tool को बड़ा response बनाना ही पड़े, तो उसे restricted permissions वाली private directory में रखें, expiry तय करें और जहाँ tooling exclusions support करती हो वहाँ routine synchronization से बाहर रखें।

Hash-chained audit record debug dump से अलग होता है। Audit record को यह बताना चाहिए कि किसने action माँगा, वह कब चला और result category क्या रही, बिना secrets की कॉपी बनाए। Sallyport अपने Sessions और Activity journals encrypted audit log से तैयार करता है और sp audit verify vault key के बिना offline hash chain verify कर सकता है। इससे raw payload को audit requirement बनाए बिना agent activity का evidence रखा जा सकता है।

Retention में exceptions भी शामिल हों। Incident के दौरान normal cleanup timer को घटना समझने के लिए ज़रूरी evidence नष्ट न करने दें। Access सीमित करें, relevant files को जानबूझकर preserve करें और उनका location दर्ज करें। फिर प्रभावित credentials rotate करें और incident process को जब उस material की आवश्यकता न रहे, तब उसे हटा दें। Incident retention ordinary agent output को permanent storage में डालने का बहाना नहीं है।

Policy बदलने के बाद backups भी जाँचें। Newly excluded scratch directory का असर केवल future backup runs पर होता है। Existing snapshots में पुरानी सामग्री provider के retention schedule के खत्म होने तक रह सकती है। Exposure response में यह तथ्य दर्ज करें, rm command से इतिहास बदल गया है ऐसा दिखावा न करें।

उत्सुक local attacker की तरह cleanup को test करें

जिस cleanup policy ने कभी search test का सामना नहीं किया, वह control नहीं, केवल वादा है। ऐसे fake canary से test करें जो उन strings जैसा हो जिन्हें आप खोना नहीं चाहते, फिर मशीन को ऐसे inspect करें जैसे कोई दूसरा local process उसे खोज रहा हो।

पहले सामान्य परिस्थितियों में test चलाएँ। Canary को input file, request field और simulated command output में रखें। Agent को पूरा चलाएँ, cleanup hook के बाद प्रतीक्षा करें और scratch location, caches, logs, project directory, shell history तथा संभावित support directories खोजें। हर hit दर्ज करें और उसका कारण बताएँ।

फिर असुविधाजनक cases चलाएँ। Process crash कराएँ। Network request के दौरान cancel करें। Tool की उपलब्ध सबसे verbose logging चालू करें। Terminal के बजाय IDE से चलाएँ। Host bind mount वाले container का उपयोग करें। हर variation output को अलग जगह भेज सकती है।

Filename के बजाय marker से खोजें। Copied payload को random filename मिल सकता है, वह SQLite database में जा सकता है या archive में compress हो सकता है। Binary या database में canary मिले तो writer पहचानें और तय करें कि उसे configuration, exclusion, redaction या अलग execution boundary की आवश्यकता है।

Agent version, operating system version, enabled plugins, आज़माई गई commands, मिले हुए paths और cleanup result वाला छोटा test record रखें। Command चलाने या requests भेजने में सक्षम कोई tool जोड़ें तो इसे update करें। यह साधारण काम है, लेकिन source code की security review से छूट जाने वाले regressions पकड़ लेता है।

आज harmless marker के साथ पहला test करें। अगर वह ऐसी जगह दिखे जिसकी आपने उम्मीद नहीं की थी, तो अधिक जटिल deletion script बनाने से पहले writer को ठीक करें। सबसे साफ़ temporary file वही है जिसमें शुरुआत से credential या sensitive response आया ही न हो।