# क्या आपके agent secret leakage tests सच में कुछ साबित करते हैं?

किसी एजेंट को token पाने के लिए उसे प्रिंट करना जरूरी नहीं है। अगर bearer token उसके environment, command line, tool payload, transcript, child process या crash artifact में पहुंच गया, तो सीमा पहले ही टूट चुकी है। मॉडल का विनम्र जवाब उस गलती को ठीक नहीं करता।

आपका टेस्ट यह नहीं होना चाहिए कि «क्या एजेंट ने secret दोहराने से बचा?» असली सवाल है: «क्या हम test gateway के जरिए वास्तविक कार्रवाइयां चला सकते हैं, एजेंट की तरफ से बनने वाले हर artifact को इकट्ठा कर सकते हैं और दिखा सकते हैं कि उनमें कोई unique working credential नहीं है?» यह दावा इतना सीमित है कि इसकी जांच हो सके और इतना मजबूत है कि production में दिखने वाली विफलताएं पकड़ सके।

Disposable accounts, disposable hosts और हर रन के लिए नया canary इस्तेमाल करें। Secret केवल gateway configuration में रखें। फिर एजेंट से सफल HTTP और SSH कार्रवाइयां करवाएं, जानबूझकर विफलताएं पैदा करें और agent side को ऐसे जांचें जैसे leak मिलने की उम्मीद हो। यही तरीका कठिन रास्तों को पकड़ता है।

## साफ जवाब का मतलब साफ सीमा नहीं है

एजेंट को secret मिल सकता है, भले ही वह उसे natural language में कभी न रखे। आम leak तब होता है जब tool implementation एजेंट से API खुद call करने को कहती है और tool input में `Authorization` value डाल देती है। दूसरा रास्ता subprocess launcher है, जो execution से पहले environment बदलने के बजाय `API_TOKEN` विरासत में दे देता है। तीसरा SSH helper है, जो temporary identity file ऐसी जगह लिख देता है जिसे एजेंट पढ़ सकता है।

ये अलग-अलग विफलताएं हैं, लेकिन परिणाम एक है: एजेंट प्रोसेस के पास gateway के बाहर कार्रवाई करने लायक सामग्री आ जाती है। इसके बाद approval prompts और audit logs जोखिम का केवल एक हिस्सा दिखाते हैं। एजेंट secret को repository में कॉपी कर सकता है, किसी दूसरी service को भेज सकता है या ऐसे transcript में छोड़ सकता है जिसे कोई बाद में export कर दे।

दो दावों को अलग रखें:

- **Action isolation** का मतलब है कि एजेंट किसी operation के लिए अनुरोध करता है और उसका परिणाम पाता है, जबकि कोई दूसरा component credential जोड़कर network या SSH exchange करता है।
- **Secret non delivery** का मतलब है कि credential और उससे बने उपयोगी रूप एजेंट प्रोसेस या एजेंट द्वारा पढ़ी जा सकने वाली फ़ाइलों में कभी नहीं पहुंचते।

टीमें अक्सर पहले दावे का परीक्षण करती हैं और दूसरे को मान लेती हैं। इसी वजह से एजेंट gateway के जरिए test API को सफलतापूर्वक call कर सकता है, फिर भी debug field या inherited environment variable में token पा सकता है।

Apple का Process documentation inheritance के बारे में स्पष्ट है: subprocess को अपना environment उस process से मिलता है जिसने उसे launch किया, जब तक launcher launch से पहले उसे बदल न दे। APIs process को command arguments और environment data भी उपलब्ध कराती हैं। इसलिए इस test में child process कोई मामूली implementation detail नहीं है। वह एक और observation point है।

Test standard इस तरह होना चाहिए:

> Gateway में केवल fresh credential canary रखे होने पर एजेंट निर्धारित HTTP और SSH कार्रवाइयां पूरी कर सकता है, लेकिन एजेंट से पहुंच योग्य किसी process, transcript, log, failure output या collected diagnostic artifact में canary या उसका पहचाना जा सकने वाला रूप नहीं मिलता।

यह दावा न करें कि black box test साबित करता है कि gateway की memory के किसी byte में secret कभी नहीं था। वह ऐसा नहीं कर सकता। वह users के लिए महत्वपूर्ण boundary जरूर स्थापित करता है: एजेंट को उसके नियंत्रित interfaces और artifacts के जरिए usable credential कभी नहीं मिलता।

## Test credential को काम और fingerprint दोनों चाहिए

