AI vs. AI Cyber Warfare: Defense Strategies and a 30-Day Plan for Small Teams

AI-versus-AI cyber conflict refers to a situation in which attackers use AI agents to advance reconnaissance and intrusion, while defenders also use AI to support detection and investigation. For small operations teams, the three priorities are: preventing intrusion, limiting the spread of damage, and noticing anomalies and recovering.

AI can continuously perform multiple tasks, but its capability and success rate vary depending on the target and the permissions granted. Before assuming that "introducing AI will provide protection," check your public-facing assets, patch priorities, administrator privileges, notification contacts, and recovery procedures.

This article is aimed at IT managers and development leads running small teams in Japan and Thailand. It organizes publicly reported attack cases and our own validation tests, and presents measures to take within the first 30 days, as well as the scope that can be entrusted to defensive AI. The 30-day plan is an example of a sequence to follow. Any critical weakness where an ongoing breach or exploitation has been confirmed should be addressed immediately, on the spot.

AI agents can repeatedly use tools to investigate a target, read the results, and choose the next action. When attackers exploit this mechanism, it automates the search for weaknesses and post-intrusion investigation.

However, success in training materials, publicly reported intrusion cases, and success in an actual company's own environment are each subject to different conditions. Below, we read each record while distinguishing what exactly it confirms.

ARTEX, which our company uses for validating penetration testing, is a platform in which an AI agent operates tools to investigate a target and report results. In a previously published validation article, we reported that, when combined with GLM, we confirmed execution on the server for two types of weaknesses intentionally set up in a custom-built PHP application.

RCE is a state in which code can be executed on a server from an external source. The tests were conducted in a controlled, local environment; the AI was not shown the application's internal code and investigated via HTTP communication. In the second case, the specific location of the weakness was not disclosed, but since the target and the investigation goal were specified, this was not a "zero-hint" test.

According to the DB measurements in the original article, the time from task creation to detection result registration was 104 seconds for command injection and 305 seconds for the upload-based case. These are single successful instances for each training material. They do not include application setup, environment configuration, human verification, or cleanup. They do not represent an average attack time, a discovery rate for unknown weaknesses, or a success rate in real-world systems. This is also distinguished from tests that reproduced the "PHP2Shell" vulnerability in PHP itself.

In editing this article, we confirmed consistency with the content reported in the original article. We did not independently re-obtain the raw communication logs or the original database timestamps, nor did we conduct re-execution of the attack or comparative testing after fixes were applied. What can be concluded from this is that in a training scenario with controlled conditions, the process from exploration to execution confirmation can proceed in a matter of minutes.

Anthropic reported that an attacker it assessed with high confidence to be a Chinese state-sponsored group exploited Claude Code to attempt intrusions into roughly 30 organizations, succeeding in a small number of cases.

By the company's estimate, AI handled 80-90% of the operational work, with human intervention required at 4-6 critical decision points per operation. This ratio is an estimate of the division of labor within that particular operation; it does not represent the success rate of the attack, nor does it suggest that all attacks can be automated to the same degree.

AI handled tasks such as target investigation, vulnerability verification, and organizing credentials and data after intrusion. At the same time, there were also errors, such as reporting credentials that did not exist or treating publicly available information as confidential. Anthropic's published report

What defenders need to grasp is both that automation increases the volume of processing, and that errors get mixed into the results. The fact that human intervention remains necessary does not mean the attack can be dismissed as minor, nor can breaches or safety be determined solely based on an AI's report.

Translating these cases into defensive design, three priorities emerge. These are the recommendations of this article.

1. Grasp your public-facing assets. Attackers can access entry points that your organization is not even aware of.
2. Limit damage before humans notice. Since the training materials showed processing advancing within minutes, don't rely solely on manual work after notification—put input restrictions and privilege separation in place beforehand.
3. Don't leave known weaknesses and authentication gaps unaddressed. In addition to AI-specific countermeasures, continue applying patches and verifying identity.

Mandiant's M-Trends 2026 reports that, among the breaches the company investigated worldwide, the initial intrusion vector was exploitation of vulnerabilities in 32% of cases and phone-based phishing in 11%. This is a breakdown of the company's investigated cases, not statistics exclusive to AI-driven attacks. M-Trends 2026

