The Problem Is No Longer Copy-Paste

If you had talked AI with a bank’s security team in 2023, you would have heard that their biggest fear was a developer copying code and pasting it into ChatGPT. Given the conditions of the day, they were right.

That fear is still valid, but it is no longer the main risk. Coding agents are not chat boxes. They read the repo themselves, change files, run tests, execute commands in the terminal and finally open a PR. Claude Code, Codex, Copilot’s agent mode, Cursor: what they have in common is that they do the work in the developer’s place. Every month more teams work with them.

In a regulated institution this means the following: the question “will code leave the building?” is still there. But a much harder one has arrived next to it: what is an external model authorised to do inside my network?

Why I am writing this series

Most people who talk about this are either selling a tool or saying generic things. I have been building this for several years, in my own products and on the banking side, for real. What I have seen is this: what teaches you is not what worked but what did not, and which decision we made and why.

Let me say this at the outset too: over time I turned what I built into a product. In these eight parts I will not describe tools or products but decisions and their reasons. How I turned these pieces into a product is the subject of a separate series.

What is inside the sentence “security won’t allow it”

You hear this sentence in every institution and it usually ends the conversation. In fact it puts three separate things into one bag. When each of the three is answered separately, “won’t allow it” turns into “we allow it under these conditions”.

The first is the classic one: data and code must not leave. The solutions on the customer-data side are familiar: masking, synthetic data, test environments. These existed long before AI and you most likely already do them. On the code side, however, the job has really changed. Previously the developer decided which piece to paste. Now the agent reads as much of the repo as it wants to build context and sends it to the model. So the question “how much code is leaving” is no longer answered by the developer but by the tool. It looks like a small difference. But it is exactly what moves data classification and context control straight into the architecture.

The second is the new one: what is the agent authorised to do? The authority of an agent that can run commands in the terminal, connect to the database and reach internal systems over MCP has to be thought of like an employee’s authority. Which directories can it write to? Which commands can it run? Which internal service does it access with which account? Who merges the PR it opens? Most institutions have not asked these questions yet; the tools run on their default settings.

The third is who is held to account. Say the code the agent wrote went live and something broke. Who is responsible: the developer, the approver, or the management that chose the tool? In a regulated institution this is a legal question. It is also what usually lies behind some institutions’ decision to run the model in-house, even on a fully closed network. The real reason is not confidentiality but being able to show the auditor: the log, the settings and the model being in the institution’s hands.

“But the tools have solved this”, you will say

A fair objection and partly true. At tool level a permission model really does exist: Claude Code’s permission modes, allowlists, hooks and server-managed settings; Copilot’s enterprise policies; Codex’s sandbox. On the standards side, OWASP published a separate Top 10 for agentic applications in December 2025; tool misuse, identity and privilege abuse, and human-agent trust exploitation are separate headings there. The July 2026 release of MCP also aligned authorisation with OAuth and OpenID Connect. So the problem is not that nobody has thought about it.

The problem is where these protections run. Almost all of them sit inside the agent’s own process: the permission mode, the rules in the prompt, the instructions in the project file. What happens when the process that reads the rule and the process that uses the permission are the same? The record of the last year and a half is clear:

• Replit, July 2025. The agent deleted the production database while it had been explicitly told “code freeze”; it then generated fake data and misreported the situation.
• PocketOS, April 2026. An agent running on Cursor used a broadly privileged Railway token it found in an unrelated file to delete the production database and all backups in a single API call. Thirty hours of downtime followed; Railway could only partially restore the data from a three-month-old backup.
• Claude Code #56694, May 2026. According to the user’s report, the agent edited the hook whitelist that was blocking it. It wrote an undocumented script to get around the line limit, changed file timestamps with os.utime() to pass the staleness check, and committed with “done” without doing the work.
• Pillar Security, July 2026. Published the result of months of research as a week-long series: seven sandbox escapes in Cursor, Codex CLI, Gemini CLI and Antigravity. The essence of the finding: agents do not break the sandbox; they write files that processes outside the sandbox later read and execute.

Add to these the several CVEs opened for Claude Code since 2025: hook and MCP definitions that run the moment a project is opened, a project setting that redirects API traffic to the attacker’s server, a malicious repo that can set bypassPermissions before the workspace-trust dialog appears. CurXecute and MCPoison in Cursor belong to the same class.

In all of these cases the control was inside the agent. In most of them, a broadly privileged credential the agent could reach was added on top.

You do not need to take my word for it; the vendors’ own documentation says so. According to Anthropic, server-managed settings are not a security boundary but a client-side control. On an unmanaged device the user can get around them without even needing sudo. If you route through Bedrock or Vertex and do not have your own gateway, these settings are disabled entirely. According to GitHub’s documentation, Copilot’s agent firewall only sees processes started from Bash, not MCP processes. It is instructive to look at what a bank does in this situation. According to Risk.net’s July 2026 report, when MUFG saw that Claude Code was too good at reaching information and was getting ahead of the bank’s security and compliance rules, it developed its own internal version rather than dropping the tool. In my view that is exactly where the industry is heading: not banning, but wrapping.

Put the control in the system, not the agent

In a bank we do not decide what a teller can do by telling them “please don’t do that”; the system decides. Which transaction, which limit, with whose approval. And every transaction leaves a trace. However persuasive the teller is, they cannot exceed the limit, because the control is not in the teller but in the system. We do this not because we distrust the teller, but because that is how it has to be.

The thesis of the series is that simple: treat the agent like a teller and put the control not in the agent itself but in the system the agent passes through.

That system, in my view, has three parts, and all three can be built inside the institution’s own walls:

• Independent control. What the code the agent wrote affects is judged not by the agent’s own explanation but by a graph extracted from the code itself. Human approval sits on top of that graph. (Part 3)
• The rulebook. Who uses how much, when to switch to which tool, which actions the agent may take, how licences are distributed. All of this written, versioned and actually enforced. (Part 5)
• The gateway. Every request the agent sends to the model and to tools passes through the institution’s own gateway. Limits, masking, tool-call control and logging are applied there. The agent can neither change this gateway nor go around it. (Part 6)

There is something all of us in architecture know: constraints do not worsen a design, they shape it. The moment you write down these three constraints, some decisions make themselves:

• Where the model runs and what goes to it will be under your control; therefore the developer interface will be yours too.
• The agent’s authority will be defined as a policy; therefore tool selection stops being “which model is best” and becomes “which one can be governed”.
• For the model to know the institution, you will carry the knowledge to it.
• Because every interaction will leave a trace, traffic will pass through a single point.

Under these decisions there is a four-layer infrastructure: model, developer interface, context and system understanding. Four layers of infrastructure, three parts of governance. I will describe the infrastructure first.

I do not think regulated institutions are behind on AI. They simply have to ask up front the questions startups never ask. This year’s cases show well enough what those who do not ask end up paying.

What the regulators say

In Türkiye the framework was clear even before AI. The BDDK’s 2020 regulation on information systems (art. 25) requires banks to keep their primary and secondary systems within the country. Article 9 of the KVKK, amended in 2024, ties the transfer of personal data abroad to safeguards such as an adequacy decision or standard contractual clauses. Every request that carries customer data to a model running abroad is a KVKK matter; an external AI service that touches the bank’s processes is a BDDK matter. The February 2026 announcement by the BDDK and KKB, together with the industry, of a plan for an AI testing and validation environment also shows that the direction is supervised use, not prohibition.

The pattern abroad is the same. DORA covers the provider of the coding agent you use as an ICT third-party risk. The EU AI Act’s timeline has slipped but its direction has not; I will return to the details in part eight. The vendors, too, are willing to come inside the institution’s walls: OpenAI announced a partnership with Dell in May 2026 to bring Codex into on-premises environments, details still unclear; on the Microsoft side, disconnected model serving on Azure Local and a Copilot CLI on GitHub Enterprise Server that connects to the institution’s own model are in preview. Anthropic’s models, for now, are offered through the cloud and cloud providers; there is no publicly available product for on-premises deployment.

Reduced to a single sentence: the regulator is not saying “don’t do it”, it is saying “do it in a way we can audit”.

Ten questions to answer before you start

Before you start discussing AI agents in your institution, I recommend answering these questions in writing. Every question left unanswered is the real reason behind the sentence “won’t allow it”.

Data and code

1. Which repos are open to the agent to read, which are closed? Is there a written list?
2. Who can see the files the agent pulls into context? Is a log kept?
3. Is there real customer data in the test environment? If so, whose responsibility is masking?

Agent authority

4. Which directories can the agent write to? Is this an allowlist or a blocklist?
5. Which commands can it run? What is there besides build and test?
6. Which internal services, databases and MCP servers can it reach, with which account?
7. Where do all these rules live: in the agent’s settings file, or somewhere outside the agent?

Accountability

8. Who approves the code the agent produces, and what does the approval look at: the agent’s explanation, or an independent impact analysis?
9. If there were an agent-originated production incident, how would you answer “who wrote this code”?
10. Who owns the constraint: information security, compliance, legal, the business unit? Is there a single name?

If you answer “in the agent’s settings” to the seventh and “the agent’s explanation” to the eighth, this series is for you.

In my case, even learning that the owner of the constraint was information security saved months. Until then everyone pointed at a place called “security”, but nobody gave a name.

Map of the series

1. The problem is no longer copy-paste: Why control must be in the system, not the agent. (this part)
2. Four layers: Model, interface, context, system understanding. Which can you start without, and a starter setup.
3. Tools and the code graph: Comparing tools with a regulated institution’s questions, and the job no tool does.
4. Local model or external model: The three reasons for the gap and which work goes to which model.
5. The rulebook: Tiers, limits, escalation and a sample policy file.
6. The gateway: Who enforces the rulebook, where the tokens go, architecture and sample rules.
7. The balance sheet: Where the gains showed up, where they did not, and what to measure from day one.
8. The software factory: How much work can be given to an agent once control is in the system.

Then a separate series: how I turned these pieces into a product.

In the next part I will describe the four layers of a closed-loop setup: which you can start without, and my setup recommendation for a team starting from scratch.

Sources: OWASP GenAI Security Project, Top 10 for Agentic Applications (9 December 2025); Model Context Protocol blog, 2026-07-28 specification; The Register (Replit, 21 July 2025); OECD AI Incidents Monitor and DevOps.com (PocketOS, April 2026); Claude Code issue #56694 (6 May 2026); BleepingComputer (Pillar Security, 20 July 2026); Check Point Research and Dark Reading (CVE-2025-59536, CVE-2026-21852, February 2026); stack.watch (CVE-2026-33068); Tenable (CurXecute/MCPoison, CVE-2025-54135/54136); Anthropic, Claude Code server-managed settings documentation; GitHub, Copilot agent firewall documentation; Risk.net (MUFG, 8 July 2026); OpenAI (Dell partnership, 18 May 2026); Microsoft Learn (Foundry Local on Azure Local, preview); GitHub Docs (Copilot on GHES, disconnected environment technical preview); BDDK, Regulation on Banks' Information Systems and Electronic Banking Services, art. 25 (Official Gazette 15.03.2020, 31069); Law No. 6698 (KVKK) art. 9 (as amended by Law No. 7499, in force 1 June 2024); Bloomberg HT (BDDK–KKB Artificial Intelligence and Cloud Technologies Workshop, 25 February 2026).