AI Coding Assistant Governance in Banking: Keeping Developer Tools Inside the AI Operating Model

Why coding assistants drift outside the operating model

Developer AI tools include chat assistants, IDE plugins and agentic tools that read a codebase and act on natural language commands. NIST's concept paper on control overlays for securing AI systems lists a coding assistant as an AI use case: a system that understands the enterprise codebase and automates software development through natural language commands. That description is useful for architects. It defines an interaction surface with its own inputs (source code, prompts, repository context), outputs (generated code, tool calls) and dependencies (a hosted model, a plugin, a vendor).

The first design decision is scope. The revised interagency model risk management guidance (OCC Bulletin 2026-13 and Federal Reserve SR 26-2, dated April 2026) rescinds the prior guidance. As of November 2026, it is risk-based, addresses governance and controls, and covers vendor and third-party products. It is expected to be most relevant to banking organizations with over $30 billion in total assets and to models supporting significant business lines, operations, services and functions. Smaller banks should apply it proportionately.

The guidance does not say that coding assistants are models. It does say that a bank's risk management and governance practices should guide the governance and controls applied to tools, processes or systems it does not cover. So the practical approach is to decide and document whether each coding tool is in or out of model risk management scope. If a tool is out, record that it is governed under the broader risk framework. Either way, it is governed. Internal policies that still cite the prior guidance should be updated.

Mapping coding tools to the elements of the operating model

Most coding assistants fall outside the operating model at the same few points. The mapping below shows each element, what it needs to cover for developer tools, and where the gap usually sits. Tiering and scoping are bank design choices, and the guidance expects the rationale to be documented.

• 1. Inventory and tiering: Record each assistant, plugin and agentic tool as its own entry, including tools developers installed without approval. Tier by what the tool can reach: repositories, secrets, build systems and external tool servers. Gap: central AI inventories are usually built from procurement, which misses free tiers and plugins.
• 2. Policy: State which models and tools are permitted, which code and data classes may be sent to them, and how generated code must be attributed. Effective policies define expectations explicitly. Gap: general AI policies rarely address source code or tool access.
• 3. Approval: Route new tools, models and plugin changes through the same workflow as other AI, with named owners. Gap: developers can adopt a tool in minutes, outside any workflow.
• 4. Monitoring: Review actual use against the assigned tier and the policy. Gap: monitoring is often periodic and relies on what the vendor chooses to report.
• 5. Evidence: Retain records that show what the tool was allowed to do and what it did. Gap: vendor-side records are fragmented, and the bank may not receive underlying components from a vendor.

Risk categories and the control point for each

Four risk categories matter most in the software development lifecycle. Each has a control point, and the point differs by category.

Sensitive data and source code leaving the environment is addressed at the moment a prompt or context payload is sent. Detecting it afterward is too late, so the control point is inspection and redaction or blocking before transmission. Insecure or unlicensed generated code is addressed through provenance (origin, licence and security context) attached to the code, followed by the bank's existing review and testing. NIST's secure software development practices for generative AI extend secure coding practice (PW.5.1) to include AI, so generated code should pass through the same development controls as any other code.

Unapproved models and plugins are addressed by an allow list enforced at the interaction, backed by inventory. Agentic tool and MCP server access is addressed at each tool call: which server, which action, with what arguments, and whether a human must approve it. The existing risk categories (operational, compliance, data, privacy and third party) all apply. The work is placing a control at the point where each one can be exercised.

Where runtime enforcement closes gaps that policy and review leave open

Policy documents state intent, and periodic reviews sample what happened. Neither changes the outcome of an individual interaction. A developer who pastes proprietary code into an unapproved tool has already sent it by the time a quarterly review runs. Governing through policy and review is necessary, but it leaves the bank reconstructing events from whatever records exist.

Runtime enforcement places the policy decision in the path of each interaction and tool call. The possible outcomes are allow, redact, block or escalate for human approval. The decision and its inputs become a record at the moment they occur. This also addresses vendor opacity: the bank holds a record from its own control point and does not depend only on what the vendor retains.

Trussed is one approach of this kind. It enforces policy in the execution path across models, agents, tools, MCP servers and coding assistants, with actions that include allow, redact, block, rate limit and escalate for human approval, applied to individual interactions and tool calls. It records code provenance: the origin, licence and security context of code. It can be deployed self-managed in the customer's cloud, with configurable retention and data residency. Trussed's deepest experience is in insurance, a regulated financial sector, and its general production proof includes 18+ months of continuous production in a regulated enterprise and 100+ models under one policy plane.

The evidence a bank needs to produce

The aim is that a model risk management reviewer, a third-party risk team, internal audit or an examiner can ask what a coding tool was allowed to do and what it did, and receive an answer from durable records rather than recollection. The bank decides the exact set, but the following artifacts cover the question.

Evidence generated by enforcement differs from vendor logs and periodic reviews in three ways. It is produced by the bank's own control point. It records the policy decision as well as the activity, so it shows what was permitted as well as what occurred. And it accumulates continuously rather than at review dates. Retention periods and data residency should be set deliberately, because evidence that cannot be retained or located does not help in an examination.

• Inventory and tier record: Each tool, its owner, its tier, the rationale, and the MRM scope decision.
• Policy version in force: The policy that applied at the time of each interaction, with approval history.
• Enforcement decisions: Allow, redact, block or escalate outcomes per interaction and tool call, with the reason.
• Human approval records: Who approved an escalated action, when, and what was approved.
• Code provenance records: Origin, licence and security context for generated code that entered a repository.