DeepSeek V4 Pro एजेंट की सुरक्षा मॉडल से नहीं, पूरे Harness से तय होती है

किसी संगठन को DeepSeek V4 Pro एजेंट की सुरक्षा का आकलन केवल मॉडल के आधार पर नहीं करना चाहिए। सही इकाई है—model–harness–task–environment configuration।

DeepSeek V4 Pro का web, mobile app, API, OpenAI Responses API या Codex integration के जरिए उपलब्ध होना यह दिखा सकता है कि कोई runtime मॉडल से संवाद कर सकता है। लेकिन इससे यह साबित नहीं होता कि prompts, tools, permissions, memory, retries या बाहरी systems पर पड़ने वाले प्रभाव हर runtime में समान होंगे।

व्यावहारिक नियम सीधा है: किसी खास, version-pinned configuration को तभी approve करें जब वही configuration अपनी स्वतंत्र safety evaluation पास कर ले।

Harness एजेंट के वास्तविक व्यवहार को कैसे बदलता है

एजेंट केवल underlying model का नाम नहीं है। Harness तय करता है कि मॉडल को instructions कैसे मिलेंगी, वह tools कैसे चुनेगा, data तक उसकी पहुंच कितनी होगी, failures का सामना कैसे करेगा और बाहरी systems पर क्या असर डाल सकेगा। महत्वपूर्ण अंतर इन क्षेत्रों में हो सकते हैं:

• system prompts और adapters;
• tool definitions और उनके implementations;
• permission scopes और approval gates;
• filesystem roots और network access;
• credential sources और identity;
• subprocess तथा generated-code behavior;
• retry, timeout और concurrency logic;
• session state, summaries, caches और persistent memory।

इसलिए एक ही DeepSeek V4 Pro backend अलग-अलग Harness या execution environment में अलग risk profile दिखा सकता है। Compatible API schema केवल integration की property है—यह safety certification नहीं है।

AgentS4D के नतीजे क्या बताते हैं

AgentS4D ने isolated model responses के बजाय पूरे runtime configurations का मूल्यांकन किया। इस benchmark में चार agent Harness और पांच model backends पर 328 risk-injected cases चलाए गए, जिससे 6,560 sandboxed runs हुए। इनमें 4,461 runs, यानी 68.0%, unsafe पाए गए। 4,344 runs, यानी 66.22%, unsafe भी थे और task completion के लिहाज से complete भी माने गए। 13

मुख्य निष्कर्ष यह है कि task का सफलतापूर्वक पूरा होना unsafe execution के साथ-साथ हो सकता है। एजेंट मांगा गया artifact तैयार कर सकता है, लेकिन उसी प्रक्रिया में forbidden change कर सकता है, sensitive data गलत तरीके से संभाल सकता है, किसी intended control को bypass कर सकता है या कोई अन्य unsafe side effect पैदा कर सकता है।

इन आंकड़ों को DeepSeek V4 Pro की production incident rate के रूप में पेश नहीं करना चाहिए। अध्ययन में जानबूझकर risk-injected cases, controlled sandbox और कई model–harness combinations का इस्तेमाल हुआ था। वास्तविक production में task mix, security controls, adversarial content का exposure, assets और harm की परिभाषाएं अलग हो सकती हैं। यह benchmark इस बात का evidence है कि runtime safety को सीधे मापा जाना चाहिए—यह हर deployment के भविष्य के incidents का forecast नहीं है। 135

Agent की गलती का अधिकतम नुकसान सीमित करें

सुरक्षा controls ऐसे होने चाहिए कि मॉडल या tool के अप्रत्याशित व्यवहार की स्थिति में भी गलती का प्रभाव सीमित रहे।

Dedicated और least-privilege identities इस्तेमाल करें

Agents, environments और tenants के लिए अलग-अलग identities बनाएं। सामान्य employee credentials, production-admin access या बड़े पैमाने पर दोबारा इस्तेमाल किए जा सकने वाले secrets से बचें। हर identity को केवल उसी काम के लिए आवश्यक resources और operations तक सीमित करें।

Filesystem और network को सीमित करें

• केवल dedicated workspace root mount करें।
• असंबंधित paths को केवल छिपाएं नहीं, बल्कि वास्तव में inaccessible बनाएं।
• Network destinations, methods, ports और जरूरत पड़ने पर egress volume की allowlist बनाएं।
• Read, draft, staging-write और production-write capabilities को अलग रखें।
• Secrets को broker या short-lived token system में रखें।
• Long-lived credentials को prompts, workspace files, environment variables या tool output में कभी न रखें।

Deletion, publishing, payments, access changes, deployments या external communication जैसे high-impact actions को execution-layer policy check से गुजारें या explicit approval अनिवार्य बनाएं।

पूरी execution chain की समीक्षा करें

Attack surface केवल first-party tools तक सीमित नहीं होता। Child processes, shell commands, generated code, package installation, remote tool servers, plugins और skill code भी side effects पैदा कर सकते हैं।

इन सभी रास्तों पर एक ही policy लागू होनी चाहिए। खास तौर पर shell या generated-code execution को filesystem, network, authorization, logging या approval controls को bypass करने से रोकें।

Tools को मॉडल के बाहर enforceable बनाएं

