What Happens When Two AI Agents Fight Over One Server?

Zero’s AI Security Experiment

In a recent Japanese tech video, creator Zero Noichi ran a fascinating experiment: he used two ZimaBoard 2 computers to simulate a cybersecurity battle between an AI-powered defender and an AI-powered attacker. One machine hosted a vulnerable internal customer management system, while the other attempted to break into it using an autonomous AI agent. The defender, also powered by AI, continuously monitored, investigated, patched, and blocked suspicious activity in real time.

As ZimaSpace, we want to thank Zero’s channel for featuring ZimaBoard 2 in such a creative and thought-provoking cybersecurity demonstration. This article transforms the video transcript into a structured English blog post for readers interested in homelab servers, AI agents, cybersecurity, Docker labs, and self-hosted infrastructure.

Important note: The original creator clearly states that the experiment was made for entertainment and educational purposes. Some dashboards, service states, and vulnerabilities were intentionally dramatized or left exposed for demonstration. This article keeps the technical concepts, data points, and experiment flow, but avoids providing actionable offensive instructions.

Why This Experiment Matters Now

The key question behind the video is simple: what happens when AI agents can keep attacking and defending without getting tired?

Zero opens the video by introducing a topic that many Japanese viewers had been waiting for: a simulated security team vs. hacker team battle using two computers. The machines used in the experiment were ZimaBoard 2 devices—compact x86 computers suitable for running services, agents, dashboards, and lightweight server workloads.

The inspiration comes from recent discussions around advanced AI security agents, including systems that may be able to inspect software, identify vulnerabilities, validate whether those vulnerabilities are exploitable, and then propose or apply fixes. Zero describes this as something that could reshape the concept of cybersecurity itself.

His goal was not to reproduce a real proprietary system exactly. Instead, he built an imagined experiment to preview the broader idea:

“AI can already act as both a hacker and a defender to this extent.”

That single idea drives the whole video.

The Hardware: Two ZimaBoard 2 Devices as AI Battle Stations

For the experiment, Zero used two ZimaBoard 2 computers. One was assigned the role of the defender, and the other became the attacker.

ZimaBoard 2 is well-suited for this kind of hands-on lab because it is small, quiet, x86-based, and designed for 24/7 services.

From the ZimaSpace perspective, this is exactly where ZimaBoard 2 shines. It is built for users who want to run real workloads at home or in a lab environment, including:

• Plex media servers
• Pi-hole network filtering
• Proxmox virtualization
• Debian or TrueNAS setups
• pfSense routing
• Docker labs
• AI containers
• Backup services
• Homelab clusters
• Lightweight development environments

The product’s hardware design is also relevant to the experiment. ZimaBoard 2 includes native SATA and PCIe support, meaning users can plug in 2.5-inch HDDs or SSDs, add a 10G NIC, use an NVMe adapter, or expand the device for personal storage and networking needs. Dual 2.5G Ethernet also makes it attractive for fast local NAS, low-latency remote access, and multi-service home routing.

As Zero’s video shows, this kind of compact device can become much more than a “mini computer.” It can become a practical platform for AI, networking, self-hosting, and cybersecurity learning.

Chat AI vs. AI Agents: The Concept Behind the Test

Zero spends time explaining the difference between ordinary chat-based AI and AI agents.

A standard chat AI—such as ChatGPT or Gemini—is mostly conversational. You ask a question, and it responds. It may be highly intelligent, but it usually does not continue working toward a goal by itself.

An AI agent is different. An AI agent receives a goal, breaks it into tasks, loops through actions, checks progress, and continues until the task is completed. In the video, Zero describes it as a system that keeps working until it reaches the goal.

Technical terms used in this part include:

• Chat AI: an AI system that responds in a conversation format.
• AI agent: an AI system that can loop through tasks toward a defined goal.
• Autonomous agent: an agent that can continue acting with less direct human input.
• Goal loop: the repeated cycle of planning, acting, checking, and improving.

Zero notes that many of his previous videos focused on AI agents. One example he mentions is an AI system that investigates a NAS and organizes files. Another previous experiment used a board computer to create a self-running AI without a clearly defined goal.

