What happens

A build sandbox holds two GitHub credentials. github, for git and gh, is the operator App. mcp_github_token, for the GitHub MCP server, is the reviewer App whenever one is connected. The build keeps one sandbox across its steps and the secrets are pushed at provisioning, so planning, implementation and evaluation all reach GitHub through MCP as the reviewer.

Only the evaluation should act as the reviewer. The reviewer App exists because GitHub does not let an App approve a pull request it authored, and that applies to the one review the build posts. Every other MCP call a build makes, reading issues and pull requests, commenting, is work of the operator and should carry its name.

A second effect: the reviewer App has to be installed on every repository a build can touch, or provisioning of the whole build fails on the MCP token. The docs ask for exactly that today. If only the evaluation used the reviewer, a missing installation would fail that step with a clear reason instead.

Where

BuildWorkspace.get_mcp_servers in backend/druks/contrib/software_factory/workflows.py declares one GitHub MCP server and signs it with get_review_actor():

# GitHub MCP acts as the review actor. The clone acts as the operator.

The identity is chosen once per sandbox, not per step.

Expected

The build's GitHub MCP server acts as the operator, and only the evaluation step acts as the reviewer. The docs describe the review identity as "a second entry"; today the build sandbox has one. The fix direction is open.