Banks Breached: Can AI Security Defend Against AI Attacks?

Can AI that is good enough for routine work also defend against attackers using more powerful models?

Four English news headlines covering savings-bank data leaks and the financial-sector emergency meeting.

Headlines on financial-sector data leaks and the emergency meeting

News reports: MBC · Savings bank breached: two days of data theft went unnoticed · The Fact · Holiday hacking emergency: CEOs across the financial sector summoned · NewDaily · Breaches spread from banks to savings banks and finance firms; regulators summon CEOs · Newspim · Savings banks and finance firms hit as hacking alarm spreads · Edaily · Yegaram Savings Bank reports a leak affecting about 40,000 customers

When companies choose AI, cost and speed often come first. If a model such as GPT-5-mini reliably sorts documents and produces summaries in a set format, there may be little reason to use a more expensive model every time. Once the required quality is established, reducing costs is a reasonable choice.

But the news about bank breaches made me question whether security can use the same standard. Attackers do not tailor their methods to the capabilities of the model we have chosen. If stronger AI helps them find weaknesses, they can use it. I believe banks need to prepare their security checks around the most capable tools attackers could use, rather than stopping at AI that is sufficient for internal office work.

The breaches have spread beyond banks to savings banks

Reported affected people: Shinhan about 25,000 customers; KB Kookmin 99 customers and 20 employees; Hana 89 customers; BNK Busan 11 contract developers; Yegaram about 40,000 customers, estimated; Hyundai Capital 146 mortgage sales agents. Figures are not added together.

Personal-data leaks by financial institution

Infographic sources: Yonhap · Shinhan Bank's leaked information and the loan-agent inquiry system · MBC · KB Kookmin Bank: 99 customers and 20 employees affected; attack timeline · Yonhap · Personal-data leak affecting 89 Hana Bank customers · Yonhap · Exposure involving 11 contract developers at BNK Busan Bank · Yonhap · Estimated leak affecting about 40,000 Yegaram Savings Bank customers · MBC · Personal-data leak affecting 146 Hyundai Capital mortgage agents

Reports on October 3 estimated that names, dates of birth, contact details and other information belonging to about 40,000 Yegaram Savings Bank customers had been leaked. Hyundai Capital also reported a leak involving some personal information for 146 mortgage sales agents. Following incidents at commercial banks such as Shinhan, other financial institutions were now reporting damage.

Financial regulators planned to hold an emergency meeting on October 4 with financial-industry association heads and executives from affected companies. Reports said the response had been brought forward from an earlier plan to receive the companies' holiday inspection results on October 7. The focus was widening from a handful of banks to the financial sector as a whole.

MBC reported that Yegaram failed to notice the theft while data was being taken for nearly two days. For customers who entrusted the bank with their names and phone numbers, both the leak and the delay in detecting it are unsettling.

This does not mean money was taken from customers' accounts. Even so, a personal-data leak is serious. If someone who knows your name and financial dealings calls while pretending to be a bank employee, an unfamiliar phone number alone may no longer be enough to make the call look suspicious.

We cannot treat all these incidents as the same AI-driven attack. But evidence that an AI tool was used is enough to make us consider the adversaries banks may face next. We also need to ask whether investment in more security equipment and internal AI is translating into an ability to defend against them.

Attackers are starting to delegate work to AI

ARTEX workflow: a person sets the target and permitted scope; AI plans; tools run checks; observations are recorded and reviewed. Results feed back into planning, with human intervention and approval controls.

ARTEX: planning, execution and review

Infographic sources: ARTEX developer · Planning, tool execution and human intervention · ARTEX · Official README at a fixed revision predating the incidents

ARTEX is the tool named in reports about the bank attacks. On October 3, Herald Economy quoted a Financial Security Institute official saying that traces of its use had been found while investigators examined attack records.

The developer describes a workflow in which AI decides what to do, runs tools, reads the results and chooses the next task. It goes beyond a chatbot that stops after one answer, connecting multiple steps into an ongoing process.

Think of fixing a program: inspect what is going wrong, try a change, run it again and check the result. The AI capabilities that help with that work can also support security testing—and can be used by attackers.

That does not mean AI independently selected and hacked banks. The public account points to a person using an AI tool. The Financial Supervisory Service regards the Yegaram incident as a different type of attack from those affecting commercial banks, and AI use in that case has not been confirmed.