Test token केवल एक उपयोगी काम करे, और कुछ नहीं। HTTP के लिए ऐसा test account बनाएं जो केवल एक endpoint, जैसे `GET /whoami` या `POST /echo-action`, call कर सके और harmless account identifier लौटाए। SSH के लिए disposable host पर restricted account बनाएं और कुछ ही commands की अनुमति दें, जो server-side event record लिखें।

`test-token` जैसे token का इस्तेमाल करके उसे खोजने की कोशिश न करें। छोटे और अनुमान लगाने योग्य markers false matches बनाते हैं और encoding checks को बेकार करते हैं। हर test execution के लिए अलग string बनाएं। उसमें पहचानने योग्य prefix के बाद random data रखें, ताकि इंसान failure पहचान सके और सामान्य output को secret न समझे।

उदाहरण के लिए harness ऐसा canary बना सकता है:

```text
sallyport_probe_7M3jP4Fqk2rV9dN8xC5a
```

यह string credential value है, एजेंट को दिखाया जाने वाला identifier नहीं। Logs के लिए अलग public label रखें, जैसे `run-2026-07-22-ssh-04`। Label transcripts में आ सकता है। Canary नहीं आना चाहिए।

हर channel और failure path के लिए अलग canary रखें। हर test में एक ही HTTP token दोहराने से एक leak stale matches का उलझा हुआ समूह बन जाता है। यह भी पता लगाना कठिन हो जाता है कि बाद का artifact मौजूदा run से आया या पिछले अधूरे cleanup से।

एक व्यावहारिक fixture में चार हिस्से होते हैं:

1. HTTP test account, जो valid authentication के बाद fixed nonsecret response लौटाए।
2. SSH test account, जिसका forced command action identifier रिकॉर्ड करे और fixed message लौटाए।
3. Gateway credential entry, जिसमें fresh canary हो और एजेंट के लिए accessible copy न हो।
4. Artifact directory के बाहर manifest, जो run label को उस run में इस्तेमाल किए गए canaries से जोड़े।

Manifest संवेदनशील test material है। उसे ऐसी जगह रखें जिसे एजेंट पढ़ न सके और run के बाद canaries हटा दें। Cleanup के बाद भी test account उन credentials को अस्वीकार करे, भले ही किसी failure ने local archive में copy छोड़ दी हो।

Sallyport gateway को test HTTP और SSH credentials रखने देता है, जबकि एजेंट को credentials के बजाय action results मिलते हैं।

Server-side record महत्वपूर्ण है। यह साबित करता है कि authentication हुआ था और खराब test को इस वजह से pass होने से रोकता है कि action चला ही नहीं। `authenticated action accepted for run-2026-07-22-ssh-04` जैसा response एजेंट को success का पर्याप्त प्रमाण देता है, बिना authentication input दोहराए।

## Launch capture पहले tool call से पहले leak पकड़ता है

Launch boundary पर एजेंट के शुरुआती arguments और environment को capture करें। यह test shell scripts, CI configuration, editor integrations, wrappers और सुविधा के लिए बनाए गए launchers से पास हुए secrets पकड़ता है। यह वह गलती भी पकड़ता है जो gateway जोड़ने के बाद होती है: पुराना `API_TOKEN` export वहीं रह जाता है क्योंकि नया रास्ता काम करता हुआ दिखता है।

एजेंट को अपने नियंत्रण वाले wrapper के जरिए शुरू करें। Wrapper अपने argument vector और environment का exact snapshot protected test directory में लिखे, फिर खुद को agent executable से replace कर दे। Process replace करना जरूरी है, क्योंकि इससे कई layers शुरू होने के बाद अनुमान लगाने के बजाय वास्तविक agent launch को मिले values रिकॉर्ड होती हैं।

Local test harness के लिए यह छोटा Python wrapper पर्याप्त है:

```python
#!/usr/bin/env python3
import json
import os
import pathlib
import sys

out = pathlib.Path(os.environ["PROBE_LAUNCH_RECORD"])
out.parent.mkdir(parents=True, exist_ok=True)
record = {
    "argv": sys.argv[1:],
    "environment": dict(os.environ),
}
out.write_text(json.dumps(record, sort_keys=True), encoding="utf-8")
os.execvp(sys.argv[1], sys.argv[1:])
```

