News of compromised bank security poses an uncomfortable question for businesses. If information leaked even from financial companies equipped with security personnel and budgets, where should companies that store customer information without even a separate security organization begin? The first aspect to note in recent financial sector breach incidents is not the name of the AI reportedly used in the attack, but rather the business systems accessed by the attacker. This is because protecting only the services directly used by customers does not guarantee the protection of the information held by the company.
This issue is specifically highlighted in the opening remarks of the Financial Services Commission (FSC) posted on its website from an emergency inspection meeting of the entire financial sector on October 6. The FSC stated that cases were identified where external web pages and servers used by loan solicitors and executives/employees for business convenience became targets of attacks. At the same time, it explained that the causes and methods of individual incidents require additional investigation and that the possibility of AI utilization cannot be ruled out. Therefore, based solely on currently disclosed official data, it cannot be concluded that this breach was entirely conducted through AI's independent judgment and execution.
However, corporate response cannot be halted while awaiting final investigation results. Separate from financial sector incidents, overseas investigations released to the public show instances where AI has been used beyond merely answering an attacker's questions to actually connecting and executing real tasks. The change for which companies must prepare is not the emergence of a specific ultra-high-performance tool, but rather the reduction in time and personnel required to prepare attacks, alongside the enhanced ability to repeatedly find the same vulnerabilities across multiple organizations.
From AI Explaining Hacking to AI Executing Tasks
Data illustrating this shift is Anthropic's cyber espionage activity investigation published on November 13, 2025. The company stated that in attacks detected in September of that year, intrusions were attempted against approximately 30 organizations, with partial success. The figure 30 here represents the scale of the targets, not the number of victimized organizations where intrusions succeeded. While the attacker set objectives and made critical decisions, AI performed various tasks such as reconnaissance, vulnerability reviews, and information gathering.
Anthropic evaluated that AI performed 80 to 90 percent of the relevant activity. This figure does not denote the global automation rate of hacking or the attack success rate of all AI tools; it is the provider's analysis of specific attack activities discovered in specific services. The same announcement included instances where AI generated non-existent authentication credentials or incorrectly judged public information as confidential information. A clear distinction must be made between the expanded scope of execution and the ability to accurately judge results on its own.
The September 2026 report demonstrates the direction of proliferation even more clearly. Analyzing blocked abuse cases between December 2025 and August 2026, Anthropic stated that not only organizations suspected of being state-sponsored, but also financially motivated criminals and individual actors, utilized AI to attack multiple targets. In some cases, while humans set objectives and reviewed leakage results, AI took charge of execution or coordinated the sequence of multiple tasks.
This is similarly not a sample survey representing entire criminal syndicates. The report explicitly states that prominent cases were selected among observed activities. Nevertheless, placing the individual cases of 2025 alongside the various patterns of 2026 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 vulnerabilities as their primary benchmark rather than assessing whether they are likely targets for large organizations.
The Speed of Development is Revealed in 'Response Time' Rather Than Attack Volume
It is difficult to express how much faster AI hacking has become using a single multiplier. The rate at which models solved tasks in experimental environments, the time actually taken for attacks, and the number of targets handled simultaneously by attackers are all different metrics. Calculating that hacking capabilities multiply every year by chaining together figures from different reports can instead lead to misjudgments of corporate risk.
The May 2025 evaluation 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 between the disclosure of a known vulnerability and its actual exploitation had already shrunk to a matter of days, and predicted that AI would reduce this even further. It also emphasized the efficiency and scaling of existing techniques alongside the emergence of new attack methods. This content is a forecast written at that time, not an outcome that occurred in 2027.
When applied to businesses, the meaning of security patches changes. Even if the same vulnerability is eventually fixed, the risk is not the same if it remained exposed to the outside for a different duration. The time granted to attackers differs between an organization that manages security measures as a to-do list to be handled at the end of the month and an organization that first reduces exposure to critical services before applying fixes. This is why one must look at the time taken for discovered risks to actually be resolved, rather than simply counting routine inspection frequencies.
For instance, consider a situation where a vulnerability is discovered in a customer inquiry web service, but the fix is delayed due to concerns over business disruption. The person in charge awaits patch approval, partner work schedules, and operational consent sequentially. In this case, management's choice is not merely a binary option between total shutdown and unconditional maintenance. Reducing the external access scope or restricting sensitive inquiry functions and operating alternative business procedures temporarily until the fix is applied can also be compared. The speed of security response depends as much on the structure for approving such exceptions as it does on technology.
Shifting Protection Criteria from Service Names to Data and Privileges
The web pages and servers for business convenience mentioned by the FSC in the recent domestic incident offer important implications for general businesses as well. Categorizing something as 'not a core system' does not mean it lacks 'important information.' Even if a service has a subsidiary name like sales support, partner management, or customer consultation, it requires appropriate protection if it accesses data revealing customer identities and transaction relationships.
The inventory that companies must build should not be limited to an IT asset register listing program names. It must connect what information each service stores, who accesses it from the outside, and who approves and revokes accounts. The US National Institute of Standards and Technology (NIST) Cybersecurity Framework 2.0 guidance similarly addresses the inventory of assets and vendor services, information flows, and the management of necessary ranges of access privileges.
To utilize this in actual decision-making, it is useful to evaluate information sensitivity and access scope together. A service that is open to the outside, can broadly query customer information, and lacks a clear management responsible party becomes a priority inspection target, even if its users are few. Conversely, a service lacking sensitive information and possessing a restricted access scope may not require the same level of emergency response. Rather than spending identical costs on all systems, this approach sets priorities based on potential damages upon an accident and current exposure levels.
Services operated by outsourced contractors cannot be excluded from this assessment. Writing security responsibilities into a contract and immediately securing the records needed in the event of an incident are two separate matters. For example, agreements must be in place specifying which company can freeze an account when abnormal nighttime access is identified, who holds connection logs, and when they are delivered. Putting NIST's recommendation—to involve suppliers in incident response and recovery planning—into actual practice translates into this type of consultation.
Finding Missing Pathways Rather Than Merely Adopting Multi-Factor Authentication
Strengthening authentication should not end as a mere race of adoption rates. Even if multi-factor authentication (MFA) is applied to employee login screens, protection levels can vary if outdated administrator screens or separate account recovery pathways are operated differently. The scope the company must verify extends beyond regular employees' initial logins to include partner accounts, administrator privileges, device replacements, and account recoveries.
In guidance released on April 23, 2026, the NCSC recommended using passkeys when supported by services, and using conventional two-step verification when unsupported. FIDO2 authentication, including passkeys, increases phishing resistance by binding authentication to legitimate services. However, this does not eliminate the security of terminal and credential management means, nor does the necessity for account recovery and revocation procedures disappear. This is why account management cannot be considered complete simply because a specific authentication product was purchased.
It is rational for a company's adoption sequence to be determined according to tasks and privileges. Enhanced authentication should be prioritized for areas with high impact upon compromise, such as administrators or external access accounts, while areas difficult to use in the field should be designed alongside alternative procedures. If employees experience inconvenience to the point where they cannot perform normal work, they will request separate accounts or temporary access. Operational measures, including recording the reasons why exceptions are needed and their allowed duration, and revoking them upon expiration, must be included for authentication policies to remain genuinely viable.
Evaluating AI Security Product Performance Through Post-Alarm Actions
AI-utilized defense can assist in organizing logs and connecting disparate abnormal signs. However, operational judgment remains between the stage where tools display warnings and the stage where access is actually blocked. Even if dangerous accounts are discovered, if the person in charge cannot be located or if one waits for business interruption approval, the benefits of accelerated detection diminish. Plans to introduce AI analytical functions must incorporate processes defining who takes 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 discovers them, but also the delivery time to the person in charge and the accuracy of the actions. More important than the result of generating numerous alarms is how well normal business operations were disrupted less while ensuring dangerous situations were not missed.
It is also reasonable to divide the scope of automated response based on the impact of actions rather than expanding it all at once. Easily reversible tasks like log collection and incident classification can be automated first, while actions impacting customers and revenue, such as transaction suspensions or large-scale account freezes, should have approval conditions attached. Operations departments gain the grounds to expand automation scope only when they can review the rationale behind AI-suggested actions and reverse erroneous judgments.
In particular, if the AI used for security tasks itself accesses customer information or administrative tools, its privileges must be designed separately. Starting by providing only the data necessary for analysis while separating the authority to alter actual systems is the baseline. Granting broad read and write privileges solely for the purpose of defense concentrates excessive influence into a single tool. Companies adopting AI must include newly created access pathways within their management scope alongside defense against external attacks.
Preparing for Post-Leakage Damage and Business Recovery
The impact of a data breach does not end simply 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 corporate incident notifications should not merely demand password changes, but must be specific about which information was affected and what points of contact 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 precisely because the information is accurate. It is advisable for companies to establish official notification channels and contact methods that customers can independently verify, and clearly communicate actions that will never be requested under the pretext of incident response. There is also a need to manage confirmed facts and scopes still under investigation in the same document so that the counseling department and the security department do not issue differing explanations.
In recovery, a distinction must be made between the fact that servers have been powered back on and the fact that normal business has resumed. If customer inquiries are possible but order processing or settlement fails, the business remains at a standstill. In the finalized April 2025 revision of its incident response guidance, NIST explains the integration of detection, response, and recovery into organization-wide cyber risk management. This directs preparations toward a process where the actual operations of sales, customer service, and partners are restored, rather than ending with a security team's tabletop exercise.
If everything cannot be recovered simultaneously during an incident, priorities must be predetermined. Depending on the company, functions that must be maintained first—such as payment approvals, shipping instructions, or customer notices—may vary. Business owners must set the tolerable downtime and restoreable data criteria, 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 redundancies to all operations.
Reports Provided to Management Must Also Change
This issue serves as an opportunity to change the questions asked in security reporting. In addition to counting how many solutions were installed and how many training sessions were conducted, management should check how many critical external systems lack designated responsible parties, and how long temporary blocking and final modifications take respectively after a risk is discovered. The adoption rate of enhanced authentication should also be read not just by total employee count, but by how well critical privileges and external access pathways are protected.
These figures are metrics for internal improvement and do not constitute a safety score universally applicable to all companies. Fast blocking is not necessarily a good response. Other losses can occur if legitimate customers are repeatedly blocked or if systems are initialized without preserving evidence. Therefore, response times must be compared alongside false positives, business disruptions, and recovery test results. A structure is required where the Chief Information Security Officer (CISO) explains technical risks, business owners present the impacts of disruption, and management determines resource allocation and permissible thresholds between them.
The challenge left to businesses by the commercial bank breach incident does not end with fearing AI's capabilities. If attackers can perform tasks with fewer personnel and less time, defending organizations must also reduce the latency spanning from discovery to action. Systems opened for business convenience, information left behind beyond necessity, privileges granted exceptionally, and response procedures with unclear owners are the starting points. Investments in AI defensive capabilities can hold clearer value in organizations where these fundamental controls genuinely function.
