{"id":54733,"plugin_id":"plugin_asdk_app_6a8061659144819197910ef2762afbc0","kind":"skill","collection_source":"plugin_package","comparison_source":null,"observed_at":"2026-10-25T12:04:51.401Z","digest":"0683671109a1e8a78818a2d017ac8e669af3ad74b8be7e108a6cb6ed6781caf4","against":null,"payload":{"description":"Gateway secure-transfer workflow. Staged/R2 transport doctrine and the enforced hash-reputation transfer workflow.","included_files":[],"name":"secure-transfer","skill_md_contents":"---\nname: secure-transfer\ndescription: \"Gateway secure-transfer workflow. Staged/R2 transport doctrine and the enforced hash-reputation transfer workflow.\"\n---\n\n\n\n# Gateway secure-transfer workflow\n\n## Transport choice\n\n- copy_between_servers has no transport parameter and v2 accepts one regular file, not a recursive directory. Between directly reachable servers it coordinates a direct source-host-to-destination-host data path, defaults max_bytes to 268,435,456,000 (250 GiB), creates no artifact or R2 staging object, and never relays payload bytes through Gateway executors or the application server. When either server connects through a Gateway overlay network, it stages the file through regional R2 instead, capped at 5,363,466,240 bytes (4.995 GiB), and deletes it after the transfer. It uses short-lived transfer-scoped authorization and fails explicitly when neither host can directly reach the other.\n- sync_between_servers defaults to transport=staged. Keep max_bytes at or below 5,363,466,240 (4.995 GiB) for staged Gateway/R2 sync.\n- For sync_between_servers, transport=auto is capped at 5,363,466,240 bytes (4.995 GiB). It may attempt direct relay only when both endpoints share an authorized executor routing context and retains a staged fallback; it is not a way to request a larger sync.\n- Explicit transport=direct for sync_between_servers supports max_bytes up to 268,435,456,000 bytes (250 GiB) only when both endpoints share that authorized routing context. When max_bytes exceeds 5,363,466,240 (the 4.995 GiB R2 single-part ceiling), transport=direct is required.\n- Publicly obtainable artifact: have the destination fetch from the authoritative public source when practical.\n- Host-to-host data above 268,435,456,000 bytes (250 GiB): the typed Gateway transfer tools reject it. Explain that limit; never invent a tunnel or listening service. Ordinary server-to-Gateway artifacts and staged/R2 sync transfers remain capped at 5,363,466,240 bytes (4.995 GiB).\n\n## Mandatory reputation pre-clear contract\n\nThe intended server-to-Gateway workflow is:\n\n1. For a directory, first create an exact archive with create_archive. The archive bytes, not the source directory representation, are the transfer artifact.\n2. Call hash_file on the exact regular file or created archive with algorithm=sha256, then take the 64 lowercase hexadecimal characters after its sha256: prefix.\n3. Call is_known_malicious with that 64-character value.\n4. If known_malicious=true, stop before creating or uploading an artifact.\n5. If known_malicious=false, call download_path with the same 64-character value as expected_sha256. This result means only \"not known malicious\"; it never means clean or safe.\n6. Gateway independently verifies the received bytes. Asynchronous security processing may later revoke or quarantine an artifact.\n\nFor a Windows server, download_path accepts one exact drive-qualified regular file such as C:\\Logs\\app.log (no UNC, device, relative, or alternate-data-stream paths, and no directories). Obtain the digest with hash_file, which also accepts Windows paths, then call is_known_malicious and download_path exactly as above. The Windows host uploads the file directly to Gateway storage; Gateway executors never relay it.\n\n## Enforced transfer boundary\n\nThis release exposes is_known_malicious and requires download_path expected_sha256. Gateway checks the digest against known-malicious evidence before reservation, independently hashes the received bytes, rejects changed or mismatched files, and rechecks malicious evidence during the durable transfer workflow.\n\nA negative reputation lookup means only \"not known malicious\" at that moment. Asynchronous security processing may later add evidence, revoke the download, or quarantine the artifact. Treat Gateway links as revocable and never describe an unknown hash as clean or safe.\n\n## Opt-in proactive server-file scanning\n\nFor a file already present on a registered server, first call get_file_scanning_preferences. Call scan_server_file only when allow_server_file_scanning=true, after hash_file and is_known_malicious, and pass the same digest as expected_sha256. Gateway enforces the preference again, accepts only one exact regular file, and routes the verified bytes through the normal transfer-artifact scanner. The result starts durable transfer work; follow the job to a terminal state, then use its artifact ID with get_file_scan_status while the scan status is pending or scanning.\n\nTreat no_detection, malicious, and indeterminate as terminal scan states. no_detection means only that the configured scanner reported no detection for those exact bytes; it is not a permanent known-clean reputation. get_file_scan_status is ownership-scoped and exposes neither the global malicious corpus nor unrelated accounts.\n\nscan_server_file uses Gateway's configured internal artifact scanner and never submits bytes to a third-party provider. Proactive detection does not authorize containment, deletion, or remediation.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}