This is part 1 of the series "Protect Your Own Service Yourself — Self-Defense Security in the Age of AI." Do the checks you can yourself; when it's hard, EarthLink Network can run the assessment for you, and fix the gaps you can't fix on your own.
Series contents
- Anyone can attack now, with AI — check your own site first (this article)
- What attackers now hold: when AI runs the attack itself
- Before you start: the whole picture of checking, and how to test without breaking production
- Testing from the outside (1): setup and the first run (coming soon)
- Testing from the outside (2): attack tools and legitimate scanners find different things (coming soon)
- Checking the code you wrote: static analysis (coming soon)
- Checking the parts you depend on: libraries and packages (coming soon)
- Checking your infrastructure settings for gaps (coming soon)
- Collect every result in one place and decide what to fix first (coming soon)
- How to fix what you found: three ways (coming soon)
- When you cannot fix it yourself: a maintenance contract (coming soon)
- Keep checking automatically every day — from building to protecting (coming soon)
In the summer of 2025, a free attack tool called Villager went up on a public site where developers share code. You tell it "look into this site," and an AI decides on its own where to look, what to try, and what to do next. In about two months, before the press picked it up, it was downloaded roughly 10,000 times.
That is the starting point for this series. Attack tools like this are now free and available to anyone. The people who attack already have them and are already using them. So instead of finding out after a break-in, check your own service yourself first, find the weak spots, and fix them. That is the most reliable defense you have.
Security is no longer only a problem for companies big enough to be targeted. Even if nobody has heard of you, machines now try every site on the internet, one after another. This part explains why that matters now, and what the series will do.
All 12 parts of this series
Here is the plan, up front.
- Part 1 (this one): why do this now. The thinking behind it, and how the series runs.
- Part 2: what tools attackers hold today, and what it means for an AI to run an attack by itself. Not how to get them, but what such an opponent can do.
- Part 3: what to decide before you start testing. Test on a separate copy of your setup so you do not break the live service your customers use, and never look into anything that is not yours.
- Part 4: testing from the outside. Setup and the first run.
- Part 5: the results of testing from the outside. We compare what attack tools find with what legitimate security scanners find.
- Part 6: checking the code you wrote by reading it without running it (static analysis).
- Part 7: checking the parts you depend on (libraries and packages) for known weaknesses. This is where findings tend to pile up.
- Part 8: checking your server and cloud settings for gaps.
- Part 9: collecting the scattered results in one place and deciding what to fix first, including the risk from partners and parts you are connected to.
- Part 10: how to fix what you found. There are three ways.
- Part 11: when you cannot fix it yourself, the option of a maintenance contract.
- Part 12: keep the checks running automatically every day. From building things to protecting them.
The service we test is promptflow, a service our own company builds and runs.
October 2026: breach announcements kept coming
In October 2026, data breach announcements did not stop. In the US, the count of people affected by the 2025 breach at Oracle's health division (formerly Cerner) rose to about 20 million. Heart monitor maker iRhythm disclosed that data on about 8.2 million people had been stolen. In the UK, online retailer ASOS disclosed a leak of customer data, and Frontline Education, which makes software for schools, disclosed a leak of school staff data. In Japan, the parcel carrier Yamato Transport announced a leak of 5.31 million records of personal data, and one count found more than 40 breach announcements there in about a month.
Ransomware is an attack that locks or steals a company's data and demands payment to give it back. Worldwide, according to the security company Bitdefender, the criminals behind it named 790 organizations as victims in September alone, the month before, 30% more than in September a year earlier.
Numbers like these can feel like someone else's problem. What caught my attention was who the victims were: a parcel carrier, an online store, health care companies, school administration. Ordinary companies, with no special reason to be targeted.
The victims were not special companies
Reading the reports, I noticed something else. The way in was not special either. A partner's server. Setting mistakes in an API (the set entry point that other systems and apps use to request data from a service) or in an admin screen. An old bug in a piece of software. A password that someone reused and that leaked elsewhere. Put them side by side, and these are ordinary paths that many companies have right now.
Take the reused password. Some other service, nothing to do with you, leaks a list of email addresses and passwords. The attacker enters those pairs, one after another, into hundreds of unrelated sites. Wherever someone reused the password, the login goes through. Nobody broke into your site. A password that leaked from some other service, and that your user had reused, simply worked on it. A machine does this nonstop, not a person. So even if your own password handling is solid, someone can get in because of what happened on the user's side.
Attacks also work in a different order now. A human attacker chose a target first, with a motive, and spent time on one company. Automated attacks go through the whole internet mechanically, site after site, and pick up whatever happens to have a hole. Whether your service is famous or large does not matter. If it is public and has a hole, that is enough. So "nobody would bother with a small business like us" does not hold. You are not being targeted; everything is being checked at once.
Attacks no longer need special skills
This is the biggest change. Until recently, attacking took real skill: a person had to work out for themselves where to look and what to try next.
Think of a door lock. The common pin tumbler lock, where you insert a key and turn it, could be picked by a skilled person with thin metal picks, setting the pins one at a time by feel. Few people could do that, and that was part of the protection. Then came devices you simply hold against the lock: press a button, and the lock turns. No skill needed. That is why people moved to locks that are harder to copy and pick, such as dimple keys, with rows of small dents on the surface.
The same thing is happening in security right now.
AI now plans the steps of an attack
Since around the summer of 2025, tools that hand the planning of an attack to an AI have been given away for free.
Villager, from a Chinese company, is the example I opened with. Part 2 covers what it does in detail.
Villager is not the only one. Several tools like it, where AI runs the attack by itself, sit on public code-sharing sites and have been copied many times. How far have they spread? One has about 7,700 copies (forks, where someone copies the project to keep their own version), another about 4,700, another about 2,900. When one gets attention, hundreds of similar copies spread right away. That is how free software works. It is not something anyone can stop.
Some of these are legitimate tools built for defenders, presented as a way to "find and fix the weaknesses in your app." In this series we use both kinds on our own service, because you only learn where someone can really get in by checking the way attackers do it. Then we show how their findings differ.
My point here is not about good or bad. It is a fact: the skill barrier has dropped to almost zero. One short instruction, and anyone, in theory even a child, can move an attack forward. The time when skill itself was the protection is almost over.
Small companies are the least likely to have checked
Small companies are the most exposed to these automated attacks. Large companies have security staff who test their systems regularly, and budget for outside firms. Sole proprietors and companies of a few people have neither. So the businesses that have checked the least are probed by these automated scans just as often as everyone else. They have not checked, so they do not know they have weak spots, and they learn about it only after the leak.
This is why I care about tools that run with one click. If a tool does the planning, a small company without security staff can still run a check at least once. As long as checking takes expert knowledge, people stop at "I know it matters, but we can't." The same thing that lowered the barrier to attack has lowered the barrier to checking. Not all of this is bad news.
Hiding information only hurts the defenders
Whenever I write like this, I get the same pushback: "Don't name those tools. You're giving attackers a lead." I think that idea is backwards.
Attackers do not learn about tools from honest articles like this one. They got them elsewhere, long ago, and that is why they are attacking right now. The pile of breaches in October 2026 is the proof. Keeping quiet did not prevent any of them.
So who is hurt when information is hidden? Only the people with no other way to find it: the defenders. Attackers already know which tools are out there and what they can do; only the defenders do not. They do not even know where they are exposed. That is the most dangerous state to be in.
Defenders benefit from this being public. Once it is known which weakness a tool goes after, software makers can fix it quickly and users can review their settings. If it were hidden, nobody could fix anything, and attackers would quietly keep using it.
It was the same with locks. Keeping a lock's design secret does not help if the lock is weak. A strong lock is strong because it holds even when everyone knows how it works. Software security is the same: do not protect it by hiding, build it to hold up when it is known. That is why, in this series, I name the tools, say what they do, and show the results of checking our own service, without hiding any of it.
First, check your own service yourself
What to do is simple. Take the same tools attackers use, run them against your own service first, find the weak spots, and fix them. If a key that works on almost any lock is on sale, first see whether it works on your own door. If it does, switch to a stronger lock. That is all.
We limit the target to our own service, promptflow, for two reasons. Because it is ours, we decide how far to test, and we can make sure the test copy does not reach real users or outside services. And we are the ones best placed to fix its weak spots. Doing the whole loop of testing, finding, and fixing on something we own seemed the most honest and useful way to show it.
promptflow is a service we build and run for working with AI. Users log in, it holds data, and it connects to other systems through APIs. It has the same kinds of entry points used in the October 2026 breaches, which makes it a good subject. If we find a weak spot in ours, the same spot may be weak in yours. We show the steps exactly as we run them, so you can check the same things on your service.
"Is it safe?" is a call a person makes after testing
I believe that from now on, people's job is to make decisions: AI does the drafting, and people make the final call. "Is my service safe?" is exactly this kind of decision. And a decision needs facts from real testing. Saying "it's probably fine" without testing is not a decision. It is a hope.
Until recently, attackers had the advantage: their attacks were automated, while defenders checked by hand, one thing at a time. Now defenders can use the same automation. If attackers can try with one click, so can we. There is no reason not to use it.
What we will actually do in this series
From Part 4, we test promptflow for real. Here is the approach, without the specific steps yet.
We check from two directions.
- From the outside, the way an attacker would: we try the service from outside, just as attackers do. The login screen, the API entrances, the admin screen, files we never meant to make public. We list those entry points, check that each lets in only who it should, and confirm whether a weakness we found can really be reached from outside. Something that is risky in theory and something that can actually be touched from outside are different things.
- From the inside, by reading: with your own service, you can see the inside too. The code you wrote, the parts you use (libraries and packages), and your server and cloud settings. We read these three without running them and check for known weaknesses and setting gaps.
Protecting only your own service is not enough. If a partner you connect to, or a system you share with other companies, is broken into, attackers can come in from there; in the October 2026 breaches, one way in was a partner's server. So we also map what your service connects to and which parts and outside services it relies on, and count those risks in the results. That does not mean testing anyone else's site. It means collecting the connections and the known weaknesses in them.
Checking only from outside, or only from inside, leaves gaps. Collect both sets of results in one place, decide what to fix first, and fix it. What you cannot fix yourself, hand to someone who can. That is one full round.
AI tools can chain these checks together without a person giving every instruction. You do not need an expensive AI model or an expert; a cheap model run many times gets you a long way, which is exactly how attackers work too. So even a first-timer can realistically run the whole thing once. From Part 4, I go through it step by step with the promptflow screens.
Checking is also not something you do once. A service keeps changing, and new weaknesses keep being found. If attackers retry automatically, defenders should re-check automatically too. New weaknesses in the parts you use are found almost every day, so the most reliable way is to run the code and library checks automatically every day. Testing from the outside is not a daily job, and it runs against a separate copy, not your live service. The last part of the series shows that setup.
Will testing break my own service?
The natural worry is: "If I use an attack tool on my own service, will it break?" Honestly, depending on how you do it, it can put a load on the service. So Part 3 explains how to test on a separate copy of your setup, or on a copy of the source code, instead of the live service your customers use, and where to draw the line so you do not push too hard. Choose where you test and how hard you push, and there is no need to be afraid. Running your live service without ever checking it is far more dangerous.
Never use these on anyone else's site
One last warning. The tools and ideas in this series are for checking services you own. Never use them on someone else's site, or on any system you do not have the rights to. It breaks the law, and it is the exact opposite of what this series is for. Only check what is yours.
Where the information in this article comes from
What I wrote here about attack tools is based on news reports and public information. The results of testing our own service start in Part 4, with real, unedited screenshots: where we found weaknesses, where we found none, and what was reported as a weakness when it was not.
Next time
Next time, we look inside the tools attackers hold. What does it actually look like, step by step, when an AI runs an attack by itself? As a defender, what should you assume? Again, I will not explain how to get them. The goal is to know what this opponent can do, so you can calmly check your own service.
In this series, in an age when attack tools are free and one click away for anyone, I show step by step how to check your own service yourself and close the gaps before someone else finds them. The target is always our own service; the series does not cover attacking anyone else's site.
If running the checks yourself is hard, EarthLink Network can do the assessment for you. Found a gap you can't fix? We'll handle the fix. Feel free to reach out.
If this was useful, please like and follow.
Our products are listed at https://www.eln.ne.jp/products
EarthLink Network builds its own products to run the whole company on AI — each one born from a need along the way. See the full index of what we build:
→ The 18 products EarthLink Network builds in-house
For more about the company and each product, visit www.eln.ne.jp.
Top comments (0)