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

feat: implement profile activation and runtime identity clarity (#131)

Browse Source
This commit is contained in:
Jason Walker
2026-07-04 02:04:07 -04:00
parent b1256d73b4
commit a0e7d3360e
4 changed files with 685 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/gitea-execution-profiles.md
+20
View File
@@ -252,6 +252,26 @@ the "one server per trust boundary" model described in
[`tool-boundaries.md`](tool-boundaries.md) and
[`credential-isolation.md`](credential-isolation.md).
## Profile Activation and Runtime Identity Clarity (#131)
To make Gitea MCP profile activation and runtime identity state explicit, the following mechanisms are supported:
### 1. Static-Profile vs. Dynamic-Profile Mode
- **Static-Profile Mode (Default):** The active profile is fixed at server launch based on the `GITEA_MCP_PROFILE` environment variable (with `GITEA_MCP_CONFIG` pointing to the config path). Local environment variables are static once a subprocess is spawned by the host. Modifying the environment variables on the host does not dynamically update an already-connected MCP server process.
- **Dynamic-Profile Mode:** Profile switching via the `gitea_activate_profile` tool is supported **only** if the configuration JSON explicitly opts in by setting `"allow_runtime_switching": true` under rules or top-level keys. Otherwise, attempting to switch profiles dynamically will fail closed.
### 2. Dual MCP Namespaces Recommendation
For security-sensitive or high-risk tasks, the preferred safety model uses separate, isolated MCP server instances (namespaces/sessions) launched with static profiles:
- `gitea-author`: Exposes tools configured with author permissions; cannot perform approvals or merges.
- `gitea-reviewer`: Exposes tools configured with reviewer permissions; used for PR reviews and merges.
This layout maintains physical separation of credentials and prevents privilege escalation within a single session.
### 3. Verification Post-Switching
When dynamic profile switching is enabled and a profile is activated via `gitea_activate_profile`, the session MUST immediately:
1. Clear the cached identity.
2. Call `gitea_whoami` with the target remote to prove and verify the fresh Gitea authenticated identity.
This guarantees the active profile operations align with the actual Gitea authenticated user credential.
## Relationship to roadmap issues
This document defines the **model only**. Related work is tracked separately