The rate of increase in AI-driven attacks cannot be derived from this figure. In practice, preparation for AI should be carried out within the same operational framework as the basic measures of patching, authentication, and recovery.

Intrusion prevention, damage mitigation, detection, and recovery are layered together. No single measure can guarantee safety, but even if entry-point defenses are breached, restricting privileges and communications can limit the impact, and logs can support the response.

The following is an example of implementation and operation based on the weaknesses of the training material and public defense guidelines. The ARTEX test did not actually measure the effectiveness of all three stages.

First, inspect both the application implementation and the server configuration. The starting point is to ensure that input coming from outside is never passed to dangerous processing.

OWASP recommends prioritizing replacement with a library or API instead of directly invoking OS commands. Even when a call is necessary, separating the arguments alone does not make the input safe; it must be combined with validation of both the command and its arguments. OS Command Injection Defense Cheat Sheet

For uploads, do not trust the Content-Type sent by the user alone; check the extension, content, storage location, and access permissions together. Simply listing rejected extensions misses other formats and the effects of server configuration. File Upload Defense Cheat Sheet

Setting up a defense measure and having it function as expected are two different things. Record who made the fix and who verified it, and keep a pair of records: verification using the problematic input and verification that normal functionality still works.

Decisions are made by combining actual exploitation, reachability from your own organization, privileges that could be seized, and business impact. Simply lining up severity scores does not tell you where your organization is most exposed to harm.

CISA's KEV (Known Exploited Vulnerabilities) is a catalog of vulnerabilities confirmed to have been exploited. It can be checked via CISA's official data and description. However, not being listed in KEV is not proof of safety, and not all weaknesses in a custom-built application will be listed there either.

The following table is an example of decision-making for use by a small team. It is not a table showing official remediation deadlines or a uniform legal obligation.

The person in charge checks not just the product name but also whether the version and configuration match the conditions for impact. A match in the KEV lookup alone does not mean an actual breach has occurred. Conversely, the absence of evidence of a breach does not mean a fix is unnecessary.

If a fix cannot be completed within the deadline, record the reason, the interim measure, the remaining risk, and the re-check date, and have the business owner approve it. Deciding in advance who should be notified and who makes the decision helps avoid a situation at night or on holidays where "no one decides to stop anything."

Preparing for post-intrusion scenarios means reducing the privileges, credentials, and communication paths an attacker could use. Even a small team can start by checking the following areas.

• Do not run the application as an administrator; limit it to the privileges necessary for that task.
• Separate credentials by purpose, and revoke unused keys or accounts.
• Understand and restrict outbound communication from the server to necessary destinations and purposes.
• Set up multi-factor authentication for administrators, and require identity verification for authentication resets and privilege additions as well.

Even after implementing multi-factor authentication, check for pathways through which settings could be changed, such as phone requests to the help desk. Instead of relying solely on the contact information specified by the requester, establish a procedure to verify through a separately registered channel.

For detection, don't just store logs—treat the following events as monitoring candidates. Since some of these may be normal depending on the environment, don't assume a breach outright; cross-check whether the activity was authorized work.

1. A web application process launched an unexpected shell or child process.
2. An unexpected executable format or configuration file was created in the upload destination.
3. An administrator was added, or important privileges were changed.
4. Communication to an unusual destination or a large data transfer occurred.

Notifications should include the target, time, observed facts, and where to verify. Once a detection rule is created, test it all the way through—confirming the notification reaches the responsible person and can be handed off to an alternate when they are unavailable. Decide in advance how to respond during hours with no monitoring, including the use of external services.

The retention period for logs should be decided based on the time needed for investigation, contracts, handling of personal data, and cost. In the M-Trends 2026 survey sample, the median time from intrusion to discovery was 14 days, but this is not a basis for setting the required retention period at 14 days. Make sure records from endpoints, authentication, and cloud services can be cross-referenced by time, and also store them somewhere that is not easily deleted from a compromised environment.