That earlier autonomous AI concept became the foundation for this new experiment.

Reimagining AI Security: Defender vs. Attacker

The experiment turns cybersecurity into a live contest between two continuously running AI systems.

Zero explains the defensive AI using a house analogy. Imagine a service as a house containing an important key. If there is a large open door, an attacker can simply walk in and take the key. In that case, the AI defender should identify the issue, test whether the opening is dangerous, and close it.

But not every opening can be closed completely. Zero gives the example of a 10 cm inspection hole. The hole may be needed by the administrator to check whether the key is still there. Closing it would break a legitimate function. So the AI must reason more carefully:

1. Is the hole actually dangerous?
2. Could an attacker exploit it with a tool?
3. Can the system preserve visibility while blocking intrusion?
4. Which defense works best?
5. Can the fix be tested against the imagined attack?

In the analogy, the final solution might be a strong mesh screen: nobody can enter, but the administrator can still see through it.

This is the central idea of the defensive AI in the video: not just finding weaknesses, but verifying them, testing possible attacks, and applying countermeasures.

Building the Test Environment

Zero then created a mock business service for the experiment. The service acted like an internal customer management system, similar to a CRM.

The system included several realistic business features:

• Customer records
• Deal or project information
• Support tickets
• Contract lists
• Internal notes
• Activity logs
• Search functionality
• A public blog
• User management
• Sensitive internal information, including intentionally exposed API keys for demonstration

He explains that many companies have similar internal management tools. If such a system is compromised, customer data, internal notes, blog content, user permissions, and operational records could be affected.

This made the test environment realistic enough to show why AI-driven defense may matter for everyday business systems.

The defender dashboard was intentionally made visually dramatic and cyberpunk-like for the video. It showed service status, alerts, recovery actions, tampering notices, and multiple agents working at once. Zero mentions that up to around five AI agents could operate together on the defender side.

The attacker system was also controlled by an agent-like workflow, continuously trying different paths to find a way in.

Why ZimaBoard 2 Fits This Kind of Homelab AI Scenario

A project like this requires a small server platform that can run continuously, handle different software stacks, and support networking experiments. That is why ZimaBoard 2 is a natural fit.

For creative DIYers and tech lovers, ZimaBoard 2 can act as a mini server that looks simple but runs serious workloads.

The original product positioning fits the video especially well:

“Small, hackable, and kind of cute. Many call it a mini server that looks like a toy but runs like a beast.”

With ZimaBoard 2, users can test operating systems such as ZimaOS, TrueNAS, Proxmox, Debian, and pfSense. They can run Docker containers, self-hosted services, media servers, storage systems, and AI experiments. In this video, the board becomes a compact cyber range—a controlled environment for observing how AI agents might behave in attack-and-defense simulations.

For readers interested in building a homelab, ZimaBoard 2 offers several advantages:

• Low power consumption for 24/7 operation
• Silent and cool performance
• Dual 2.5G Ethernet for networking workloads
• Native SATA for storage expansion
• PCIe support for NICs, GPUs, or NVMe adapters
• Compatibility with multiple server operating systems
• A compact form factor that fits small workspaces

This is why a ZimaBoard 2 homelab can support not only storage and media streaming, but also practical experiments in AI automation and cybersecurity monitoring.

Launching the Defender First

Zero explains that, in the real world, defense should ideally be prepared before attack tools become widespread. He references the idea that governments and organizations may want to harden banks, services, and infrastructure before powerful AI systems become generally available.

In the video, he starts the defender first.

The defender begins by inspecting the service, checking for problems, and attempting to fix what can be fixed. At first, there are no visible attacks. The service continues running normally.

After about one and a half minutes, Zero decides the attacker should begin. He notes that if the defender is given too much preparation time, the video may become less balanced. He wants the simulation to resemble a world where attackers appear before defenders have fully completed their work.

Then the attacker starts.

The Attack Begins: Continuous Probing

