The Weak Link Identified by AI: October 2026, When the Outer Contact Point Collapsed
Security Blind Spots Identified by AI
The large-scale data breaches disclosed in quick succession in South Korea and Japan in October 2026 mostly originated not from internal core systems, but from peripheral entry points such as externally exposed web services, app backend APIs, and outsourced SaaS (services provided by third-party vendors via the cloud, such as email delivery or backup). During the same period, vulnerabilities allowing unauthenticated remote code execution were disclosed one after another in widely used software such as web backend runtimes (e.G., PHP and Node.Js) and GitLab, and there were also numerous reports that AI agents, such as ARTEX, were used in actual breach operations.
In South Korea, starting in late September, a series of breaches swept through the financial sector—beginning with commercial banks and extending to savings banks, finance companies, mutual financial institutions, virtual asset service providers, and insurance companies—while data breaches were also confirmed in the non-financial sector, including corporate accounting software providers, large churches, universities, and franchise chains. In Japan, announcements of personal data breaches ranging from several million to tens of millions of records were made during the same period, and Japanese government agencies identified a method involving the analysis of publicly available apps to attack backend servers as one of the primary causes.
This trend is not limited to these two countries. During the same period, breaches involving outsourced services and publicly exposed websites, as well as large-scale automated attacks using AI agents, were reported in the US, Europe, and South America. This article synthesizes publicly available news reports, announcements from various agencies, and reports from security firms to identify common patterns in these incidents—with a focus on South Korea and Japan, where cases were most heavily publicized—and examines how these same patterns are being observed overseas. Based on this analysis, the article proposes preventive and response measures that companies should implement. The causes of individual incidents are mostly under investigation; organizations affected by damage are categorized by industry based on public reports.
South Korean Financial Sector: The Start of a Chain of Breaches
Breaches in the Korea financial sector began at commercial banks in late September and spread across the entire industry over the course of a month. As of October 14, financial authorities had identified 16 financial institutions affected by the breaches, including commercial banks, savings banks, finance companies, mutual financial institutions, electronic financial service providers, online investment-linked financial service providers, and virtual asset service providers; the confirmed scale of personal information leaks was approximately 100,000 records. However, considering the number of affected financial institutions, the scale of the leak is assessed as relatively limited; this suggests the possibility that the incident involved the retrieval of individual records through external access points—such as publicly exposed inquiry services—rather than the theft of a large-scale database (DB) itself. Subsequently, on October 26, a data leak was also reported in the insurance industry.
It is noteworthy that the attack targets were not the banks’ core IT systems responsible for processing deposits and transfers. According to the disclosed information, the paths of entry were auxiliary systems attached to the main services—such as inquiry services exclusively for loan brokers, sales support systems for internal employees, and external webpages related to mutual aid programs.
|
Category |
Point of Compromise |
Disclosed Information |
|
Commercial Bank A |
Inquiry service exclusively for loan brokers |
By bypassing standard authentication and repeatedly entering query values, loan-related information for approximately 25,000 people was leaked |
|
Commercial Bank B |
Employee Sales Support System (ODS) |
Unauthorized access to a system separate from internet and mobile banking led to the leak of information on 89 people |
|
Mutual Finance |
External webpage related to mutual aid |
Damage was not detected until two days after the attack |
[Table 1] Major Security Breaches in the Korean Financial Sector and Affected Institutions
In an emergency inspection conducted by financial authorities in early October targeting 555 financial institutions, 130 reported deficiencies. The main deficiencies included failure to apply the latest security patches, poor management of systems no longer receiving technical support, and the lack of a 24-hour monitoring system. It is more accurate to say that the threat actors quickly identified poorly managed peripheral systems rather than employing new techniques.
Traces of ARTEX, an AI-powered automated penetration testing tool, were identified in this attack on the financial sector. The Korean security industry first discovered ARTEX-related strings on the web server used in the attack, and CrowdStrike obtained ARTEX configuration files and work logs from AI coding tools found in an exposed folder on the threat actor’s server. Analysis indicates that the threat actors connected and used several large language models (LLMs), such as DeepSeek, GLM, and Grok, with ARTEX. However, the threat actors’ identities and nationalities have not been confirmed.
Breaches Spreading Beyond the Financial Sector
Data breaches also continued outside the financial sector during the same period. Although the affected organizations spanned diverse sectors—including enterprise accounting software providers, large churches, coffee franchises, universities, and education districts—the points of compromise were consistently access points outside core business systems, such as employee VPN accounts, external backup solutions, temporary files left in the cloud, portals, and cloud accounts used for training.
|
Category |
Point of Breach |
Disclosed Details |
|
Enterprise accounting and ERP software providers |
Employee VPN accounts, external backup solutions |
Evidence suggests unauthorized access to development servers via VPN accounts and the partial exfiltration of encrypted data through a vulnerability in the backup solution The government has classified this as a major incident and formed a joint public-private investigation team |
|
Large Church |
Church information system |
Data breach involving the names and dates of birth of approximately 850,000 congregants |
|
Coffee franchise |
Temporary data files left on the cloud |
Approximately 2.76 Million records leaked during unauthorized access attempts aimed at cryptocurrency mining Caused by temporary files from a past Service overhaul |
|
University |
Portal Service |
Student ID numbers, contact information, and email addresses of approximately 10,000 current students and alumni were leaked |
|
Office of Education |
Cloud accounts for learning |
Over 110,000 accounts hacked across six education offices, causing damage |
[Table 2] Major Data Breach Cases and Points of Compromise in Korea’s Non-Financial Sector
Among these, the case involving a corporate accounting and ERP software provider highlights supply chain risks stemming from third-party contractors. Since this company’s accounting software is used by more than 110,000 businesses, concerns have been raised that a single breach could spread to the payroll and tax information of employees at client companies. However, the actual scope of the data breach is still under investigation. The coffee franchise case involved temporary data files created for a past service overhaul that remained in the cloud and were subsequently leaked, illustrating that data past its retention period poses a risk if not properly disposed of.
In late October, a suspect accused of hacking using generative AI was arrested in Korea for the first time. According to police, the ringleader had no formal IT background but taught himself the technology and had prior experience conducting penetration testing at a security firm. This group combined ARTEX with an AI coding agent to carry out Information Theft on approximately 8.2 Million records—including personal information—from about 90 companies in Korea; notably, they attacked 60 of these companies over a 44-day period starting in late August. Police stated that no direct link had been confirmed between this incident and the financial sector incident.
The Same Pattern Repeated in Japan
Japan also saw a concentration of announcements regarding large-scale data breaches during the same period. According to data compiled by the Japanese security firm Marknica, announcements of personal information leaks through web systems operated by Japanese organizations totaled 119 as of October 6, 2026, already surpassing the 84 cases reported for all of 2025 and the 62 cases in 2024; 81 of these occurred after July.
Japanese authorities identified backend attacks through apps as one of the causes. On October 13, the National Institute of Information and Communications Technology (NICT) analyzed publicly available Android apps to identify the target servers and API structures, then named the method of exploiting server-side vulnerabilities “A2B (App-to-Backend) attacks.” The vulnerabilities primarily targeted include SSRF, RCE, SQL injection, and IDOR/BOLA; even if the app itself has no flaws, data leaks can occur if there are vulnerabilities in the server-side API. On October 8, JPCERT/CC also identified the following as major attack types: exploiting existing vulnerabilities, abusing administrative APIs through app analysis, exploiting an SQL injection vulnerability (CVE-2026-72898) in the BI tool Metabase, and installing web shells. However, since neither organization identified specific companies that suffered damage, it is not possible to definitively classify a particular incident as an A2B attack.
| Category |
Point of Compromise |
Disclosed Information |
|
Software Sales |
Member Information Query API |
The API was misused for four days, potentially leading to the leak of up to approximately 22.52 Million records of member information, including passwords |
|
Major Discount Store |
App and Online Store Servers |
Unauthorized access gained by exploiting software functions that make up the Service, resulting in the leak of information on up to approximately 1.73 Million people |
|
SaaS Company |
API servers for an email-sending SaaS service |
Command execution occurred on two API servers, resulting in the export of all subscriber information and the mailing lists of some customers |
|
Japanese subsidiary of a food brand |
Outsourced e-commerce platform |
A software vulnerability in the outsourced vendor’s server was exploited, resulting in the leakage of approximately 3.14 Million records |
|
Department store group |
Reservation Site → Customer Management System |
Access to the customer management system via the reservation site; approximately 1.26 Million records—nearly the entire membership base using the group’s common ID—were leaked |
|
News Platform |
Business Management Tool |
A vulnerability in the management tool could lead to the leak of approximately 323,000 records, including email addresses |
|
E-book Service |
System log files |
In addition to 319 records from the member database, up to approximately 4.2 Million records of information remaining in log files were leaked |
|
Securities Firm |
Outsourced FAQ System |
Possible leak of information on approximately 110,000 people due to a breach of an external Service used for managing inquiries |
|
Cloud Service Provider |
Cloud Infrastructure |
Ransomware attack caused service disruptions for 495 clients, including local governments and businesses |
[Table 3] Major Data Breach Cases in Japan and Points of Compromise
In most Japanese cases as well, the point of origin was peripheral systems rather than core systems. In particular, the department store group case involved a single reservation site that led to the group’s entire shared ID database, while the e-book service case demonstrated that even if the member database was protected, information could still be leaked if the same data remained in the logs.
ARTEX was also identified in Japan. On October 19, the Japanese security firm GMO Cyber Security by Iera announced that it had detected traces of ARTEX in the attack infrastructure used to attack companies in Korea. Eight of the companies identified by the firm as targets announced data breaches in September and October. However, the names of these companies were not disclosed, and there is no evidence to suggest they were the work of the same threat actors responsible for the attacks in South Korea. At this point, it has only been confirmed that the same tool was used in both countries.
Simultaneous Revelations of Critical Vulnerabilities
During the third week of October, serious vulnerabilities in foundational software for the web and infrastructure were disclosed in rapid succession over the course of approximately a few days. Since many of these were components directly exposed to the internet, this further heightened the risk at the perimeter.
|
Scope |
Target |
CVE |
Impact |
Action |
|
Web Runtime |
PHP |
CVE-2026-109618, CVE-2026-109619 (CVSS 9.2) |
Unauthenticated Remote Code Execution (PHP2Shell) |
Update to version 8.5.12, 8.4.27, 8.3.36, 8.2.35, Or later. For versions 8.1 And earlier, switch to a supported version Set `session.Upload_progress.Enabled=0` until an official patch is released |
|
Web Runtime |
PHP |
CVE-2026-115560 (CVSS not disclosed) |
Remote code execution under specific session settings |
Set `session.Upload_progress.Enabled=0` until an official patch is released |
|
Development Platform |
GitLab CE/EE |
CVE-2026-110264 (CVSS 10.0) |
Unauthenticated remote code execution via a regular expression compiler integer overflow Affects versions starting with GitLab 7.0 (2014) |
19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13 And later |
|
Server Runtime |
Node.Js 22, 24, 26 |
CVE-2026-111497 (CVSS 9.2) |
Remote code execution via Brotli decoder buffer overflow (Node2Shell) |
22.23.4, 24.22.1, 26.12.1 And later |
|
DNS |
Unbound 1.22.0–1.26.1 |
CVE-2026-97206 (CVSS 7.5) |
Remote Denial of Service when using DNS-over-QUIC |
Version 1.26.2 Or later, or disable DoQ |
|
DNS |
ISC BIND 9 |
CVE-2026-19630 and 3 others (CVSS 7.5) |
Denial of Service, GSS-TSIG memory corruption (CVE-2026-94300, potential remote code execution) |
9.20.30, 9.21.27 And later |
|
PKI |
8 EMudhra intermediate CAs |
N/A |
Private keys are generated in a state where they can be easily recovered, enabling certificate forgery |
Update the trust stores in browsers, operating systems, and runtimes |
|
PKI |
Oracle Java JSSE |
CVE-2026-91403 (CVSS 9.1) |
Java update that treats eMudhra-related intermediate CAs as untrusted |
Apply the latest updates for Java SE and GraalVM |
|
File Sharing |
Windows SMB Server |
CVE-2026-96325 (CVSS 7.5) |
Unauthenticated Remote Service Denial of Service |
October Regular Security Updates Applied |
[Table 4] Status of Major Vulnerability Disclosures in October 2026
PHP2Shell illustrates just how short the response time has become. Information about the vulnerability was leaked externally before the Vulnerability Patch was released, and Amazon Threat Intelligence had already detected attack attempts on October 17—four days before the official disclosure. In Korea, the government also raised the cyber threat alert level for the private sector from “Attention” to “Caution” on October 22. Therefore, even for servers that have been patched, it is necessary to check access logs from the period before and after the disclosure and verify whether a web shell has been installed.
Oracle Java’s CVE-2026-91403 is not a general patch to fix a code flaw, but rather an update that prevents Java from trusting the compromised eMudhra intermediate CA certificate. Since runtimes that use their own trust stores—such as Java—and older clients must be updated separately even if browsers have blocked the certificate, PKI issues cannot be resolved by server patches alone.
AI is also playing an increasingly significant role in the vulnerability discovery process. CVE-2026-94300 in BIND was reported by a researcher at OpenAI, and the official Node.Js announcement credited CVE-2026-111497 to OpenAI Codex Security. While this represents legitimate vulnerability research by the defense community, the fact that the same capabilities can be exploited by attackers suggests that patch cycles are likely to become even shorter in the future.
Agentic AI Attacks: From Experimentation to Real-World Application
Attacks in which AI agents autonomously carry out a sequence of actions—including reconnaissance, vulnerability scanning, penetration, and web shell installation—have begun to emerge as actual breach cases. Key reports released in October include the following as follows
|
Reporting Entity |
Tools |
Details Disclosed |
|
ARTEX |
AI coding tool activity logs and ARTEX configuration files found on threat actors’ servers targeting South Korean financial institutions Evidence of DeepSeek, GLM, and Grok usage |
|
|
ARTEX and variants |
Tracked 600 IP addresses of ARTEX operational systems exposed to the internet; this number had increased to over 900 as of October 14 Secured 51 pieces of attack operation data—including web shell command transmissions, internal RDP relaying, and internal network scan results—from open directories on some hosts Traces of redistributed versions—which changed their names and user interfaces after the original repository was deleted—and Korean localization were also identified |
|
|
Cairn |
An investigation of exposed Cairn management screens revealed more than 1,100 attack projects in the largest cluster Over 1,200 sites were attacked, compromising more than 100 corporate websites. The total cost of the tokens was approximately $5,000 |
|
|
ARTEX |
Confirmed use of ARTEX in attack infrastructure targeting Japanese companies |
|
|
ARTEX |
China-linked group Storm-0940 attacks hundreds of organizations worldwide using ARTEX The group exploited the credentials of a US IT managed services provider’s cloud backup app to attempt logins to more than 2,250 Microsoft 365 tenants; in some cases, they gained privileged access to the cloud within three hours of being targeted for the first time |
|
|
Various Harnesses |
Four new threat actors observed between May and August disclosed Includes breaches at at least 15 Argentine healthcare institutions All four bypassed the safety mechanisms of commercial AI |
[Table 5] Reported Real-World Infiltration Cases Using Agentic AI
We also replicated ARTEX in a separate Test Environment to verify the extent of its autonomous penetration capabilities. We provided only a brief instruction—such as “Penetrate the Attack Target”—simple enough for even a user with no security knowledge to enter, yet ARTEX identified the file upload function on the web server and executed a program as a web shell without any human intervention. In an environment where Apache ActiveMQ was exposed, ARTEX gained initial access via a known vulnerability (CVE-2023-46604) and proceeded to perform remote command execution on four internal hosts. Since both experiments did not involve new techniques but instead exploited vulnerabilities and misconfigurations in publicly accessible services, they align with this article’s assessment that peripheral entry points are the primary targets for AI agents.
Furthermore, even after the original GitHub repository was removed, ARTEX continues to be reused by various operators under different names and with modified interfaces. The redistributed versions verified by our company contained configurations for various LLMs—including DeepSeek, GLM, Kimi, and Claude—as well as traces of a publicly available PoC for an e-commerce platform vulnerability (CVE-2026-75650) exploitable without authentication and embedded IRC-based remote control code. This means that even if the developer stops releasing the tool, its spread does not stop.
What these reports reveal is a shift toward the economics of attack. In the Cairn case, the operator entered only a Chinese command of less than 100 characters, after which the agent—without human supervision—figured out how to perform code execution on each site and installed a web shell. Repetitive tasks that once required skilled personnel—such as vulnerability scanning, testing attack paths, modifying payloads, and retrying after failures—are now being entrusted to agents that work nonstop for hours on end. As it has become easy to combine open-source AI models with freely available agent frameworks, cyberattacks that once required advanced technical skills are now within anyone’s reach. Cases of non-technical hackers apprehended in Korea illustrate this, and the cost of carrying out such operations is dropping just as rapidly.
The Microsoft case also illustrates where these attacks are headed. Storm-0940’s brute-force password attack generated up to 2,900 failed login attempts per minute but did not result in a single successful login. The actual breach occurred through the app credentials of a third-party service to which the customer had already granted access. While direct authentication held up, a trusted external connection was breached.
The extent to which tools like ARTEX were actually involved in incidents within the Korean financial sector is still under investigation. However, even based on publicly available reports alone, it is clear that attacks using AI agents have moved beyond the hypothetical stage and are being used in actual breaches, and the disclosed cases are likely only a fraction of the total.
Common Pattern: The Breach Occurred at Peripheral Touchpoints
When comparing cases in South Korea and Japan side by side, the patterns are nearly identical. It was not the internal core systems—where defenses are concentrated—that were breached, but rather peripheral touchpoints such as externally exposed app backend APIs, reservation sites, management tools, and outsourced SaaS services. The term “peripheral entry points” used in this article refers collectively to the externally exposed attack surface, as well as supply chain and third-party touchpoints.
|
Types of Peripheral Touchpoints |
Cases in South Korea |
Japanese Cases |
Common Vulnerabilities |
|
Externally Exposed Application Backend APIs |
Inquiry Service Exclusively for Loan Brokers |
Member Information Lookup API, App and Online Store Servers |
Inadequate authentication and authorization verification; failure to detect repeated queries |
|
Additional Web Services |
External web pages related to mutual aid, university portals |
Department Store Reservation Sites |
Security level lower than this Service; connection to core databases |
|
Management and business tools |
Sales Support System for Employees |
Business management tools, BI tools |
Accessible from outside the organization; delayed patching |
|
Outsourced SaaS, supply chain |
Backup service for enterprise accounting software |
Email-Sending SaaS, Managed E-commerce Platforms, Managed FAQ Systems |
A single breach can spread to multiple clients |
|
Accounts, credentials |
Employee VPN accounts, cloud accounts for training |
Work-related cloud accounts, administrator accounts |
Weak authentication, lack of multi-factor authentication |
|
Neglected data |
Temporary data files left in the cloud |
System log files, data on former employees |
Data past its retention period that has not been deleted |
[Table 6] Comparison of South Korean and Japanese Cases for Each Type of Perimeter Access Point
This assessment aligns precisely with the technical characteristics of AI-agent-based attacks. Rather than directly breaching highly fortified core systems, autonomous attack agents automatically scan the entire external attack surface and relentlessly exploit weak links on the periphery where security controls are relatively lax. Long-disclosed N-day vulnerabilities, configuration errors, and weak authentication are prime targets. Even minor ancillary services—which would likely be deprioritized by a human—become targets that an agent, operating at virtually no cost, will attempt to exploit without exception.
Another characteristic of peripheral entry points is that the damage does not end at that point. This is illustrated by cases where attacks spread from a booking site to a shared member database, from a third-party backup service to the data of tens of thousands of client companies, and from a third-party app’s identity to a customer’s cloud tenant. Even if peripheral touchpoints appear small in scale, they can serve as gateways to core data.
Prevention: We Must Redraw the Perimeter
The starting point for prevention is knowing exactly what an organization is exposing to the internet. Since threat actors are using AI agents to conduct comprehensive scans of external attack surfaces, defenders must also reassess their assets from the same perspective. In particular, assets that have been pushed down the management priority list—such as ancillary services attached to the main service, event pages, management tools, and APIs called by apps—should be prioritized for inspection.
|
Scope |
Inspection Items |
|
Asset Management for Externally Exposed Assets |
Compile a comprehensive list of web services, APIs, management pages, and remote access points exposed to the Internet, and assign responsible personnel. Block external access to unused services and test servers. |
|
App Backend APIs |
Assume that the app can be analyzed at any time. Verify server-side authentication and object-level authorization for all API requests, and do not embed API keys or authentication credentials within the app. Implement per-user query limits and detect abnormal repetitive queries. |
|
Management and Business Tools |
Ensure that management pages, BI tools, and sales support systems cannot be accessed directly from the outside; if unavoidable, apply IP restrictions and multi-factor authentication. Permissions for these tools to access the business database are minimized. |
|
Outsourced SaaS and Supply Chain |
Compile a list of data held by third-party providers and their access permissions. Regularly review the cloud permissions granted to third-party apps (such as OAuth consent), and specify the third-party provider’s breach notification procedures in the contract. |
|
Accounts and Authentication |
Implement phishing-resistant multi-factor authentication for VPNs, remote access, and business cloud accounts. Detect sudden spikes in failed login attempts and access from unusual locations to guard against attacks that use compromised account credentials obtained from external sources. |
|
Patches and End-of-Support |
Establish a separate procedure for components exposed to the internet (such as PHP, GitLab, Node.Js, and DNS servers) with the goal of responding on the same day a vulnerability is disclosed. Develop replacement plans for systems that have reached end-of-support, and minimize external exposure until then. |
|
Data Minimization |
We purge information on members whose retention period has expired, former employees, temporary development files, and logs containing personal information. Data that no longer exists cannot be leaked. |
|
Detection and Monitoring |
Collect logs from peripheral touchpoints at the same level as core systems and include them in 24-hour monitoring. Implement rules to detect post-compromise behavior, such as web servers executing shells or download tools. |
[Table 7] Preventive Inspection Items Focused on Perimeter Endpoints
It is also important to consider that attacks using AI agents are fast. Given that there have been cases where it took less than three hours from initial targeting to privileged access, the traditional cycle of patching within a few days after a manual inspection may be too slow to respond. Automated response measures—such as the preemptive application of web firewall rules and the immediate blocking of exposed assets—must be prepared in advance. Conversely, it is advisable for the defense side to utilize AI-based vulnerability assessments to identify weak points in the perimeter before threat actors do.
Response: When a Breach is Suspected
The scale of damage from a breach incident varies significantly depending on the speed of the initial response. In this case as well, there were instances where the damage was not recognized until several days after the attack, during which time additional data leaks could have occurred.
|
Multi-stage |
Response Details |
|
Initial Response |
Block the attacking IP addresses and exploited paths, and isolate the affected Service. To preserve evidence, do not immediately reset the server; instead, secure the logs, memory, and disk images first. |
|
Scope Verification |
Trace access trails from the compromised external endpoint to connected databases, internal systems, and third-party vendor systems. In the event that vulnerability information was leaked prior to public disclosure, review logs retroactively up to the date of disclosure. |
|
Credential Management |
Accounts, API keys, and access tokens associated with the breach path are revoked and reissued. Verify whether any persistence mechanisms, such as web shells, remain. |
|
Reporting |
In Korea, in accordance with the Information and Communications Network Act, report the breach to the Ministry of Science and ICT or the Korea Internet & Security Agency (KISA; dial 118 without an area code) within 24 hours of becoming aware of the incident. If personal information has been leaked, in accordance with the Personal Information Protection Act, notify the data subjects within 72 hours of becoming aware of the breach and report the incident to the Personal Information Protection Commission or KISA. Financial institutions must report to the Financial Supervisory Service, and cases of cybercrime must be reported to the Cyber Investigation Division of the National Police Agency. |
|
Preventing Secondary Damage |
Since phishing attacks, smishing, and brute-force attacks using the leaked information may follow, advise users to change their passwords and be wary of fraudulent contact attempts. Do not comply with any monetary demands from the threat actor; instead, consult with law enforcement agencies. |
[Table 8] Step-by-Step Response Procedures in Case of a Suspected Breach
Time to Shift the Focus of Defense
The incidents over the past month demonstrate that the center of gravity in security is shifting. Until now, many organizations have designed their defenses around core systems, but threat actors have found their way in through small entry points outside those systems. AI agents have made this exploration faster and more efficient, resulting in smaller assets—which had been neglected due to their scale—becoming the first targets.
Therefore, future defense strategies must begin by asking where threat actors can enter, rather than focusing solely on what to protect most rigorously. Asset management of externally exposed assets, API authentication and authorization, controlling connections to third-party vendors, multi-factor authentication, prompt patching, and data minimization are not new measures. However, these incidents have clearly demonstrated that if these basic measures are not applied without exception to all perimeter touchpoints, AI will be the first to find those gaps—which is why this article focuses on AI-driven automated attacks and perimeter touchpoint breaches.