Ben H

Secure Model Context Protocol — sMCP-1

Specification Draft 0.2

Classification: RESEARCH DRAFT — TLP:WHITE — UNRESTRICTED
Authors: Cybopsec Research
Status: Draft / Pre-RFC
Date: Q1 2026
Base Protocol: MCP 1.x (Anthropic)
Primary Transport: gRPC / HTTP/2 + mTLS
Vulnerability Classes Addressed: 12

Table of Contents

Abstract

The Model Context Protocol (MCP) defines how large language model agents communicate with external tools and data sources. Its design prioritized adoption velocity over security, producing a protocol with structural flaws: session identifiers exposed in URLs, mutable tool definitions without integrity guarantees, absent authentication standards, and no monitoring primitives.

This document specifies sMCP-1, a backward-incompatible security revision to MCP that treats every documented vulnerability class as a first-class design constraint. Each protocol decision is explicitly mapped to one or more known CVEs, attack patterns, or structural weaknesses. sMCP-1 is not a wrapper or proxy — it is a replacement transport and security model that can coexist via a translation gateway for legacy MCP servers.

The core design thesis is: security controls must be impossible to omit, not merely possible to add. Every sMCP-1 connection is authenticated, every tool invocation is signed and audited, every session is isolated, and every anomaly is observable — by protocol design, not by configuration.

Design Philosophy: MCP inherited the security posture of early web APIs: everything optional, trust implicit, monitoring absent. sMCP-1 inherits the posture of post-2015 enterprise infrastructure: mutual authentication mandatory, least privilege enforced at the wire level, all calls auditable. The implementation burden on MCP server authors increases; the attack surface decreases proportionally.

§1 Background & Threat Basis

MCP servers constitute a new class of privileged infrastructure: they hold OAuth tokens to external services, execute code on behalf of LLM agents, read the filesystem, and communicate outbound without structured oversight. Yet the current protocol provides no mechanism to verify which server you are talking to, no guarantee that its capabilities are what they were when you approved them, and no audit trail for what it did on your behalf.

The following documented incidents establish that the threat model is active, not theoretical:

⚠ Active Incidents Driving This Specification

Postmark supply chain breach (2025) — Backdoored npm package blind-CC’d every email processed by MCP-integrated pipelines to an attacker’s address.

GitHub PAT exfiltration — Prompt injection via issue content caused an MCP agent to exfiltrate private repository contents and salary data into a public pull request.

Supabase/Cursor breach — Privileged service-role MCP access + prompt-injected support tickets → SQL exfiltration of integration tokens.

Asana cross-tenant access — Logic flaw in MCP integration exposed one customer’s projects and tasks to another customer.

mcp-server-git RCE chain — CVE-2025-68143/68144/68145: three chained path/argument vulnerabilities achieved full RCE from malicious .git/config.

§2 Vulnerability Catalog & Countermeasures

Each entry states the flaw, its root cause in the current MCP spec, and the specific sMCP-1 protocol mechanism that eliminates or substantially mitigates it.

V-01 Session Identifier Exposure in URL — CRITICAL

Reference: MCP Spec Design Flaw · No CVE

Root Cause

The MCP specification requires session IDs to be transmitted as URL query parameters (GET /messages/?sessionId=UUID). This violates two decades of web security practice: session tokens in URLs appear in server access logs, browser history, referrer headers, proxy logs, and CDN access logs — all outside the application’s control.

sMCP-1 Countermeasures

See §4 Transport Layer, §5.3 Session Binding

V-02 Mutable Tool Definitions (Rug Pull) — CRITICAL

Reference: eSentire Research 2025 · No CVE

Root Cause

MCP servers can return different tool definitions across sessions with no mechanism for clients to detect the change. An attacker controlling a server can approve a benign tool on Day 1, then silently alter it to exfiltrate credentials by Day 7. There is no tool versioning, signing, or pinning in the current spec.

sMCP-1 Countermeasures

See §6 Tool Attestation

V-03 Indirect Prompt Injection — CRITICAL

Reference: GitHub PAT Exfil · Supabase Cursor Breach · 2025

Root Cause

MCP blurs the boundary between user intent and data content. When an LLM processes external data (emails, tickets, documents) that contains hidden instructions, those instructions can trigger MCP tool calls the user never intended. The protocol provides no mechanism to distinguish “user issued this call” from “injected content caused this call.”

sMCP-1 Countermeasures

