News of compromised bank security poses an uncomfortable question to businesses. If information leaked even from financial companies equipped with security personnel and budgets, where should companies that store customer information without even maintaining a separate security organization begin? The first aspect to note in recent financial sector intrusion incidents is not the name of the AI reportedly used in the attacks, but the business systems accessed by the attackers. Protecting only the services directly used by customers does not mean that the information held by the company is protected.
This issue is specifically revealed in the opening remarks of the Financial Services Commission (FSC) at an emergency inspection meeting of the entire financial sector, posted on its website on October 6. The FSC stated that cases were identified where external webpages and servers used by loan solicitors and employees for work convenience became targets of attacks. At the same time, it explained that the causes and methods of individual accidents require additional investigation and that the possibility of AI utilization cannot be ruled out. Therefore, it cannot be concluded based solely on currently disclosed official materials that this intrusion was entirely carried out through AI's independent judgment and execution.
However, a company's response cannot stop while awaiting final investigation results. Separate from the financial sector incidents, overseas investigations made public confirm instances where AI has been used beyond merely answering an attacker's questions to actually connecting and executing real tasks. The change that companies must prepare for is not the emergence of a specific ultra-high-performance tool, but the reduction in time and personnel required to prepare attacks, and the expansion of the ability to repeatedly find the same weakness across multiple organizations.
From AI Explaining Hacking to AI Executing Tasks
Data demonstrating this shift is the cyber intelligence investigation published by Anthropic on November 13, 2025. The company stated that in an attack detected in September of that year, intrusions were attempted targeting about 30 organizations, with success in some. Here, 30 refers to the scale of attack targets, not the number of victim organizations where intrusion succeeded. The attacker set goals and made critical decisions, while AI performed various tasks such as reconnaissance, vulnerability review, and information gathering.
Anthropic assessed that AI performed 80 to 90 percent of the relevant activity. This figure does not imply the automation rate of global hacking or the attack success rate of all AI tools; it is the provider's analysis of specific attack activities discovered in a specific service. The same announcement includes instances where AI generated non-existent authentication credentials or misjudged public information as confidential information. A clear distinction must be made between the fact that the execution scope has expanded and the ability to accurately judge results by itself.
The September 2026 report demonstrates the direction of diffusion even more clearly. Analyzing abuse cases blocked between December 2025 and August 2028, Anthropic stated that not only organizations suspected of being state-linked, but also financially motivated criminals and individual actors utilized AI for attacks against multiple targets. In some cases, while humans set goals and reviewed leakage results, AI took charge of execution or coordinated the sequence of multiple tasks.
This is likewise not a sample survey representing entire criminal groups; the report specifies that it selected prominent cases among observed activities. Nevertheless, placing the individual cases of 2025 and the various types of 2026 together reveals a managerially significant change: it has become difficult to gauge whether AI was utilized based solely on the attacker's scale or expertise. Companies need to use the presence of externally accessible weaknesses as their primary benchmark rather than whether they are likely to be targets of large organizations.
The Speed of Development Appears in 'Response Time' Rather Than Attack Count
It is difficult to present a single multiplier for how much faster AI hacking has become. The rate at which models solved tasks in experimental environments, the time taken for actual attacks, and the number of targets handled simultaneously by attackers are all different indicators. Connecting figures from different reports to calculate how many times hacking capabilities grow each year can actually lead to misjudging a company's risks.
The May 2025 assessment by the UK's National Cyber Security Centre (NCSC) explains this issue from a temporal perspective. Looking ahead to threats through 2027, the NCSC noted that the period from the disclosure of known vulnerabilities to their actual exploitation has already shortened to a matter of days, and that AI will further reduce this. Furthermore, it emphasized the efficiency and scale expansion of existing techniques as much as the emergence of new attack methods. This content is a forecast written at the time, not an outcome that occurred in 2027.
Applied to businesses, the meaning of security patches changes. Even if the same vulnerability is eventually fixed, the risk differs if the period it remained exposed to the outside differs. The time allowed to attackers varies between an organization that manages security measures as a task list to be processed at the end of the month and an organization that first reduces the exposure of critical services before patching them. This is why one must look at the time taken for discovered risks to be actually resolved, rather than just the number of regular inspections.
For example, consider a situation where a vulnerability is discovered in a web service for customer inquiry, but its fix is delayed due to concerns over business interruption. The person in charge awaits patch approval, partner work schedules, and operational consent in sequence. At this time, management's choice is not limited to a binary option of a total shutdown or unconditional maintenance. Alternatives can also be compared, such as reducing the scope of external access, restricting sensitive inquiry functions, and temporarily operating alternative work procedures until the fix is made. The speed of security response depends as much on the structure that approves such exceptional measures as it does on technology.
Shifting Protection Standards from Service Names to Data and Authorities
The business-convenience webpages and servers mentioned by the FSC in the recent domestic incident offer important implications for general companies as well. A classification that a system is not a 'primary system' does not mean it lacks 'important information.' Services with auxiliary names such as sales support, partner management, or customer consultation require protection commensurate with their access to data revealing customer identities and transaction relationships.
The inventory that companies must create is insufficient if it merely lists program names in an IT asset ledger. It must connect what information each service stores, who accesses it from the outside, and who approves and revokes accounts. The guidance of the U.S. National Institute of Standards and Technology (NIST) Cybersecurity Framework 2.0 also addresses inventories of assets and supplier services, data flows, and access control for required scopes together.
To use this for actual decision-making, it is useful to look at information sensitivity and access scope together. A service open to the outside that can broadly query customer information and lacks a clear management supervisor becomes a priority inspection target, even if it has few users. Conversely, services lacking sensitive information and having a restricted access scope may not require the same level of emergency response. Rather than spending identical costs on all systems, this method prioritizes based on potential damage upon an accident and current exposure.
Services operated by outsourcing vendors cannot be omitted from this judgment. Writing security responsibilities into contracts and immediately securing records necessary in the event of an incident are two different matters. For instance, agreements must be in place regarding which company can suspend accounts when abnormal access is identified at night, and who holds and when they deliver access logs. Translating NIST's recommendation to involve suppliers in incident response and recovery plans into actual operations results in such consultations.
Finding Missing Paths Rather Than Whether Multi-Factor Authentication is Adopted
Authentication strengthening should not end as a mere competition in adoption rates. Even if multi-factor authentication is applied to employee login screens, the protection level may differ if an outdated administrator screen or a separate account recovery path is operated in a different manner. The scope a company must verify extends beyond regular employees' initial logins to partner accounts, administrator permissions, and device replacements and account recoveries.
In an explanation released on April 23, 2026, the NCSC recommended using passkeys if supported by the service, and using existing two-factor authentication if not. FIDO2 authentication, including passkeys, increases phishing resistance by binding authentication to normal services. However, the security of terminal and authentication credential management means, along with account recovery and revocation procedures, does not disappear. This is why account management cannot be considered complete simply because a specific authentication product was purchased.
It is reasonable for a company's adoption sequence to be determined according to tasks and authorities. A method should be designed where enhanced authentication is preferentially applied to areas with high impact when compromised, such as administrators or external access accounts, while areas difficult to use in the field are designed with alternative procedures. If employees experience inconvenience to the extent that normal work cannot be performed, they will request separate accounts or temporary access. Authentication policies can only be truly maintained if they include operations such as recording why exceptions are needed and their allowed duration, and revoking them upon termination.
Evaluating the Performance of AI Security Products by Actions Following Alarms
Defense utilizing AI can help organize logs and connect disparate anomaly signals. However, operational judgment remains between the stage where tools display warnings and the stage where access is actually blocked. Even if hazardous accounts are found, if the person in charge cannot be found or if they must wait for service interruption approval, the benefits of accelerated detection are diminished. Plans to introduce AI analysis functions must incorporate determining who will take action under what circumstances.
To this end, an evaluation method companies can utilize is limited verification based on actual business scenarios. This involves setting up situations in a controlled test environment, such as abnormal access and bulk customer information queries, and examining not only whether the tool detects them, but also the time it takes to reach the person in charge and the accuracy of the action. More important than getting many alarms is how well normal business operations were disrupted less while not missing hazardous situations.
It is also reasonable to divide the scope of automated responses based on the impact of actions rather than expanding it all at once. Tasks that are easy to revert, such as record collection and incident classification, should be automated first, while actions impacting customers and revenue, such as transaction suspensions or large-scale account freezes, should have approval conditions placed on them. The operational department can obtain grounds to expand the scope of automation only when AI records the basis on which it proposed actions and erroneous judgments can be reversed.
In particular, if the AI used for security tasks itself accesses customer information or administrator tools, its permissions must be designed separately. A starting point is to provide only the data necessary for analysis while separating the authority to actually change systems. Granting broad read-and-write permissions solely for the purpose of defense concentrates excessive influence into a single tool. Companies that introduce AI must include newly created access paths in their management scope alongside defenses against external attacks.
Preparing Even for Post-Leakage Damage and Business Recovery
The impact of a data breach does not end with whether money was stolen. The FSC also warned of the possibility that leaked information could lead to secondary damages such as voice phishing and smishing. This is why a company's incident notification should go beyond simply demanding password changes to be specific about which information was affected and what contacts customers should watch out for.
For instance, assuming a situation where someone with knowledge of actual transaction details demands additional authentication or payment from a customer, the customer might trust the contact itself simply because the information is accurate. It is better for companies to pre-determine official communication channels and contact methods that customers can directly verify, and clearly communicate actions that will not be requested under the pretext of incident response. It is also necessary to manage confirmed facts and the scope still under investigation in the same document to prevent consultation departments and security departments from giving conflicting explanations.
In recovery, a distinction must be made between the fact that servers are turned back on and the fact that normal business operations have returned. If customer inquiries are possible but order processing or settlement is not, the business remains at a standstill. In its finalized incident response guideline revision in April 2025, NIST explains integrating detection, response, and recovery into the cyber risk management of the entire organization. This points toward preparing beyond security-team-only simulations to include the actual recovery processes of sales, customer service, and partner operations.
If everything cannot be recovered simultaneously during an incident, priorities must be set in advance. Depending on the company, the functions that must be maintained first among payment approvals, shipping instructions, and customer notices may vary. Business managers must set the tolerable downtime and criteria for recoverable data, followed by technical personnel verifying feasibility through actual recovery testing. This is because resources can be concentrated on sustaining core functions rather than applying costly full redundancy to all operations.
Reports That Management Must Receive Also Change
Taking this issue as an opportunity, the questions in security reporting can be changed. In addition to how many solutions were installed and how many training sessions were conducted, management should check how many critical external systems remain without designated management supervisors, and how long each process took from risk discovery to temporary blocking and final modification. The adoption rate of enhanced authentication should also be read by examining how well critical permissions and external access paths are protected, rather than calculating it solely based on total employee count.
These figures are metrics for internal improvement and do not constitute a safety score universally applicable to all companies. Quick blocking is not necessarily a good response either. Other losses may occur if normal customers are repeatedly blocked or systems are initialized without preserving evidence. Therefore, response times must be compared with false-positive rates, business disruptions, and recovery test results. A structure is required where security managers explain technical risks, business managers present the impact of disruptions, and management determines resource allocation and permissible ranges between them.
The task left to businesses by the commercial bank intrusion incident does not end with fearing AI capabilities. If attackers can perform tasks with fewer personnel and less time, defending organizations must also reduce the delay from detection to action. Systems left open for work convenience, information retained beyond necessity, exceptionally granted permissions, and response procedures with unclear supervisors are the starting points. Investments in AI defense capabilities can hold clearer value in organizations where these basic controls actually operate.
