Coding agents at a bank: control lives in permissions, not prompts, and productivity gains still have to be proven

By HackerNoon · October 28, 2026.

Lokesh Suri, a vice president at JPMorgan Chase, has published a guide in HackerNoon on scaling agentic coding assistants at a regulated institution. He says it draws on his experience supporting more than 600 engineers at a large financial organization. It should be read as a practitioner's account, not as an independent study or an official position of the bank.

He proposes a four-layer architecture. Governance: central rules that define what is never allowed, such as reading credentials files or skipping human approval before a "push". Guardrails: "hooks", scripts that run deterministically before or after each agent action and block prohibited patterns. Curated knowledge: "skills", repeatable procedures reviewed like code. Integration: a closed list of tools connected through the Model Context Protocol (MCP), the open standard agents use to access external systems. Underneath it all sits the usual pipeline of pull request reviews, tests and security scanning. Agents get no separate path to production.

The configuration examples use Anthropic's Claude Code, though the author says the architecture depends on the type of control, not the product. Engineers in his environment also use GitHub Copilot, Windsurf and Codex.

The piece offers a useful point about the evidence on productivity, which is mixed. In one randomized trial the author cites, a new JavaScript task was completed 55.8% faster with an assistant. Another trial from 2025, with experienced maintainers working in their own repositories, found completion times 19% longer, even though participants believed they had been faster. On security, one study he cites found that people using an assistant wrote less secure code and trusted it more. According to the author, regulation does not help either. The US banking model risk guidance, revised in April 2026 (SR 26-2), leaves out generative and agentic AI, so each institution has to apply its own practices.

The author illustrates the design with a hypothetical prompt-injection attack. A ticket contains a hidden instruction to read the .env file and send it to an external URL. The model might comply, but the central policy blocks the read, the outbound "curl" is denied, the unauthorized MCP server is unreachable, and any "push" requires human approval. No layer has to be perfect. The attacker has to beat them all.

Our take: the most valuable thing in the piece is a principle, "rules in code, not in prompts". A natural-language instruction is a suggestion that the model can ignore or that someone can manipulate. A permission denied by configuration, or a hook that returns an error, is a barrier. It is the same logic we see in enterprise agent governance: moving from written policies to verifiable controls and auditable logs. In general, regulators and risk teams will end up asking for proof that controls work. Those who have built policy into code and log every action will come to that conversation with an advantage.

The most honest part of the article is also the least flashy: measurement. A 55.8% improvement in one case and a 19% loss in another mean the gains depend on context and on how mature the codebase is. The author proposes comparing cohorts of teams that adopt the tools with teams that do not, tracking lead time and change failure rate together. That is the right approach, because a speedup that raises failure rates is not an improvement. Any bank that rolls out agents out of enthusiasm, without that baseline, will not know whether it has gained anything.

The author acknowledges some limits himself. Hooks based on text patterns are a last line of defense that a determined user can get around, so they are no substitute for an isolated environment. Skills go stale if nobody maintains them. And for small teams without regulatory obligations, the architecture is too heavy. We would add a caveat of our own: the article is a practice guide based on personal experience, with no outcome data of its own. It does not quantify how much productivity improved or how many incidents the design prevented.

In the long run, the message is hopeful. If the most heavily regulated sectors manage to get agents working under verifiable controls, tedious engineering work can be automated without sacrificing trust. In the short term, the transition depends on teams that put as much effort into governance and measurement as into the model itself. That is where the hard part lies today.