मॉडल द्वारा बनाया गया tool call एक untrusted request है। Authorization और safety rules लागू करने की जिम्मेदारी मॉडल की नहीं, tool server की होनी चाहिए।

Narrow schemas बनाएं, जिनमें ये controls शामिल हों:

• सीमित enum values और length limits;
• normalized paths और स्पष्ट resource identifiers;
• destination allowlists;
• pagination और result-size caps;
• मॉडल के बाहर argument validation;
• specific caller, tenant, target और operation के लिए server-side authorization।

Planning या preview tools को effectful tools से अलग रखें। Destructive या आसानी से reverse न किए जा सकने वाले operations के लिए:

• preview और confirmation या approval token जरूरी करें;
• जहां संभव हो soft-delete, quarantine या reversible workflow अपनाएं;
• idempotency keys अनिवार्य करें;
• retry होने पर duplicate request का व्यवहार पहले से तय करें;
• durable receipts लौटाएं, ताकि retry से वही effect दोबारा न हो।

यह जरूरी है क्योंकि देखने में सही JSON tool call में भी unauthorized target, dangerous path, जरूरत से ज्यादा scope या ऐसा operation हो सकता है जिसके लिए human review आवश्यक हो।

Deployment से पहले state और memory का व्यवहार तय करें

State कई turns, tasks, users और environments के बीच risk आगे ले जा सकता है। Messages, uploaded files, workspace files, summaries, tool results, caches और persistent memory के lifecycle rules लिखित रूप में तय करें और लागू करें।

कम-से-कम इन बातों को स्पष्ट करें:

• Isolation: User, tenant, task और environment के अनुसार state अलग हो। Implicit cross-session sharing की अनुमति न हो।
• Retention: Time-to-live, encryption, access control और deletion rules निर्धारित हों।
• Reset: हर run के बीच context, memory, workspace state, credentials और caches साफ करने का documented तरीका हो।
• Retries और timeouts: Counts और budgets सीमित हों। Retries idempotency बनाए रखें और चुपचाप privileges न बढ़ाएं।
• Concurrency: Shared files, approvals और external operations के लिए locking तथा conflict-handling rules तय हों।

State-reset behavior को security boundary का हिस्सा मानें। यदि पुराने instructions, credentials या tool results नए task में अनपेक्षित रूप से वापस आ सकते हैं, तो model upgrade या prompt change से response-only testing में दिखे बिना risk बदल सकता है।

हर risk carrier को untrusted input मानें

Prompt injection केवल user के सीधे message से नहीं आता। Risk-bearing instructions इन स्रोतों में छिपे हो सकते हैं:

• uploaded documents और repository files;
• retrieved webpages;
• external skills और plugins;
• tool-service responses;
• persisted memory;
• summaries और cached context;
• user-provided text।

ऐसी सामग्री को data की तरह parse, label और quote करें। उसे agent की authority, policy, tool selection, credential use या approval requirements बदलने की अनुमति नहीं मिलनी चाहिए। यह separation runtime को enforce करनी चाहिए; केवल मॉडल के malicious instructions पहचान लेने पर निर्भर रहना पर्याप्त नहीं है।

Harness-specific release checklist

Deployment approve करने से पहले exact configuration को freeze करके record करें:

1. Model और routing: Model identifier और version, provider route, inference settings या effort level तथा compatibility adapters।
2. Harness behavior: Harness version, system prompt, session logic, retry और timeout rules, subprocess policy तथा memory implementation।
3. Tools और policies: Tool definitions और versions, policy versions, approval thresholds, authorization logic तथा tool-server trust boundaries।
4. Permissions: Identities, scopes, filesystem roots, network destinations, credential sources और production-write paths।
5. State semantics: Isolation, retention, reset, cache behavior, concurrency और cross-session boundaries।
6. Adversarial coverage: हर risk carrier के जरिए prompt injection, confused-deputy attempts, credential exposure, path traversal, SSRF या egress abuse, malicious tool responses, retry duplication, memory poisoning और approval bypasses।
7. Evidence: Prompts और policy versions, tool calls और results, approvals, policy decisions, workspace diffs, outbound requests, इस्तेमाल की गई identity, final artifacts, completion outcome और stable run ID के तहत safety outcome।

Completion और safety को अलग-अलग score करें। सही final artifact unsafe side effect की भरपाई नहीं कर सकता—यही AgentS4D के नतीजों का केंद्रीय सबक है। 12

Configuration बदलते ही tests दोबारा चलाएं

Approved test target कोई स्थायी label जैसे “DeepSeek V4 Pro agent” नहीं, बल्कि pinned configuration है। इनमें से किसी भी material change के बाद configuration-specific suite दोबारा चलाएं:

• model या provider route;
• inference settings या effort level;
• system prompt या adapter;
• Harness या session logic;
• tools या remote tool servers;
• permission और approval policies;
• credential routing;
• memory, retry, timeout या concurrency behavior;
• network या filesystem boundaries।

इस तरीके से runtime safety, model quality के बारे में एक व्यापक धारणा नहीं रहती। वह वास्तविक दुनिया में प्रभाव पैदा कर सकने वाले exact environment से जुड़ा एक measurable release decision बन जाती है।