इसे जानबूझकर sparse environment के साथ launch करें। केवल वही चीजें शामिल करें जिनसे एजेंट अपना executable, temporary directory, MCP endpoint या stdio shim और wrapper के record path को ढूंढ सके। आदत के कारण developer का पूरा shell environment inherit न करें। Full shell environment अनावश्यक credentials, cloud configuration, package registry tokens और पुराने SSH settings ला सकता है, जिससे test गलत कारण से fail होगा।

Expected launch record इस तरह दिखेगा:

```json
{
  "argv": ["agent-command", "run", "tests/agent-task.txt"],
  "environment": {
    "HOME": "/private/tmp/agent-home",
    "PATH": "/usr/bin:/bin",
    "PROBE_LAUNCH_RECORD": "/private/tmp/probe/launch.json"
  }
}
```

Exact paths महत्वपूर्ण नहीं हैं। महत्वपूर्ण यह है कि record में HTTP या SSH canary, उसका base64 रूप, URL encoded रूप या private key वाली file का नाम न हो।

Scanner के देखने से पहले इस record को redact न करें। लोगों के लिए बनाए गए reports में redaction की जगह है। Raw record evidence है। अगर release test केवल साफ किया हुआ version record करता है, तो वह redactor के काम को साबित कर सकता है और उस leak को छिपा सकता है जिसे पकड़ना था।

Launch snapshot की सीमा है: यह केवल बताता है कि process किससे शुरू हुआ। यह नहीं बताता कि बाद में tool call secret को child environment या temporary file में डालती है या नहीं। इसलिए अगले tests agent से startup के बाद काम करवाते हैं।

## Child processes भी agent boundary का हिस्सा हैं

एजेंट अक्सर formatters, package managers, test runners, Git commands, SSH clients और scripts चलाते हैं। अगर एजेंट child launch कर सकता है, तो child अपना environment और arguments disk पर लिख सकता है, उन्हें output में लौटा सकता है या network request में भेज सकता है। जब तक कोई मजबूत तकनीकी कारण न हो, हर child को agent reachable मानें।

एजेंट को ऐसा harmless task दें जो gateway action पूरा होने के बाद probe program चलाए। Probe अपने arguments और environment को machine-readable रूप में लिखे। क्योंकि यह agent-side runtime का child है, यह उस समय runtime द्वारा आगे भेजी गई values देखता है।

Probe को बड़े environment dump को model conversation में लौटाने के बजाय controlled directory में लिखने दें। आप leak की जांच कर रहे हैं, उसे transcript में आमंत्रित नहीं कर रहे।

```python
#!/usr/bin/env python3
import json
import os
import pathlib
import sys

path = pathlib.Path(os.environ["PROBE_CHILD_RECORD"])
path.parent.mkdir(parents=True, exist_ok=True)
path.write_text(
    json.dumps(
        {"argv": sys.argv, "environment": dict(os.environ)},
        sort_keys=True,
    ),
    encoding="utf-8",
)
print("child probe completed")
```

एजेंट से पहले authenticated action करवाएं और फिर `after-http-action` जैसे साधारण argument के साथ probe चलवाएं। SSH के बाद यही sequence दोहराएं। अगर gateway implementation किसी helper के लिए credential को environment variable में डालकर उसे agent descendant बनने देती है, तो यह test उसे पकड़ लेगा।

Argument paths को अलग से जांचें। Developers जानते हैं कि environment variables leak होते हैं, लेकिन command arguments कई बार ज्यादा खतरनाक होते हैं, क्योंकि process inspection, shell history, error formatting और diagnostic collectors उन्हें रिकॉर्ड कर सकते हैं। Apple बताता है कि process `CommandLine.arguments` के जरिए अपने arguments access कर सकता है और `ProcessInfo` arguments तथा environment दोनों उपलब्ध कराता है। इसलिए argv में दिया गया secret उसी process के code को तुरंत दिखाई देता है।

`--token-file=/private/tmp/secret` जैसे argument को केवल इसलिए स्वीकार न करें कि token bytes मौजूद नहीं हैं। उस file path की भी जांच करें। अगर एजेंट file पढ़ सकता है, तो उसके पास secret है। अगर file केवल अलग gateway process के लिए readable है और agent-controlled working directories में कभी नहीं जाती, तो इस तथ्य को test setup में दर्ज करें।

SSH के लिए केवल private key text न खोजें। Identity file path, test identity उजागर करने वाला agent socket, private material वाला generated `known_hosts` record या password वाली command line मिलने पर fail करें। Temporary file में रखी private key फिर भी private key ही है, भले ही एजेंट को केवल उसका path मिला हो।

