Roadmap: Task-scoped MCP execution profiles for LLM-operated Gitea workflows #10

New Issue

2026-07-01T11:15:31-05:00

jcwalker3 commented

2026-07-01 11:15:31 -05:00

Context

MCP Control Plane should allow LLMs to handle routine Gitea workflow operations safely:

create issues
comment on issues
create branches
open PRs
review PRs
request changes
approve PRs
merge PRs
close issues after merge

Roles should be fluid. A specific LLM should not be permanently assigned as “author,” “reviewer,” or “merger.”

Instead:

The LLM is not the role.
The MCP credential/profile used for the task is the role.

An LLM may perform different workflow roles only when operating through a task-appropriate MCP execution profile.

Desired model

Named Gitea MCP execution profiles:

gitea-issue-manager
gitea-author
gitea-reviewer
gitea-merger
gitea-owner

Each profile must expose:

profile name
authenticated Gitea username
allowed operations
forbidden operations
audit label
token source name, but never the token itself

Required safety behavior

Before any mutating action, the MCP workflow must verify:

authenticated Gitea identity
current execution profile
requested operation
target repository
target issue or PR
PR author, if reviewing or merging
whether the authenticated user is eligible for the action

If identity cannot be verified, the workflow must fail closed.

Critical rule

A profile/session must not approve or merge a PR authored by the same authenticated Gitea user.

Relationship to MCP Control Plane security model

This roadmap builds on the security and trust-boundary model documented under issue #52.

It must preserve these rules:

one MCP server per trust boundary
separate credentials per MCP server/profile
mutating actions require audit logging
production-style actions require explicit confirmation
secrets and tokens must be redacted
no Jenkins/Ops/deploy behavior is added to Gitea MCP

Non-goals

Do not add Jenkins behavior.
Do not add Ops behavior.
Do not add deploy behavior.
Do not add production actions.
Do not create an all-powerful MCP server.
Do not expose tokens.
Do not bypass Gitea branch protections.
Do not allow self-review/self-merge.

Child issue checklist

#11 — Add authenticated-user identity lookup to Gitea MCP
#12 — Define task-scoped Gitea MCP execution profile model
#19 — Support separate Gitea MCP runtime profiles via environment configuration
#13 — Add read-only Gitea MCP profile discovery
#14 — Add PR author and reviewer eligibility checks to Gitea MCP
#15 — Add gated Gitea PR review actions
#16 — Add gated Gitea PR merge workflow
#18 — Audit-log Gitea MCP mutating actions with execution profile metadata
#17 — Document LLM-operated Gitea workflow runbooks

Proposed labels

mcp · gitea · roadmap · security · dogfooding

Discovered through dogfooding: while reviewing/merging PR #8 for issue #52, the LLM could inspect Gitea state but could not safely prove which Gitea account the MCP tool was authenticated as, blocking safe merge behavior.

## Context MCP Control Plane should allow LLMs to handle routine Gitea workflow operations safely: * create issues * comment on issues * create branches * open PRs * review PRs * request changes * approve PRs * merge PRs * close issues after merge Roles should be fluid. A specific LLM should not be permanently assigned as “author,” “reviewer,” or “merger.” Instead: ```text The LLM is not the role. The MCP credential/profile used for the task is the role. ``` An LLM may perform different workflow roles only when operating through a task-appropriate MCP execution profile. ## Desired model Named Gitea MCP execution profiles: ```text gitea-issue-manager gitea-author gitea-reviewer gitea-merger gitea-owner ``` Each profile must expose: * profile name * authenticated Gitea username * allowed operations * forbidden operations * audit label * token source name, but never the token itself ## Required safety behavior Before any mutating action, the MCP workflow must verify: * authenticated Gitea identity * current execution profile * requested operation * target repository * target issue or PR * PR author, if reviewing or merging * whether the authenticated user is eligible for the action If identity cannot be verified, the workflow must fail closed. ## Critical rule A profile/session must not approve or merge a PR authored by the same authenticated Gitea user. ## Relationship to MCP Control Plane security model This roadmap builds on the security and trust-boundary model documented under issue #52. It must preserve these rules: * one MCP server per trust boundary * separate credentials per MCP server/profile * mutating actions require audit logging * production-style actions require explicit confirmation * secrets and tokens must be redacted * no Jenkins/Ops/deploy behavior is added to Gitea MCP ## Non-goals * Do not add Jenkins behavior. * Do not add Ops behavior. * Do not add deploy behavior. * Do not add production actions. * Do not create an all-powerful MCP server. * Do not expose tokens. * Do not bypass Gitea branch protections. * Do not allow self-review/self-merge. ## Child issue checklist - [ ] #11 — Add authenticated-user identity lookup to Gitea MCP - [ ] #12 — Define task-scoped Gitea MCP execution profile model - [ ] #19 — Support separate Gitea MCP runtime profiles via environment configuration - [ ] #13 — Add read-only Gitea MCP profile discovery - [ ] #14 — Add PR author and reviewer eligibility checks to Gitea MCP - [ ] #15 — Add gated Gitea PR review actions - [ ] #16 — Add gated Gitea PR merge workflow - [ ] #18 — Audit-log Gitea MCP mutating actions with execution profile metadata - [ ] #17 — Document LLM-operated Gitea workflow runbooks ## Proposed labels `mcp` · `gitea` · `roadmap` · `security` · `dogfooding` --- _Discovered through dogfooding: while reviewing/merging PR #8 for issue #52, the LLM could inspect Gitea state but could not safely prove which Gitea account the MCP tool was authenticated as, blocking safe merge behavior._

Roadmap: Task-scoped MCP execution profiles for LLM-operated Gitea workflows #10