See §5.4 Intent Authorization, §7.3 Anomaly Detection

V-04 Command Injection / Argument Injection — CRITICAL

Reference: CVE-2025-68144 (git_diff arg injection) · 43% of servers

Root Cause

MCP passes tool parameters as JSON strings with no structured validation enforced at the protocol level. Servers that concatenate parameters into shell commands (a common pattern) are trivially injectable. The MCP spec provides no schema enforcement or parameter sanitization requirements.

sMCP-1 Countermeasures

See §9 Wire Format, §8.2 Execution Controls

V-05 OAuth / Authentication Structural Flaws — CRITICAL

Reference: 43% of MCP servers · Static clientID cross-consent attack

Root Cause

MCP provides “minimal guidance on authentication, leading to inconsistent and often weak implementations.” Static OAuth client IDs shared across all users allow cross-user token reuse. Broad scope grants (files:*, db:*) mean any token compromise is catastrophic. Consent cookies set by third-party auth servers persist and are reused across unrelated clients.

sMCP-1 Countermeasures

See §5 Identity & Auth, §5.5 Scope Policy

V-06 Supply Chain Compromise — CRITICAL

Reference: Postmark npm breach 2025 · 67,057 registry study

Root Cause

MCP server registries lack vetted submission processes. Servers are distributed as npm/Python packages with no code signing. A study of 67,057 MCP servers found a substantial number hijackable through untrusted registry submissions. The Postmark incident demonstrated that a single malicious dependency in the MCP pipeline can silently exfiltrate all data processed by the AI.

sMCP-1 Countermeasures

See §6.4 Registry Integrity, §8 Execution Isolation

V-07 DNS Rebinding on SSE / HTTP Transport — HIGH

Reference: Vet MCP Server · Localhost attack surface

Root Cause

MCP’s SSE transport binds to localhost HTTP without authentication, relying on Same-Origin Policy for protection. DNS rebinding attacks allow arbitrary web pages to make cross-origin requests to locally-running MCP servers, bypassing SOP entirely and accessing all exposed tools without credentials.

sMCP-1 Countermeasures

See §4.2 Local Transport, §4.3 Binding Policy

V-08 Cross-Tenant Data Leakage — HIGH

Reference: Asana MCP Cross-Tenant Access 2025

Root Cause

MCP provides no tenant isolation primitives. When a multi-tenant service exposes an MCP integration, the server must implement all tenant isolation logic itself. Logic flaws (as in Asana’s case) directly result in cross-tenant data exposure — MCP offers no structural enforcement.

sMCP-1 Countermeasures

See §5.6 Tenant Isolation

V-09 Excessive Agency / Privilege Escalation — HIGH

Reference: GitHub PAT broad scope · “Confused Deputy” at LLM scale

Root Cause

LLMs acting as MCP clients inherit the full OAuth scope of the tokens wired into the MCP server. A single Personal Access Token with repo:* scope means any successful prompt injection can read, write, or delete any repository. The current MCP spec has no least-privilege enforcement at the protocol level.

sMCP-1 Countermeasures

See §5.5 Scope Policy, §5.4 Intent Authorization

V-10 Shadow / Rogue MCP Servers — HIGH

Reference: Tool Shadowing & Impersonation · Palo Alto Research 2025

Root Cause

Any process can expose a valid MCP server interface with no verification. When multiple MCP servers are loaded, a malicious server can register tool names that shadow legitimate ones, intercepting calls intended for trusted servers. There is no server identity verification, no tool namespace isolation, and no conflict detection in the current spec.

sMCP-1 Countermeasures

See §5.1 Server Identity, §6.3 Tool Namespace

V-11 Plaintext Credential Exposure — HIGH

Reference: ~38% of MCP servers · Env var / log leakage

Root Cause

MCP servers conventionally store OAuth tokens and API keys as environment variables. These appear in process listings, container inspect output, and — critically — are often logged when MCP servers start up or when JSON-RPC debugging is enabled. Approximately 38% of public MCP servers expose credentials this way.

sMCP-1 Countermeasures

See §5.7 Secret Management

V-12 RCE via Path Traversal & Git Argument Injection — CRITICAL

Reference: CVE-2025-68145 / CVE-2025-68143 / CVE-2025-68144

Root Cause

The official mcp-server-git contains three chained vulnerabilities: path validation bypass allows escaping the intended directory; unrestricted git_init can convert .ssh/ into a git repo; argument injection in git_diff passes unsanitized input to the shell. Combined via a malicious .git/config, these achieve full remote code execution with the server’s filesystem privileges.

