# AI agent file uploads के लिए सख्त सीमाएँ Upload endpoint outbound data channel होता है, भले ही engineers उसे attachment feature कहें। जैसे ही AI agent किसी log, export, screenshot या customer file को attach कर सकता है, «इसे support को भेजो» जैसा अस्पष्ट निर्देश irreversible disclosure में बदल सकता है। AI agent file uploads में bytes, content और receivers के चारों ओर सख्त सीमाएँ चाहिए। ये सीमाएँ उस action में लगाएँ जो upload करता है, agent prompt में नहीं और न ही इस उम्मीद पर कि व्यस्त दिन के अंत में कोई reviewer गलत filename पहचान लेगा। ## Upload action को घोषित करना चाहिए कि क्या बाहर जा सकता है सुरक्षित upload flow हर फ़ाइल को घोषित उद्देश्य वाले object की तरह देखता है। उद्देश्य उसकी maximum size, स्वीकार किए जाने वाले formats, अनुमत receiver, retention की अपेक्षा और human approval की ज़रूरत तय करता है। अगर आपकी API arbitrary multipart body और caller-supplied URL स्वीकार करती है, तो आपने आसान developer interface के साथ general data exfiltration route बना दिया है। लोग अक्सर untrusted client से फ़ाइल लेने और agent की ओर से फ़ाइल भेजने के बीच का अंतर भूल जाते हैं। पारंपरिक upload guidance आपके server को malicious files से बचाने पर केंद्रित होती है। Agent uploads में यह सुरक्षा भी चाहिए, लेकिन तत्काल जोखिम data को बहुत व्यापक send से बचाना है। PDF parse करने के लिए पूरी तरह सुरक्षित हो सकती है, फिर भी ticketing system को भेजने के लिए अनुपयुक्त हो सकती है। Generic `upload_file` action के बजाय named upload purposes तय करें। `diagnostic_bundle` जैसा purpose एक compressed support bundle को एक support receiver तक भेजने की अनुमति दे सकता है। `invoice_export` जैसा purpose accounting receiver को CSV भेज सकता है। किसी भी purpose को एक ही request में path, receiver URL और arbitrary file स्वीकार नहीं करनी चाहिए। एक छोटा contract सीमा को स्पष्ट करता है: ```json { "purpose": "diagnostic_bundle", "file_path": "/private/tmp/app-diagnostics-2025-03-08.zip", "destination_id": "support-case", "case_reference": "CASE-1842" } ``` Caller approved purpose चुनता है और business action के लिए ज़रूरी metadata देता है। Upload service `support-case` को अपने नियंत्रण वाले receiver से map करती है। वह caller को issue comment, document या tool response में मौजूद URL से receiver बदलने नहीं देती। File paths पर भी नियंत्रण रखें। Agent को केवल designated staging directories से फ़ाइल चुनने दें, या service को known inputs से attachment खुद बनानी चाहिए। Agent को कोई भी readable path बताने देने से diagnostics attach करने का अनुरोध configuration files, SSH material, browser data या किसी दूसरे user के export को पढ़ने का अनुरोध बन सकता है। ## Size limits के लिए दो measurements चाहिए File limit ऐसी body को service के store, scan या forward करने से पहले अस्वीकार करे जो बहुत बड़ी हो। HTTP edge पर `Content-Length` मौजूद हो तो उसे लागू करें, फिर पढ़ते समय bytes गिनें, क्योंकि client header छोड़ भी सकता है या झूठा भी भेज सकता है। Limit purpose के अनुरूप होनी चाहिए। Customer CSV के लिए 25 MB और compressed diagnostic bundle के लिए 25 MB तय करना एक जैसा निर्णय नहीं है। Parser CSV पढ़ते समय उससे कहीं बड़ा memory allocation बना सकता है। Archive transport size से कई गुना बड़ा decompress हो सकता है। Wire-size limit और processed-size limit दोनों लगाएँ। Agent को rejected file को कई legal requests में बाँटने न दें, जब तक receiver chunked uploads को साफ़ तौर पर support न करता हो और आपकी service कुल आकार track न करती हो। वरना 10 MB का नियम 100-part transfer बन जाएगा और आपकी सोची हुई सुरक्षा नहीं रहेगी। जल्दी reject करें और ऐसा response दें जिससे agent सुरक्षित तरीके से recover कर सके: ```json { "error": "attachment_too_large", "purpose": "diagnostic_bundle", "observed_bytes": 12582911, "max_bytes": 8388608, "safe_alternatives": [ "create_redacted_diagnostic_bundle", "attach_selected_log_window" ] } ``` यह response महत्वपूर्ण है। अगर rejection सिर्फ़ «upload failed» कहता है, तो agent दूसरा destination आज़मा सकता है, फ़ाइल compress कर सकता है या बार-बार retry कर सकता है। उसे बताएँ कि अगली अनुमत कार्रवाई क्या है, लेकिन debug message के ज़रिए rejected file उजागर न करें। Buffering भी एक शांत failure है। कई frameworks application code तक पहुँचने से पहले multipart request को memory या temporary directory में parse कर देते हैं। Web server, framework parser, reverse proxy और application reader को एक ही limit पर configure करें। सबसे छोटी limit लागू होगी, लेकिन कोई अनपेक्षित रूप से बड़ी layer छोटी layer के reject करने से पहले disk space खा सकती है। Text normalization, image conversion, document extraction और archive unpacking के बाद का आकार भी मापें। केवल original attachment पर लागू limit बाद में बनाए गए material के resource use या disclosure potential को नियंत्रित नहीं करती। ## Filename और MIME header लगभग कुछ साबित नहीं करते File type checks के लिए independent evidence चाहिए, क्योंकि filename extension और `Content-Type` header sender देता है। Agent बिना किसी दुर्भावना के भ्रामक label forward कर सकता है। कोई support tool हर attachment को `application/octet-stream` कह सकता है। दोनों स्थितियों में receiver को bytes और अनुमत structure के आधार पर निर्णय लेना चाहिए। OWASP की File Upload Cheat Sheet extensions को allow-list करने, `Content-Type` header पर भरोसा न करने, server-side filenames बनाने और uploads को webroot के बाहर रखने की सलाह देती है। यह guidance सही है, लेकिन agent workflows में एक अतिरिक्त नियम चाहिए: service remote receiver से संपर्क करने से पहले type को named purpose से मिलाए। Valid PDF हर upload purpose के लिए valid नहीं होती। अलग सवालों के जवाब देने वाले कई checks रखें: - Extension बताती है कि sender का दावा क्या है। - Signature bytes बताते हैं कि content claimed format जैसा शुरू होता है या नहीं। - Bounded parser बताता है कि bytes format का इतना हिस्सा पूरा करते हैं या नहीं कि उन्हें सुरक्षित ढंग से संभाला जा सके। - Content inspection बताता है कि file में उस purpose के लिए प्रतिबंधित material है या नहीं। CSV export के लिए `.csv` और UTF-8 text जैसी छोटी allow list रखें, सीमित sample parse करें और embedded binary data या असामान्य रूप से चौड़ी rows अस्वीकार करें। PDF के लिए `%PDF-` signature जाँचें, size limit लगाएँ और pages inspect करने हों तो time तथा memory limits वाले parser का इस्तेमाल करें। Images के लिए processing से पहले dimensions decode करें, क्योंकि छोटी file भी decode होने पर बहुत अधिक memory ले सकती है। एक blanket «archive» type से बचें। ZIP, TAR और GZIP अलग हैं और हर format का अपना inspection work है। Business process को archive की ज़रूरत न हो तो उसे अस्वीकार करें। Users को कभी-कभी इसकी ज़रूरत पड़ती है, इसलिए format स्वीकार करना generic attachment endpoint बनने का रास्ता है। Accepted files का नाम service side पर बदलें। Original filename को sanitize करने के बाद display metadata के रूप में रखें, लेकिन escaping के बिना उसे filesystem path, object-store key या `Content-Disposition` value के रूप में इस्तेमाल न करें। Names में control characters, deceptive Unicode, path separators और downstream logs बदलने वाले strings हो सकते हैं। ## Redirect के बाद भी destination checks लागू रहने चाहिए Receiver allow list को वह exact जगह पहचाननी चाहिए जहाँ file पहुँच सकती है। `https://example.com` की अनुमति अधूरी है, अगर HTTP client दूसरे host पर redirect follow कर सकता है, internal address resolve कर सकता है या अलग port स्वीकार कर सकता है। Destinations को server-side records के रूप में रखें, जिनमें fixed scheme, host, port, path prefix, credential identity और accepted purposes हों। Action को `destination_id` मिले, freeform endpoint नहीं। Receiver को path में case ID चाहिए तो full URL agent से लेने के बजाय constrained identifier से path बनाएँ। हर send के लिए HTTP client को ये checks लागू करने चाहिए: 1. Documented internal exception न हो तो HTTPS अनिवार्य करें। 2. Connect करने से पहले requested host और port को destination record से मिलाएँ। 3. Redirects डिफ़ॉल्ट रूप से बंद रखें। Receiver को redirect चाहिए तो हर redirect target को उसी record से जाँचकर ही अगला byte भेजें। 4. IP literals, loopback addresses, link-local addresses और private ranges अस्वीकार करें, जब तक controlled internal service के लिए वह destination स्पष्ट रूप से मौजूद न हो। 5. पूरे host की अनुमति देने के बजाय allowed path prefix और HTTP method तय करें। चौथा बिंदु अक्सर SSRF protection कहलाता है, और यह वही है। यह उस agent के ज़रिए accidental disclosure भी रोकता है जो task description से URL follow करता है। Internal networks तक पहुँच रखने वाले upload client को task text को किसी address से संपर्क करने का अधिकार कभी नहीं मानना चाहिए। Original authorization context forward न करें। Case-management API को भेजने वाला credential केवल उसी receiver और action का होना चाहिए। Arbitrary agent headers copy करने वाला file upload gateway header injection का आसान रास्ता बनाता है और agent को credentials अप्रत्यक्ष रूप से चुनने देता है। Redirect के बाद final URL record करें, लेकिन operational logs में query values redact करें। Query strings में अक्सर signed upload tokens होते हैं। Destination log करना उपयोगी है, usable authorization token को दोबारा इस्तेमाल योग्य रूप में log करना लापरवाही है। ## Logs के लिए सोच-समझकर बनाया गया export path चाहिए Logs वह attachment class है जिसे teams सबसे ज़्यादा कम आँकती हैं। उनमें request headers, customer identifiers, SQL fragments, stack traces, internal hostnames और कभी-कभी पूरी request या response bodies होती हैं। Log का developer directory में होना उसे email या upload करने के लिए सुरक्षित नहीं बनाता। इसे agent को «secrets हटा दो» कहने वाले instruction से हल न करें। Agents formats miss कर सकते हैं, बहुत ज़्यादा redact कर सकते हैं या suspicious string को harmless context मान सकते हैं। Diagnostic-bundle builder बनाएँ जो known files पढ़े, deterministic filters लगाए और staging directory में नया artifact बनाए। व्यावहारिक filter policy हर संभावित secret pattern को खोजने के बजाय पूरे fields हटा सकती है। `Authorization`, `Cookie`, `Set-Cookie`, API key fields, session identifiers और request bodies डिफ़ॉल्ट रूप से हटाएँ। Correlation ज़रूरी हो तो customer identifiers को stable local tokens से बदलें। Incident window तक timestamps सीमित रखें, हफ्तों का history न भेजें। उदाहरण के लिए raw HTTP trace की तुलना में diagnostic record का यह रूप सुरक्षित है: ```json { "time": "2025-03-08T14:22:11Z", "request_id": "local-7f3c", "method": "POST", "route": "/v1/reports", "status": 502, "upstream": "reporting-service", "authorization": "[removed]", "body": "[omitted]" } ``` Bundle builder को file names, byte counts, hashes और लागू किए गए filters वाला manifest बनाना चाहिए। Reviewer को हर attachment खोले बिना ठोस चीज़ जाँचने को मिलेगी। Receiver truncated या modified upload भी पहचान सकेगा। Database exports के लिए और सख्त नियम चाहिए। Ticket में «send a sample» लिखा हो, सिर्फ़ इसलिए agent production export attach न करे। Schema-only artifact, approved columns वाली purpose-built query या synthetic reproduction बनाएँ। अगर incident में वास्तविक customer records ज़रूरी हों, तो उसे explicit destination, scope और human approval वाली अलग action बनाएँ। Screenshots पर भी यही संदेह रखें। इनमें customer accounts, messages, browser tabs, notifications और local paths दिख सकते हैं। Agent को broad screenshot directory देने के बजाय controlled tool से cropped या focused capture बनाएँ। ## Archives और office documents एक से अधिक files छिपा सकते हैं Archive के भीतर एक दूसरा upload set बन जाता है। भेजने से पहले member list जाँचें और member count, compressed bytes, expanded bytes, path depth और nesting की सीमाएँ लगाएँ। Absolute paths, `..` traversal, duplicate names या symlinks वाली entries अस्वीकार करें। Disk पर 2 MB की ZIP worker या receiver को थका देने वाले आकार तक expand हो सकती है। इसे आम तौर पर decompression bomb कहते हैं, लेकिन समस्या केवल malicious inputs तक सीमित नहीं है। Build systems गलती से बहुत बड़े archives बना सकते हैं और agent export जैसी दिखने वाली पहली file attach कर सकता है। Office documents में भी सावधानी चाहिए। Modern document formats में अक्सर ZIP containers, embedded media, metadata, comments, tracked changes और external relationships होते हैं। Page पर document redacted दिख सकता है, फिर भी package में पुराना text या author information बची हो सकती है। Workflow को केवल rendered content चाहिए तो editable original forward करने के बजाय approved data से नया PDF बनाएँ। Request path में arbitrary documents को recursively «sanitize» न करें। Complex formats parse और rewrite करने की अपनी security तथा reliability cost होती है। Narrow workflow के लिए generated artifacts का narrow set स्वीकार करें। Exceptional document को human review process में भेजें, जहाँ actual file और उसका destination जाँचा जा सके। ## Action contract unsafe requests को असंभव बनाए Agent-facing tool को raw HTTP request builder नहीं, आपके controls के अनुरूप choices दिखानी चाहिए। अगर tool `url`, `headers`, `file_path` और `method` देता है, तो policy की अधिकांश संरचना पहले ही खो चुकी है। ऐसा request schema रखें जिसमें untrusted fields intent बताएँ और trusted records authority दें। यह उदाहरण recipient, credentials और permitted file class को agent के नियंत्रण से बाहर रखता है: ```json { "action": "send_attachment", "purpose": "customer_export", "destination_id": "finance-import", "artifact_id": "exp_8c4e1a", "note": "March reconciliation correction" } ``` Service `artifact_id` को उस staged object से resolve करती है जिसे उसने बनाया या अलग intake flow से स्वीकार किया। वह digest और detected type खुद निकालती है। `destination_id` को fixed receiver record से resolve करती है। Send के समय recipient credential जोड़ती है। Agent credential देख नहीं सकता और approval के बाद दूसरा recipient नहीं चुन सकता। Preflight result में informed decision के लिए पर्याप्त detail होनी चाहिए: ```json { "decision": "approval_required", "artifact": { "name": "reconciliation-2025-03.csv", "bytes": 482913, "detected_type": "text/csv", "sha256": "a4d1...c09e" }, "destination": { "label": "Finance import", "host": "imports.example.internal", "path": "/v2/reconciliation" }, "reason": "customer_export requires approval" } ``` Reviewer को केवल filename और approve button न दिखाएँ। Measured size, detected type, destination host, destination label और purpose दिखाएँ। File sensitive हो तो approval surface पर पूरी सामग्री के बजाय sampled classification result या manifest दिखाएँ। Artifact IDs short-lived और single-purpose रखें। Staged diagnostic bundle support case बंद होने के बाद generic upload object की तरह reusable न रहे। बनाते समय उसे purpose और receiver से bind करें और छोटी operational window के बाद expire कर दें। Retries के लिए idempotency चाहिए। Network failures सामान्य हैं और agents तेज़ी से retry करते हैं। Action layer पर idempotency token बनाएँ, उसे artifact digest और destination से bind करें और केवल उसी intended send के लिए reuse करें। बदले हुए path या digest वाले retry को पहले का authorization न मिलने दें। ## Human approval तभी उपयोगी है जब वह वास्तविक सीमा पर लगे Approval validation का विकल्प नहीं है। कोई व्यक्ति modal देखकर ZIP bomb, disguised file या redirect flaw विश्वसनीय रूप से नहीं पहचान सकता। Approval उस निर्णय के लिए है जिसे policy अपने-आप नहीं कर सकती: क्या यह customer export इस incident के लिए इसी recipient को भेजना चाहिए। High-sensitivity sends, नए recipients, production exports और broad diagnostic artifacts के लिए per-call approval रखें। Narrow और routine artifacts को approved purpose के अंतर्गत चलने दें, अगर destination और contents constrained हों। हर test report पर approval माँगने से लोग पढ़े बिना click through करने लगेंगे। Approval record को artifact digest, declared purpose और destination record से bind करें। इनमें से कोई भी बदले तो approval हटा दें। Filename पर्याप्त नहीं है, क्योंकि दो files का नाम एक हो सकता है और bytes अलग। Sallyport agent को HTTP upload में इस्तेमाल होने वाले credential से अलग रख सकता है और उसका per-key approval option उन sends के लिए उपयोगी है जिन पर हर बार व्यक्ति का निर्णय चाहिए। फिर भी application-level artifact contract ज़रूरी है, क्योंकि gateway यह नहीं जान सकता कि customer CSV किसी support case में जानी चाहिए या नहीं। दो audit views रखें: एक बताए कि किस agent run को कार्रवाई का अधिकार मिला, दूसरा हर transfer attempt और result दर्ज करे। Audit record में digest, measured bytes, type verdict, purpose, recipient record, decision, response status और time हों। Secrets और full file contents को कहीं और रखें, अगर उन्हें रखना भी ज़रूरी हो। ## Agent के खोजने से पहले rejection paths की जाँच करें जो policy केवल happy path पर सफल हो, वह अधूरी है। ऐसा isolated receiver बनाएँ जो मिली हुई exact request दर्ज करे और boundary trigger करने वाले fixtures चलाएँ। Test receiver के विरुद्ध plain upload request से शुरू करें: ```bash curl -i -X POST https://receiver.test/attachments \ -H 'Authorization: Bearer test-token' \ -F 'file=@fixtures/diagnostic.zip;type=application/zip' \ -F 'case_reference=CASE-1842' ``` Successful test method, final host, path, digest और size की पुष्टि करे। उपयोगी tests वे हैं जो साबित करें कि receiver को कुछ नहीं मिला। Assert करें कि over-limit body forwarding से पहले reject हो, forged `text/plain` header binary payload को पास न करा सके और unlisted destination को connection न मिले। Test fixture set में ये मामले रखें: - Valid extension लेकिन mismatched signature bytes। - ऐसा compressed archive जिसका expanded size rule से बड़ी हो। - Allowed host से unallowed host की ओर redirect। - Authorization header और customer email address वाला log fixture। - अलग file bytes के साथ वही idempotency token इस्तेमाल करने वाला retry। इन tests के दौरान server logs भी देखें। दो बातें जाँचनी हैं: transfer हुआ नहीं और आपके अपने logs ने rejected body, bearer token या signed URL सुरक्षित नहीं रखे। Teams अक्सर network path ठीक कर देती हैं, लेकिन वही sensitive material exception traces में रह जाता है। Tests उसी agent tool interface से चलाएँ जिसे production agents इस्तेमाल करते हैं। Secure internal HTTP client पर्याप्त नहीं है, अगर agent-facing wrapper raw URL चुन सकता है या artifact staging path bypass कर सकता है। ## Safe route को raw route से आसान बनाएँ Approved path धीमा, अस्पष्ट या सामान्य support work के लिए अनुपयोगी हो तो teams upload controls bypass करती हैं। लोगों को सच में चाहिए ऐसे artifacts का छोटा set बनाएँ: redacted diagnostic bundle, narrow export, generated report और defined bounds वाला incident screenshot। Agent के लिए हर एक को नाम से request करना आसान बनाएँ। Generic raw uploader को agent tool list से बाहर रखें। Engineer को unusual case में इसकी ज़रूरत हो तो interactive operational path दें, जहाँ वह पूरे context के साथ file और receiver चुने। यह असुविधा उचित है, क्योंकि इस action का विश्वसनीय automated classification नहीं है। Rejected sends की समीक्षा successful sends जितनी गंभीरता से करें। Oversized bundles का pattern बताता है कि diagnostic artifact गलत है। Logs को नए host पर भेजने की repeated कोशिशें justified destination addition की ज़रूरत दिखा सकती हैं, या यह भी कि agent prompt controls के आसपास रास्ता खोज रहा है। अंतर तभी दिखेगा जब purpose, file verdict और receiver decision एक साथ capture हों। मैं सबसे पहले एक सरल बदलाव करूँगा: agent upload action से freeform URLs और arbitrary file paths हटा दूँगा। Action केवल staged artifacts, named purposes और destination IDs स्वीकार करने लगे, तो size limits और content checks को काम करने के लिए भरोसेमंद जगह मिल जाएगी।