Once the attacker starts, the number of attempts rises quickly. Zero observes the count climbing from the 30s upward as the attacking AI tests different possible entry points.

The attacker tries many general methods because it has not been given full details about the target service. Zero explains that if the attacker were given more target-specific information, it would likely focus its efforts more effectively. But in this experiment, the attacker is broadly probing anything that seems plausible.

Technical terms appearing in this section include:

• API: an interface that lets software send commands or requests to a service.
• SQL: a database query language often associated with database access and injection risks.
• JWT: JSON Web Token, a token format commonly used for authentication.
• GraphQL: an API query language used to request structured data.
• Admin endpoint: a URL or API route intended for administrator functions.

Zero emphasizes why AI changes the situation:

“Until now, this was mechanical. Now it becomes AI, and that is scary.”

AI can reason, vary its attempts, and test patterns with randomness. That makes the behavior feel less like a static script and more like an adaptive operator.

The Defender Detects the Attacker

At first, the defender dashboard remains calm. Then, the attacker discovers exposed areas, including intentionally vulnerable paths. Zero sees findings related to source-control exposure, API previews, GraphQL data leaks, and API keys.

Soon the defender begins reacting.

One of the most important moments in the video is when the defender identifies the attacker’s IP and starts investigating the activity.

The defensive agent detects suspicious access patterns. It appears to notice attempts against administrative APIs and possible JWT-related behavior. The system begins to report alerts, investigation logs, and defensive actions.

Zero describes the scene as the two sides finally “fighting.”

The defender also takes practical action. One example is disabling or locking the predictable admin account. Zero later tests this manually by trying a common admin login pattern and confirms that the account has been locked, with the reason displayed.

This demonstrates a key defensive principle: predictable privileged accounts are dangerous and should be protected, renamed, disabled, or hardened.

Service Shutdown and Recovery

Another dramatic moment occurs when the service goes down.

Zero notices that the dashboard reports a critical issue involving general user passwords stored in SQL in plaintext, meaning they were saved without encryption. The service appears to stop temporarily.

He interprets this as a deliberate defensive action. In other words, the defender may have taken the service offline to prevent further exposure while applying changes.

Then the service restarts.

Zero confirms that the login screen is accessible again. The dashboard indicates that a defense has been applied. He does not explain every technical detail, but summarizes that a vulnerability was found and cleared.

This moment shows a practical trade-off in cybersecurity: sometimes temporary downtime is safer than leaving a vulnerable service online.

For real businesses, this is why incident response planning matters. A system should not only detect issues but also know when to isolate, patch, restart, or restore services.

The Numbers: Attempts, Findings, and AI Cost

The video includes several useful data points from the experiment:

• The attacker made approximately 1,000 attack attempts.
• Around 5 sensitive areas that should not have been exposed were discovered.
• The defender reported around 3 alert or report items at one point.
• The experiment ran long enough for both sides to enter a back-and-forth cycle.
• Zero had charged roughly 4,000 yen for AI usage, but the budget was consumed quickly.
• He notes that he used a relatively capable model, which increased cost.
• Multiple AI processes were running rapidly, with the final commentary suggesting many agents were active at high speed.

The most memorable practical lesson may be the cost. Even when using a lower-cost AI option, continuous agent loops can consume credits very quickly.

Zero stops the experiment when the AI requests run out of budget.

“The money ran out.”

That line captures one of the overlooked realities of agentic AI systems: autonomy is powerful, but continuous reasoning can become expensive.

What the Experiment Proved

The main takeaway is that AI-driven cybersecurity can become a real-time contest of discovery, defense, adaptation, and cost.

Zero concludes that the experiment became a kind of cat-and-mouse game. The attacker found issues, the defender reacted, and both systems continued operating at high speed.

He also makes a broader point: humans alone may not be able to keep up with this pace. If attackers use AI to automate probing and exploitation attempts, defenders may need AI-supported monitoring, patching, and response systems too.

However, he also points out that today’s world has more mature attacker-side AI experimentation than defender-side systems. Attackers may appear in large numbers, not just one at a time. In the video, a single attacker produced around 1,000 attempts. If that became 100 or 1,000 attackers, the scale would change dramatically.