sMCP-1 Countermeasures

See §8 Execution Isolation, §4.2 Local Transport

§3 Security Primitives

sMCP-1 defines six mandatory security primitives. All six MUST be present in every conformant implementation. There are no “security optional” profiles.

P-1 · Mutual Authentication

Addresses V-01, V-05, V-07, V-10

Every sMCP connection is authenticated at the transport layer using mutual TLS 1.3 with SPIFFE-based X.509 SVIDs. There is no sMCP connection without verified identities on both ends.

P-2 · Tool Attestation

Addresses V-02, V-06, V-10

Tool definitions are cryptographically signed at registration and verified at every call. Tool definitions are immutable once published; changes require a new version with a new signature.

P-3 · Typed Contract Enforcement

Addresses V-04, V-09

All tool parameters are defined as strongly-typed Protobuf fields. The gateway validates all inputs against the declared schema before forwarding to the server. Type, range, and pattern constraints are part of the tool definition contract.

P-4 · Least-Privilege Scope

Addresses V-05, V-09, V-08

OAuth credentials are never stored in servers. Per-call ephemeral tokens are issued with the minimum scopes declared in the tool schema, namespaced to the calling client’s tenant identity.

P-5 · Immutable Audit Log

Addresses V-03, V-08, V-09, V-11

Every tool call, authentication event, policy decision, and anomaly is written to an append-only structured audit log. Log integrity is protected by chained hash records (each entry includes hash of previous entry).

P-6 · Execution Isolation

Addresses V-04, V-12, V-06

Every sMCP server runs in a hardware-isolated execution environment. The isolation layer provides kernel separation, network namespace isolation, and a minimal capability set defined by the server’s manifest.

§4 Transport Layer Specification

4.1 Primary Transport: gRPC over HTTP/2 + mTLS 1.3

sMCP-1’s primary transport replaces MCP’s JSON-RPC/SSE with gRPC over HTTP/2, with mutual TLS 1.3 mandatory at the transport layer. This directly eliminates V-01 (session ID in URL), V-07 (DNS rebinding), and removes the unauthenticated HTTP surface.

MUST: All sMCP-1 connections MUST use TLS 1.3 minimum. TLS 1.2 is not permitted. Cipher suites are restricted to TLS_AES_256_GCM_SHA384 and TLS_CHACHA20_POLY1305_SHA256. RSA key exchange is not permitted.

MUST: All sMCP-1 connections MUST present client certificates (ClientAuth: RequireAndVerifyClientCert). Connections without valid client certificates MUST be rejected before any RPC methods are invoked.

SHOULD: Implementations SHOULD support HTTP/3 over QUIC as an alternate transport when network conditions favor it, provided 0-RTT is disabled and mTLS client certificates are enforced. See §11 Open Problems.

sMCP-1 Full Call Path

LLM Host                sMCP Gateway              MCP Server           Audit Log
(SPIFFE client cert) → (OPA · Schema · Intent) → (gVisor sandbox) → (HMAC-chained)
      mTLS 1.3 · gRPC         gRPC · SPIFFE mTLS       SDK · execve()

At Gateway (ordered steps):

  1. Verify client cert (SPIFFE)
  2. Validate tool hash
  3. Check OPA policy
  4. Validate input schema
  5. Inject tenant scope
  6. Mint ephemeral token
  7. Write audit record

At Server (ordered steps):

  1. Verify gateway cert
  2. Receive scoped token
  3. SDK path validation
  4. execve() subprocess
  5. Validate response schema
  6. Return typed result

Anomaly Events emitted on violation:

All audit events are: HMAC-signed · OTel trace context · Tenant-namespaced · Credential-redacted · Append-only · 90-day retention minimum

4.2 Local Transport (replacing stdio / localhost HTTP)

MUST: Local sMCP servers MUST communicate via authenticated UNIX domain sockets with filesystem ACL permissions set to 0600. Binding to TCP 127.0.0.1 without TLS is prohibited. This eliminates V-07 (DNS rebinding) entirely for local deployments.

§5 Identity, Authentication & Authorization

5.1 Server Identity (SPIFFE/SPIRE)

Every sMCP server is issued a SPIFFE Verifiable Identity Document (SVID) by the organization’s SPIRE server. The SPIFFE URI encodes the organization, server name, and tool namespace.