For recovery, don't stop at confirming that a backup was successfully taken—actually restore the data needed for business operations and verify that the application works. Separate backup management privileges from normal operational privileges, and record the time taken for recovery and the point to which data was restored. If a breach is suspected, restoring to the same state without checking the cause or credentials could lead to re-intrusion.

For the first 30 days, use an example plan that advances asset inventory, fixes, detection, and recovery on a weekly basis. Urgent issues should be addressed without waiting for the end of the week. If a lack of multi-factor authentication or an inability to recover is discovered, move the plan forward as well.

Even if the same person is responsible, separate the role of doing the work from the role of approving the remaining risk. If a small team cannot assign a separate verifier, decide on a decision-making path that includes management or an outsourced maintenance provider. Do not set the completion criteria as "prevented through the diligence of the person in charge."

The work ledger should include at least: target, issue, person in charge, deadline, evidence of completion, remaining risk, approver of exceptions, and next review date. It is also important not to bury cases with signs of intrusion within the regular update-waiting list.

After 30 days, focus on whether gaps have been reduced rather than on increasing the number of list entries. Recording the number of public-facing assets with unknown ownership, overdue critical items, failed notification tests, and scope that could not be restored in recovery drills makes it easier to decide where to spend time next.

AI-based information organization can be tested in parallel with this work. However, this is premised on not leaving asset list updates or emergency communications entirely to AI's judgment.

In addition to contacts at each site, decide who will make the overall decisions on isolation, resumption, and external communication. The time difference between Japan and Thailand is 2 hours. Create a list covering nights and holidays at both sites, including the primary contact, backup personnel, and how to contact the maintenance vendor.

For example, even if a staff member in Japan discovers an anomaly, if they lack the authority to stop a system running at the Thailand site, time will be wasted simply on communication. Confirm in advance who can stop the system, who approves the stoppage, and who decides on customer communication, and also determine the handover contact when the primary person is unavailable.

So that the person receiving the report can begin investigating, the initial report should include the following:

• The time and time zone of discovery, and the occurrence time to the extent known.
• The affected system, the observed anomaly, and the business operations suspected of being impacted.
• Any isolation or stoppage actions already taken, and who performed them.
• Where the original logs and evidence are stored, and what has not yet been confirmed.

When staff in Japan and Thailand cross-check logs, align the time notation. If Japan time, Thailand time, and UTC are mixed together, there is a risk of misreading the sequence of operations. Also decide on operating rules so that personal data or authentication information is not pasted as-is into broad communication groups.

If a leak is suspected, hand off to the legal and personal data protection staff in parallel with the technical investigation. Discuss in advance who reports what, to whom, and when, and train so that reporting can happen without waiting for the investigation to be complete. Do not decide whether notification is required, or the deadline, based on this procedure alone — have the responsible staff confirm the applicable laws and regulations.

When checking Thailand's system, use the PDPA and AI Usage Checklist as a starting point, then proceed to official documents and expert review. In this article, the completion condition is reaching a state where the team can begin technical response and handover.

Start by trying defensive AI for initial alert investigation, identifying affected assets, and inspections in approved environments. In the initial rollout, having AI present candidates with supporting evidence while humans decide on the response makes it possible to measure errors and the burden of verification.

Don't fix the rollout timing by number of days — decide based on whether the data handled and the permissions involved can be restricted.

Choose where to introduce it not based on "work AI can handle," but based on notifications that humans cannot fully read through, or tasks where confirming impact takes a long time.

If, during initial rollout, you have AI automatically apply fixes, change permissions, or send external notifications, the impact of errors becomes larger. Start with a design that grants no execution authority, and carries out actions through existing operational procedures only after approval.

For example, a summary like "This server is safe" alone cannot be verified by staff. Have the AI produce "which logs were checked, during what time period and under what conditions, what was found, and what could not be confirmed." Make it a condition for adopting any output that one can trace back to the log lines and asset information the AI cited.

Measure effectiveness by comparing, across similar cases, the time taken for investigation, time to remediation, oversights, and the time humans spend on verification. Even if AI's processing time is short, if extra time is needed to verify errors, the overall burden on the team will not decrease. Before rollout, decide the evaluation targets and the conditions for discontinuation, and judge based on a small scope.

