A financial services company deploys a Copilot agent for code analysis and developer assistance. Compliance requirements mandate that no code change can be made without a human approval chain. What tool configuration satisfies this compliance requirement while maximizing the agent's usefulness to developers?
Select an answer to reveal the explanation.
Short Explanation and Infographic
In compliance-regulated environments, least privilege isn't just a best practice — it's the architecture. Answer C is correct: read-only tooling plus an explicit human escalation hook gives the agent maximum analytical value without ever touching the code. The agent analyzes, recommends, and surfaces — a human approves and acts. This is not just policy-compliant, it's the most trustworthy pattern for financial services. Write access under a separate identity, non-production-only writes, and disabling the agent all either violate the requirement or destroy the value.
Full explanation below image
Full Explanation
Financial services compliance requirements around code changes often derive from SOX, PCI-DSS, or internal change management policies that require human accountability for every modification to code in the approval chain. The architectural response is least-privilege tooling plus an escalation hook.
Why C is correct: Provisioning only read-only tools (grep/search APIs, PR read access, log read access, dependency analysis) means the agent is architecturally incapable of writing code — the tool doesn't exist in its toolkit. The escalation hook is the key addition: when the agent has a recommendation (a bug fix, a refactoring suggestion, a security finding), it surfaces that recommendation in a structured format to a human approver through a defined channel (GitHub comment, Slack message, ticketing system). The human then reviews and initiates the change through their own credentials and approval workflow. The agent's value is fully preserved — analysis, synthesis, recommendation — while compliance is satisfied because no code path allows the agent to write.
Why A is wrong: Allowing write access to non-production repositories partially violates the compliance requirement if those repositories feed into production pipelines. More importantly, 'non-production write access' is a fuzzy boundary that erodes: developers promote non-production-branch commits to production constantly. The compliance requirement is about the approval chain for code changes, not about which repository the change lands in first.
Why B is wrong: A separate agent identity makes writes attributable to the agent in audit logs, but it does not remove the agent from the change-making process. The compliance requirement is not 'changes must be traceable' — it is 'changes must not occur without a human approval chain.' An agent identity committing code, even a clearly labeled one, is a non-human actor bypassing that chain.
Why D is wrong: Disabling the agent for production-bound repositories eliminates the compliance risk but also eliminates virtually all developer value — most meaningful code analysis happens on production-bound code. This is the 'turn it off to make it safe' approach, which defeats the purpose of deploying the agent in the first place. Compliance and utility are not mutually exclusive when least-privilege plus escalation is used correctly.