Remote-MCP: decommission Gitea credentials and privileged local MCP processes from LLM workstations #961

Open
opened 2026-07-28 02:55:17 -05:00 by jcwalker3 · 0 comments
Owner

Parent epic: #929.
Cross-link: #797, #807, #955 (certification umbrella).
Depends on: #938, #939, #960.

Goal supported: secure isolation. This issue is the one that objectively achieves the stated end state.

Problem

Every other #929 child makes the remote endpoint possible. None removes the credential from the workstation, and #939 explicitly lists permanent decommissioning as a non-goal, calling it "a separate decision for the operator." Until the keychain entries, GITEA_* credential-bearing environment variables, and privileged local mcp_server.py processes are gone and verified gone, LLM clients still hold Gitea credentials and the goal is unmet regardless of how good the endpoint is.

Current evidence

  • #939's non-goals, verbatim: decommissioning the local fleet permanently is out of scope.
  • #933's non-goals keep the keychain provider.
  • #929's completion gate says "no mutation path reads the operator's macOS keychain" but assigns that removal to no child.
  • #797 records that five scheduled workers run locally today.

Scope

  • Enumerate every workstation credential artifact: keychain entries per role, GITEA_* credential environment, credential-helper entries, local profile configs.
  • Define and execute removal per artifact.
  • Convert every client to remote-endpoint configuration.
  • Verify absence by positive proof, not by assumption.
  • Leave local privileged MCP processes unable to start with credentials.

Non-goals

  • Removing the keychain provider code#933 keeps it for supported local mode.
  • Decommissioning the local fleet as a code path.
  • Changing scheduled-worker orchestration, owned by #797.

Security and concurrency boundaries

After this issue, the workstation is outside the credential boundary entirely. No LLM client process may hold, resolve, or reach a Gitea credential.

Acceptance criteria

  • An inventory of every workstation credential artifact with its removal verdict.
  • After execution, no Gitea token is resolvable on any LLM workstation, proven by an executed check rather than inspection.
  • Every commissioned client reaches Gitea only through the remote endpoint.
  • A local privileged MCP process started on a workstation fails closed with a named blocker instead of authenticating.
  • All repositories and all five clients are commissioned through the remote service.

Required positive tests

  • Each client completes one read and one permitted mutation through the endpoint post-decommission.

Required negative and adversarial tests

  • A workstation attempting keychain credential resolution, asserted to fail.
  • A workstation attempting a direct Gitea API call, asserted to fail authentication.
  • A stale local config attempting to spawn a privileged process, asserted refused.
  • A scheduled worker attempting to run against the local fleet, asserted refused.

Deployment and migration requirements

A per-workstation checklist with recorded evidence.

Rollback and recovery requirements

Documented credential reinstallation, gated on explicit operator authorization and recorded as an exception.

Observability and audit requirements

The absence check is repeatable and reportable.

Definition of done

The secure-isolation end state is objectively true and demonstrated: LLM clients possess no Gitea credentials or privileged infrastructure access.

Parent epic: #929. Cross-link: #797, #807, #955 (certification umbrella). Depends on: #938, #939, #960. **Goal supported:** secure isolation. **This issue is the one that objectively achieves the stated end state.** ## Problem Every other #929 child makes the remote endpoint *possible*. None removes the credential from the workstation, and **#939 explicitly lists permanent decommissioning as a non-goal**, calling it "a separate decision for the operator." Until the keychain entries, `GITEA_*` credential-bearing environment variables, and privileged local `mcp_server.py` processes are gone and verified gone, LLM clients still hold Gitea credentials and the goal is unmet regardless of how good the endpoint is. ## Current evidence - #939's non-goals, verbatim: decommissioning the local fleet permanently is out of scope. - #933's non-goals keep the keychain provider. - #929's completion gate says "no mutation path reads the operator's macOS keychain" but assigns that removal to no child. - #797 records that five scheduled workers run locally today. ## Scope - Enumerate every workstation credential artifact: keychain entries per role, `GITEA_*` credential environment, credential-helper entries, local profile configs. - Define and execute removal per artifact. - Convert every client to remote-endpoint configuration. - Verify absence by positive proof, not by assumption. - Leave local privileged MCP processes unable to start with credentials. ## Non-goals - Removing the keychain **provider code** — #933 keeps it for supported local mode. - Decommissioning the local fleet as a code path. - Changing scheduled-worker orchestration, owned by #797. ## Security and concurrency boundaries After this issue, the workstation is outside the credential boundary entirely. No LLM client process may hold, resolve, or reach a Gitea credential. ## Acceptance criteria - An inventory of every workstation credential artifact with its removal verdict. - After execution, no Gitea token is resolvable on any LLM workstation, proven by an executed check rather than inspection. - Every commissioned client reaches Gitea only through the remote endpoint. - A local privileged MCP process started on a workstation fails closed with a named blocker instead of authenticating. - All repositories and all five clients are commissioned through the remote service. ## Required positive tests - Each client completes one read and one permitted mutation through the endpoint post-decommission. ## Required negative and adversarial tests - A workstation attempting keychain credential resolution, asserted to fail. - A workstation attempting a direct Gitea API call, asserted to fail authentication. - A stale local config attempting to spawn a privileged process, asserted refused. - A scheduled worker attempting to run against the local fleet, asserted refused. ## Deployment and migration requirements A per-workstation checklist with recorded evidence. ## Rollback and recovery requirements Documented credential reinstallation, gated on explicit operator authorization and recorded as an exception. ## Observability and audit requirements The absence check is repeatable and reportable. ## Definition of done The secure-isolation end state is objectively true and demonstrated: LLM clients possess no Gitea credentials or privileged infrastructure access.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Scaled-Tech-Consulting/Gitea-Tools#961