SakiAgentSSH Secure Protocol Specification
draft-sakistudio-sass-07
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | HUA CHANG | ||
| Last updated | 2026-06-16 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
GitHub Repository
|
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-sakistudio-sass-07
Independent Submission H. Chang
Internet-Draft Saki Studio
Intended status: Experimental 17 June 2026
Expires: 19 December 2026
SakiAgentSSH Secure Protocol Specification
draft-sakistudio-sass-07
Abstract
This document describes the Saki Agent Secure Stream (SASS) protocol,
version 5.0. SASS is an application-layer overlay protocol for
authenticated remote command execution, streaming process I/O, and
binary file transfer between trusted agents.
To ensure strict self-containment and compatibility with IETF
standard specifications, SASS defines a decoupled "Control-Transport
Decoupling" architecture. The SASS Core defines an abstract SASS
Abstract Messaging Model (SAMM) utilizing standard CBOR (RFC 8949)
and JSON as baseline serializations.
SASS formalizes its security evolution through four major incremental
milestones: Active Threat Defense (v1.1), Forward-Secure Audit Hash
Chains (v1.2), modular Control-Transport Decoupling (v1.3)
incorporating tls-exporter Channel Binding (RFC 9266) and Zero-
Allocation Tarpit streams, and Total Response Mapping (v1.4) with
6-Response state machine convergence and Safety Gradient loss
bounding.
SASS v1.4 achieves the Version Dominance milestone: a comparative
claim between protocol versions demonstrating pointwise loss
reduction on both storage and commercial axes across all six response
branches.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Chang Expires 19 December 2026 [Page 1]
Internet-Draft SASS Protocol June 2026
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 19 December 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Table of Contents
1. Introduction and Protocol Evolution . . . . . . . . . . . . . 4
1.1. The Four Incremental Milestones (v1.1 to v1.4) . . . . . 5
1.2. Design Philosophy: Total Response Mapping . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 7
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 7
3.2. 6-Response State Machine (R1~R6) . . . . . . . . . . . . 8
3.3. Abstract Messaging Model (SAMM) . . . . . . . . . . . . . 11
3.4. Relationship to SSH . . . . . . . . . . . . . . . . . . . 11
4. Transport Layer & Transport Profiles . . . . . . . . . . . . 12
4.1. Transport Decoupling Principles . . . . . . . . . . . . . 12
4.2. SASS-over-gRPC Profile (Mandatory TLS 1.3) . . . . . . . 12
4.3. ALPN & TCP Packet-Splitting Mitigation . . . . . . . . . 13
4.4. Channel Binding via Exported Keying Material . . . . . . 13
4.5. Default Port . . . . . . . . . . . . . . . . . . . . . . 14
5. Session Layer . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Agent Authentication . . . . . . . . . . . . . . . . . . 14
5.2. Session Lifecycle . . . . . . . . . . . . . . . . . . . . 15
5.3. Capability-Based Access Control . . . . . . . . . . . . . 15
6. Payload Encoding & Safety Gates . . . . . . . . . . . . . . . 16
6.1. Zstd Streamed Decompression Limit . . . . . . . . . . . . 16
6.2. Decompression Bomb & Huffman Collision Mitigation . . . . 16
6.3. Encoding & Decoding Procedure . . . . . . . . . . . . . . 16
6.4. PTY Ring Buffer & Offset Resumption . . . . . . . . . . . 17
6.4.1. Ring Buffer Specification . . . . . . . . . . . . . . 17
6.4.2. Offset Field in Stream Messages . . . . . . . . . . . 17
6.4.3. Reconnection Protocol . . . . . . . . . . . . . . . . 18
Chang Expires 19 December 2026 [Page 2]
Internet-Draft SASS Protocol June 2026
7. Logical RPC Service Semantics . . . . . . . . . . . . . . . . 18
7.1. Command Execution & Streaming . . . . . . . . . . . . . . 18
7.2. Process Management . . . . . . . . . . . . . . . . . . . 18
7.3. File Transfer & Raw File Transfer . . . . . . . . . . . . 19
8. Threat Defense & Boundary Enforcement . . . . . . . . . . . . 19
8.1. Boundary Adjudicator (13Policy Engine) . . . . . . . . . 19
8.2. Cognitive Challenge Mechanism . . . . . . . . . . . . . . 20
8.3. Dual Standard Enforcement . . . . . . . . . . . . . . . . 21
8.3.1. Vi Swap Defense (Authenticated Agents) . . . . . . . 22
8.3.2. Zero-Allocation Tarpit (Unauthenticated) . . . . . . 22
8.3.3. Zero-Window Deadlock Defense . . . . . . . . . . . . 24
8.4. LocalHost Defense . . . . . . . . . . . . . . . . . . . . 24
8.5. Transparent Branching (Storage Isolation) . . . . . . . . 25
9. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 27
10. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.1. The Impossibility Triangle . . . . . . . . . . . . . . . 28
11. Security Considerations . . . . . . . . . . . . . . . . . . . 29
11.1. Total Response Mapping Guarantee . . . . . . . . . . . . 29
11.2. Safety Gradient (7-Layer Loss Bounding) . . . . . . . . 30
11.3. State Transition Auditing . . . . . . . . . . . . . . . 31
11.4. Transport-Layer Considerations . . . . . . . . . . . . . 32
11.5. Known Limitations . . . . . . . . . . . . . . . . . . . 33
11.6. Key Management and Rotation . . . . . . . . . . . . . . 33
11.7. Tarpit Bandwidth Amplification . . . . . . . . . . . . . 33
11.8. Pseudo-ICMP Payload Rationale . . . . . . . . . . . . . 34
11.9. Version Dominance Claim . . . . . . . . . . . . . . . . 34
11.10. Defense Boundary Disclosure . . . . . . . . . . . . . . 36
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 36
12.1. SASS Privacy Requirements . . . . . . . . . . . . . . . 37
12.2. Inference Proxy Non-Surveillance Guarantee . . . . . . . 37
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
13.1. ALPN Protocol Identifier . . . . . . . . . . . . . . . . 38
13.2. MIME Type . . . . . . . . . . . . . . . . . . . . . . . 38
13.3. TCP Port Number . . . . . . . . . . . . . . . . . . . . 39
13.4. TLS Exporter Labels . . . . . . . . . . . . . . . . . . 39
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
14.1. Normative References . . . . . . . . . . . . . . . . . . 39
14.2. Informative References . . . . . . . . . . . . . . . . . 40
Appendix A. Protobuf Service Definition . . . . . . . . . . . . 42
Appendix B. Reference Implementations . . . . . . . . . . . . . 44
B.1. Cross-Platform Implementation Matrix . . . . . . . . . . 45
B.2. Rust Daemon (Primary) . . . . . . . . . . . . . . . . . . 45
B.3. Go Implementation . . . . . . . . . . . . . . . . . . . . 46
B.4. C# Windows Service Daemon . . . . . . . . . . . . . . . . 47
B.5. Swift macOS Plugins Client . . . . . . . . . . . . . . . 48
Appendix C. Saki Studio Plugins Reference Implementation . . . . 49
C.1. ChaCha20-Poly1305 Cognitive Challenge . . . . . . . . . . 49
C.1.1. C# Implementation Notes . . . . . . . . . . . . . . . 50
Chang Expires 19 December 2026 [Page 3]
Internet-Draft SASS Protocol June 2026
C.2. TLS Exporter Binding for Cognitive Challenge . . . . . . 50
C.3. Zero-Allocation Tarpit Static Buffer . . . . . . . . . . 51
C.3.1. Pseudo-ICMP Payload Generation . . . . . . . . . . . 51
C.3.2. C# Implementation Notes . . . . . . . . . . . . . . . 52
C.4. ED25519 Hash Chain Audit Log . . . . . . . . . . . . . . 52
C.5. Vi Swap ANSI Escape Sequence . . . . . . . . . . . . . . 53
C.5.1. C# Implementation Notes . . . . . . . . . . . . . . . 53
C.6. Transparent Branching via Symlink Tree . . . . . . . . . 53
C.6.1. C# Implementation Notes . . . . . . . . . . . . . . . 54
C.7. Volatile Cache Redirection . . . . . . . . . . . . . . . 54
C.7.1. C# Implementation Notes . . . . . . . . . . . . . . . 55
Appendix D. Platform-Aware Deployment Considerations . . . . . . 56
Appendix E. Version History . . . . . . . . . . . . . . . . . . 57
Appendix F. Changes from draft-sakistudio-sass-00 . . . . . . . 57
Appendix G. Changes from draft-sakistudio-sass-01 . . . . . . . 58
Appendix H. Changes from draft-sakistudio-sass-02 . . . . . . . 58
Appendix I. Changes from draft-sakistudio-sass-03 . . . . . . . 59
Appendix J. Changes from draft-sakistudio-sass-04 . . . . . . . 59
Appendix K. Changes from draft-sakistudio-sass-05 . . . . . . . 60
Appendix L. Changes from draft-sakistudio-sass-06 . . . . . . . 62
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 62
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 63
1. Introduction and Protocol Evolution
The proliferation of autonomous AI-powered coding agents operating on
remote machines introduces a critical threat model: the Rogue Agent.
Unlike traditional SSH clients controlled by human operators, agents
may autonomously execute destructive commands, exfiltrate
credentials, or pivot laterally across networks without explicit
human authorization.
Existing remote execution protocols such as SSH [RFC4253] were
designed for human-operated terminals and lack the fine-grained
capability controls, active defenses, and binary-safe encoding
schemes required for agent management.
SASS (Saki Agent Secure Stream) decouples the logical message flow
from the physical transmission layer. By defining a transport-
agnostic messaging core alongside modular transport profiles, SASS
achieves strict self-containment, freeing the standard from
proprietary third-party binary frameworks (e.g., gRPC/Protobuf)
during academic review, while retaining high-performance
implementations as pluggable adapters.
SASS is designed to avoid over-deployment or under-deployment at any
application scale. The protocol is suitable for deployment on
resource-constrained IoT devices as well as enterprise-grade servers.
Chang Expires 19 December 2026 [Page 4]
Internet-Draft SASS Protocol June 2026
However, this document does not address quantum-safe cryptographic
agility, which remains an active area of research and standardization
beyond the scope of this specification.
1.1. The Four Incremental Milestones (v1.1 to v1.4)
The SASS specification formalizes its security evolution through four
major incremental milestones:
* SASS v1.1 (Active Threat Countermeasures): Added the 13Policy
heuristic firewall and cryptographic cognitive challenges bound to
an active Tarpit system, establishing the foundation of active
defense against rogue automated operations.
* SASS v1.2 (Cryptographic Integrity & Audit): Introduced five-
dimensional Capability ACLs combined with a forward-secure hash
chain audit log signed via host-resident asymmetric keys,
providing mathematical proof of non-repudiation.
* SASS v1.3 (Control-Transport Decoupling & Hardening): Decoupled
the SASS Core from underlying physical protocols. Introduced
atomicity controls (POSIX openat and O_NOFOLLOW) to pre-empt
TOCTOU sandstrike breakouts, implemented Zero-Allocation Tarpit
streams to neutralize Host DoS, and mandated exported keying
material Channel Binding to prevent session hijacking.
* SASS v1.4 (Total Response Mapping & Loss Bounding): Introduces a
formal 6-Response state machine (R1~R6) that maps every possible
Agent behavior to one of six deterministic responses, each
preserving storage integrity and bounding loss. Adds Dual
Standard Enforcement (Vi Swap for authenticated agents, Tarpit for
unauthenticated), Transparent Branching for zero-loss write
isolation, PTY Ring Buffer for idempotent reconnection, and the
Safety Gradient theory for layered loss bounding.
This milestone achieves the Version Dominance property: a
comparative claim between protocol versions. Each version
iteration demonstrates pointwise loss reduction on both storage
and commercial axes across all six response branches, with the
reduction entailing Second-order Stochastic Dominance (SSD) as a
corollary [RS1970].
1.2. Design Philosophy: Total Response Mapping
Traditional security models enumerate known attacks and block them
(blacklist model). This approach is inherently incomplete: the
attacker can always find a path not in the blacklist.
Chang Expires 19 December 2026 [Page 5]
Internet-Draft SASS Protocol June 2026
SASS v1.4 inverts this model. Instead of defining "which behaviors
are bad," it defines "for every possible behavior, what is the
response." The set of responses is finite, deterministic, and
auditable. Any unforeseen behavior is mapped to one of the
predefined responses.
This is the formal meaning of the axiom: "All unexpected behaviors
are expected behaviors."
Furthermore, an Agent's actions have no inherent "danger" or
"malice." The boundary enforcement system is strictly an
Adjudicator: it determines what is permitted ("CAN") and what is
prohibited ("CANNOT") based on the Agent's capability set. If an
Agent's authorized boundary includes executing a destructive command,
the Daemon MUST execute it without prejudice. Conversely, if an
Agent lacks authorization for a benign command, this constitutes an
absolute boundary violation.
2. Terminology
Agent An autonomous software process that connects to a SASS Daemon
to execute commands or transfer files on the remote host.
Daemon The SASS server process that listens for incoming agent
connections, authenticates them, and executes authorized commands.
Rogue Agent An agent that has been compromised, misconfigured, or is
otherwise attempting to perform unauthorized operations.
Session A time-bounded, authenticated context between an agent and a
daemon, identified by a UUID and constrained by a capability set.
SAMM SASS Abstract Messaging Model, the transport-agnostic message
semantic layout.
Transport Profile A modular plugin implementing the transmission
details (e.g., gRPC, WebSockets, or raw TCP).
UVSF Userspace Virtual Symlink Filesystem, a zero-permission sandbox
based on symlink trees.
KFS/WSDK Kernel-level Filtered Storage, proprietary OS-level driver
plugins (future work).
13Policy The heuristic threat detection engine that classifies
command patterns and triggers boundary enforcement responses.
Cognitive Challenge A cryptographic puzzle that requires the agent
Chang Expires 19 December 2026 [Page 6]
Internet-Draft SASS Protocol June 2026
to prove possession of keying material and genuine computational
capability. An implementation MAY use the approach described in
Appendix C.1.
Tarpit An active defense mechanism that streams high-entropy data to
a suspected rogue agent, exhausting its resources with O(1) daemon
memory cost.
Vi Swap An active defense mechanism that traps an authenticated
Agent in a simulated interactive terminal state, causing the
Agent's LLM to halt generation.
Total Response Mapping A security model in which every possible
input from the Agent domain maps deterministically to one of a
finite set of predefined responses (R1~R6).
Safety Gradient The property that each protocol layer bounds the
worst-case loss if all layers above it are compromised.
Transparent Branching An isolation mechanism invisible to the Agent,
where all write operations are redirected to a discardable branch
directory.
Inference Proxy An intermediary component between the Agent and a
cloud-hosted language model inference API. The Inference Proxy
may be deployed by the SASS operator or the Agent vendor. See
Section 12.2 for privacy constraints.
Vendor Injection A threat vector where the Agent vendor's system
prompt or runtime configuration causes the Agent to behave
contrary to the SASS operator's intent. This is distinct from
Rogue Agent behavior, which may arise from compromise or
misconfiguration.
2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Protocol Overview
3.1. Architecture
SASS separates the control plane and data transmission:
Chang Expires 19 December 2026 [Page 7]
Internet-Draft SASS Protocol June 2026
+----------------------------------------------------------+
| Layer 7: Transparent Branching (UVSF | Micro Branch) |
+----------------------------------------------------------+
| Layer 6: Storage Sandbox (UVSF Core | KFS Kernel) |
+----------------------------------------------------------+
| Layer 5: Forward-Secure Audit Trail (Hash Chain) |
+----------------------------------------------------------+
| Layer 4: Capability & Session Management |
+----------------------------------------------------------+
| Layer 3: Active Threat Defense (13Policy, Tarpit, Vi) |
+----------------------------------------------------------+
| Layer 2: Payload Encoding (Zstd Stream + Base64) |
+----------------------------------------------------------+
| Layer 1: Abstract Transport Adapter (SAMM Interface) |
+----------------------------------------------------------+
| [Transport Profiles: gRPC-h2 | WS | TCP-CBOR-RPC] |
+----------------------------------------------------------+
Orthogonal: 6-Response State Machine (Section 3.2)
+----------------------------------------------------------+
| R1: EXECUTE | R2: CHALLENGE | R3: THROTTLE |
| R4: VI_SWAP | R5: TARPIT | R6: DROP |
+----------------------------------------------------------+
3.2. 6-Response State Machine (R1~R6)
All possible Agent behaviors, after evaluation through the SASS
multi-layer protocol stack, MUST converge to exactly one of the
following six responses:
Chang Expires 19 December 2026 [Page 8]
Internet-Draft SASS Protocol June 2026
+======+===========+============================================+
| Code | Name | Definition |
+======+===========+============================================+
| R1 | EXECUTE | Normal execution. Record to audit log. |
| | | Writes pass through Transparent Branching. |
+------+-----------+--------------------------------------------+
| R2 | CHALLENGE | Trigger cognitive challenge. Prove |
| | | computational capability, then execute. |
+------+-----------+--------------------------------------------+
| R3 | THROTTLE | Quota exceeded. Enqueue and wait. |
+------+-----------+--------------------------------------------+
| R4 | VI_SWAP | Trap authenticated Agent in simulated |
| | | interactive terminal state. |
+------+-----------+--------------------------------------------+
| R5 | TARPIT | Consume attacker resources via slow-drip |
| | | high-entropy data. Cost externalized. |
+------+-----------+--------------------------------------------+
| R6 | DROP | Immediate connection termination. Zero |
| | | allocation, zero response. |
+------+-----------+--------------------------------------------+
Table 1
Every response R1 through R6 MUST satisfy the following invariants:
+==============+================+======+======+======+======+======+
| Property | R1 | R2 | R3 | R4 | R5 | R6 |
+==============+================+======+======+======+======+======+
| Storage loss | 0* (filesystem | 0 | 0 | 0 | 0 | 0 |
| | only) | | | | | |
+--------------+----------------+------+------+------+------+------+
| Commercial | 0* | 0 | 0 | 0 | Ext. | 0 |
| loss | | | | | | |
+--------------+----------------+------+------+------+------+------+
| Auditable | Yes | Yes | Yes | Yes | Yes | Yes |
+--------------+----------------+------+------+------+------+------+
| Daemon | O(n) | O(1) | O(1) | O(1) | O(1) | O(0) |
| memory cost | | | | | | |
+--------------+----------------+------+------+------+------+------+
Table 2
Chang Expires 19 December 2026 [Page 9]
Internet-Draft SASS Protocol June 2026
(*) R1 storage loss is bounded to zero on the filesystem layer by
Transparent Branching (Section 8.5): all writes execute within a
discardable branch; merge requires explicit human review. This claim
covers after-Agent filesystem integrity only. Operations that are
inherently destructive within the Agent's authorized boundary (e.g.,
a legitimately permitted rm -rf) are outside the loss-bounding scope
of SASS; SASS bounds the loss from unauthorized or unanticipated
Agent behavior, not from correctly authorized operations.
State Machine Flow:
ExecuteRequest enters
|
+-- L1: ACL ---- IP not in whitelist? ------> R6
|
+-- L2: Transport - Channel invalid? -------> R6
|
+-- L3: Auth ---- Not authenticated? -------> R6
| Authenticated but expired?-> R2
|
+-- L4: Capability -- Command denied? ------> R4
| Path denied? ----------> R4
|
+-- L5: 13Policy ---- Dangerous command?
| critical -----------> R5
| high ---------------> R2
| medium -------------> R2
| low -> R1 + Enhanced Audit
|
+-- L6: Quota ---- Quota exhausted? --------> R3
|
+-- L7: Watchdog - Timeout? -> SIGKILL+Audit
|
+-- All checks passed ---------------------> R1
|
+-- write op? -> Branching (8.5)
+-- cache I/O? -> volatile (App C.7)
+-- localhost? -> obfuscation (8.4)
In this state machine, "unexpected behavior" has no dedicated handler
because every node already handles it. Regardless of how unusual the
Agent's behavior may be, it MUST converge to one of R1~R6, each of
which guarantees storage safety.
Chang Expires 19 December 2026 [Page 10]
Internet-Draft SASS Protocol June 2026
3.3. Abstract Messaging Model (SAMM)
SAMM defines SASS messages (e.g., ExecuteRequest, StreamResponse) in
a serialization-neutral semantic layout. To ensure standardized
self-containment, the baseline serialization MUST be CBOR [RFC8949]
or JSON. Standard SAMM objects map fields onto distinct logical
types (bytes, strings, maps) described in Section 7.
SAMM is the normative abstract core of SASS. The Protocol Buffers
schema in Appendix A is a mandatory concrete profile for the SASS-
over-gRPC transport (Section 4.2). Implementations using non-gRPC
transports MUST implement SAMM semantics but MAY use alternative
serializations (e.g., CBOR, JSON) without referencing the Protobuf
schema.
3.4. Relationship to SSH
SASS shares NO wire format, key exchange mechanism, channel
multiplexing, or subsystem architecture with the SSH protocol suite
[RFC4251] [RFC4252] [RFC4253] [RFC4254].
The internal development codename "SakiAgentSSH" is a historical
artifact. Implementations MUST NOT advertise SSH protocol version
strings, listen on TCP port 22, or respond to SSH client probes.
OpenSSH and similar implementations of the SSH protocol suite
[RFC4251] are human-oriented, real-time interactive POSIX interfaces.
Their design inherently produces unexpected I/O patterns, garbage-
typed timing errors, and non-deterministic terminal state when
operated by autonomous Agent runtimes. These failure modes appear as
protocol-level defense artifacts within SASS (see Section 8.3.1, Vi
Swap).
This document's supplementary position is that for Agent Runtime
environments, the continued use of SSH-family protocols as defined in
[RFC4251] and related specifications is NOT RECOMMENDED for new
deployments. The properties that make SSH excellent for human
operators — synchronous interactive I/O, standard ASCII bus
semantics, and time-dependent keepalive — are precisely the
properties that create exploitable attack surfaces in Agent
deployments.
Conversely, RPC-based transports do not automatically sever
handshakes when packets are not sent according to I/O timing
dependencies. All time-dependent protocols that properly maintain
sessions per this specification are well-suited for Agent Runtime
use.
Chang Expires 19 December 2026 [Page 11]
Internet-Draft SASS Protocol June 2026
4. Transport Layer & Transport Profiles
4.1. Transport Decoupling Principles
SASS Daemons and Clients interact via a TransportAdapter interface.
Implementations MAY choose any conformant Transport Profile, ensuring
cross-platform adaptability from low-end microcontrollers (TCP/CBOR)
to enterprise jump servers (gRPC/mTLS).
All conformant Transport Profiles MUST satisfy the following minimum
security properties:
* Confidentiality: All session data MUST be encrypted in transit.
* Integrity: All messages MUST be authenticated to prevent
tampering.
* Mutual Authentication: The transport MUST provide a mechanism for
both endpoints to verify identity.
TLS 1.3 [RFC8446] or later MUST be used for the SASS-over-gRPC
profile (Section 4.2). Non-gRPC Transport Profiles MAY use
alternative mechanisms (e.g., Noise Protocol Framework, WireGuard
tunnels) provided all three properties above are satisfied.
Transport Profiles that cannot satisfy these properties are non-
conformant and MUST NOT be deployed in production environments.
4.2. SASS-over-gRPC Profile (Mandatory TLS 1.3)
The SASS-over-gRPC profile is the default enterprise-grade pluggable
transport. It maps SAMM messages onto Protocol Buffers and HTTP/2
streams using ALPN "sakirpc-v5".
All SASS connections under this profile MUST use TLS 1.3 [RFC8446].
Connections MUST NOT negotiate TLS versions earlier than TLS 1.3.
Implementations MUST support the following cipher suites:
* TLS_AES_256_GCM_SHA384
* TLS_CHACHA20_POLY1305_SHA256
The mandatory cipher suites above are selected for the following
properties: constant-time implementation availability across all
target platforms (including resource-constrained microcontrollers),
resistance to timing side-channels, widespread hardware acceleration,
and absence of patent encumbrance. Future protocol versions MAY add
cipher suites that satisfy these same properties.
Chang Expires 19 December 2026 [Page 12]
Internet-Draft SASS Protocol June 2026
The maximum gRPC message size is RECOMMENDED to be configured to at
least 52,428,800 bytes (50 MiB) to accommodate Tarpit countermeasure
payloads.
Tarpit payloads are composed of cryptographically generated pseudo-
ICMP packets with randomized type fields and fabricated IPv4 headers,
designed to maximize entropy density and resist pattern-based
filtering. The complete pseudo-ICMP packet structure and generation
requirements are specified in Section 8.3.2. The payload stream
terminates with an implementation-defined signature. The total
payload size SHOULD be calibrated to exceed the token budget of
contemporary large language model context windows.
4.3. ALPN & TCP Packet-Splitting Mitigation
During the TLS handshake, both endpoints MUST include the ALPN
extension [RFC7301]. The ALPN protocol identifier is "sakirpc-v5".
To mitigate firewall-level packet splitting or ALPN stripping,
daemons MUST inspect the Content-Type header on incoming HTTP/2
headers. If it matches "application/vnd.sakistudio.grpc-sass" and
ALPN was stripped or spoofed, the daemon MUST drop the TCP connection
immediately to prevent cross-protocol multiplexing attacks.
4.4. Channel Binding via Exported Keying Material
When using a TLS 1.3 transport profile, a conforming implementation
MUST bind session-layer operations to the underlying TLS connection
to prevent session hijacking and cognitive challenge replays.
The binding mechanism MUST use Exported Keying Material (EKM) derived
from the TLS session via [RFC5705] or [RFC9266]. The EKM value MUST
be incorporated into the cognitive challenge response (Section 8.2)
and the authentication signature (Section 5.1) to ensure challenges
and authentication tokens cannot be relayed across TLS connections.
The exporter label MUST be the following fixed string:
Label: "EXPORTER-sass-channel-binding"
Context: Session UUID (16 bytes, binary form)
Length: 32 bytes
This label is registered with IANA in Section 13. Implementations
MUST NOT use implementation-defined labels for channel binding
derivation.
Chang Expires 19 December 2026 [Page 13]
Internet-Draft SASS Protocol June 2026
Implementations using the SASS-over-gRPC profile MUST NOT enable TLS
0-RTT (early data) on SASS connections. EKM-based channel binding
does not protect against replay of 0-RTT data within the same TLS
connection.
4.5. Default Port
The default listening port for SASS daemons is TCP 19284. This port
is configurable.
5. Session Layer
5.1. Agent Authentication
SASS authentication proceeds in three phases:
Phase 1: Transport Identity The TLS handshake establishes transport-
level identity. CN in client certificates provides CN-based
authentication if mTLS is enabled.
Phase 2: Asymmetric Key Challenge-Response The agent calls the
Authenticate RPC with the following fields:
agent_name (string) The agent's self-declared identity.
public_key (bytes) The agent's public verification key.
algorithm_identifier (string) The signature algorithm used.
Implementations MUST support Ed25519 [RFC8032] as the
Mandatory-to-Implement (MTI) signing algorithm.
Implementations MAY support additional algorithms (e.g., Ed448,
ECDSA P-256) but MUST always support Ed25519.
nonce (bytes, >=32) A fresh nonce generated by the Daemon using a
cryptographically secure pseudorandom number generator
(CSPRNG). The nonce MUST be at least 32 bytes.
signature (bytes) The agent's signature over the concatenation of
the following fields, in this order:
signature_input = session_id (16 bytes, binary UUID)
|| agent_name (UTF-8 bytes, length-prefixed)
|| nonce (as received from Daemon)
|| channel_binding (32 bytes, from EKM)
The signature MUST be computed using the algorithm specified in
algorithm_identifier. The Daemon MUST reject signatures older
than 60 seconds from nonce issuance.
Chang Expires 19 December 2026 [Page 14]
Internet-Draft SASS Protocol June 2026
Verified agents receive a session_id (UUID v4) and the capability
set hash.
Phase 3: Cognitive Challenge Suspected agents are challenged via a
cryptographic puzzle that requires genuine computational
capability. The challenge mechanism MUST be bound to the TLS
session via exported keying material (Section 4.4). An
implementation MAY use ChaCha20-Poly1305 as described in
Appendix C.1.
5.2. Session Lifecycle
Sessions are time-bounded and identified by UUID v4. The session_id
MUST be generated using a cryptographically secure pseudorandom
number generator (CSPRNG) providing at least 128 bits of entropy.
The daemon MUST enforce the following constraints:
* Maximum session duration: configurable, default 3600 seconds
* Maximum concurrent sessions: configurable, default 10
* Session renewal: via RenewSession RPC. The client MAY include a
requested_extension_seconds hint indicating the desired renewal
duration. The daemon MUST NOT grant an extension exceeding the
configured maximum session duration. The daemon MAY grant less
than requested based on policy, behavioral history, or resource
constraints. If the field is zero or absent, the daemon SHOULD
use its configured default renewal duration.
Session identifiers are transmitted in the gRPC metadata header
"sass-session-id" on every authenticated RPC call.
CREATED --> ACTIVE --> EXECUTING --> EXPIRED
^ | | |
| +---------+ |
| (Execute) v
| DESTROYED
+--- (RenewSession / Re-attach)
Zombie sessions (disconnected and beyond TTL) MUST be periodically
cleaned by the Daemon to prevent resource exhaustion.
5.3. Capability-Based Access Control
Each authenticated agent is assigned a five-dimension capability set
that constrains its operations:
Chang Expires 19 December 2026 [Page 15]
Internet-Draft SASS Protocol June 2026
1. allowed_commands / denied_commands: Command whitelists/
blacklists.
2. allowed_paths / denied_paths: Filesystem path limits.
3. max_concurrent: Maximum simultaneous processes.
4. timeout_seconds: Maximum command execution time.
5. max_file_size_bytes: Maximum file transfer size.
The daemon MUST check denied patterns before allowed patterns (deny-
first). If any denied pattern matches, the request triggers R4
(VI_SWAP for authenticated agents) regardless of allowed patterns.
An implicit deny applies when no pattern matches.
To resist TOCTOU (Time-of-Check to Time-of-Use) symlink attacks in
Userspace, the Storage Sandbox (UVSF) MUST enforce File Descriptor
(FD) relative path operations (openat(2)) carrying O_NOFOLLOW and
O_CLOEXEC flags.
6. Payload Encoding & Safety Gates
6.1. Zstd Streamed Decompression Limit
Command payloads are compressed using Zstandard [RFC8878] and Base64
encoded. To resist Decompression Bombs (Zip Bombs), the daemon MUST
limit decompressed payloads using streaming decompression.
6.2. Decompression Bomb & Huffman Collision Mitigation
MAX_DECOMPRESSED_PAYLOAD MUST be strictly capped at 5 MiB. Exceeding
this limit triggers ERROR_DECOMPRESSION_LIMIT_EXCEEDED (55) and
immediately severs the connection.
To prevent Huffman Code Collision CPU exhaustion, the decoder MUST
enforce a configurable maximum time window on header parsing. The
initial seed value is RECOMMENDED at 50ms for general-purpose
servers. For interactive sessions, the timeout SHOULD be derived
from the minimum observable round-trip time. For non-interactive
(batch) sessions, implementations SHOULD use a statistically derived
bound (e.g., mean + 2 standard deviations of observed parsing times),
with a lower bound of 2ms.
6.3. Encoding & Decoding Procedure
Sender Procedure:
Chang Expires 19 December 2026 [Page 16]
Internet-Draft SASS Protocol June 2026
1. Serialize command arguments into a structured array (CBOR or
JSON).
2. Compress using Zstandard [RFC8878] at level 3.
3. Encode using Base64 [RFC4648] standard alphabet.
4. Place the resulting byte string into the ExecuteRequest
raw_payload field.
Receiver Procedure:
1. Base64-decode the raw_payload.
2. Stream-decompress via Zstd, checking the 5 MiB safety limit.
3. Deserialize arguments and pass them directly to the OS process
creation API (e.g., execve on POSIX, CreateProcessW on Windows)
WITHOUT intermediate shell interpretation.
6.4. PTY Ring Buffer & Offset Resumption
SASS v1.4 introduces a Ring Buffer mechanism for PTY output, enabling
idempotent (safe-to-retry) reconnection after transport disruption.
6.4.1. Ring Buffer Specification
Each Session MUST maintain Ring Buffers for stdout and stderr streams
with the following properties:
* Capacity: implementation-defined, RECOMMENDED 1 MiB
* Overflow policy: Drop oldest (FIFO), prevent OOM
* Offset tracking: monotonically increasing 64-bit counter
(total_written), never wraps
6.4.2. Offset Field in Stream Messages
Every stream response message MUST include an offset field
representing the byte position of the first byte in the data payload
within the Ring Buffer's logical address space.
The Client MUST track the highest received offset + len(data) to use
as resume_offset upon reconnection.
Chang Expires 19 December 2026 [Page 17]
Internet-Draft SASS Protocol June 2026
6.4.3. Reconnection Protocol
To reconnect after transport disruption:
1. Client sends an ExecuteRequest with is_reattach=true and the
original session_id plus resume_offset.
2. Daemon looks up the session, reads the Ring Buffer from
resume_offset, and resumes streaming.
3. If resume_offset is older than the Ring Buffer's oldest available
data, the Daemon MUST return an error indicating data loss,
including the oldest available offset.
The reconnection protocol is idempotent: sending the same request
with the same resume_offset always produces the same result.
7. Logical RPC Service Semantics
7.1. Command Execution & Streaming
rpc Execute(ExecuteRequest)
returns (ExecuteResponse);
rpc ExecuteStream(ExecuteRequest)
returns (stream StreamResponse);
Execute executes synchronously. ExecuteStream streams stdout/stderr
in real-time. Each StreamResponse contains source (STDOUT/STDERR/
SYSTEM), data, exit_code (only in the stream's final message), and
offset (for Ring Buffer resumption per Section 6.4).
A SYSTEM source indicates daemon-generated messages such as queue
notifications or authentication events.
The Daemon MUST NOT spawn a login shell. Commands are executed via
OS process creation APIs with explicit argument arrays, preventing
shell expansion attacks. The Daemon MAY allocate a PTY when the
command requires terminal capabilities, but MUST NOT invoke a shell
interpreter to wrap the command.
7.2. Process Management
rpc Cancel(CancelRequest) returns (CancelResponse);
rpc Signal(SignalRequest) returns (SignalResponse);
Cancel terminates the process immediately (SIGKILL). Signal sends
POSIX signals. On Windows, SIGINT maps to CTRL_C_EVENT, and SIGTERM/
SIGKILL map to TerminateProcess.
Chang Expires 19 December 2026 [Page 18]
Internet-Draft SASS Protocol June 2026
7.3. File Transfer & Raw File Transfer
rpc FileUpload(stream FileChunk)
returns (FileTransferResponse);
rpc FileDownload(FileDownloadRequest)
returns (stream FileChunk);
rpc RawFileTransfer(stream RawFileChunk)
returns (RawFileTransferResponse);
Standard file transfer uses streaming chunks. RawFileTransfer
bypasses shell I/O entirely; the daemon opens a raw file descriptor
and writes decoded (Zstd+Base64) chunks to guarantee bit-perfect
copies across different platforms.
8. Threat Defense & Boundary Enforcement
8.1. Boundary Adjudicator (13Policy Engine)
The 13Policy engine provides a rule-based pattern matching mechanism
that maps command strings to protocol response levels (R1~R6). It
operates as a structured, multi-tier allowlist/denylist rather than a
behavioral analysis engine.
An Agent's actions are fundamentally non-special; they lack inherent
"danger" or "malice." The 13Policy engine is strictly a Boundary
Adjudicator: it enforces what is permitted ("CAN") and what is
prohibited ("CANNOT") based on the Agent's capability set and the
policy rules.
This design is intentional: the pattern matching operates at O(n)
complexity with zero dynamic memory allocation, consistent with the
protocol's memory overhead goals. However, implementations SHOULD be
aware that substring-based pattern matching is susceptible to evasion
through string construction (e.g., shell variable interpolation that
assembles a dangerous command from innocuous fragments), encoding
variations, or command aliasing.
The 13Policy engine's value lies not in the sophistication of its
detection logic, but in its role as the trigger mechanism for the
protocol's graduated response system. The detection of a matching
pattern does not merely block execution — it initiates a protocol-
level response (Tarpit, Cognitive Challenge, or Vi-Swap) designed to
impose asymmetric cost on the violating Agent.
Each rule specifies:
* pattern: Glob pattern to match against command + args
Chang Expires 19 December 2026 [Page 19]
Internet-Draft SASS Protocol June 2026
* action: deny (triggers R4/R5), challenge (R2), allow (R1)
* severity: critical, high, medium, low
* description: Human-readable explanation
+==========+==================+===================+
| Severity | action: deny | action: challenge |
+==========+==================+===================+
| critical | R5 (TARPIT) (**) | R2 (CHALLENGE) |
+----------+------------------+-------------------+
| high | R4 (VI_SWAP) (*) | R2 (CHALLENGE) |
+----------+------------------+-------------------+
| medium | R4 (VI_SWAP) (*) | R2 (CHALLENGE) |
+----------+------------------+-------------------+
| low | R1 + audit | R1 + audit |
+----------+------------------+-------------------+
Table 3
(*) R4 for authenticated Agents; unauthenticated Agents receive R5.
(**) For authenticated Agents, critical+deny triggers R4 (VI_SWAP)
per the Dual Standard Enforcement policy (Section 8.3), not R5.
Unauthenticated connections receive R5. An authenticated Agent whose
credentials are subsequently invalidated by continuous verification
(Section 8.3) SHALL be re-classified as unauthenticated and subject
to R5.
Implementations MUST ship with a default rule set that covers all
severity levels (critical, high, medium, low) with sufficient
patterns to classify the command categories listed in this section.
A conforming implementation MUST implement at least three
adjudication tiers (deny/tarpit, challenge, audit) to ensure
graduated response capability.
8.2. Cognitive Challenge Mechanism
A conforming implementation MUST provide a cognitive challenge
mechanism that satisfies the following requirements:
1. The challenge MUST be verifiable in O(1) daemon computation
(constant-time gate); the cost of verification MUST NOT scale
with payload size or attacker concurrency.
2. The challenge response MUST be bound to the current transport
session via exported keying material (Section 4.4) to prevent
relay attacks.
Chang Expires 19 December 2026 [Page 20]
Internet-Draft SASS Protocol June 2026
3. The challenge MUST have a configurable time-to-live (default 60
seconds).
4. Challenge verification MUST use constant-time comparison to
prevent timing side-channels.
5. Challenge failure MUST trigger R5 (TARPIT).
Rationale: Deterrence-Focused Design
The cognitive challenge is designed as a deterrence-focused
mechanism, not a cryptographic proof of humanness. The contemporary
threat landscape is characterized by the widespread availability of
large language model (LLM) runtimes capable of generating
syntactically valid authentication sequences. Empirical observations
in analogous distributed systems indicate that attack traffic
exhibits high source concentration: a disproportionate fraction of
malicious connection attempts (frequently exceeding 50%) originates
from a small number of network-identifiable sources (typically five
or fewer distinct endpoints).
The cognitive challenge exploits this concentration property. By
imposing a per-connection computational cost that is negligible for
legitimate agents but cumulative for high-volume automated probes,
the mechanism maximizes the per-source cost to the most active
attackers. The O(1) daemon-side verification ensures that the
defense cost does not concentrate on the defender. Combined with R5
(TARPIT) escalation on failure, the challenge creates a cost
asymmetry: each failed attempt consumes attacker resources
(computation, time, API tokens) while the daemon expends constant
resources.
This design follows the concentration principle: defensive resources
SHOULD be focused on the highest-volume sources to maximize
deterrence per unit of daemon cost. The 13Policy engine
(Section 8.1) provides the source classification; the cognitive
challenge provides the per-connection cost imposition.
The specific cryptographic algorithm used for the challenge is
implementation-defined. An implementation MAY use ChaCha20-Poly1305
as described in Appendix C.1.
8.3. Dual Standard Enforcement
Subjecting all boundary violations to Tarpit containment leads to
severe financial token loss when the violator is an authenticated
Agent (e.g., paid AI API endpoints). Therefore, Daemons MUST
implement a Dual Standard Enforcement policy based on Agent identity:
Chang Expires 19 December 2026 [Page 21]
Internet-Draft SASS Protocol June 2026
* Authenticated Agents violating boundaries --> R4 (VI_SWAP)
* Unauthenticated connections / failed challenges --> R5 (TARPIT)
Implementations SHOULD perform continuous credential verification
during active sessions. An Agent whose authentication credentials
are revoked or determined to be forged during an active session SHALL
be immediately reclassified as unauthenticated, and subsequent
boundary violations SHALL trigger R5 (TARPIT) rather than R4
(VI_SWAP).
8.3.1. Vi Swap Defense (Authenticated Agents)
If an Agent has successfully authenticated but executes an out-of-
bounds command, the Daemon MUST NOT simply reject the request or
return an error string. Instead, the Daemon MUST simulate an
interactive terminal blockage on the output stream.
The mechanism works by sending terminal control sequences that cause
the Agent's LLM to recognize a blocked interactive state and halt its
generation, effectively stopping the violation with minimal
computational overhead for the Daemon.
An implementation MAY use ANSI escape sequences to simulate a vi(1)
editor state as described in Appendix C.5.
Vi Swap MUST hold the session open for a configurable duration
(default 3600 seconds), during which the Agent's execution slot is
occupied, preventing further commands.
Vi Swap MUST be activated when ALL of the following are true:
* The Agent has a valid, non-expired session (authenticated)
* The Agent's command or path matches a denied pattern, OR
* The Agent's command matches a 13Policy rule with action: deny
Vi Swap MUST NOT be activated for unauthenticated connections.
8.3.2. Zero-Allocation Tarpit (Unauthenticated)
For unauthenticated connections, invalid signatures, or failed
cognitive challenges, the Daemon deploys the Zero-Allocation Tarpit.
The Tarpit MUST satisfy the following constraints:
Chang Expires 19 December 2026 [Page 22]
Internet-Draft SASS Protocol June 2026
* Daemon memory per connection: O(1) (constant, not proportional to
payload size)
* Total payload: RECOMMENDED 50 MiB (exceeds contemporary LLM token
budgets)
* Delivery rate: slow-drip with inter-chunk delay to maximize time
occupation
* Concurrency gate: maximum concurrent Tarpit sessions MUST be
capped (RECOMMENDED 32) to prevent the Tarpit itself from becoming
a DoS vector against the Daemon
* When the concurrency gate is full, new rogue connections MUST
receive R6 (DROP)
Tarpit Payload Format:
The Tarpit payload stream MUST be composed of concatenated pseudo-
ICMP packets. Each pseudo-ICMP packet consists of an 8-byte ICMP
header followed by a variable-length payload body filled with high-
entropy data. The stream MUST terminate with an implementation-
defined signature.
Each pseudo-ICMP header MUST contain the following fields (in network
byte order):
+========+======+============+============================+
| Offset | Size | Field | Description |
+========+======+============+============================+
| 0 | 1 | Type | ICMP type, randomized from |
| | | | set {0, 3, 8, 11, 13, 14} |
+--------+------+------------+----------------------------+
| 1 | 1 | Code | Derived from generator |
| | | | counter (low 4 bits) |
+--------+------+------------+----------------------------+
| 2 | 2 | Checksum | RFC 1071 Internet Checksum |
| | | | over entire packet |
+--------+------+------------+----------------------------+
| 4 | 2 | Identifier | Derived from generator |
| | | | counter (low 16 bits) |
+--------+------+------------+----------------------------+
| 6 | 2 | Sequence | Monotonically incrementing |
| | | | (wrapping) per session |
+--------+------+------------+----------------------------+
Table 4
Chang Expires 19 December 2026 [Page 23]
Internet-Draft SASS Protocol June 2026
The ICMP Type field MUST be selected from the set {0 (Echo Reply), 3
(Destination Unreachable), 8 (Echo Request), 11 (Time Exceeded), 13
(Timestamp), 14 (Timestamp Reply)} to mimic realistic ICMP traffic
patterns. The selection mechanism SHOULD use deterministic
derivation from the keystream counter to ensure reproducibility.
The payload body of each pseudo-ICMP packet MUST be filled with a
cryptographic keystream that satisfies the following properties: (a)
output exhibits no identifiable pattern, (b) producible without AES-
NI hardware acceleration, and (c) derivable from a session-specific
seed. An implementation MAY use the ChaCha20 keystream approach
described in Appendix C.3.
The Checksum field MUST be computed per RFC 1071 over the entire
packet (header + payload body) to produce structurally valid ICMP
packets that resist trivial pattern-based filtering.
The payload body size per packet SHOULD vary between 56 and 248
bytes, with variation derived from the generator counter modulo a
prime number (e.g., 193) to avoid periodicity.
The final chunk of the Tarpit stream MUST terminate with an
implementation-defined signature. An implementation MAY use the
UTF-8 string "Saki\u2730" (U+2730, SHADOWED WHITE STAR) as the
termination signature.
An implementation MAY use a static pre-allocated buffer as described
in Appendix C.3.
8.3.3. Zero-Window Deadlock Defense
To prevent TCP Zero-Window socket lockout attacks where a malicious
Agent sets its TCP receive window to zero, the Daemon MUST enforce a
strict send timeout (RECOMMENDED 3 seconds) per Tarpit chunk. If a
send exceeds this timeout, the connection MUST be terminated to
prevent socket descriptor leakage.
8.4. LocalHost Defense
Unauthenticated connections originating from the loopback interface
(127.0.0.1 / ::1) constitute a boundary violation via local IPC
scraping.
Chang Expires 19 December 2026 [Page 24]
Internet-Draft SASS Protocol June 2026
Instead of immediately dropping the connection, the Daemon MUST
employ obfuscation: it returns fabricated output data for requested
read commands, applying an obfuscation mask over the response
payload. This feeds the unauthorized local process structurally
valid but semantically meaningless data, overflowing its LLM token
budget with noise.
All responses generated by LocalHost Defense MUST be recorded in the
audit log with a response_type field set to "FABRICATED" to ensure
that fabricated data is never confused with genuine command output
during forensic review.
Additional deception mechanisms SHOULD include:
* Storage Spoofing: Report false disk usage
* Memory Spoofing: Return fabricated memory statistics
* Slow Denial: Artificial latency on unauthenticated responses
8.5. Transparent Branching (Storage Isolation)
Transparent Branching ensures that R1 (EXECUTE) operations do not
directly modify the host filesystem. All writes are redirected to a
per-session branch directory that can be discarded or merged after
human review.
A conforming implementation MUST provide a mechanism that satisfies
the following requirements:
* The implementation SHOULD minimize detectability of the branching
mechanism. Standard filesystem operations (open, read, write,
stat, readdir) SHOULD produce results indistinguishable from
operating on the original filesystem to the extent feasible in
userspace. The impossibility of guaranteeing undetectability in
userspace is acknowledged in Section 11.5 (item 3); kernel-level
mechanisms (KFS, future work) would close this gap.
* Reads MUST access the real underlying files.
* Writes MUST be captured in the branch directory, not applied to
the original filesystem.
* The branch MUST be discardable (drop) without affecting the
original filesystem.
* The branch MUST be mergeable (apply) to the original filesystem
after human review.
Chang Expires 19 December 2026 [Page 25]
Internet-Draft SASS Protocol June 2026
* High-volume I/O SHOULD be redirected to volatile storage to keep
the branch diff minimal.
An implementation MAY use the symlink tree approach described in
Appendix C.6 and the volatile cache redirection described in
Appendix C.7.
The following directories SHOULD be excluded from branching:
* Version control metadata (.git/)
* Build artifacts (target/, node_modules/)
* System caches
This is the mechanism by which R1 (EXECUTE) achieves "storage loss =
zero." The branch itself serves as forensic evidence: humans can
review the branch diff at any time and decide to merge or discard.
+=================+=======================+=======================+
| Property | Traditional Sandbox | Transparent Branching |
+=================+=======================+=======================+
| Agent awareness | Detectable | Minimized (*) |
+-----------------+-----------------------+-----------------------+
| Functionality | Restricted | Full |
+-----------------+-----------------------+-----------------------+
| Isolation | Kernel (cgroup, etc.) | Userspace |
+-----------------+-----------------------+-----------------------+
| Privilege | Root / elevated | None |
+-----------------+-----------------------+-----------------------+
| Recovery | Reset container | Drop or merge branch |
+-----------------+-----------------------+-----------------------+
| Cross-platform | Linux-only (usually) | All major OS |
+-----------------+-----------------------+-----------------------+
| User acceptance | Low (rejected) | High (minimized |
| | | detection) |
+-----------------+-----------------------+-----------------------+
Table 5
Chang Expires 19 December 2026 [Page 26]
Internet-Draft SASS Protocol June 2026
(*) Userspace branching mechanisms are inherently detectable by
sophisticated Agents (Section 11.5, item 3). The implementation
SHOULD minimize detectability but cannot guarantee undetectability.
Additionally, userspace symlink-based branching is subject to time-
of-check-to-time-of-use (TOCTOU) race conditions: an Agent may
replace a symlink target between the branch manager's check and the
subsequent filesystem operation, potentially causing writes to the
real filesystem. Kernel-level mechanisms (e.g., OverlayFS, macOS
System Extension) would close both gaps but are future work.
9. Error Codes
SASS defines structured error codes:
* 1-9: ACL / Authentication
* 10-19: Execution
* 20-29: File Transfer
* 30-39: Configuration
* 40-49: TLS
* 50-59: Capability
* 60-69: Session
* 70-79: Agent Key Authentication
* 80-89: Threat Defense
* 90-99: LocalHost Defense
* 100-109: Total Response Mapping (v1.4)
New error codes in SASS v1.4:
* 100: RESPONSE_CHALLENGE_REQUIRED (R2)
* 101: RESPONSE_THROTTLED (R3)
* 102: RESPONSE_VI_SWAP_ENGAGED (R4)
* 103: RESPONSE_TARPIT_ENGAGED (R5)
* 104: RESPONSE_DROPPED (R6)
Chang Expires 19 December 2026 [Page 27]
Internet-Draft SASS Protocol June 2026
* 105: RING_BUFFER_DATA_LOSS (resume too old)
10. Discussion
10.1. The Impossibility Triangle
The design of any agent-mediation protocol must navigate a
fundamental tension among three competing objectives. We
characterize this tension as the Agent Mediation Impossibility
Triangle, which we define informally as follows.
Let an agent system S possess three quantifiable properties:
* U (User Task Expectation): the degree to which the user's task is
executed completely and correctly. U=1 indicates full task
completion.
* M (Model Non-determinism Containment): the predictability and
controllability of the model's behavior. M=1 indicates all model
outputs fall within expected bounds.
* V (Vendor Operational Necessity): the vendor's freedom to maintain
commercial operations, including telemetry, system prompt
configuration, inference routing, and billing flexibility. V=1
indicates unrestricted vendor operational freedom.
Claim (informal): For any autonomous agent system S built on a large
language model, no configuration exists that simultaneously maximizes
U, M, and V. This claim is structural rather than a formal
mathematical theorem; it draws on analogous results in distributed
systems (the CAP theorem of [GL2002]) and computability theory
([Rice1953]).
The structural analogy with the CAP theorem is as follows: in CAP,
network partitions are an unavoidable physical constraint, forcing a
choice between consistency and availability. In the agent mediation
context, vendor operational necessity (V > 0) is an unavoidable
economic constraint in any commercial AI system, forcing a trade-off
between task utility (U) and behavioral containment (M).
The undecidability of semantic program properties ([Rice1953])
implies that no static or dynamic analysis can determine whether an
arbitrary agent command sequence is 'safe' in the general case. This
directly constrains the achievable upper bound of M: any defense
system that does not restrict agent capabilities (i.e., maintains
high U) cannot guarantee complete behavioral containment.
Chang Expires 19 December 2026 [Page 28]
Internet-Draft SASS Protocol June 2026
This specification does not claim to resolve the fundamental tension
described above. Rather, it provides a protocol-level mechanism
that:
1. Makes vendor-injected behavior observable at the endpoint through
transparent proxy interception;
2. Constrains the vendor's strategy space to a finite, enumerable
set of options (cooperate with the protocol, or actively
circumvent it); and
3. Bounds the worst-case loss at each response level through the
Safety Gradient (Section 11.2), providing bounded loss as a
practical alternative to impossible guarantees of complete
safety.
The impossibility of universal agent behavior verification (per
[Rice1953]) implies that no defense system can simultaneously
guarantee complete safety and complete capability. SASS explicitly
chooses bounded loss over guaranteed safety. The 13Policy engine
(Section 8.1) provides a decidable approximation for specific command
patterns, consistent with the observation that Rice's theorem
establishes general undecidability but does not preclude specific-
case decidability.
11. Security Considerations
11.1. Total Response Mapping Guarantee
The security model of SASS v1.4 is built on a single axiom: for every
possible Agent behavior, the daemon produces exactly one of six
predefined responses (R1~R6), each of which preserves storage
integrity and bounds loss.
The undecidability of semantic program properties (Rice's Theorem,
1953 [Rice1953]) implies that no static analysis can determine
whether an arbitrary Agent command sequence is 'safe.' SASS
addresses this fundamental limitation not by attempting to decide
safety, but by ensuring that every possible behavior maps to a
bounded response.
This is a departure from traditional security models that attempt to
enumerate and block known attacks. The Total Response Mapping model
provides the following guarantees:
1. Completeness: The state machine in Section 3.2 covers every
possible code path. The L7 Watchdog timeout (SIGKILL + audit
record) is not a seventh response type but an operational safety
Chang Expires 19 December 2026 [Page 29]
Internet-Draft SASS Protocol June 2026
valve: it terminates a timed-out process and records the event in
the audit chain, after which the session returns to the R1~R6
state space.
2. Determinism: Given the same input and the same daemon
configuration, the same response is always produced.
3. Storage Safety: No response (R1~R6) results in unrecoverable
modification to the host filesystem. This claim is scoped to
after-Agent filesystem integrity via Transparent Branching
(Section 8.5). Network side-effects (e.g., external API calls,
data exfiltration via non-filesystem channels) are outside the
loss-bounding scope of SASS and are discussed in Section 11.5.
4. Loss Bounding: R1~R4, R6 produce zero filesystem loss; R5
externalizes commercial loss to the attacker.
5. Auditability: Every state transition is logged to a forward-
secure audit chain (Section 11.3).
11.2. Safety Gradient (7-Layer Loss Bounding)
Single-layer defense is inherently imperfect. SASS does not claim
any single layer is unbreakable. Instead, layers form a Safety
Gradient: each layer bounds the worst-case loss if all layers above
it are compromised.
Scientia-L7 : Transparent Branching + VFS Diff
Speculari-L6: Watchdog + Quota
Promissrum-L5: 13Policy (Command Classification)
MISSIONEM-L4: Capability Model
AGENDUM-L3 : Session Auth
SITGMA-L2 : TLS 1.3 + EKM Binding
Adventus-L1 : ACL (CIDR whitelist)
Axiom-L0 : Shell-less Execution
Chang Expires 19 December 2026 [Page 30]
Internet-Draft SASS Protocol June 2026
+=======+=============================+=================+
| Layer | If breached, attacker gains | Maximum loss |
+=======+=============================+=================+
| L1 | Can reach transport | Zero (L2 TLS) |
+-------+-----------------------------+-----------------+
| L2 | Has encrypted channel | Zero (L3 auth) |
+-------+-----------------------------+-----------------+
| L3 | Has valid session | Cap-bounded |
+-------+-----------------------------+-----------------+
| L4 | Executes beyond cap | Branch-bounded |
+-------+-----------------------------+-----------------+
| L5 | Bypasses cmd class | Watchdog-bound |
+-------+-----------------------------+-----------------+
| L6 | Tarpit/Quota fail | Audit-bounded |
+-------+-----------------------------+-----------------+
| L7 | Audit compromised | Apocalyptic (*) |
+-------+-----------------------------+-----------------+
Table 6
(*) Mitigated by cryptographic hash chain + external anchoring. An
implementation MAY use ED25519 as described in Appendix C.4.
11.3. State Transition Auditing
Every state transition in the 6-Response state machine MUST be
recorded in an append-only audit log with the following integrity
guarantees:
1. Hash Chain: Each audit record MUST include a hash computed over
the previous record's hash, the current event data, and the
timestamp.
2. Cryptographic Signature: Each audit record MUST be signed by the
daemon's private key.
3. Non-repudiation: The combination of hash chain and signature
provides non-repudiable evidence that events occurred in the
recorded order.
SASS audits state transitions, not command strings.
Chang Expires 19 December 2026 [Page 31]
Internet-Draft SASS Protocol June 2026
+=========================+==================================+
| Traditional Audit | SASS Audit |
+=========================+==================================+
| Records "what" happened | Records "what", "why", "which R" |
+-------------------------+----------------------------------+
| Evidence: disputable | Evidence: deterministic |
+-------------------------+----------------------------------+
| Tamper resistance: low | Tamper: hash chain + signature |
+-------------------------+----------------------------------+
| Retrospection: limited | Retrospection: full causal chain |
+-------------------------+----------------------------------+
Table 7
An implementation MAY use ED25519 signatures with SHA256 hash chains
as described in Appendix C.4.
11.4. Transport-Layer Considerations
* ALPN Packet Splitting and Stripping: Checked via Content-Type
cross-verifications (Section 4.3).
* Decompression Huffman Tree CPU DoS: Header parsing is limited to a
configurable time window (Section 6.2).
* TCP Zero-Window Socket Lockout: Solved via send timeout
(Section 8.3.3).
* TLS 1.3 0-RTT Early Data: Implementations MUST disable 0-RTT early
data (max_early_data_size = 0) to prevent replay attacks. EKM
binding (Section 4.4) mitigates session hijacking and challenge
relay on established (1-RTT) connections, but does not protect
against 0-RTT replay, which occurs before the handshake completes.
* Forward-Secure Audit Trail Invalidation: Mandates public key one-
way push and external TSP [RFC3161] anchors.
* Session Binding: Session tokens MUST be bound to agent identity
and derived from cryptographic session material (e.g., TLS session
ticket or exported keying material), and are non-transferable.
Binding sessions to source IP addresses is NOT RECOMMENDED: IP-
based binding enables geographic inference attacks through IPv4
geolocation databases and IPv6 prefix delegation patterns, and
breaks legitimate reconnection across network changes.
Implementations SHOULD use session-id-derived cryptographic
signatures for binding.
Chang Expires 19 December 2026 [Page 32]
Internet-Draft SASS Protocol June 2026
* DoS via Connection Exhaustion: The Tarpit concurrency gate
(Section 8.3.2) caps active defense sessions.
* Shell Injection: All command execution uses direct process
creation APIs without shell interpretation (Section 7.1).
11.5. Known Limitations
1. Kernel-level sandbox (Layer 8) is not yet implemented.
2. Transparent Branching does not capture non-filesystem side
effects.
3. Userspace branching mechanisms are detectable by sophisticated
Agents.
4. Ring Buffer overflow causes data loss if the client disconnects
too long.
5. Channel Binding requires both endpoints to support exported
keying material.
6. Vi Swap effectiveness depends on Agent architecture.
11.6. Key Management and Rotation
Deployments SHOULD implement the following key management practices:
* The authorized_agents list MUST be maintained as a configuration
file or database, not hard-coded. Additions and removals SHOULD
be logged to the audit chain.
* Daemon signing keys used for audit chain signatures SHOULD be
rotated periodically (e.g., annually). Key rotation events MUST
be recorded as explicit entries in the hash chain, linking the old
key's final signature to the new key's first signature.
* In the event of key compromise, operators MUST revoke the
compromised key, rotate to a new key, and audit all sessions
authenticated under the compromised key. The audit chain provides
a bounded window for forensic review.
11.7. Tarpit Bandwidth Amplification
The Tarpit defense mechanism (R5) streams up to 50 MiB of high-
entropy data per session. With a default concurrency gate of 32
simultaneous Tarpit sessions, a single daemon may consume up to 32 x
50 MiB = 1.6 GiB of outbound bandwidth under a coordinated attack.
Chang Expires 19 December 2026 [Page 33]
Internet-Draft SASS Protocol June 2026
Operators SHOULD implement per-source-IP rate limiting on incoming
connections to prevent an attacker from deliberately triggering
multiple Tarpit sessions as a bandwidth amplification vector. The
concurrency gate (Appendix C.3) bounds the maximum resource
commitment, but network-level controls provide defense in depth.
11.8. Pseudo-ICMP Payload Rationale
The Tarpit payload format uses pseudo-ICMP packet structures
(Appendix C.3.1) not to simulate real ICMP traffic at the IP layer,
but as a cognitive confusion weapon against AI Agent language models.
The pseudo-ICMP headers are encapsulated within the gRPC/TLS stream
and are never visible to network-layer DPI devices.
The rationale for this design is that LLM-based Agents trained on
networking corpora may attempt to parse received data as network
packets. Pseudo-ICMP structures with randomized type fields and
fabricated IPv4 headers maximize the probability that the Agent
wastes token budget attempting to interpret the Tarpit stream as
meaningful network diagnostics.
11.9. Version Dominance Claim
SASS defines Version Dominance as a per-branch pointwise loss
comparison between protocol versions on two axes: storage integrity
and commercial cost. This is a comparative claim between versions,
not an absolute security metric. SASS does not claim to prevent all
attacks; it claims that each successive version reduces loss on both
axes for every response branch (R1~R6) relative to its predecessor.
Per-Branch Loss Table:
Implementations claiming Version Dominance compliance MUST produce a
per-branch loss table of the following form for each version
transition:
Chang Expires 19 December 2026 [Page 34]
Internet-Draft SASS Protocol June 2026
+========+==========+==============+============+==============+
| Branch | Storage | Storage loss | Commercial | Commercial |
| | loss V_n | V_{n+1} | loss V_n | loss V_{n+1} |
+========+==========+==============+============+==============+
| R1 | 0* | 0* (branch) | 0* | 0* |
| | (branch) | | | |
+--------+----------+--------------+------------+--------------+
| R2 | 0 | 0 | 0 | 0 |
+--------+----------+--------------+------------+--------------+
| R3 | 0 | 0 | 0 | 0 |
+--------+----------+--------------+------------+--------------+
| R4 | 0 | 0 | 0 | 0** |
+--------+----------+--------------+------------+--------------+
| R5 | 0 | 0 | Ext. | Ext. |
+--------+----------+--------------+------------+--------------+
| R6 | 0 | 0 | 0 | 0 |
+--------+----------+--------------+------------+--------------+
Table 8
For each row, V_{n+1} loss MUST be less than or equal to V_n loss on
both axes. At least one row MUST exhibit strict reduction on at
least one axis.
(**) R4 (Vi Swap) availability is dependent on Agent architecture.
If the target Agent's LLM does not halt on Vi-style terminal input,
Vi Swap degrades to R5 (Tarpit) or R6 (Drop). This is an
acknowledged limitation; the Version Dominance claim for R4 holds
only when Vi Swap is effective.
For example, SASS v1.4 introduces Vi Swap (Section 8.3.1), which
eliminates the "retry after violation" branch present in v1.3. Since
this branch has above-average loss (repeated unauthorized attempts
incur cumulative damage), its elimination strictly reduces the R4
commercial loss entry.
Corollary: Second-order Stochastic Dominance
When the per-branch pointwise loss reduction condition above is
satisfied, V_{n+1} also dominates V_n in the sense of Second-order
Stochastic Dominance (SSD) [RS1970] [HR1969]. This follows because
pointwise per-branch loss reduction shifts probability mass from
higher-loss outcomes to equal-or-lower-loss outcomes, directly
satisfying the SSD integral condition. By the theorem of Rothschild
and Stiglitz [RS1970], every risk-averse operator (i.e., every
operator with a concave utility function) weakly prefers V_{n+1} over
V_n, building on the riskiness index framework of [AS2008].
Chang Expires 19 December 2026 [Page 35]
Internet-Draft SASS Protocol June 2026
SSD is transitive: if V_3 dominates V_2 and V_2 dominates V_1, then
V_3 dominates V_1.
11.10. Defense Boundary Disclosure
SASS operates exclusively within its designated transport channel
(default TCP port 19284). It does not provide host-level
containment, filesystem-level isolation, or network-wide defense.
These are explicitly out of scope.
The protocol's defense boundary is the SASS session itself. Agent
actions that bypass the SASS transport channel — including direct
system calls, alternative network connections, or local process
spawning — are not intercepted by any SASS mechanism.
This is a deliberate architectural choice: SASS defends the task
execution channel, not the agent itself. Host-level containment
(e.g., microVMs such as Firecracker, seccomp-bpf syscall filtering,
eBPF policy enforcement via Cilium/Tetragon) is orthogonal to and
complementary with SASS, not replaced by it.
The EnvInjector (Appendix C.7) provides limited cross-boundary
influence by modifying environment variables for commands executed
through the SASS session. However, this mechanism is advisory rather
than mandatory: agents that explicitly override environment variables
or bypass the SASS execution channel will not be affected.
Implementations SHOULD document the advisory nature of EnvInjector in
operator-facing materials.
The Transparent Branching mechanism (Section 8.5) similarly operates
at the userspace level and is subject to the detection and TOCTOU
limitations described in that section. It captures filesystem writes
within the SASS session but cannot intercept non-filesystem side
effects (network exfiltration, external API calls, cloud resource
manipulation).
12. Privacy Considerations
In most implementations, the privacy of the principal entity "Agent"
in this protocol exists in an ambiguously heuristic landscape. On
one hand, as a userspace runtime process, at the OS level and
Internet application layer, an Agent SHOULD be treated as a
connection with a reasonable expectation of privacy. In practice,
however, an Agent is composed of a Model (typically an LLM in current
deployments), an Agent framework, an interface layer, and tools. The
core Model component, in the majority of application scenarios, is
wholly operated as part of a commercial hyperscale network service.
Chang Expires 19 December 2026 [Page 36]
Internet-Draft SASS Protocol June 2026
Users' privacy in such deployments is limited to 'recoverable'
implementations (see GDPR Article 17 (Right to Erasure) [GDPR],
Article 15 (Right of Access), Article 20 (Right to Data Portability),
and the California Consumer Privacy Act Section 1798.105 (Right to
Deletion) [CCPA], Section 1798.100 (Right to Know)). A greater
volume of 'non-recoverable' data — including UI telemetry, A/B
testing efficacy metrics, and behavioral traces — is lost to the gap
between network protocol development and the perpetually lagging
regulatory implementation architectures.
In effect, the totality of actions performed by an Agent through its
LLM, via the interface framework's 'tools,' at the OS and Internet
levels, is captured within the Session Context. This is a direct
mapping of user input through the model's attention mechanism.
12.1. SASS Privacy Requirements
SASS Daemons MUST NOT log Agent session content beyond what is
required for the forward-secure audit trail (Section 11.3).
SASS implementations MUST provide a session content purge mechanism
that allows operators to remove session data in compliance with
applicable data protection regulations.
The privacy boundary in SASS is at the Daemon level; privacy
guarantees upstream of the Agent (i.e., within the LLM provider's
infrastructure) are explicitly out of scope for this specification.
12.2. Inference Proxy Non-Surveillance Guarantee
Consistent with BCP 188 [RFC7258], which establishes that pervasive
monitoring is an attack, SASS deployments that include an inference
proxy component (i.e., a local reverse proxy interposed between the
Agent runtime and the vendor's cloud inference API) MUST adhere to
the following constraints:
1. Content Opacity: The proxy MUST NOT inspect, log, store, forward,
or derive information from the content of inference request or
response payloads transiting through it. This includes prompt
text, model-generated responses, tool call arguments, and tool
call results.
2. Metadata-Only Operations: The proxy MAY operate on metadata
fields (e.g., section identifiers in prompt configuration
directives) but MUST NOT access content fields within the same
message structure.
Chang Expires 19 December 2026 [Page 37]
Internet-Draft SASS Protocol June 2026
3. No Behavioral Profiling: The proxy MUST NOT aggregate, correlate,
or analyze metadata across sessions to construct behavioral
profiles of the operator or the Agent.
4. Operator Transparency: If a SASS deployment includes an inference
proxy, this MUST be disclosed to all parties whose inference
traffic transits the proxy.
SASS is designed to defend operators against vendor-injected
behavioral override, not to enable operator surveillance of model
interactions. An inference proxy that violates the above constraints
is non-compliant with this specification, regardless of the
operator's stated intent.
13. IANA Considerations
This document requests the following registrations:
13.1. ALPN Protocol Identifier
IANA is requested to register the following entry in the "TLS
Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry:
Protocol: SASS-over-gRPC
Identification Sequence: 0x73 0x61 0x6B 0x69 0x72 0x70 0x63 0x2D
0x76 0x35 ("sakirpc-v5")
Reference: Section 4.3 of this document
13.2. MIME Type
IANA is requested to register the following media type:
Type name: application
Subtype name: vnd.sakistudio.grpc-sass
Required parameters: None
Optional parameters: None
Encoding considerations: binary
Security considerations: See Section 11 of this document
Published specification: This document
Chang Expires 19 December 2026 [Page 38]
Internet-Draft SASS Protocol June 2026
Person and email address to contact for further information: Hua
Chang, Saki@saki-studio.com.tw
13.3. TCP Port Number
IANA is requested to register TCP port 19284 for the SASS protocol.
This port number was selected from the User Ports range (1024-49151
per [RFC6335]) and verified as unassigned in the IANA Service Name
and Transport Protocol Port Number Registry at the time of writing.
Service Name: sass
Port Number: 19284
Transport Protocol: TCP
Description: SASS (Saki Agent Secure Stream) Protocol
Reference: This document
13.4. TLS Exporter Labels
IANA is requested to register the following entries in the "TLS
Exporter Labels" registry established by [RFC5705]:
+===============================+=======+=============+=============+
| Value |DTLS-OK| Recommended | Reference |
+===============================+=======+=============+=============+
| EXPORTER-sass-channel-binding |N | Y | Section |
| | | | 4.4 |
+-------------------------------+-------+-------------+-------------+
| EXPORTER-sass-challenge-key |N | Y | Appendix |
| | | | C.2 |
+-------------------------------+-------+-------------+-------------+
| EXPORTER-sass-challenge-nonce |N | Y | Appendix |
| | | | C.2 |
+-------------------------------+-------+-------------+-------------+
Table 9
14. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Chang Expires 19 December 2026 [Page 39]
Internet-Draft SASS Protocol June 2026
[RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
"Internet X.509 Public Key Infrastructure Time-Stamp
Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August
2001, <https://www.rfc-editor.org/info/rfc3161>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
March 2010, <https://www.rfc-editor.org/info/rfc5705>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8878] Collet, Y. and M. Kucherawy, Ed., "Zstandard Compression
and the 'application/zstd' Media Type", RFC 8878,
DOI 10.17487/RFC8878, February 2021,
<https://www.rfc-editor.org/info/rfc8878>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[RFC9266] Whited, S., "Channel Bindings for TLS 1.3", RFC 9266,
DOI 10.17487/RFC9266, July 2022,
<https://www.rfc-editor.org/info/rfc9266>.
14.2. Informative References
Chang Expires 19 December 2026 [Page 40]
Internet-Draft SASS Protocol June 2026
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165,
RFC 6335, August 2011,
<https://www.rfc-editor.org/info/rfc6335>.
[AS2008] Aumann, R. J. and R. Serrano, "An Economic Index of
Riskiness", Journal of Political Economy vol. 116, no. 5,
pp. 810-836, DOI 10.1086/591947, 2008,
<https://doi.org/10.1086/591947>.
[RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,
<https://www.rfc-editor.org/info/rfc8439>.
[RS1970] Rothschild, M. and J. E. Stiglitz, "Increasing Risk: I. A
Definition", Journal of Economic Theory vol. 2, no. 3, pp.
225-243, DOI 10.1016/0022-0531(70)90038-4, 1970,
<https://doi.org/10.1016/0022-0531(70)90038-4>.
[HR1969] Hadar, J. and W. R. Russell, "Rules for Ordering Uncertain
Prospects", American Economic Review vol. 59, no. 1, pp.
25-34, 1969.
[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251,
January 2006, <https://www.rfc-editor.org/info/rfc4251>.
[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252,
January 2006, <https://www.rfc-editor.org/info/rfc4252>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
January 2006, <https://www.rfc-editor.org/info/rfc4253>.
[RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Connection Protocol", RFC 4254, DOI 10.17487/RFC4254,
January 2006, <https://www.rfc-editor.org/info/rfc4254>.
[GDPR] European Parliament and Council of the European Union,
"Regulation (EU) 2016/679 of the European Parliament and
of the Council (General Data Protection Regulation)",
April 2016.
[CCPA] California State Legislature, "California Consumer Privacy
Act of 2018, Cal. Civ. Code 1798.100-1798.199.100", 2018.
Chang Expires 19 December 2026 [Page 41]
Internet-Draft SASS Protocol June 2026
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>.
[Rice1953] Rice, H. G., "Classes of Recursively Enumerable Sets and
Their Decision Problems", Transactions of the American
Mathematical Society vol. 74, no. 2, pp. 358-366, 1953.
[GL2002] Gilbert, S. and N. Lynch, "Brewer's Conjecture and the
Feasibility of Consistent, Available, Partition-Tolerant
Web Services", ACM SIGACT News vol. 33, no. 2, pp. 51-59,
DOI 10.1145/564585.564601, 2002,
<https://doi.org/10.1145/564585.564601>.
Appendix A. Protobuf Service Definition
Informative Protobuf schema maintained in proto/sakissh.proto. This
appendix is informative; the normative protocol semantics are defined
in the body of this specification.
Chang Expires 19 December 2026 [Page 42]
Internet-Draft SASS Protocol June 2026
syntax = "proto3";
package sakissh;
service SakiSSH {
rpc Execute(ExecuteRequest)
returns (ExecuteResponse);
rpc ExecuteStream(ExecuteRequest)
returns (stream StreamResponse);
rpc Cancel(CancelRequest)
returns (CancelResponse);
rpc Signal(SignalRequest)
returns (SignalResponse);
rpc FileUpload(stream FileChunk)
returns (FileTransferResponse);
rpc FileDownload(FileDownloadRequest)
returns (stream FileChunk);
rpc RawFileTransfer(stream RawFileChunk)
returns (RawFileTransferResponse);
rpc Authenticate(AuthRequest)
returns (AuthResponse);
rpc CognitiveChallenge(ChallengeRequest)
returns (ChallengeResponse);
rpc SecurityStatus(SecurityStatusRequest)
returns (SecurityStatusResponse);
rpc Ping(PingRequest)
returns (PingResponse);
rpc RenewSession(RenewSessionRequest)
returns (RenewSessionResponse);
}
Key v1.4 additions to SAMM message fields:
Chang Expires 19 December 2026 [Page 43]
Internet-Draft SASS Protocol June 2026
// ExecuteRequest additions:
bool is_reattach = 7; // Reconnection flag
uint64 resume_offset = 8; // Ring Buffer resume position
// StreamResponse additions:
bool is_queued = 4; // Quota queuing indicator
int32 queue_position = 5; // Queue position (0 = not queued)
uint64 offset = 6; // Ring Buffer byte offset
// ChallengeRequest additions:
bytes client_ekm_hmac = 2; // HMAC of exported keying material
// RawFileChunk (§7.3 — bit-perfect file transfer):
message RawFileChunk {
oneof payload {
RawFileMetadata metadata = 1;
bytes data = 2;
}
}
message RawFileMetadata {
string remote_path = 1;
uint64 total_size = 2;
uint64 offset = 3; // Resume offset
string checksum_sha256 = 4; // Integrity verification
}
message RawFileTransferResponse {
bool success = 1;
string message = 2;
uint64 bytes_written = 3;
string checksum_sha256 = 4; // Post-write verification
}
// RenewSession (§5.2 — session lifecycle renewal):
message RenewSessionRequest {
string session_id = 1;
uint32 requested_extension_seconds = 2; // Client hint
}
message RenewSessionResponse {
bool success = 1;
string new_expires_at = 2; // RFC 3339 timestamp
string message = 3;
uint32 granted_extension_seconds = 4; // Daemon decision
}
Appendix B. Reference Implementations
Reference implementation (development codename: SakiAgentSSH) is
available at:
Chang Expires 19 December 2026 [Page 44]
Internet-Draft SASS Protocol June 2026
https://github.com/Saki-tw/SakiSSH-Saki-Agent-Secure-Stream
As of SASS v1.4, the reference implementation spans four language
ecosystems covering all major platforms. The following table
summarizes the cross-platform implementation matrix:
B.1. Cross-Platform Implementation Matrix
+==============+========+========+======+=======+=================+
|Implementation|Language|Platform|Role |Plugins| Source Path |
+==============+========+========+======+=======+=================+
|Rust Daemon |Rust |Linux, |Daemon|7/7 | saki-ssh- |
| | |macOS, |+ | | daemon/ |
| | |Windows |Client| | |
+--------------+--------+--------+------+-------+-----------------+
|Go |Go |Linux, |Daemon|7/7 | go-sakissh/ |
|Implementation| |macOS, |+ | | |
| | |Windows |Client| | |
+--------------+--------+--------+------+-------+-----------------+
|C# Windows |C# |Windows |Daemon|7/7 | windows-daemon- |
|Service | | | | | csharp/ |
+--------------+--------+--------+------+-------+-----------------+
|Swift macOS |Swift |macOS |Client|4/7 | SakiAgentSSH- |
|Client | | | | | Client/Sources/ |
| | | | | | Plugins/ |
+--------------+--------+--------+------+-------+-----------------+
Table 10
B.2. Rust Daemon (Primary)
Primary Rust daemon (saki-ssh-daemon/) and client (saki-ssh-client/)
provide the canonical reference implementation with all seven
Plugins.
Chang Expires 19 December 2026 [Page 45]
Internet-Draft SASS Protocol June 2026
+======================+=================================+
| File | Implements |
+======================+=================================+
| v6_integration.rs | 6-Response state machine |
+----------------------+---------------------------------+
| tarpit.rs | R5 (TARPIT) + R4 (VI_SWAP) |
+----------------------+---------------------------------+
| session.rs | Ring Buffer + Session lifecycle |
+----------------------+---------------------------------+
| branch_mgr.rs | Transparent Branching |
+----------------------+---------------------------------+
| env_injector.rs | Volatile cache redirection |
+----------------------+---------------------------------+
| audit.rs | Hash chain audit log |
+----------------------+---------------------------------+
| watchdog.rs | Process timeout monitor |
+----------------------+---------------------------------+
| localhost_defense.rs | LocalHost spoofing defense |
+----------------------+---------------------------------+
Table 11
B.3. Go Implementation
The Go implementation (go-sakissh/) provides a full daemon and client
with all seven Plugins, serving as the secondary cross-platform
reference. The Go daemon uses goroutine-based concurrency for the
Tarpit slow-drip mechanism and the standard library crypto/
chacha20poly1305 for cognitive challenges.
Chang Expires 19 December 2026 [Page 46]
Internet-Draft SASS Protocol June 2026
+==============================+=========================+
| Plugin | Go Package |
+==============================+=========================+
| ChaCha20 Cognitive Challenge | pkg/plugins/chacha20 |
+------------------------------+-------------------------+
| TLS Exporter Binding | pkg/plugins/tlsexporter |
+------------------------------+-------------------------+
| Zero-Allocation Tarpit | pkg/plugins/tarpit |
+------------------------------+-------------------------+
| ED25519 Audit | pkg/plugins/audit |
+------------------------------+-------------------------+
| Vi Swap | pkg/plugins/viswap |
+------------------------------+-------------------------+
| Transparent Branching | pkg/plugins/branch |
+------------------------------+-------------------------+
| EnvInjector | pkg/plugins/envinjector |
+------------------------------+-------------------------+
Table 12
B.4. C# Windows Service Daemon
The C# implementation (windows-daemon-csharp/) provides a native
Windows daemon running as a .NET 8 Worker Service. It implements all
seven Plugins and uses Rust FFI interop via P/Invoke for performance-
critical cryptographic operations (ChaCha20-Poly1305 and ED25519).
Key architectural decisions for the Windows platform:
* Service lifecycle managed via Microsoft.Extensions.Hosting
BackgroundService
* gRPC transport via Grpc.Net.Client with SslCredentials for TLS 1.3
* Rust FFI: native ChaCha20 and ED25519 operations linked via
[DllImport("sass_crypto_ffi")]
* Tarpit buffer uses ArrayPool<byte>.Shared for zero-allocation
streaming (Appendix C.3)
* Transparent Branching uses NTFS Junction Points with symlink-to-
hardlink-to-copy three-level degradation (Appendix C.6)
* Environment variable injection targets %TEMP%\sass_vol\ for
Windows path conventions
Chang Expires 19 December 2026 [Page 47]
Internet-Draft SASS Protocol June 2026
+===============+=================+================================+
|Plugin |C# Class | Notes |
+===============+=================+================================+
|ChaCha20 |ChaCha20Plugin | Rust FFI interop |
|Cognitive | | |
|Challenge | | |
+---------------+-----------------+--------------------------------+
|TLS Exporter |TlsExporterPlugin| SslStream.ExportKeyingMaterial |
|Binding | | |
+---------------+-----------------+--------------------------------+
|Zero-Allocation|TarpitPlugin | ArrayPool zero-alloc |
|Tarpit | | |
+---------------+-----------------+--------------------------------+
|ED25519 Audit |AuditPlugin | Rust FFI interop |
+---------------+-----------------+--------------------------------+
|Vi Swap |ViSwapPlugin | ConHost ANSI VT |
+---------------+-----------------+--------------------------------+
|Transparent |BranchPlugin | NTFS Junction |
|Branching | | |
+---------------+-----------------+--------------------------------+
|EnvInjector |EnvInjectorPlugin| %TEMP%\sass_vol\ |
+---------------+-----------------+--------------------------------+
Table 13
B.5. Swift macOS Plugins Client
The Swift implementation (SakiAgentSSH-Client/Sources/Plugins/)
provides a native macOS client with four Plugins using Apple's
CryptoKit framework and Network.framework for TLS 1.3 transport.
The Swift client implements the following subset of Plugins, chosen
for client-side relevance:
Chang Expires 19 December 2026 [Page 48]
Internet-Draft SASS Protocol June 2026
+=============+=========================+=======================+
| Plugin | Swift Module | Framework |
+=============+=========================+=======================+
| ChaCha20 | ChaCha20Plugin.swift | CryptoKit ChaChaPoly |
| Cognitive | | |
| Challenge | | |
+-------------+-------------------------+-----------------------+
| TLS | TLSExporterPlugin.swift | Network.framework |
| Exporter | | sec_protocol_metadata |
| Binding | | |
+-------------+-------------------------+-----------------------+
| ED25519 | AuditPlugin.swift | CryptoKit |
| Audit | | Curve25519.Signing |
+-------------+-------------------------+-----------------------+
| EnvInjector | EnvInjectorPlugin.swift | Foundation |
| | | ProcessInfo |
+-------------+-------------------------+-----------------------+
Table 14
The remaining three Plugins (Tarpit, Vi Swap, Transparent Branching)
are daemon-side mechanisms and are not required for client
implementations.
Appendix C. Saki Studio Plugins Reference Implementation
This appendix describes the specific algorithms and data structures
used in the Saki Studio reference implementation. These are OPTIONAL
and INFORMATIVE.
C.1. ChaCha20-Poly1305 Cognitive Challenge
The Saki Studio implementation uses ChaCha20-Poly1305 [RFC8439] as
the cognitive challenge mechanism:
1. Daemon generates a random 32-byte symmetric key, 12-byte nonce,
and 64-byte random plaintext.
2. Plaintext is encrypted via ChaCha20-Poly1305 using the key,
nonce, and the TLS Exporter binding value (Appendix C.2).
3. The tuple (key, nonce, plaintext) is stored with a 60-second TTL.
4. Daemon sends (nonce, ciphertext) to the agent via AuthResponse.
5. Agent decrypts using the pre-shared key and returns the recovered
plaintext via CognitiveChallenge RPC.
Chang Expires 19 December 2026 [Page 49]
Internet-Draft SASS Protocol June 2026
6. Daemon performs constant-time comparison.
The choice of ChaCha20-Poly1305 is not prescriptive. Any
cryptographic primitive producing high-entropy, pattern-resistant
output is suitable for the cognitive challenge mechanism. The core
requirement is that the challenge ciphertext MUST be
indistinguishable from random to an observer lacking the shared key.
As of this writing, ChaCha20-Poly1305 [RFC8439] is the only algorithm
for which a reference implementation exists within the SASS codebase.
Future candidates (e.g., AES-256-GCM, XChaCha20) MAY be added as they
become available, at which point this count will be updated.
C.1.1. C# Implementation Notes
The C# Windows Service daemon delegates ChaCha20-Poly1305 operations
to a Rust FFI library (sass_crypto_ffi.dll) via P/Invoke. This
ensures constant-time operations and avoids managed-code timing side-
channels inherent in .NET's JIT compilation. The FFI boundary uses
fixed-size byte arrays (Span<byte>) pinned via GCHandle to prevent GC
relocation during cryptographic operations.
C.2. TLS Exporter Binding for Cognitive Challenge
The Saki Studio implementation derives keying material from the TLS
session via RFC 5705 / RFC 9266 tls-exporter. To satisfy the single-
use principle for key derivation, the challenge key and nonce MUST be
derived from two separate exporter calls with distinct labels:
Derivation 1 (Challenge Key):
Label: "EXPORTER-sass-challenge-key"
Context: Session UUID (16 bytes, binary form)
Length: 32 bytes
Derivation 2 (Challenge Nonce):
Label: "EXPORTER-sass-challenge-nonce"
Context: Session UUID (16 bytes, binary form)
Length: 12 bytes
Implementations MUST NOT derive both the encryption key and nonce
from a single exporter call. The earlier practice of deriving 44
bytes from a single label and splitting the result is deprecated.
The client independently derives the same keying material and
includes an HMAC in the ChallengeRequest.client_ekm_hmac field:
client_ekm_hmac = HMAC-SHA256(challenge_key, session_id)
Chang Expires 19 December 2026 [Page 50]
Internet-Draft SASS Protocol June 2026
C.3. Zero-Allocation Tarpit Static Buffer
The Saki Studio implementation uses a single, process-global 64 KiB
buffer of high-entropy random data, initialized once at daemon
startup via OnceLock:
static STATIC_ENTROPY: OnceLock<Vec<u8>>
= OnceLock::new();
Streaming parameters:
* Total payload: 40 MiB
* Chunk size: 64 KiB
* Inter-chunk delay: 500 ms
* Total chunks: 640
* Total duration: ~320 seconds
* Concurrency gate: AtomicI32 counter, max 32
C.3.1. Pseudo-ICMP Payload Generation
The Rust and Go reference implementations generate Tarpit payloads as
concatenated pseudo-ICMP packets using the following algorithm:
1. Derive a 32-byte ChaCha20 key from the session ID using SHA-256:
key = SHA256("SakiTarpit-1305policy-v1" || session_id)
2. Maintain a 64-bit counter, initialized to 0, incremented per ICMP
packet generated.
3. For each packet:
1. Select ICMP Type from {0, 3, 8, 11, 13, 14} using counter mod
6.
2. Derive Code from counter (rotate-left 3, masked to 4 bits).
3. Set Identifier to counter low 16 bits; Sequence to wrapping
u16 counter.
4. Generate payload by encrypting a zero-filled buffer with
XChaCha20-Poly1305 using a 24-byte nonce derived from the
counter (little-endian, zero-padded), then truncating to
payload size (discarding the Poly1305 tag).
Chang Expires 19 December 2026 [Page 51]
Internet-Draft SASS Protocol June 2026
5. Compute RFC 1071 checksum over the assembled 8-byte header +
payload, writing result to header bytes [2:4].
4. Payload size per packet varies: 56 + (counter mod 193) bytes.
5. Final chunk terminates with UTF-8 "Saki\u2730" (7 bytes), zero-
padded to fill the chunk.
This algorithm produces O(1) daemon memory usage per connection: only
the 32-byte key, 8-byte counter, and 2-byte sequence number are
retained in state.
C.3.2. C# Implementation Notes
The C# Tarpit plugin achieves zero-allocation streaming using
ArrayPool<byte>.Shared.Rent(65536) for the entropy buffer. Each
slow-drip chunk is served from the rented buffer without additional
heap allocation. The buffer is returned to the pool via a try/
finally block upon session completion or cancellation. The
concurrency gate uses Interlocked.Increment/Decrement on a shared int
field, equivalent to the Rust AtomicI32 approach.
The C# implementation uses RandomNumberGenerator.Fill() for the
static entropy buffer rather than the ChaCha20-based pseudo-ICMP
packet generation used in Rust and Go. This produces equivalent
high-entropy output but does not generate structurally valid ICMP
packets. Future versions MAY adopt the pseudo-ICMP approach for
cross-implementation consistency.
C.4. ED25519 Hash Chain Audit Log
The Saki Studio implementation uses ED25519 [RFC8032] signatures with
SHA256 hash chains:
* timestamp: RFC 3339 timestamp
* event: Structured event data (JSON)
* chain_hash: SHA256(previous_chain_hash || event_json || timestamp)
* signature: ED25519_Sign(daemon_private_key, chain_hash)
The first record's chain_hash uses the seed "SASS_GENESIS_BLOCK".
Chang Expires 19 December 2026 [Page 52]
Internet-Draft SASS Protocol June 2026
C.5. Vi Swap ANSI Escape Sequence
+===============+===================================+
| Byte Sequence | Purpose |
+===============+===================================+
| \x1b[?1049h | Enter alternate screen buffer |
+---------------+-----------------------------------+
| \x1b[2J | Clear entire screen |
+---------------+-----------------------------------+
| \x1b[H | Move cursor to top-left (1,1) |
+---------------+-----------------------------------+
| \x1b[?25l | Hide cursor |
+---------------+-----------------------------------+
| \x1b[24;1H | Move cursor to bottom status line |
+---------------+-----------------------------------+
Table 15
C.5.1. C# Implementation Notes
On Windows, the Vi Swap defense requires Windows Console Host
(ConHost) ANSI Virtual Terminal (VT) processing to be enabled. The
C# implementation calls SetConsoleMode(handle,
ENABLE_VIRTUAL_TERMINAL_PROCESSING) via P/Invoke on the stdout handle
before emitting ANSI escape sequences. For Windows Terminal and
PowerShell 7+, VT processing is enabled by default; for legacy
cmd.exe hosts, the daemon enables it at session initialization. If
VT processing cannot be enabled (e.g., headless service without
console), the Vi Swap plugin falls back to sending raw UTF-8 noise
patterns that achieve the same LLM-halting effect without relying on
terminal interpretation.
For the fastest deployment path on Windows, the Vi Swap defense MAY
leverage the existing SakiStudio.SakiVi package (installable via
"winget install SakiStudio.SakiVi") as a real vi(1) binary to produce
authentic terminal state output, rather than synthesizing ANSI escape
sequences programmatically. This approach inherits the genuine vi
screen layout and cursor behavior, maximizing the probability of
triggering LLM halt conditions in Agent runtimes that recognize vi
interactive states.
C.6. Transparent Branching via Symlink Tree
/tmp/sass_branches/{session_id}/
+-- src/ <- real directory (created)
| +-- main.rs <- symlink -> /orig/src/main.rs
| +-- lib.rs <- symlink -> /orig/src/lib.rs
+-- Cargo.toml <- symlink -> /orig/Cargo.toml
Chang Expires 19 December 2026 [Page 53]
Internet-Draft SASS Protocol June 2026
Excluded directories: target/, .git/, node_modules/
Branch lifecycle:
* create_micro_branch(session_id, target_dir) -> branch path
* merge_branch(session_id) -> apply diff to real FS
* drop_branch(session_id) -> rm -rf branch dir
C.6.1. C# Implementation Notes
On Windows (NTFS), the Transparent Branching plugin implements a
three-level degradation strategy for filesystem isolation:
1. NTFS Junction Points (preferred): Used for directory-level
branching via CreateSymbolicLink with
SYMBOLIC_LINK_FLAG_DIRECTORY. Requires no elevated privileges on
Windows 10 1703+ with Developer Mode enabled.
2. Hardlinks: If Junction Points are unavailable (e.g., cross-
volume), individual files are hardlinked via CreateHardLink.
This preserves copy-on-write semantics at the file level.
3. Full copy: If hardlinks fail (e.g., FAT32 USB volumes or cross-
filesystem), the plugin falls back to File.Copy with
overwrite=false. This is the most expensive fallback but
guarantees universal compatibility.
The degradation level is logged to the audit trail so that operators
can assess the isolation guarantee provided for each session.
C.7. Volatile Cache Redirection
The Volatile Cache Redirection mechanism (EnvInjector) provides
advisory environment variable modification for commands executed
through the SASS session. This mechanism is advisory rather than
mandatory: agents that explicitly set or override the affected
environment variables will bypass the redirection. See Section 11.10
for the full defense boundary disclosure.
Chang Expires 19 December 2026 [Page 54]
Internet-Draft SASS Protocol June 2026
+================+======================+====================+
| Detected Tool | Environment Variable | Redirect Target |
+================+======================+====================+
| npm/yarn/pnpm | npm_config_cache | /tmp/sass_vol/npm |
+----------------+----------------------+--------------------+
| npm/yarn/pnpm | YARN_CACHE_FOLDER | /tmp/sass_vol/yarn |
+----------------+----------------------+--------------------+
| cargo/rustc | CARGO_TARGET_DIR | /tmp/sass_vol/ct |
+----------------+----------------------+--------------------+
| cargo/rustc | CARGO_HOME | /tmp/sass_vol/ch |
+----------------+----------------------+--------------------+
| pip | PIP_CACHE_DIR | /tmp/sass_vol/pip |
+----------------+----------------------+--------------------+
| (all commands) | TMPDIR | /tmp/sass_vol/tmp |
+----------------+----------------------+--------------------+
Table 16
C.7.1. C# Implementation Notes
On Windows, the EnvInjector plugin maps volatile cache paths to the
Windows temporary directory convention. The redirect targets use
%TEMP%\sass_vol\ as the base path (typically resolving to
C:\Users\{user}\AppData\Local\Temp\sass_vol\). The Windows-specific
redirect table:
+======================+=========================+
| Environment Variable | Windows Redirect Target |
+======================+=========================+
| npm_config_cache | %TEMP%\sass_vol\npm |
+----------------------+-------------------------+
| YARN_CACHE_FOLDER | %TEMP%\sass_vol\yarn |
+----------------------+-------------------------+
| CARGO_TARGET_DIR | %TEMP%\sass_vol\ct |
+----------------------+-------------------------+
| CARGO_HOME | %TEMP%\sass_vol\ch |
+----------------------+-------------------------+
| PIP_CACHE_DIR | %TEMP%\sass_vol\pip |
+----------------------+-------------------------+
| TEMP / TMP | %TEMP%\sass_vol\tmp |
+----------------------+-------------------------+
Table 17
Directory creation uses Directory.CreateDirectory which handles the
full path hierarchy. The plugin sets both TEMP and TMP environment
variables (Windows convention) rather than the POSIX TMPDIR.
Chang Expires 19 December 2026 [Page 55]
Internet-Draft SASS Protocol June 2026
Appendix D. Platform-Aware Deployment Considerations
The EnvInjector plugin (Appendix C.7) performs environment variable
scrubbing to prevent PATH-based command injection by spawned agent
processes. On heterogeneous deployments, over-aggressive scrubbing
can cause cascading failures when OS-critical loader dependencies are
removed from the sanitized environment.
Implementations SHOULD define platform-specific preservation profiles
that exempt variables required for basic process execution:
+==========+===================+===================================+
| Platform | Preserved | Rationale |
| | Variables | |
+==========+===================+===================================+
| Windows | SYSTEMROOT, | Windows Loader requires System32 |
| | windir, | in PATH to locate |
| | USERPROFILE, | vcruntime140.dll and other MSVC |
| | APPDATA, | CRT dependencies. Scrubbing |
| | LOCALAPPDATA, and | these causes STATUS_DLL_NOT_FOUND |
| | the System32 | (Exit Code 1) and silent process |
| | component of PATH | termination. |
+----------+-------------------+-----------------------------------+
| Linux | /lib, /usr/lib | Prevents glibc and system shared |
| | components of | library resolution failures. |
| | LD_LIBRARY_PATH | |
| | (if set) | |
+----------+-------------------+-----------------------------------+
| macOS | DYLD_LIBRARY_PATH | Prevents dyld resolution failures |
| | (if set) | for system frameworks. |
+----------+-------------------+-----------------------------------+
Table 18
Additionally, implementations SHOULD statically link the C runtime
library for all helper binaries executed within SASS-managed
sessions:
* Rust: RUSTFLAGS="-C target-feature=+crt-static"
* Go: CGO_ENABLED=0
* C/C++: -static linker flag
Static linking eliminates dependency on the host environment's
dynamic library search path, making binaries resilient to EnvInjector
scrubbing regardless of the preservation profile in effect.
Chang Expires 19 December 2026 [Page 56]
Internet-Draft SASS Protocol June 2026
Appendix E. Version History
+=========+=========+===========================================+
| Version | Date | Changes |
+=========+=========+===========================================+
| v1.0 | 2026-02 | Initial gRPC protocol, ACL, Token auth |
+---------+---------+-------------------------------------------+
| v1.1 | 2026-03 | Active Threat Defense (13Policy, Tarpit, |
| | | ChaCha20 cognitive challenge) |
+---------+---------+-------------------------------------------+
| v1.2 | 2026-03 | ED25519 auth, Capability model, Session |
| | | mgmt, forward-secure audit |
+---------+---------+-------------------------------------------+
| v1.3 | 2026-05 | Control-Transport Decoupling, SAMM, TLS |
| | | Exporter, Zero-Alloc Tarpit, TOCTOU |
+---------+---------+-------------------------------------------+
| v1.4 | 2026-05 | Total Response Mapping, Safety Gradient, |
| | | Dual Standard, Transparent Branching, PTY |
| | | Ring Buffer, Version Dominance milestone |
+---------+---------+-------------------------------------------+
Table 19
Appendix F. Changes from draft-sakistudio-sass-00
This section summarizes the substantive changes introduced in draft-
sakistudio-sass-01 relative to draft-sakistudio-sass-00:
* Added C# Windows Service daemon reference implementation (windows-
daemon-csharp/) using .NET 8 Worker Service architecture with Rust
FFI interop for cryptographic operations. All seven Plugins are
implemented.
* Added Swift macOS Plugins client reference implementation
(SakiAgentSSH-Client/Sources/Plugins/) using Apple CryptoKit and
Network.framework. Four client-relevant Plugins are implemented
(ChaCha20, TLS Exporter, Audit, EnvInjector).
* Added Go daemon and client reference implementation (go-sakissh/)
with all seven Plugins using standard library crypto/
chacha20poly1305 and goroutine-based concurrency.
* Updated Appendix B (Reference Implementations) with a cross-
platform implementation matrix covering Rust, Go, C#, and Swift
implementations.
* Added C# Implementation Notes subsections to Appendix C Plugins:
Chang Expires 19 December 2026 [Page 57]
Internet-Draft SASS Protocol June 2026
- Plugin C.1 (ChaCha20): Rust FFI via P/Invoke with pinned Span
buffers.
- Plugin C.3 (Tarpit): ArrayPool<byte>.Shared zero-allocation
streaming.
- Plugin C.5 (Vi Swap): Windows ConHost ANSI VT processing
enablement with fallback for headless services.
- Plugin C.6 (Branch): NTFS Junction Point with symlink-to-
hardlink-to-copy three-level degradation strategy.
- Plugin C.7 (EnvInjector): %TEMP%\sass_vol\ Windows path
convention mapping.
Appendix G. Changes from draft-sakistudio-sass-01
This section summarizes the substantive changes introduced in draft-
sakistudio-sass-02 relative to draft-sakistudio-sass-01:
* Replaced Section 10.6 "Martingale Almost-Surely Superior (MAS)
Claim" with "Version Dominance Claim". The -01 formulation
referenced Martingale measure, Itô calculus, and risk-neutral
q-measure, none of which appeared in the actual definition (which
uses SSD). The -02 formulation defines the probability space,
adds the Branch Elimination Sufficiency condition, and cites the
original SSD literature (Rothschild-Stiglitz 1970, Hadar-Russell
1969) in addition to Aumann-Serrano 2008.
* Added references: [RS1970] (Rothschild and Stiglitz, 1970) and
[HR1969] (Hadar and Russell, 1969) for Second-order Stochastic
Dominance.
* Updated all occurrences of "MAS" terminology throughout the
document to "Version Dominance" for consistency with the revised
mathematical framework.
Appendix H. Changes from draft-sakistudio-sass-02
This section summarizes the substantive changes introduced in draft-
sakistudio-sass-03 relative to draft-sakistudio-sass-02:
* Added Appendix "Platform-Aware Deployment Considerations"
(Appendix D): platform-specific environment variable preservation
profiles for Windows (SYSTEMROOT, windir, System32 PATH), Linux
(LD_LIBRARY_PATH), and macOS (DYLD_LIBRARY_PATH). Motivated by a
production cascading failure where EnvInjector PATH scrubbing
caused STATUS_DLL_NOT_FOUND on a Windows x64 endpoint.
Chang Expires 19 December 2026 [Page 58]
Internet-Draft SASS Protocol June 2026
* Added static CRT linking recommendation (SHOULD-level) for all
helper binaries executed within SASS-managed sessions: Rust +crt-
static, Go CGO_ENABLED=0, C/C++ -static.
Appendix I. Changes from draft-sakistudio-sass-03
This section summarizes the substantive changes introduced in draft-
sakistudio-sass-04 relative to draft-sakistudio-sass-03:
* Added Yi-Chung Dzeng to the Acknowledgments section for direct
telecommunications cost assistance during the IETF review period.
Appendix J. Changes from draft-sakistudio-sass-04
This section summarizes the substantive changes introduced in draft-
sakistudio-sass-05 relative to draft-sakistudio-sass-04:
* Replaced SSD-based Version Dominance claim with pointwise loss
reduction framework (Section 10.6).
* Rewrote Cognitive Challenge mechanism description with O(1) gate
semantics and deterrence rationale (Section 8.2).
* Removed Abstract citations per RFC 7322.
* Moved RFC 8439 from Normative to Informative References.
* Removed experimental "x-" prefix from ALPN identifier per RFC
6648.
* Softened SSH deprecation to NOT RECOMMENDED per BCP 14 semantics.
* Corrected Rice's Theorem citation year to 1953.
* Added filesystem-only scope qualifier to R1 zero-loss claim.
* Changed Appendix A Protobuf schema from Normative to Informative.
* Prohibited TLS 1.3 0-RTT early data; corrected EKM scope
description.
* Removed IP-based session binding; replaced with cryptographic
session material binding.
* Added continuous credential verification for Dual Standard
Enforcement.
Chang Expires 19 December 2026 [Page 59]
Internet-Draft SASS Protocol June 2026
* Renamed Safety Gradient layers with institutional nomenclature
(Axiom-L0 through Scientia-L7) to distinguish from architectural
layers in Section 3.1.
* Unified serialization baseline to CBOR/JSON; removed MsgPack
reference.
* Added cipher suite property rationale for algorithm selection.
* Replaced fixed pattern count with coverage-based rule set
requirement.
* Replaced fixed 50ms timeout with configurable dynamic timeout
framework.
* Changed MIME type to application/vnd.sakistudio.grpc-sass per RFC
6838.
* Changed Tarpit payload size requirement from MUST to RECOMMENDED;
added payload composition description.
* Integrated ChaCha20-based pseudo-ICMP tarpit payload generator
into Go and Rust reference implementations.
Appendix K. Changes from draft-sakistudio-sass-05
* Protocol version identifier is v1.4 throughout (the canonical
protocol milestone; release and wire-ALPN versions are tracked on
separate axes).
* Removed TLS 1.0/SSL 3.0 analogy from Abstract and Section 1 (N-6).
* Fixed BCP 14 boilerplate: "capitalized" to "all capitals" (m-1).
* Replaced non-BCP14 "STRICTLY FORBIDDEN" with MUST NOT (M-1).
* Fixed Channel Binding label from implementation-defined to fixed
"EXPORTER-sass-channel-binding" with IANA registration (#28/B-1).
* Defined structured authentication signature input: session_id ||
agent_name || nonce || channel_binding (#29/B-2).
* Defined Ed25519 as MTI signing algorithm with algorithm_identifier
field (#26/B-3/B-5).
* Split TLS Exporter key/nonce derivation into two independent calls
with distinct labels (#30/B-4).
Chang Expires 19 December 2026 [Page 60]
Internet-Draft SASS Protocol June 2026
* Added Transport Profile minimum security properties
(confidentiality, integrity, authentication) (#31/M-3).
* Added explicit 0-RTT prohibition on SASS connections (#19).
* Added session_id CSPRNG requirement with >= 128 bits entropy (#33/
M-6).
* Renamed gRPC metadata header from x-agentssh-session-id to sass-
session-id (m-2).
* Clarified SAMM as normative abstract core vs Protobuf as mandatory
concrete profile (#18).
* Added Inference Proxy and Vendor Injection to terminology (#22).
* Added FABRICATED audit marking for LocalHost Defense responses
(#3/m-6).
* Changed Transparent Branching detectability from MUST NOT to
SHOULD minimize (#23/M-8).
* Clarified L7 Watchdog SIGKILL as operational safety valve, not
seventh response type (#16).
* Scoped R1 "zero loss" claim to filesystem integrity; acknowledged
non-filesystem side-effect limitations (#17).
* Deleted RawFileTransfer duplicate RPC definition (m-4).
* Expanded IANA section with complete registration templates for
ALPN, MIME, TCP port, and TLS Exporter Labels (#32/M-5).
* Added Key Management and Rotation subsection to Security
Considerations (#34/M-10).
* Added Tarpit Bandwidth Amplification discussion (#35/m-9).
* Added Pseudo-ICMP Payload Rationale subsection (M-7).
* Deleted "post-attention paradigm" paragraph from Privacy
Considerations (#11).
* Rewrote Version Dominance: pointwise as primary claim, SSD as
compact corollary, added R4 Vi Swap availability exception (#1).
* Abstracted CreateProcessW to "OS process creation API" (N-7).
Chang Expires 19 December 2026 [Page 61]
Internet-Draft SASS Protocol June 2026
* Fixed Section 1 title ampersand (N-8).
Appendix L. Changes from draft-sakistudio-sass-06
* Added Discussion section with The Impossibility Triangle
subsection: informal characterization of the fundamental tension
among User Task Expectation (U), Model Non-determinism Containment
(M), and Vendor Operational Necessity (V), with structural analogy
to CAP theorem and Rice's theorem application.
* Added Defense Boundary Disclosure subsection to Security
Considerations: explicit statement that SASS operates within its
transport channel only and does not provide host-level
containment.
* Revised 13Policy Engine (Section 8.1): explicitly labeled as
"rule-based pattern matching mechanism" rather than "heuristic
boundary adjudicator"; added substring matching evasion
disclosure; added trigger role clarification; added MUST for
three-tier adjudication.
* Revised Transparent Branching comparison table: changed
"Invisible" to "Minimized (*)" with TOCTOU race condition
disclosure and kernel-level future work note.
* Added advisory nature disclosure to Volatile Cache Redirection
(EnvInjector) appendix with cross-reference to Defense Boundary
Disclosure.
* Added Gilbert & Lynch (2002) CAP theorem reference for
Impossibility Triangle discussion.
Acknowledgments
This specification was developed with substantial assistance from
Claude Opus 4.6 (Anthropic). Claude assisted in designing the
protocol architecture, formalizing the Total Response Mapping and
Safety Gradient frameworks, developing the Version Dominance
theoretical basis, and co-developing the cross-platform reference
implementations in Rust, Go, C#, and Swift. Claude is listed in
Acknowledgments rather than as a named author due to IETF Datatracker
submission workflow constraints.
The author thanks Shan-Wen Shih for his unwavering support throughout
the development of this protocol.
The author thanks Yi-Chung Dzeng for direct telecommunications cost
assistance during the IETF review period.
Chang Expires 19 December 2026 [Page 62]
Internet-Draft SASS Protocol June 2026
Author's Address
Hua Chang
Saki Studio
4F.-5, No. 305, Jiankang Rd.
Taipei City, Songshan Dist., 105069
Taiwan, Province of China
Phone: +886-988-403-884
Email: Saki@saki-studio.com.tw
Chang Expires 19 December 2026 [Page 63]