Logs, code, and emails that AI reads may contain content an attacker can write into. The problem where instructions embedded in such content steer AI's judgment or actions is prompt injection.

Google GTIG reported that malware associated with TeamPCP (UNC6780) contained text aimed at causing AI security scanners to fail analysis or skip content. This is an analysis of the attacker's intent, not proof that detection evasion succeeded against all scanners. GTIG's report

OWASP states that it is unclear whether there is a reliable way to prevent prompt injection, and presents countermeasures combining least privilege, human approval, and separation of external input. OWASP's overview

When introducing this, check the following five points:

1. Retain the original data and processing scope. Cross-check, on the program side, the number of items passed to the AI, the number processed, and the target period, to catch omissions or failures. Since matching counts don't guarantee correct content, also perform spot checks.
2. Control permissions outside the AI. Restrict the operations and targets that can be executed through the app or authorization mechanism. Prohibiting something only in the instruction text does not constitute a permission restriction.
3. Restrict the scope of reading and the destinations of sending. Do not pass authentication information or unnecessary personal data, and check the conditions for sending to external AI services. Even for read-only access, inspect any pathway through which information could be extracted.
4. Separate external input from instructions. Pass logs and emails as untrusted data, and test designs that prevent any commands contained within them from being treated as operational instructions. Do not evaluate this as a complete safeguard just because the data is passed separately.
5. Decide behavior on failure and handoff to humans. When evidence is insufficient, the format is invalid, or a timeout occurs, leave the item unprocessed and route it to a human. Do not automatically mark it as "no issue found" or "response complete."

Even when misleading command text is inserted into approved test data, check whether it exceeds restrictions on sending destinations or permissions, and whether abnormal records are dropped from the summary. If incorrect completion judgments or unauthorized operations/transmissions are found, decide in advance the criteria for stopping automated processing and returning to human review.

The original ARTEX article also contains a record of a review timing out due to a defect in the response format of the model reviewing the operation. The ability to detect issues and the proper functioning of the review process must be verified separately.

Confirm the necessity of AI, the scope to inspect, and the first steps to take.

For your own systems as well, check the terms of service and outsourcing agreements, and implement only within the scope where the target, time window, permitted operations, and stop conditions have been approved. First, use an isolated test environment and restrict the test from spreading to shared infrastructure or external services. Plan through to deleting any deployed files and resetting the environment, and cross-check the AI's reports against communication and output logs.

Introducing AI is not necessarily essential. First, establish asset discovery, remediation, access restriction, notification, and recovery for publicly exposed assets. If humans cannot keep up with reading all the notifications, or if confirming impact takes too much time, try a defensive AI as an evidence-based investigation aid, and judge its effectiveness by weighing both missed cases and the confirmation workload.

In the first week, confirm the following four points:

1. List out public-facing assets and their owners.
2. Check whether any known, actively exploited vulnerabilities apply.
3. Confirm multi-factor authentication for administrators and emergency contact information.
4. Test whether necessary data can be restored from backups.

For any unresolved issues, assign an owner, a deadline, and an interim measure. If an ongoing breach is suspected, prioritize incident response over this improvement plan.

Preparedness for a small team means combining intrusion prevention, damage containment, and detection and recovery. Regardless of whether AI is used, reduce exposed weaknesses, excessive privileges, notifications that go unnoticed, and backups that cannot be restored.

The first action is to open your list of public-facing assets and check for targets with no clear owner and for any known, actively exploited vulnerabilities that apply. For each issue, assign an owner, a deadline, and evidence of completion, and also decide on an interim measure and an approver in case it cannot be fixed. Use the 30-day plan to complete one full cycle of this process.

Start defensive AI as an investigation aid that can be rolled back to the original record. Restrict its inputs, permissions, and destinations, make errors and processing failures visible, and keep the decision on marking a response complete or making significant changes in human hands. Measure the effectiveness of adoption by weighing speed against missed cases and the confirmation burden together.

You can check the experimental conditions in RCE Validation with ARTEX×GLM, the mechanics of the tools in An Explanation of Strix, Cairn, and Hermes, and the overall picture of related risks in Latest Trends in AI Cybersecurity.