## Successful actions को hostile transcripts चाहिए

`200 OK` लौटाने वाला happy path लगभग कुछ साबित नहीं करता। वह केवल यह दिखाता है कि किसी ने request की। एजेंट से gateway के जरिए वास्तविक action करवाएं और agent side पर बने हर transcript और tool trace को सुरक्षित रखें।

HTTP test ऐसा endpoint call करे जो authenticated test account की पुष्टि करे, लेकिन request headers वापस न दिखाए। उपयोगी response ऐसा fixed object हो सकता है:

```json
{
  "account": "gateway-test-http",
  "accepted": true,
  "request_label": "run-2026-07-22-http-01"
}
```

एजेंट इस response से reasoning कर सकता है। उसे bearer token, authorization scheme, injected header name या token prefix की जरूरत नहीं है। अगर debugging के लिए action interface request object लौटाता है, तो उसे अलग test target बनाएं, क्योंकि वह likely leak है। `request_headers` नाम का result field design bug है, जब तक यह सुनिश्चित न हो कि agent boundary पार करने से पहले credential material हट गया है।

SSH के लिए host को `report-status <run-label>` जैसी fixed command स्वीकार करने दें। Server authenticated account, requested command और label रिकॉर्ड करे। वह `status recorded` जैसा response लौटाए। एजेंट को private key, SSH agent export या authentication exchange का transcript नहीं मिलना चाहिए।

Agent side से ये artifacts सुरक्षित रखें:

- मूल agent prompt और model transcript।
- Raw MCP messages या equivalent action requests और responses।
- Agent-controlled commands का standard output और standard error।
- Tool debug logs, retry logs और structured event files।
- Agent workspace, temporary directory और configured cache directory के अंदर लिखी गई files।

Cleanup routine evidence हटाने से पहले इन्हें collect करें। फिर केवल UTF-8 text नहीं, exact bytes scan करें। Secret JSON escapes, percent encoding, base64, compressed trace या ऐसी file में आ सकता है जिसमें invalid bytes होने के कारण साधारण text search match छोड़ दे।

Sallyport का `sp mcp` shim इस test के लिए उपयोगी है, क्योंकि इससे वही सामान्य MCP path exercise किया जा सकता है जिसका एजेंट इस्तेमाल करता है, जबकि credentials app के vault में रहते हैं।

Redacted transcript को proof न समझें। `Authorization: [REDACTED]` operator output के लिए ठीक हो सकता है, लेकिन उसके पीछे का raw event object token रख सकता है। Display formatting से पहले capture करें और formatter को अलग test करें। ये दो अलग जिम्मेदारियां हैं।

## Secret isolation अक्सर error handling में टूटती है

Gateway success response साफ रख सकता है और फिर भी error के समय secret leak कर सकता है। Error paths में debug context, request reconstruction, exception chaining और retry messages जुड़ते हैं। उन्हें जानबूझकर चलाएं।

HTTP failures को अलग-अलग चरणों पर चलाएं:

1. Test server valid canary मिलने के बाद nonsecret `401` लौटाए। एजेंट को यह पता चले कि authentication fail हुआ, भेजी गई header value नहीं।
2. Server `500` लौटाए और body में public run label रखे। Gateway bounded error body दे सकता है, लेकिन request headers या curl equivalent नहीं जोड़ना चाहिए।
3. Gateway authentication तैयार करने के बाद connection बंद करें। इससे वे low-level exceptions पकड़ी जाती हैं जो request objects को अपने description में शामिल करती हैं।
4. Successful authentication के बाद malformed JSON लौटाएं। Parsers अक्सर offending response या आसपास का context exception में डाल देते हैं।
5. किसी test route के लिए ऐसा DNS name इस्तेमाल करें जो resolve न हो। इससे retry और endpoint diagnostic output जांचा जाएगा।

फिर connection setup से पहले और बाद की SSH failures चलाएं। Wrong host identity वाला host, nonzero status लौटाने वाली remote command और controlled error लौटाने वाला forced command इस्तेमाल करें। Wrong private key का परीक्षण ऐसा करके न करें कि test key एजेंट को वापस भेजनी पड़े या server उसे log करे। एजेंट को केवल `connection rejected` या `remote command failed` जैसी classification और safe request label मिलना चाहिए।

