SakiAgentSSH Secure Protocol 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/v5.0 (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.¶

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.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.1. Architecture

SASS separates the control plane and data transmission:¶

+----------------------------------------------------------+
| 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:¶

Every response R1 through R6 MUST satisfy the following invariants:¶

(*) 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.¶

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.¶

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]. Downgrades to TLS 1.2 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.¶

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 12. Implementations MUST NOT use implementation-defined labels for channel binding derivation.¶

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.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.¶

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:¶

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.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:¶

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.¶

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.¶

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.1. Boundary Adjudicator (13Policy Engine)

The 13Policy engine is a heuristic boundary adjudicator. It matches command strings against patterns in a configuration file and triggers the appropriate Response (R1~R6) based on severity.¶

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.¶

Each rule specifies:¶

• pattern: Glob pattern to match against command + args¶
• action: deny (triggers R4/R5), challenge (R2), allow (R1)¶
• severity: critical, high, medium, low¶
• description: Human-readable explanation¶

(*) 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.¶

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.¶
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:¶

• 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.4. LocalHost Defense

Unauthenticated connections originating from the loopback interface (127.0.0.1 / ::1) constitute a boundary violation via local IPC scraping.¶

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 10.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.¶
• 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.¶

10.1. Total Response Mapping Guarantee

The security model of SASS v5.0 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 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 10.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 10.3).¶

10.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

(*) Mitigated by cryptographic hash chain + external anchoring. An implementation MAY use ED25519 as described in Appendix C.4.¶

10.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.¶

An implementation MAY use ED25519 signatures with SHA256 hash chains as described in Appendix C.4.¶

10.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.¶

• 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).¶

10.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.¶

10.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.¶

10.7. Tarpit Bandwidth Amplification

The Tarpit defense mechanism (R5) streams up to 40 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 40 MiB = 1.28 GiB of outbound bandwidth under a coordinated attack.¶

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.¶

10.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.¶

10.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:¶

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/v5.0 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].¶

SSD is transitive: if V_3 dominates V_2 and V_2 dominates V_1, then V_3 dominates V_1.¶

11.1. SASS Privacy Requirements

SASS Daemons MUST NOT log Agent session content beyond what is required for the forward-secure audit trail (Section 10.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.¶

11.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.¶
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.¶

12.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¶

12.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 10 of this document¶

Published specification:

This document¶

Person and email address to contact for further information:

Hua Chang, Saki@saki-studio.com.tw¶

12.3. TCP Port Number

IANA is requested to register TCP port 19284 for the SASS protocol. This port number was selected from the Dynamic Ports range (49152-65535 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¶

12.4. TLS Exporter Labels

IANA is requested to register the following entries in the "TLS Exporter Labels" registry established by [RFC5705]:¶

B.1. Cross-Platform Implementation Matrix

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.¶

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.¶

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¶

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:¶

The remaining three Plugins (Tarpit, Vi Swap, Transparent Branching) are daemon-side mechanisms and are not required for client implementations.¶

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.¶
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.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)

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.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".¶

C.5. Vi Swap ANSI Escape Sequence

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

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.7. Volatile Cache Redirection