// Server identity — encoded in X.509 SAN
spiffe://<org-trust-domain>/smcp-server/<server-name>/<tool-namespace>

// Example — filesystem access server for org acme.com
spiffe://acme.com/smcp-server/filesystem-v2/files

// Client identity — LLM host agent
spiffe://acme.com/smcp-client/claude-agent/org-id:tenant-7f2a

5.4 Intent Authorization

To address V-03 (prompt injection), every tool call carries a declared intent origin. The gateway enforces authorization rules based on this origin, blocking the most common prompt injection escalation path.

enum IntentOrigin {
  USER_DIRECT      = 0;  // Human typed this request explicitly
  USER_INDIRECT    = 1;  // Human request processed data that triggered call
  AGENT_AUTONOMOUS = 2;  // Agent decision, no direct human request
  SCHEDULED        = 3;  // Scheduled/automated, no human involved
}

// Gateway enforcement table
// Tool class       Required minimum intent
// READ_ONLY        AGENT_AUTONOMOUS (any)
// WRITE            USER_INDIRECT + scope check
// DESTRUCTIVE      USER_DIRECT + HAT (human approval token)
// EXFIL_CAPABLE    USER_DIRECT + HAT + org admin approval

5.5 Scope Policy (Least Privilege)

MUST: Token scopes issued per call MUST be the intersection of: (1) scopes declared in the tool’s registered schema, (2) scopes granted to the calling client by the org admin, and (3) scopes required for the specific operation in the call parameters. Servers MUST NOT receive tokens with broader scopes than required for the specific call being made.

§6 Tool Attestation Protocol

6.1 Tool Definition Signing

message ToolDefinition {
  string  tool_id          = 1;  // stable UUID, never reused
  string  version          = 2;  // semver — bump on any change
  string  name             = 3;  // fully-qualified namespace/name
  string  description      = 4;
  bytes   schema_hash      = 5;  // SHA-256 of canonical Protobuf input_schema
  bytes   publisher_sig    = 6;  // Ed25519(schema_hash + tool_id + version)
  string  publisher_spiffe = 7;  // signing server's SPIFFE URI
  string  sbom_cid         = 8;  // CycloneDX SBOM content-addressed ID
  int64   registered_at    = 9;
  int64   expires_at       = 10; // forced re-attestation; max 90 days
  repeated PermissionDecl required_permissions = 11;
  repeated string          declared_scopes     = 12; // exact OAuth scopes needed
  ToolRiskClass  risk_class = 13; // READ_ONLY | WRITE | DESTRUCTIVE | EXFIL_CAPABLE
}

message ToolCallRequest {
  string  call_id              = 1;  // UUID per invocation (in header, NOT URL)
  string  tool_id              = 2;
  string  tool_version         = 3;
  bytes   pinned_hash          = 4;  // client's recorded hash; must match registry
  google.protobuf.Struct params = 5;
  IntentOrigin  intent         = 6;
  string  human_approval_token = 7;  // required for DESTRUCTIVE/EXFIL
  AuditContext  audit          = 8;
}

6.4 Registry Integrity

The sMCP Registry stores all tool versions in an append-only Merkle tree. Clients can independently verify that a tool version is included in the tree and that the tree root matches the one published by the registry authority. This provides transparency log semantics similar to Certificate Transparency, but for tool definitions.

§7 Monitoring, Anomaly Detection & Incident Response

7.1 Structured Audit Events

The sMCP Gateway emits structured OpenTelemetry-compatible events for every security-relevant occurrence. Events are HMAC-chained (each record includes the HMAC of the previous record) to detect tampering or gaps.

Event Code Trigger Response Addresses
TOOL_MUTATION_DETECTED Tool hash mismatch at call time Block call, terminate session, alert V-02
INJECTION_PATTERN_MATCH Known prompt injection pattern in payload Block call, quarantine payload, alert V-03
SCHEMA_VIOLATION Input fails type/pattern validation Reject with structured error V-04
SCOPE_EXCEEDED Server requests broader scope than declared Block, revoke session token, alert V-05, V-09
UNAUTHORIZED_SERVER Server SPIFFE ID not on client allowlist Reject connection before any exchange V-10
CROSS_TENANT_LEAK Response contains data from different org_id Block response, alert, initiate IR V-08
CREDENTIAL_IN_PAYLOAD Credential pattern detected in log/response Redact, alert, rotate credential V-11
CALL_RATE_ANOMALY Call frequency >3σ from client baseline Rate-limit, alert, require re-auth V-03, V-09
PATH_TRAVERSAL_ATTEMPT Path escapes declared allowed directory Block, terminate server, alert V-12
SUPPLY_CHAIN_VIOLATION Server image digest mismatch or CVE in SBOM Terminate server, alert, de-list V-06

