A housing authority's casework application team connects its coding agent to source control through an MCP-based integration and must decide what repository permissions to grant the agent's identity. Which approach best follows the principle of least privilege?
Select an answer to reveal the explanation.
Short Explanation
Think of repo permissions like a caseworker's building key: you don't hand out a master key to every unit in the complex just because they need to get into one file. Scope the agent's identity to the one casework repository and only the operations its tasks actually need, so a mistake or compromise stays contained to that project. Broad access might feel convenient, but it turns one agent into a skeleton key for the whole organization.
Full Explanation
The mechanism is least-privilege scoping applied to an agent's identity exactly as it would be to a human contractor: grant only the repository, branches, and operations, say read plus pull-request-create, the assigned task needs, and nothing that task doesn't touch. That keeps the blast radius of a compromised or misbehaving agent limited to one project rather than the whole source-control estate.
Organization-owner access fails the concept directly, it optimizes for future convenience at the cost of turning a single agent identity into a path to every repository the organization owns. Read-only access across every repository sounds safer but still carries real exposure, since source code, configuration, and even accidentally committed credentials in unrelated repositories become visible to a workload with no legitimate reason to read them, so breadth of read access is not risk-free. Mirroring a lead developer's personal permissions ties the agent's access to a human role rather than the task at hand, meaning the agent inherits whatever that person has accumulated over time, most of which the casework task doesn't need.
Scope caveat: least-privilege scoping needs periodic review as the task changes, since a grant that was correct at project start can become stale as the agent takes on new work. A concrete check: list every repository the agent's identity can currently reach and confirm each one maps to an active, assigned task.