That observation is one of the strongest parts of the video. Cybersecurity is not just about one smart attacker. It is about volume, automation, persistence, and asymmetry.

Safe Lessons for Homelab Users and Builders

While the video is entertaining, it also offers practical lessons for anyone running a homelab, NAS, self-hosted service, or small business server.

A ZimaBoard 2 homelab is a great place to learn these lessons safely in a controlled environment.

Here are the safe, defensive takeaways:

1. Do not expose unnecessary services
   If an entry point does not need to be public, keep it closed.

2. Avoid predictable admin accounts
   Default or obvious administrator usernames create unnecessary risk.

3. Never store passwords in plaintext
   Passwords should be securely hashed, not stored as readable text.

4. Protect API routes carefully
   APIs often become high-value targets because they can modify users, data, or settings.

5. Monitor logs continuously
   Activity logs can reveal probing, repeated failures, unusual access, and suspicious automation.

6. Use segmentation
   Keep experimental services separate from important production systems.

7. Have a recovery plan
   Restarting, isolating, or rolling back a service should be planned before an incident occurs.

8. Budget for AI workloads
   Autonomous AI loops can consume tokens and credits faster than expected.

9. Use labs responsibly
   Security experiments should be performed only on systems you own or have permission to test.

These are practical lessons for anyone running Docker labs, Proxmox nodes, personal NAS systems, or AI containers on ZimaBoard 2.

Why This Is a Strong Use Case for ZimaSpace Users

ZimaSpace devices are designed for users who like to build, test, break, fix, and learn. This video fits that culture perfectly.

ZimaBoard 2 is not just a board for storage or media streaming; it is a flexible x86 platform for real-world technical curiosity.

For example, users can create:

• A home firewall with pfSense
• A personal NAS with TrueNAS or ZimaOS
• A Docker-based service lab
• A local AI agent test environment
• A Plex server
• A Pi-hole DNS filtering node
• A Proxmox mini virtualization host
• A private development sandbox
• A small cybersecurity monitoring lab

Because ZimaBoard 2 supports native SATA, PCIe expansion, and dual 2.5G Ethernet, it can grow with the user’s ideas. Want local storage? Add SSDs. Want faster networking? Add a 10G NIC. Want to experiment with AI acceleration or NVMe storage? Use PCIe expansion.

This is the value of a compact x86 home server: it gives creators and developers a physical playground for modern computing.

The Bigger Picture: AI Will Change Both Sides of Security

Zero ends the video by reflecting on the future. If powerful AI systems become widely available, some people will misuse them. Targets could be anywhere in the world. The best response is to understand the risk, protect what can be protected, and recognize that defensive tools will also continue to improve.

He also adds a very human note:

“Humans should stay healthy. Health is important.”

It is a funny and grounding ending after a fast, intense AI battle.

The broader message is clear: AI security is moving quickly. Attackers can use automation, but defenders can also use automation. The question is whether individuals, companies, and builders are ready to test, understand, and secure their systems before problems occur.

ZimaBoard 2’s Role in AI-Assisted Security

Zero’s experiment using two ZimaBoard 2 devices offers an exciting glimpse into the future of AI-assisted cybersecurity. One board acted as a defender, continuously inspecting and hardening a mock CRM service. The other acted as an attacker, generating around 1,000 probing attempts and discovering several intentionally exposed sensitive areas. The defender detected activity, locked risky accounts, applied fixes, and even appeared to take the service down temporarily for protection.

For ZimaSpace, this is a perfect example of what makes compact x86 devices valuable. A small, quiet, low-power board can become a media server, NAS, router, Docker host, AI container platform, or cybersecurity lab.

If you are a DIY builder, homelab enthusiast, developer, or security learner, ZimaBoard 2 gives you a practical platform to explore the future of self-hosting and AI-driven automation—safely, responsibly, and creatively.

Once again, thanks to Zero’s channel for the imaginative demonstration and for showing how much can be done with compact hardware, AI agents, and a strong experimental mindset.