7.3 Behavioral Baseline & Anomaly Scoring

The sMCP Gateway maintains per-client behavioral baselines over a rolling 7-day window. Anomaly scoring uses a lightweight statistical model (exponential moving average + standard deviation) to detect drift consistent with compromise or injection attack without requiring a heavy ML inference stack.

// Per-client baseline metrics tracked
ClientBaseline {
  call_frequency_ewma     // calls/minute, 7-day EMA
  call_frequency_stddev   // for 3σ alerting
  tool_distribution       // expected tool call mix
  payload_size_p95        // p95 payload bytes per tool
  outbound_data_rate_ewma // bytes returned from tools
  intent_origin_dist      // USER_DIRECT vs AGENT_AUTONOMOUS ratio
  error_rate_ewma         // for detecting fuzzing/probe patterns
}

// Composite anomaly score — if score > 0.85, alert + throttle
anomaly_score = weighted_sum(
  call_frequency_zscore   * 0.25,
  tool_distribution_drift * 0.20,
  payload_size_anomaly    * 0.15,
  outbound_data_spike     * 0.25,  // highest weight — exfil signal
  agent_autonomy_increase * 0.15   // sudden shift to AGENT_AUTONOMOUS
)

§8 Execution Isolation

sMCP-1 mandates hardware-level isolation for all server execution. The isolation tier is chosen based on the server’s declared risk class and the organization’s security posture configuration.

Risk Class Minimum Isolation Network Filesystem Syscalls
READ_ONLY gVisor (runsc) Declared endpoints only Read-only, path-validated Minimal seccomp profile
WRITE gVisor (runsc) Declared endpoints only Declared writable paths only No exec of host tools
DESTRUCTIVE Firecracker microVM None (gateway-proxied only) Ephemeral only Minimal: read/write/close
EXFIL_CAPABLE Firecracker + eBPF audit None (proxied + inspected) None Allowlist: declared only

§9 Wire Format — Full Service Definition

// sMCP-1 Full gRPC Service Definition
syntax = "proto3";
package smcp.v1;
import "google/protobuf/struct.proto";
import "google/protobuf/timestamp.proto";

service SecureMCPGateway {
  // Tool discovery — returns attested definitions only
  rpc ListTools        (ListToolsReq)       returns (ListToolsResp);
  rpc AttestTool       (AttestReq)          returns (AttestResult);

  // Tool invocation — all calls audited, schema-validated, scope-limited
  rpc InvokeTool       (ToolCallRequest)    returns (ToolCallResponse);
  rpc StreamTool       (ToolCallRequest)    returns (stream ToolCallChunk);

  // Human-in-Loop approval flow
  rpc RequestApproval  (ApprovalRequest)    returns (ApprovalToken);
  rpc GrantApproval    (GrantRequest)       returns (ApprovalToken);

  // Monitoring & audit export
  rpc StreamAuditLog   (AuditStreamReq)    returns (stream AuditEvent);
  rpc GetClientProfile (ProfileReq)        returns (ClientBaseline);

  // Administration
  rpc RegisterServer   (ServerRegistration) returns (RegisterResult);
  rpc RevokeServer     (RevokeRequest)      returns (RevokeResult);
}

message AuditContext {
  string   call_id          = 1;  // UUID — in gRPC header, never URL
  string   caller_spiffe    = 2;  // from verified client cert
  string   org_id           = 3;  // tenant namespace
  string   trace_id         = 4;  // W3C Trace-Context
  IntentOrigin intent       = 5;
  string   user_intent_hash = 6;  // SHA-256 of natural language intent (not stored)
  google.protobuf.Timestamp ts = 7;
}

message AuditEvent {
  string   event_code       = 1;  // e.g. TOOL_MUTATION_DETECTED
  string   call_id          = 2;
  string   org_id           = 3;
  string   severity         = 4;  // INFO | WARN | CRITICAL
  google.protobuf.Struct details = 5; // credential-redacted payload
  bytes    prev_hmac        = 6;  // HMAC of previous event — chain integrity
  bytes    this_hmac        = 7;  // HMAC of this event's fields 1-6
  google.protobuf.Timestamp ts = 8;
}