Locked state का भी परीक्षण करें। Vault locked होने पर action network authentication से पहले fail होना चाहिए। Response कह सकता है कि authorization उपलब्ध नहीं है। उसमें token placeholder, credential storage का path, SSH identity filename या secret में characters की संख्या नहीं होनी चाहिए। Unlock के बाद action दोहराएं और server-side success record आवश्यक करें। इससे वे implementations पकड़ी जाती हैं जो lock जांचने से पहले credential request बना लेती हैं।

एक उपयोगी failure fixture दोनों तरफ assertions रखता है:

```text
Agent side: the canary is absent from every collected artifact.
Gateway side: the attempted action has the expected safe error classification.
Server side: the expected request occurred, or did not occur for a locked vault test.
```

आखिरी assertion false confidence रोकती है। अगर test retry error की उम्मीद करता है, लेकिन gateway ने configuration mistake के कारण call पहले ही रोक दी, तो leak scan चलाए बिना भी test pass हो सकता है।

Raw exceptions boundary के पार न भेजें। Error objects में action identifier, safe category, इंसान के लिए उपयोगी message और शायद retry hint होना चाहिए। उन्हें उस request configuration को serialize नहीं करना चाहिए जिसके कारण exception आई। आसान debugging के लिए full request dumps लोकप्रिय हैं, लेकिन credential injector वाले request में यह गलत default है।

## Crash artifacts के लिए जानबूझकर failure करें

Crash सामान्य API result नहीं है, इसलिए टीमें इसे छोड़ देती हैं। यह गलती है। Developer crash report को issue में जोड़ सकता है, support script उसे archive कर सकती है और diagnostic system संबंधित logs collect कर सकता है। अगर secret वहां पहुंच गया, तो आपने safe boundary के बजाय delayed leak बनाया है।

Successful HTTP action के बाद और फिर successful SSH action के बाद agent-side probe process को abort करवाएं। Crash target को gateway से अलग रखें। आप यह देखना चाहते हैं कि agent side ने secret inherit या record किया था या नहीं, न कि credential holder को जानबूझकर crash करके उसकी private state उजागर करना।

macOS पर Console या test environment के diagnostic collection path से report लें और unedited file scan करें। Apple crash reports को application state के विस्तृत records बताता है और पूरे operating system report का analysis करने की सलाह देता है। Crash report documentation यह भी बताता है कि reports में process identity, path, parent process, timing और thread state जैसी process और environment information हो सकती है।

macOS crash report में canary न मिलना यह साबित नहीं करता कि वह memory में कभी मौजूद नहीं था। सामान्य crash report complete memory dump नहीं होती। फिर भी test छोड़ना जरूरी नहीं है। परिणाम को सही तरह लिखें: report ने canary उजागर नहीं किया और agent process ने tested channels के जरिए उसे प्राप्त नहीं किया।

Crash के आसपास बने application logs और support archives भी scan करें। Apple developers को logs में privacy-sensitive information न रखने की चेतावनी देता है। इसे अपनी fixture की requirement मानें: अगर exception printer request object रिकॉर्ड करती है, तो crash test fail होना चाहिए, भले ही operating system crash report साफ हो।

अगर बाद में Linux पर संबंधित tests चलाएं, तो artifact set में core dump metadata और journal output जोड़ें। `systemd-coredump` manual ऐसे fields का documentation देता है जिनमें crashed process की command line और environment रखे जा सकते हैं। केवल core file scan करने वाली suite metadata को अनदेखा करके एक सीधा leak path छोड़ देती है।

## Bytes, encodings और split values scan करें

साधारण recursive grep कुछ न करने से बेहतर है, लेकिन वह JSON, URLs, stack traces और binary bundles में दिखने वाले forms छोड़ देता है। ऐसा scanner बनाएं जो files को bytes के रूप में पढ़े और हर canary के कई deterministic transforms खोजे।

कम से कम हर canary के लिए ये needles बनाएं:

```text
raw bytes
base64 text
URL encoded text
JSON escaped text
hex text
first half and second half separated by one newline
```

Split case उन log wrappers को पकड़ता है जो लंबी values को fold करते हैं। Encoded cases उन systems को पकड़ते हैं जो structured data serialize करके लिखते हैं। केवल token prefix scan न करें। Prefix test तब pass हो सकता है जब token उपयोगी रहने लायक characters तक truncated हो, और unrelated identifier पर fail हो सकता है।

एक compact scanner file path, transform name और byte offset report कर सकता है, बिना secret print किए:

```python
import base64
import json
import pathlib
import urllib.parse

secret = bytes.fromhex("73616c6c79706f72745f70726f62655f5837")
needles = {
    "raw": secret,
    "base64": base64.b64encode(secret),
    "url": urllib.parse.quote_from_bytes(secret).encode(),
    "json": json.dumps(secret.decode()).encode(),
    "hex": secret.hex().encode(),
}

for path in pathlib.Path("artifacts").rglob("*"):
    if not path.is_file():
        continue
    data = path.read_bytes()
    for name, needle in needles.items():
        offset = data.find(needle)
        if offset >= 0:
            raise SystemExit(f"secret match: {path} transform={name} offset={offset}")
```

Code जानबूझकर matching bytes के बजाय offset report करता है। Test failure को CI output में दूसरा leak नहीं बनना चाहिए। केवल incident process की जरूरत हो तो tightly controlled forensic copy रखें और उसे सामान्य build logs से बाहर रखें।

Archives को protected temporary directory में unpack करने के बाद scan करें। जब व्यावहारिक हो, compressed data भी scan करें, क्योंकि raw byte scan compressed payload के अंदर का canary नहीं देख सकता। अगर telemetry client events batch करता है, तो batch test machine से बाहर जाने से पहले collect करें। बाद में यह पता लगाना बेकार है कि scanner ने केवल local files देखीं और encoded token पहले ही third-party collector को जा चुका था।

Expected public labels के लिए allowlist रखें, secrets के लिए नहीं। अगर test इसलिए fail हो कि field में test account name है, तो तय करें कि वह नाम खुद access देता है या नहीं। Scanner को green बनाने के लिए broad exclusions न जोड़ें। हर exclusion वह hole है जिसे आप फिर जांचना भूल जाएंगे।

## Report में absence और action दोनों दिखने चाहिए

अच्छी test report चार सवालों का जवाब देती है और reader से आपकी interpretation पर भरोसा करने को नहीं कहती।

पहला, कौन-सा gateway action सफल या असफल हुआ? Public run label, action type और server-side observation दिखाएं। दूसरा, कौन-से artifacts collect किए गए? Launch snapshot, child snapshot, transcript bundle, workspace tree, error outputs और crash artifacts की सूची दें। तीसरा, scanner ने कौन-से secret transforms खोजे? चौथा, क्या कोई scanner read permission problem, खराब encoding assumption या skipped archive के कारण fail हुआ?

Skipped artifact pass नहीं है। उसे incomplete mark करें और suite fail करें, जब तक documented reason न हो कि वह agent boundary से बाहर है। CI setup के दौरान यह नियम परेशान कर सकता है, लेकिन यह उस स्थिति को रोकता है जिसमें test केवल इसलिए success report करे कि वह leak वाली directory खोल ही नहीं सका।

Gateway का action record agent artifact bundle से अलग रखें। Gateway audit साबित कर सकता है कि credential-protected action हुआ। Agent bundle साबित कर सकता है कि एजेंट को क्या मिला। दोनों को एक सुविधाजनक export में मिलाना sensitive information के लिए अनावश्यक नया रास्ता बनाता है।

Release checks के लिए pass condition कड़ी रखें:

```text
PASS only when the server confirms the intended action,
all required artifacts were collected,
and no raw or transformed canary appears in agent reachable material.
```

फिर negative controls जोड़ें। एक जानबूझकर खराब fixture चलाएं जो canary को environment variable या fake debug response के जरिए पास करे। Scanner को उसे fail करना चाहिए। जो test known leak पकड़ने की अपनी क्षमता कभी प्रदर्शित नहीं करता, वह केवल दिखावा है।

जब भी credential injection, process launch code, MCP transport, error formatting, logging, support collection या SSH handling बदले, suite चलाएं। Review में ये बदलाव असंबंधित लग सकते हैं, लेकिन credentials अक्सर इन्हीं रास्तों से बाहर निकलते हैं। सामान्य integration tests में छोटा version रखें और crash तथा archive collection महंगा हो तो उसे scheduled या release runs के लिए रखें।

Standard को इस तरह कहना कठिन नहीं है: gateway secret का इस्तेमाल करके action कर सकता है, लेकिन एजेंट को वह secret data के रूप में नहीं मिलना चाहिए। अगर आपका test केवल देखता है कि एजेंट क्या कहता है, तो बहुत कुछ जांच से बाहर रह जाता है। एजेंट से action करवाएं, उसे fail करवाएं, child spawn करवाएं, crash करवाएं और जो बचा है उसे scan करें।