Scaled-Tech-Consulting/Gitea-Tools
2
0
Fork 0
Code Issues 17 Pull Requests 1 Actions Packages Projects Releases Wiki Activity

docs: Document MCP security model and trust boundaries #8

Merged
jcwalker3 merged 2 commits from feature/52-security-docs into master 2026-07-01 10:40:15 -05:00
Conversation 7 Commits 2 Files Changed 4
+4 -2
3 changed files with 4 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Showing only changes of commit b402de83fe - Show all commits
docs/credential-isolation.md
+1 -1
View File
@@ -3,7 +3,7 @@
This document describes how credentials and sensitive environment variables are handled within the MCP tools monorepo. This document describes how credentials and sensitive environment variables are handled within the MCP tools monorepo.
## Separate Credentials ## Separate Credentials
Even though multiple MCP servers share the same monorepo, they **must** have separate credentials and runtimes. Even though multiple MCP servers share the same monorepo, they **must** have separate credentials and runtimes.
- **No Shared Environments**: Each MCP server (`gitea-mcp`, `jenkins-mcp`, `ops-mcp`, etc.) must be instantiated as an independent service with its own dedicated `.env` configuration file. - **No Shared Environments**: Each MCP server (`gitea-mcp`, `jenkins-mcp`, `ops-mcp`, etc.) must be instantiated as an independent service with its own dedicated `.env` configuration file.
- **Strict Isolation**: A server will only have access to the credentials required for its specific trust boundary. For instance, `gitea-mcp` has no access to Jenkins or Ops authentication tokens. - **Strict Isolation**: A server will only have access to the credentials required for its specific trust boundary. For instance, `gitea-mcp` has no access to Jenkins or Ops authentication tokens.
docs/release-workflows.md
+1 -1
View File
@@ -5,5 +5,5 @@ This document outlines the scope and boundaries of the optional future `release-
## Orchestrator Role ## Orchestrator Role
The `release-mcp` package may be introduced later to coordinate workflows across the different MCP packages. The `release-mcp` package may be introduced later to coordinate workflows across the different MCP packages.
- **Coordination, not Consolidation**: It can call or compose other tools, but it **must not** become an all-powerful server holding credentials for all other components. - **Coordination, not Consolidation**: It can call or compose other tools, but it **must not** become an all-powerful server holding credentials for all other components.
- **Example Workflows**: Tasks such as collecting release evidence, verifying TEST deploy checklists, summarizing state (issue/PR/build/deploy), and posting evidence back to Gitea. - **Example Workflows**: Tasks such as collecting release evidence, verifying TEST deploy checklists, summarizing state (issue/PR/build/deploy), and posting evidence back to Gitea.
docs/tool-boundaries.md
+2
View File
@@ -2,6 +2,8 @@
This document defines the strict boundaries between the different MCP server packages within the monorepo. This document defines the strict boundaries between the different MCP server packages within the monorepo.
The project is named **MCP Control Plane** and lives in the `mcp-control-plane` repository. It groups the following packages: `common`, `gitea-mcp`, `jenkins-mcp`, `ops-mcp`, and `release-mcp`.
## 1. Architectural Philosophy ## 1. Architectural Philosophy
- **One MCP Server per Trust Boundary**: While the packages share a monorepo, their runtime services must remain entirely separate. There is no single "everything" server. - **One MCP Server per Trust Boundary**: While the packages share a monorepo, their runtime services must remain entirely separate. There is no single "everything" server.