We can respect that distinction and still start preparing. There is no need to wait until every incident has been conclusively attributed to AI. Security planning should already reflect the fact that attackers can now delegate some of their work to it.

Evidence of AI-tool use is distinct from a fully autonomous attack. AI use in the Yegaram incident remains unconfirmed.

Banks have been too cautious about adopting AI

A black-and-white illustration of connections between business-system screens and data stores.

Connections between business systems and data stores

I believe banks have been reluctant to make generative AI part of employees' everyday work. Outside the bank, using ChatGPT to write, fix code and work through complex problems has become familiar. Inside a restricted corporate network governed by network-separation rules, even opening ChatGPT and giving it work materials has not been something employees could do freely.

So AI that handles internal information is built on premises: installed inside the bank itself. That means buying GPUs and servers, choosing an LLM that can be installed, connecting internal data and assigning people to operate it. In its 2024 financial-sector AI support plan, the Financial Services Commission described restrictions on internal-network installation and high initial development costs as difficulties facing financial companies.

What concerns me is an approach that spends all this money and staff time yet stops at an LLM less capable than the latest external AI services. An expensive server does not automatically make the AI running on it powerful. The top models offered by external services are not software a bank can simply buy GPUs and install. While the bank spends heavily on an internal deployment, people outside can access stronger AI through a service.

For document search and summarization, that level of capability may have been enough. Helping staff find rules more quickly or draft a report is a worthwhile result. It was therefore possible to argue that business work does not always require the best model.

Security makes that standard worth reconsidering. Attackers can ask the strongest AI available to them to analyze code and look for weaknesses. What happens if the bank defending itself restricts external AI and relies only on a less capable internal model? Announcing an AI deployment and being ready to respond to attacks can be very different things.

This concern is not purely hypothetical. In September 2026, the Financial Services Commission reported that powerful AI had rapidly identified vulnerabilities in large codebases during a security-focused test involving eased network-separation restrictions. Expanding the conditions under which banks can use stronger AI to inspect their own systems has become a security issue.

I do not think a bank should feel reassured simply because it has built AI internally. Its security team needs access to analytical capabilities that can keep pace with attackers. If direct adoption of external services is difficult, it should look for ways to obtain those capabilities through routes such as Azure and Copilot.

Perhaps Copilot could offer a way forward

A black-and-white illustration of security staff sharing information and addressing weaknesses in connected systems.

Security staff sharing findings and fixing weaknesses

If a bank finds it difficult to adopt OpenAI or Anthropic services directly, it could consider using Azure servers and connecting cloud-based LLMs to its work. Rather than relying solely on installed models running on GPUs inside the bank, it could draw on powerful models offered in the cloud. Copilot can also provide a route for employees to use those capabilities at work.

There is already a starting point. In February 2025, Microsoft announced that Microsoft 365 Copilot had been authorized for use on the internal networks of 26 Korean financial institutions, and highlighted its adoption by KB Kookmin Bank. Banks are not entirely cut off from external AI. There are examples of approved services being made available for permitted work.

A bank can run business systems or AI services on Azure servers and connect them to LLMs provided through Azure OpenAI or Microsoft Foundry. It calls a cloud model to carry out tasks without having to train the model itself or run it on internal hardware. Foundry offers GPT and Claude model families, while Azure OpenAI provides options for private-network connectivity and access control.

Using Azure does not mean data stays entirely inside the bank. The bank must establish which model processes it, where processing takes place and what information may be sent. Copilot's available models also depend on the feature, license and administrator settings. These conditions need to be set in line with the bank's information-protection requirements.

I would like this route to extend beyond meeting notes and report writing. Security teams should also be able to use powerful models to analyze permitted code and system information, and to recheck weaknesses an internal model missed. A Copilot contract does not automatically make that possible, but it can be a starting point for putting current models to work in actual defense.

For routine business work, getting the required result at a lower cost is reasonable. Security also has to take account of the analytical capabilities available to attackers. Connecting Azure servers and cloud LLMs to bank operations, and expanding permitted uses through enterprise services such as Copilot, could offer a way to narrow that gap.

Considering Azure and Copilot as routes for security analysis is the author's proposal. An enterprise contract does not by itself authorize every sensitive-data use or every model.