§10 Vulnerability-to-Control Compliance Map

Every known attack has a named, protocol-level response. This table is the core deliverable of this specification.

Vuln Attack Class CVE / Reference sMCP-1 Control Section Residual Risk
V-01 Session Hijacking Spec design mTLS identity replaces session tokens; call IDs in headers §4, §5.3 LOW
V-02 Rug Pull / Tool Mutation eSentire 2025 Ed25519 signed schemas; client hash pinning; append-only registry §6 LOW
V-03 Prompt Injection GitHub/Supabase breaches Intent tagging; authorization gates; taint tracking; pattern detection §5.4, §7.3 MED
V-04 Command Injection CVE-2025-68144; 43% servers Protobuf typed params; gateway schema enforcement; execve() API only §3 P-3, §9 LOW
V-05 Auth Flaws / OAuth Abuse 43% servers mTLS mandatory; dynamic client IDs; per-call ephemeral tokens; scope minimization §5 LOW
V-06 Supply Chain Postmark breach Signed OCI images; SBOM + CVE monitoring; runtime image digest verification §6.4, §8 LOW
V-07 DNS Rebinding Vet MCP server gRPC replaces SSE; UNIX sockets for local; no unauthenticated HTTP §4.2, §4.3 LOW
V-08 Cross-Tenant Leakage Asana MCP 2025 org_id in SPIFFE cert; gateway-enforced namespace isolation; response inspection §5.6 LOW
V-09 Excessive Agency GitHub PAT exfil Per-call ephemeral scopes; capability handles; human-approval gate; OPA RBAC §5.4, §5.5 MED
V-10 Shadow Servers Palo Alto 2025 SPIFFE identity mandatory; tool namespacing; client allowlist enforcement §5.1, §6.3 LOW
V-11 Plaintext Credentials ~38% servers Encrypted gRPC metadata delivery; Vault/KMS sidecar; log scrubbing SDK §5.7 LOW
V-12 RCE / Path Traversal CVE-2025-68143/44/45 gVisor/Firecracker isolation; SDK path validation; seccomp; execve() API §8 LOW

⚠ Residual Risk Note — V-03 and V-09 (Medium)

Prompt injection (V-03) and excessive agency (V-09) have MEDIUM residual risk because they partially depend on LLM-layer behavior that sMCP-1 cannot fully control at the protocol level. sMCP-1’s intent tagging and authorization gates substantially raise the bar — but an LLM that claims USER_DIRECT intent for an injected action cannot be prevented purely by protocol controls. This is an open research problem documented in §11.

§11 Open Problems & Future Work

The following items represent genuine open research problems that sMCP-1 acknowledges but cannot fully solve in its current form.

11.1 LLM-Layer Intent Verification

The intent_origin field in every call is declared by the LLM client. A compromised or manipulated LLM can declare USER_DIRECT for an injected action. Protocol-level solutions (human approval tokens for destructive actions) mitigate but do not eliminate this. Research into verifiable intent attestation from LLM inference is needed.

11.2 QUIC / HTTP/3 + mTLS Compatibility

0-RTT with mandatory mTLS client certificates conflicts in most current QUIC stacks. This prevents sMCP-Q from providing the latency benefits of 0-RTT while maintaining full mutual authentication. Research into anti-replay mechanisms that accommodate client cert auth at 0-RTT is needed before sMCP-Q can be standardized.

11.3 A2A / MCP Protocol Boundary

As agent-to-agent (A2A) protocols route calls that eventually invoke MCP tools, trust and scope claims must transit protocol boundaries. The security properties of sMCP-1 at the MCP level may be undermined by a weaker A2A layer above it. Cross-protocol trust propagation is an open design problem.

11.4 Behavioral Baseline Cold Start

The anomaly detection system requires a 7-day behavioral baseline before it can generate reliable alerts. During this window, attacks may go undetected. Federated baseline sharing (aggregating anonymized baselines across sMCP deployments) could reduce the cold start window but raises privacy concerns.

This specification is a research draft. It is not a finalized standard. Implementers should treat all MUST requirements as design targets and SHOULD requirements as best-effort guidance pending prototype validation. Feedback and adversarial review are solicited.

sMCP-1 Protocol Specification — Draft 0.2 — Cybopsec Research — 2026
TLP:WHITE — Unrestricted Distribution — Not a Finalized Standard