Governing coding agents in a bank: a 12-point checklist
The controls a regulated enterprise needs before coding agents write production code at scale. One page, kept current, meant to be copied into your own standards.
Most banks I talk to are past the question of whether to use coding agents. The question now is what has to be true before agents touch code that moves money, holds customer data or sits in front of a regulator. This is my answer, written as a checklist you can hold a program against.
None of these controls is exotic. What separates programs that scale from programs that stall is doing all twelve at once, and building them into the platform instead of a review board. If a control depends on someone remembering to apply it, agents will outrun it within a quarter.
Write down what each agent may do
Scope every agent by repository, environment and action: read, propose, commit, deploy. Default to propose-only and widen access per use case. OWASP calls the failure mode excessive agency, and it is the easiest one to prevent on day one.
Check: Every agent has a written scope, and the platform enforces it.
Give every agent its own identity
No shared service accounts and no long-lived tokens pasted into configuration. Each agent gets a workload identity with short-lived credentials, so every action is attributable. Patterns such as SPIFFE and the MCP authorization specification show the direction.
Check: You can name which agent made any change, and revoke it in minutes.
Send every model call through one gateway
A single AI gateway gives you one place for the model allowlist, logging, data-loss controls, rate limits and cost. Teams that wire models directly into tools end up with as many policies as they have teams.
Check: No production path calls a model except through the gateway.
Govern the tools as well as the models
Agents act through tools, and tool descriptions are an attack surface: Invariant Labs showed tool poisoning in practice. Keep an internal registry of approved MCP servers and block the rest, the way GitHub added registry and allowlist controls for Copilot.
Check: Unregistered tool servers are blocked by default.
Curate the context agents read
Agents follow whatever standards they can see. Give them your approved patterns, architecture decisions and security standards as owned, dated context, and retire stale material. Anthropic treats context as a finite resource; in a bank it is also a control.
Check: Every context source an agent reads has an owner and a review date.
Put policy in the pipeline
Architecture and security rules run as code on every pull request, for human and agent changes alike, using tools such as Open Policy Agent. The Architecture-as-Code prototype at aac.muthub.org shows what that looks like end to end, waivers included.
Check: A change that breaks a standard fails the build, with a named waiver path.
Keep maker and checker separate
Agents propose; a person with authority approves. Scale review effort to two questions: how far can this change reach, and how quickly can we undo it. A one-line fix in a test helper and a change to payment routing should not get the same review.
Check: No agent can approve its own change, and high-impact paths require named approvers.
Record provenance for every change
Capture which agent and model produced the change, from which spec or prompt, and who approved it. Emerging formats such as Agent Trace build on supply-chain ideas like SLSA provenance. If you cannot show why the code exists, you cannot defend it to an auditor.
Check: For any production change, you can show the agent, the inputs and the approver.
Scan everything agents add
Agents add dependencies, copy patterns and occasionally leak secrets. Run dependency, secret and license scanning on every change and keep software bills of materials current, so a new vulnerability maps to affected services in hours.
Check: Every merged change has passed dependency, secret and license checks.
Use specs for high-risk changes
For regulated logic, review the specification first and let tests trace back to it. GitHub's Spec Kit and the Thoughtworks Radar describe the approach. Auditors can review a contract; nobody can review every generated line.
Check: High-risk changes link to an approved spec, and tests trace to it.
Measure outcomes, not usage
Seats and prompts tell you nothing. Track delivery and stability measures in the spirit of DORA's research, plus rework and escaped defects. Be wary of perceived speed: METR's randomized study found experienced developers were slower with AI tools on their own codebases while believing they were faster.
Check: Every pilot has a baseline, a target and a gate before it scales.
Plan for the bad day
Have a kill switch per agent, a rollback path and an incident playbook for agent misbehavior, including prompt injection from content the agent reads. The OWASP Top 10 for LLM Applications is a good list to red-team against. Rehearse it before an auditor or an attacker does it for you.
Check: You can disable any agent in minutes and have rehearsed doing it.
If you can tick all twelve, you are ready to widen agent access. If you cannot, the gaps tell you what to build next. Which of the twelve would your program fail today?
Copy it, adapt it, use it in your own standards. A Markdown version is easier to paste. Related: Model is a tool, harness is the strategy and Adopting MCP in a bank. Views are my own and do not represent my employer.