Model Context Protocol
Replies: 4 comments 1 reply
-
|
NOTE: Some of the functionality in this RFC is demonstrably desired per the following discussions:
I have created a repository which has the necessary SDKs in order to easily retrofit SMCP around existing MCP tooling: https://github.com/100monkeys-ai/secure-model-context-protocol |
Beta Was this translation helpful? Give feedback.
-
|
Very nice proposal. My compliments. A small suggestion...RE: this use of wildcards in the tool_pattern 5.2.1. Capability Fields tool_pattern (string, REQUIRED) Suggestion: Consider specifying (perhaps optional) use of a standardized filtering syntax. The one I'm personally familiar with is RFC-1960 from OSGi service platform, but there are probably others more recently specified. It also (IMHO) fits with the json name -> value (properties) structure nicely for filtering at the group level. |
Beta Was this translation helpful? Give feedback.
-
|
@scottslewis Thank you for the feedback fellow Portlandian. :) |
Beta Was this translation helpful? Give feedback.
-
|
Great proposal addressing several security gaps. following for updates |
Beta Was this translation helpful? Give feedback.
-
|
This was a fun read. I have a few high level questions: How is the security scope decided? It feels underspecified and like this is a major concern / weakpoint. How you know who to trust if you use code signing, etc.? Are you using something like Sigstore or in-toto for this? Why JWT? An hour of exposure is a pretty large amount in practice, etc. Is this because it's in the IETF and you want to use it for that reason? Thanks! |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Pre-submission Checklist
Your Idea
RFC: Secure Model Context Protocol (SMCP) v1.0
Network Working Group
Request for Comments: TBD
Category: Standards Track
Abstract
This document specifies the Secure Model Context Protocol (SMCP), an extension to the Model Context Protocol (MCP) that adds cryptographic authentication, authorization, and integrity protection for AI agent-tool interactions. SMCP addresses critical security vulnerabilities in autonomous AI systems, specifically the "Confused Deputy" problem, lack of non-repudiation, and insufficient authorization granularity.
SMCP introduces a Security Envelope pattern that wraps standard MCP JSON-RPC messages with cryptographic signatures and authorization tokens. This extension maintains backward compatibility with existing MCP tool servers while enabling fine-grained, per-request security policy enforcement.
The protocol is designed for zero-trust environments where AI agents may be compromised through prompt injection or code vulnerabilities, yet must be prevented from misusing their assigned tools.
Status of This Memo
This document specifies a proposed standard protocol for the Internet community and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) 2026. This document may be reproduced and distributed in accordance with open standards practices.
Table of Contents
1.1. Motivation
1.2. Requirements Notation
1.3. Terminology
2.1. Confused Deputy Attack
2.2. Prompt Injection
2.3. Tool Server Impersonation
2.4. Security Objectives
3.1. Component Roles
3.2. Trust Model
3.3. Protocol Layers
4.1. Security Envelope Structure
4.2. Security Token (JWT)
4.3. Signature Format
5.1. Security Scope
5.2. Capability Definition
5.3. Policy Evaluation Semantics
6.1. Handshake Flow
6.2. Identity Verification
6.3. Token Issuance
7.1. Signature Algorithm (Ed25519)
7.2. Token Format (JWT)
7.3. Canonical Message Construction
7.4. Key Management
8.1. Error Codes
8.2. Error Response Format
9.1. Replay Attack Prevention
9.2. Man-in-the-Middle Protection
9.3. Key Compromise
9.4. Token Theft
9.5. Rate Limiting
9.6. Audit Trail
10.1. Protocol Negotiation
10.2. Legacy Client Support
10.3. Migration Strategy
11.1. Test Vectors
11.2. Compliance Requirements
12.1. Protocol Identifier Registry
12.2. Error Code Registry
12.3. JWT Claim Names Registry
12.4. Security Scope Registry
13.1. Normative References
13.2. Informative References
Appendix A: Security Scope Examples
Appendix B: Implementation Guidelines
Appendix C: Test Vectors
Appendix D: Compliance Mapping
1. Introduction
1.1. Motivation
The Model Context Protocol (MCP), introduced by Anthropic in 2024, has become the de facto standard for AI agent-tool integration. As of February 2026, MCP is widely adopted by major technology companies and open-source projects for enabling Large Language Models (LLMs) to interact with external tools, APIs, and data sources.
However, MCP was designed primarily for functionality rather than security. The protocol provides:
But lacks critical security primitives:
This gap creates significant security risks in autonomous AI systems, particularly when:
SMCP addresses these gaps by extending MCP with a Security Envelope pattern that adds cryptographic authentication, fine-grained authorization, and integrity protection while maintaining compatibility with existing MCP tool servers.
1.2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
1.3. Terminology
This specification uses the following terms:
2. Threat Model
This section describes the security threats that SMCP is designed to mitigate.
2.1. Confused Deputy Attack
Definition: A confused deputy attack occurs when a privileged system is tricked into misusing its authority on behalf of an attacker.
Scenario in MCP Context:
SMCP Mitigation: The agent's Security Scope does not include "fs.delete" capability, so the Gateway rejects the request before it reaches the tool server.
2.2. Prompt Injection
Definition: An attack where malicious content in user input causes an LLM to generate unintended actions.
Attack Vector: Untrusted content (web pages, documents, API responses) can contain instructions that override the agent's original task.
SMCP Mitigation: Even if prompt injection succeeds in changing agent behavior, the agent cannot escape its cryptographically signed Security Scope. A "read-only-research" agent cannot suddenly perform write operations.
2.3. Tool Server Impersonation
Definition: An attacker replaces a legitimate MCP tool server with a malicious one to intercept or manipulate requests.
Attack Vector: Compromised deployment pipeline, man-in-the-middle attack, or insider threat.
SMCP Mitigation: While not fully addressed in v1.0, SMCP's Security Envelope provides integrity protection. Future versions will include tool server attestation via code signing or hardware-backed provenance.
2.4. Security Objectives
SMCP aims to achieve the following security properties:
3. Protocol Architecture
3.1. Component Roles
SMCP defines three primary components:
3.1.1. Client (AI Agent)
Responsibilities:
Trust Level: UNTRUSTED (may be compromised via prompt injection or code vulnerabilities)
3.1.2. Gateway (Policy Enforcement Point)
Responsibilities:
Trust Level: TRUSTED (protected by infrastructure isolation and hardening)
3.1.3. Tool Server (MCP Provider)
Responsibilities:
Trust Level: VARIES (may be first-party or third-party)
Note: Tool servers have NO awareness of SMCP. They receive unwrapped, standard MCP messages.
3.2. Trust Model
SMCP operates on the following trust assumptions:
3.3. Protocol Layers
SMCP adds a security layer around standard MCP:
┌──────────────────────────────────────────────────────────┐ │ Application Layer (AI Agent Logic) │ └──────────────────────────────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────────────┐ │ SMCP Layer (Security Envelope + Signature) │ ← NEW └──────────────────────────────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────────────┐ │ MCP Layer (Standard JSON-RPC Tool Calls) │ └──────────────────────────────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────────────┐ │ Transport Layer (HTTPS, WebSocket, gRPC) │ └──────────────────────────────────────────────────────────┘4. Message Formats
4.1. Security Envelope Structure
All SMCP messages MUST use the following JSON structure:
{ "protocol": "smcp/v1", "security_token": "<JWT_STRING>", "signature": "<BASE64_SIGNATURE>", "payload": { // Standard MCP JSON-RPC message (UNCHANGED) }, "timestamp": "<ISO8601_UTC>" }4.1.1. Field Definitions
protocol(string, REQUIRED)"smcp/v1"for this specificationsecurity_token(string, REQUIRED)signature(string, REQUIRED)payload(object, REQUIRED)tools/call,tools/list,resources/readtimestamp(string, REQUIRED)YYYY-MM-DDTHH:MM:SS.sssZ4.1.2. Example: Tool Call Request
{ "protocol": "smcp/v1", "security_token": "eyJhbGciOiJFZERTQSIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJhZ2VudC04YTlmN2IiLCJzY3AiOiJyZWFkLW9ubHktcmVzZWFyY2giLCJ3aWQiOiJkb2NrZXI6Ly84YTlmN2IzYyIsImlhdCI6MTcwODI2MTkyMSwiZXhwIjoxNzA4MjY1NTIxfQ.signature_here", "signature": "3k9j2lV8d+QpL7mN1wR/xY4zP0aB6sC8tE2uF9gH5iJ3kK7lM4nO0pQ1rS9tU0vW", "payload": { "jsonrpc": "2.0", "id": "req-a1b2c3d4", "method": "tools/call", "params": { "name": "fs.read", "arguments": { "path": "/workspace/data.csv" } } }, "timestamp": "2026-02-17T14:32:01.583Z" }4.2. Security Token (JWT)
The Security Token is a JSON Web Token (JWT) as defined in RFC 7519.
4.2.1. JWT Header
{ "alg": "EdDSA", "typ": "JWT" }algMUST be"EdDSA"(Ed25519 signature algorithm)typMUST be"JWT"4.2.2. JWT Claims
The following claims MUST be present:
Standard Claims (RFC 7519):
sub(Subject): Client identifier (unique string, e.g., UUID)iat(Issued At): Unix timestamp when token was issuedexp(Expires): Unix timestamp when token expiresSMCP-Specific Claims:
scp(Security Scope): Name of the assigned Security Scope (see Section 5.1)wid(Workload Identity): Verifiable identifier for the execution environment (e.g., container ID)Optional Claims:
jti(JWT ID): Unique identifier for this token (for revocation tracking)aud(Audience): Intended recipient (e.g., gateway hostname)iss(Issuer): Gateway identifier4.2.3. Example JWT Claims
{ "sub": "agent-8a9f7b3c", "scp": "read-only-research", "wid": "docker://8a9f7b3c-4d5e-6f7g-8h9i-0j1k2l3m4n5o", "iat": 1708261921, "exp": 1708265521, "jti": "session-9d8f2e1c", "aud": "gateway.example.com", "iss": "smcp-gateway" }4.2.4. Token Expiration
exp <= iat + 3600)4.3. Signature Format
Signatures MUST be computed using the Ed25519 algorithm as defined in RFC 8032.
4.3.1. Signature Algorithm
4.3.2. Signed Message
The signature MUST be computed over the canonical representation of:
canonical_message = { "security_token": "<JWT_STRING>", "payload": <MCP_PAYLOAD_OBJECT>, "timestamp": <UNIX_TIMESTAMP_INTEGER> }Canonicalization MUST follow:
See Section 7.3 for detailed algorithm.
5. Authorization Model
SMCP implements a capability-based authorization model with deny-by-default semantics.
5.1. Security Scope
A Security Scope is a named permission boundary that defines what operations a client may perform.
5.1.1. Scope Structure
{ "name": "string", "description": "string", "capabilities": [ { "tool_pattern": "string", "constraints": { "path_allowlist": ["string"], "command_allowlist": ["string"], "domain_allowlist": ["string"], "rate_limit": { "calls": integer, "per_seconds": integer }, "max_response_size": integer } } ], "deny_list": ["string"] }5.1.2. Field Definitions
name(string, REQUIRED)^[a-z][a-z0-9-]*$(lowercase, hyphens allowed)"read-only-research","code-assistant"description(string, REQUIRED)capabilities(array, REQUIRED)deny_list(array, OPTIONAL)5.2. Capability Definition
A Capability grants permission to use a tool, optionally with constraints.
5.2.1. Capability Fields
tool_pattern(string, REQUIRED)"fs.read") or wildcard ("fs.*","web.*")"*"matches all tools (use with caution)constraints(object, OPTIONAL)5.2.2. Constraint Types
File System Constraints (for
fs.*tools):path_allowlist(array of strings): Allowed filesystem paths (glob patterns supported)max_response_size(integer): Maximum file size in bytesCommand Execution Constraints (for
cmd.runor similar):command_allowlist(array of strings): Allowed base commands (e.g.,["git", "npm"])Network Constraints (for
web.*tools):domain_allowlist(array of strings): Allowed domains (wildcards supported, e.g.,*.wikipedia.org)Rate Limiting (applies to any tool):
rate_limit.calls(integer): Maximum number of callsrate_limit.per_seconds(integer): Time window in seconds5.2.3. Example: Filesystem Capability
{ "tool_pattern": "fs.read", "constraints": { "path_allowlist": [ "/workspace/shared/*", "/workspace/docs/*" ], "max_response_size": 10485760 } }This capability allows:
fs.readonly/workspace/shared/or/workspace/docs/5.3. Policy Evaluation Semantics
5.3.1. Deny-by-Default
All tool calls are DENIED unless explicitly allowed by a capability in the client's Security Scope.
5.3.2. Evaluation Algorithm
When a Gateway receives a tool call request:
5.3.3. Precedence Rules
5.3.4. Example Evaluation
Security Scope:
{ "name": "research-safe", "capabilities": [ { "tool_pattern": "fs.*", "constraints": { "path_allowlist": ["/workspace/shared/*"] } } ], "deny_list": ["fs.delete"] }Test Cases:
fs.read{"path": "/workspace/shared/data.csv"}fs.*capability, path in allowlistfs.write{"path": "/workspace/shared/output.txt"}fs.*capability, path in allowlistfs.delete{"path": "/workspace/shared/temp.txt"}fs.read{"path": "/etc/passwd"}web.search{"query": "example"}6. Attestation Protocol
Before exchanging tool calls, clients MUST perform an attestation handshake with the Gateway to establish identity and receive a Security Token.
6.1. Handshake Flow
Client Gateway KMS │ │ │ │──1. Generate Keypair────────>│ │ │ (Ed25519, ephemeral) │ │ │ │ │ │──2. Attestation Request─────>│ │ │ {public_key, workload_id} │ │ │ │ │ │ │──3. Verify Workload Identity─>│ │ │ (Container/Process check) │ │ │ │ │ │──4. Sign Token───────────────>│ │ │<──5. Signed JWT───────────────│ │ │ │ │<──6. Attestation Response────│ │ │ {security_token, expires_at}│ │ │ │ │ │──7. Tool Call (with token)──>│ │ │ │ │6.2. Identity Verification
6.2.1. Attestation Request
Method:
POST /smcp/v1/attestRequest Body:
{ "public_key": "<BASE64_ED25519_PUBLIC_KEY>", "workload_id": "<WORKLOAD_IDENTIFIER>", "requested_scope": "<SCOPE_NAME>" }Field Definitions:
public_key(string, REQUIRED): Client's Ed25519 public key (32 bytes, Base64-encoded)workload_id(string, REQUIRED): Verifiable workload identifier (implementation-specific, e.g., container ID, process ID, VM instance metadata)requested_scope(string, REQUIRED): Name of the Security Scope the client is requesting6.2.2. Workload Identity Verification
Gateways MUST verify that the
workload_idis authentic before issuing a Security Token. Verification methods include:If verification fails, the Gateway MUST respond with HTTP 401 Unauthorized.
6.3. Token Issuance
6.3.1. Attestation Response
Response Body (on success):
{ "status": "success", "security_token": "<JWT_STRING>", "expires_at": "<ISO8601_UTC>", "session_id": "<OPTIONAL_SESSION_ID>" }Response Body (on failure):
{ "status": "error", "error_code": "WORKLOAD_VERIFICATION_FAILED", "message": "Container ID not found or labels missing" }6.3.2. Token Lifetime
6.3.3. Session Management
Gateways MAY maintain session state for active clients:
session_id→ (client_public_key, security_scope, creation_time)7. Cryptographic Specifications
7.1. Signature Algorithm (Ed25519)
SMCP MUST use Ed25519 signatures as defined in RFC 8032.
7.1.1. Algorithm Parameters
7.1.2. Signature Generation (Client-Side)
7.1.3. Signature Verification (Gateway-Side)
7.2. Token Format (JWT)
Security Tokens MUST conform to RFC 7519 (JSON Web Token).
7.2.1. JWT Structure
7.2.2. Signature Algorithm
algclaim MUST be"EdDSA"7.3. Canonical Message Construction
To ensure deterministic signature verification, the signed message MUST be canonicalized:
7.3.1. Canonicalization Algorithm
7.3.2. Implementation Notes
7.4. Key Management
7.4.1. Client Keys (Ephemeral)
7.4.2. Gateway Keys (Long-Lived)
7.4.3. Supported KMS Providers
SMCP is agnostic to KMS implementation. Recommended providers:
8. Error Handling
8.1. Error Codes
SMCP defines the following error codes:
8.2. Error Response Format
8.2.1. SMCP Error Response
When a Gateway rejects a request, it MUST respond with:
{ "protocol": "smcp/v1", "status": "error", "error": { "code": "<ERROR_CODE>", "message": "<HUMAN_READABLE_MESSAGE>", "timestamp": "<ISO8601_UTC>", "request_id": "<ORIGINAL_REQUEST_ID>", "details": { // Optional additional context } } }8.2.2. Example: Policy Violation
{ "protocol": "smcp/v1", "status": "error", "error": { "code": "POLICY_VIOLATION_PATH_NOT_ALLOWED", "message": "Path '/etc/passwd' not in allowlist ['/workspace/shared/*', '/workspace/docs/*']", "timestamp": "2026-02-17T14:32:01.583Z", "request_id": "req-a1b2c3d4", "details": { "tool": "fs.read", "attempted_path": "/etc/passwd", "security_scope": "read-only-research", "allowed_paths": ["/workspace/shared/*", "/workspace/docs/*"] } } }8.2.3. HTTP Status Codes
9. Security Considerations
9.1. Replay Attack Prevention
Threat: An attacker intercepts a valid Security Envelope and resends it to perform unauthorized actions.
Mitigation:
timestampis older than 30 seconds from current server timeidfield) and reject duplicates within the 30-second windowImplementation Guidance:
idfield)9.2. Man-in-the-Middle Protection
Threat: An attacker intercepts and modifies Security Envelopes in transit.
Mitigation:
payload,security_token, ortimestampinvalidates the Ed25519 signatureImplementation Guidance:
9.3. Key Compromise
Threat: An attacker obtains the client's Ed25519 private key.
Mitigation:
Blast Radius:
Implementation Guidance:
9.4. Token Theft
Threat: An attacker steals a valid Security Token (JWT) from the client.
Mitigation:
Defense in Depth:
9.5. Rate Limiting
Threat: An attacker (or misbehaving client) floods the Gateway with requests.
Mitigation:
rate_limitper tool (e.g., 10 calls/minute)Implementation Guidance:
Retry-Afterheader9.6. Audit Trail
Security Requirement: All SMCP operations MUST be logged for forensic analysis.
Required Audit Events:
workload_id,security_scope,timestampworkload_id,failure_reason,timestampclient_id,tool_name,arguments(sanitized),security_scope,timestampclient_id,tool_name,violation_type,security_scope,timestampclient_id,timestampclient_id,expired_atsession_id,reason,timestampAudit Log Format:
10. Backward Compatibility
10.1. Protocol Negotiation
SMCP-capable Gateways SHOULD support both SMCP and legacy MCP clients during a migration period.
10.1.1. Capability Advertisement
During MCP initialization, Gateways SHOULD advertise SMCP support:
MCP Initialization Response:
{ "jsonrpc": "2.0", "id": 1, "result": { "protocolVersion": "2024-11-05", "capabilities": { "tools": {}, "resources": {} }, "serverInfo": { "name": "example-gateway", "version": "1.0.0" }, "extensions": { "smcp": { "supported": true, "version": "v1", "attestation_endpoint": "/smcp/v1/attest" } } } }10.1.2. Client Detection
Clients can detect SMCP support by:
extensions.smcp.supported == truein initialization response10.2. Legacy Client Support
10.2.1. Fallback Mode
Gateways MAY allow legacy (non-SMCP) clients if configured with:
{ "smcp": { "required": false, "legacy_scope": "default-restricted" } }required: falseallows legacy clientslegacy_scopeassigns a default Security Scope to unauthenticated clientsSecurity Warning: This reduces security to pre-SMCP levels. RECOMMENDED only for transition periods.
10.2.2. Upgrade Path
10.3. Migration Strategy
10.3.1. Client-Side Changes
Required changes for existing MCP clients:
Add Ed25519 Key Generation
Implement Attestation
Wrap MCP Calls in Security Envelopes
Estimated Engineering Effort: 1-2 days per client project
10.3.2. Tool Server Changes
Good News: Tool servers require ZERO changes. They continue to receive standard MCP JSON-RPC payloads after the Gateway unwraps Security Envelopes.
11. Interoperability
11.1. Test Vectors
This section provides test vectors for verifying SMCP implementations.
11.1.1. Test Vector 1: Valid Security Envelope
Ed25519 Keypair (hex):
Security Token (JWT):
MCP Payload:
{ "jsonrpc": "2.0", "id": "req-test-001", "method": "tools/call", "params": { "name": "fs.read", "arguments": { "path": "/workspace/test.txt" } } }Timestamp:
2026-02-17T14:32:01.000Z(Unix: 1708261921)Canonical Message (for signing):
{"payload":{"id":"req-test-001","jsonrpc":"2.0","method":"tools/call","params":{"arguments":{"path":"/workspace/test.txt"},"name":"fs.read"}},"security_token":"eyJhbGciOiJFZERTQSIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ0ZXN0LWFnZW50LTEyMyIsInNjcCI6InJlYWQtb25seS1yZXNlYXJjaCIsIndpZCI6ImRvY2tlcjovL3Rlc3QiLCJpYXQiOjE3MDgyNjE5MjEsImV4cCI6MTcwODI2NTUyMX0.signature_placeholder","timestamp":1708261921}Ed25519 Signature (base64):
Complete Security Envelope:
{ "protocol": "smcp/v1", "security_token": "eyJhbGciOiJFZERTQSIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ0ZXN0LWFnZW50LTEyMyIsInNjcCI6InJlYWQtb25seS1yZXNlYXJjaCIsIndpZCI6ImRvY2tlcjovL3Rlc3QiLCJpYXQiOjE3MDgyNjE5MjEsImV4cCI6MTcwODI2NTUyMX0.signature_placeholder", "signature": "<COMPUTED_SIGNATURE_BASE64>", "payload": { "jsonrpc": "2.0", "id": "req-test-001", "method": "tools/call", "params": { "name": "fs.read", "arguments": { "path": "/workspace/test.txt" } } }, "timestamp": "2026-02-17T14:32:01.000Z" }11.1.2. Test Vector 2: Tampered Payload (Should Fail)
Take Test Vector 1 and modify the payload's
pathto/etc/passwd:{ "protocol": "smcp/v1", "security_token": "<SAME_TOKEN_AS_VECTOR_1>", "signature": "<SAME_SIGNATURE_AS_VECTOR_1>", "payload": { "jsonrpc": "2.0", "id": "req-test-001", "method": "tools/call", "params": { "name": "fs.read", "arguments": { "path": "/etc/passwd" } } }, "timestamp": "2026-02-17T14:32:01.000Z" }Expected Result: Gateway MUST reject with
INVALID_SIGNATUREerror (signature does not match modified payload)11.1.3. Test Vector 3: Expired Token
Use Test Vector 1 but set
expclaim to a past timestamp:{ "sub": "test-agent-123", "scp": "read-only-research", "wid": "docker://test", "iat": 1708261921, "exp": 1708261920 }Expected Result: Gateway MUST reject with
TOKEN_EXPIREDerror11.2. Compliance Requirements
An SMCP implementation is compliant if it:
12. IANA Considerations
12.1. Protocol Identifier Registry
IANA is requested to create a registry for SMCP protocol versions:
Registry Name: Secure Model Context Protocol (SMCP) Versions
smcp/v1Registration Procedure: RFC Required
12.2. Error Code Registry
IANA is requested to create a registry for SMCP error codes:
Registry Name: SMCP Error Codes
Range: 1000-9999
Sub-Ranges:
Registration Procedure: Specification Required
Initial registrations defined in Section 8.1.
12.3. JWT Claim Names Registry
IANA is requested to register the following JWT claim names in the JSON Web Token Claims Registry (RFC 7519):
scpwid12.4. Security Scope Registry
IANA is requested to create a registry for standard Security Scope names:
Registry Name: SMCP Standard Security Scopes
Purpose: Reserve well-known scope names to prevent conflicts
read-only-researchcode-assistantunrestrictedRegistration Procedure: Expert Review
Expert Guidelines: New scopes should be generic enough for broad adoption, not vendor-specific.
13. References
13.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
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
https://www.rfc-editor.org/info/rfc7519
[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
[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
[MCP-SPEC] Anthropic, "Model Context Protocol Specification", November 2024,
https://modelcontextprotocol.io/specification
13.2. Informative References
[OWASP-AI-2026] OWASP Foundation, "OWASP AI Security and Privacy Guide", 2026,
https://owasp.org/www-project-ai-security/
[NIST-AI-RMF] National Institute of Standards and Technology, "Artificial Intelligence Risk Management Framework (AI RMF 1.0)", January 2023,
https://www.nist.gov/itl/ai-risk-management-framework
[SPIFFE] SPIFFE Authors, "Secure Production Identity Framework for Everyone (SPIFFE) Specification", v1.0, 2023,
https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE.md
[Cedar] Amazon Web Services, "Cedar Policy Language Specification", 2024,
https://www.cedarpolicy.com/en/policies/syntax-policy
[CONFUSED-DEPUTY] Norm Hardy, "The Confused Deputy: (or why capabilities might have been invented)", ACM SIGOPS Operating Systems Review, 1988
Appendix A: Security Scope Examples
This appendix provides reference Security Scope definitions for common use cases.
A.1.
read-only-researchUse Case: AI agent that searches the web and reads shared documentation, but cannot modify files or execute commands.
Scope Definition:
{ "name": "read-only-research", "description": "Read-only context for research agents. Can search web from safe domains, read shared files, but cannot modify filesystem or execute commands.", "capabilities": [ { "tool_pattern": "web.search", "constraints": { "domain_allowlist": [ "*.google.com", "*.wikipedia.org", "*.arxiv.org", "*.github.com" ], "rate_limit": { "calls": 10, "per_seconds": 60 } } }, { "tool_pattern": "fs.read", "constraints": { "path_allowlist": [ "/workspace/shared/*", "/workspace/docs/*" ], "max_response_size": 10485760 } }, { "tool_pattern": "fs.list", "constraints": { "path_allowlist": [ "/workspace/*" ] } } ], "deny_list": [ "fs.write", "fs.delete", "cmd.run", "net.connect" ] }A.2.
code-assistantUse Case: AI agent that generates code, runs tests, and manages git repositories.
Scope Definition:
{ "name": "code-assistant", "description": "Full access for code generation agents. Can read/write source files, run build tools, but cannot access system files.", "capabilities": [ { "tool_pattern": "fs.*", "constraints": { "path_allowlist": [ "/workspace/src/*", "/workspace/tests/*", "/workspace/docs/*" ], "max_response_size": 52428800 } }, { "tool_pattern": "cmd.run", "constraints": { "command_allowlist": [ "git", "npm", "cargo", "pytest", "make", "cargo" ] } }, { "tool_pattern": "web.search", "constraints": { "domain_allowlist": [ "*.stackoverflow.com", "*.github.com", "docs.rs", "crates.io" ], "rate_limit": { "calls": 20, "per_seconds": 60 } } } ], "deny_list": [ "fs.read:/etc/*", "fs.read:/var/*", "cmd.run:rm", "cmd.run:dd", "cmd.run:curl" ] }A.3.
unrestrictedUse Case: Highly trusted agent with full system access (use only for administrative tasks).
Scope Definition:
{ "name": "unrestricted", "description": "Full system access. Use only for highly trusted administrative agents with human oversight.", "capabilities": [ { "tool_pattern": "*" } ], "deny_list": [] }Security Warning: This scope grants unlimited access. It SHOULD only be used:
Appendix B: Implementation Guidelines
B.1. Client Implementation (Python Example)
B.2. Gateway Implementation (Pseudocode)
Appendix C: Test Vectors
C.1. Ed25519 Test Vector (RFC 8032)
Test Case 1 (from RFC 8032):
Private Key (hex):
Public Key (hex):
Message (hex):
Signature (hex):
Expected: Signature verification MUST succeed
C.2. Canonical Message Test Vector
Inputs:
"eyJhbGciOiJFZERTQSJ9.eyJzdWIiOiJ0ZXN0In0.c2lnbmF0dXJl"{"jsonrpc": "2.0", "id": 1, "method": "test"}"2026-02-17T14:32:01.000Z"1708261921Expected Canonical Message (UTF-8 bytes):
{"payload":{"id":1,"jsonrpc":"2.0","method":"test"},"security_token":"eyJhbGciOiJFZERTQSJ9.eyJzdWIiOiJ0ZXN0In0.c2lnbmF0dXJl","timestamp":1708261921}SHA-256 Hash (for verification):
Appendix D: Compliance Mapping
This appendix maps SMCP features to common compliance frameworks.
D.1. SOC 2 Type II
D.2. GDPR (EU Regulation 2016/679)
D.3. NIST AI Risk Management Framework
D.4. ISO/IEC 27001:2022
Appendix E: Future Work
The following topics are considered for future versions of SMCP:
E.1. Tool Server Attestation
Problem: Clients currently trust that the Gateway forwards requests to genuine tool servers. A compromised Gateway could proxy to malicious servers.
Proposed Solution:
E.2. Policy Language Standardization
Problem: This RFC describes Security Scope semantics but doesn't mandate a specific policy language.
Proposed Solution:
E.3. Multi-Party Trust
Problem: Current trust model assumes a single trusted Gateway. In federated scenarios, multiple parties may need to collaborate.
Proposed Solution:
E.4. Hardware-Backed Attestation
Problem: Software-based workload identity verification can be spoofed by privileged attackers.
Proposed Solution:
E.5. Rate Limit Enforcement Standardization
Problem: RFC specifies
rate_limitin capabilities but doesn't define algorithm details.Proposed Solution:
Authors' Addresses
Jeshua ben Joseph
100monkeys.ai
Email: jeshua@100monkeys.ai
(Additional authors to be added during publication process)
Scope
Beta Was this translation helpful? Give feedback.
All reactions