docs: Document MCP security model and trust boundaries for #52

docs/credential-isolation.md

@@ -0,0 +1,9 @@
+# Credential Isolation
+
+This document describes how credentials and sensitive environment variables are handled within the MCP tools monorepo.
+
+## Separate Credentials
+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.
+- **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

@@ -0,0 +1,9 @@
+# Release Workflows
+
+This document outlines the scope and boundaries of the optional future `release-mcp` orchestrator.
+
+## Orchestrator Role
+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. 
+- **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/safety-model.md

@@ -0,0 +1,15 @@
+# MCP Safety Model
+
+This document outlines the safety requirements for all tools within the MCP monorepo.
+
+## 1. Audit Logging and Confirmation
+All mutating actions (e.g., triggering builds, creating resources, updating environments) must be recorded in an audit log. These actions require explicit confirmation from the user before execution to prevent accidental state changes.
+
+## 2. Production Environment Safety
+Any action that targets a production environment must have a hard confirmation gate. Production actions must never run based on vague or ambiguous prompts. The user must provide explicit, unambiguous consent to proceed with a production deployment or modification.
+
+## 3. Secret Redaction
+To maintain a secure environment, all secrets, tokens, passwords, and sensitive keys must be strictly redacted from:
+- System and application logs
+- Tool return values/outputs
+- Any form of persistent storage or console output

docs/tool-boundaries.md

@@ -0,0 +1,11 @@
+# Tool Boundaries
+
+This document defines the strict boundaries between the different MCP server packages within the monorepo.
+
+## 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.
+
+## 2. Package-Specific Boundaries
+- **gitea-mcp**: Restricted to source-control and work-item capabilities (issues, PRs, comments). This package **must not** have Jenkins or Ops credentials, nor can it execute deploy operations.
+- **jenkins-mcp**: Focused on CI/CD capabilities. This package **must not** have Ops credentials unless explicitly configured for a specific, isolated pipeline later.
+- **ops-mcp**: Dedicated to live environment and host checks. In its initial state, this package starts as strictly read-only (e.g., health checks, status checks, log reading).