AI vs. AI: After 30 Years in Cybersecurity, I Can No Longer Compete With What We've Built

The cybersecurity industry is racing to add artificial intelligence to existing products. After four years building an entire company around autonomous AI employees, I believe most organizations are approaching the problem backward.

I've spent more than 30 years working in cybersecurity.

I've performed penetration tests, compromised networks during authorized engagements, investigated security incidents, developed software, and watched security technologies evolve through multiple generations.

I've seen firewalls become next-generation firewalls. Antivirus evolve into EDR and XDR. Security operations centers grow increasingly complex, with endless dashboards, alerts, and products promising to solve the same problems.

And now everyone is talking about artificial intelligence.

But after what I've witnessed over the past several months, I believe we're approaching the most significant transformation in cybersecurity I've experienced during my entire career.

I recently watched our AI systems accomplish in approximately 30 hours what traditionally would have required a team of experienced security professionals working across multiple disciplines.

It wasn't simply following a script.

It wasn't a chatbot answering questions.

It was an autonomous workforce building systems, validating configurations, researching attack techniques, conducting controlled security tests, and using its findings to guide further investigations.

And some of what it demonstrated genuinely concerned me.

Not because our systems were operating outside their authorized environment, but because I understand what these capabilities could mean in the hands of an attacker.

This is no longer theoretical.

We're Building AI the Wrong Way

Look at how most companies are approaching AI.

They're adding chat interfaces to existing products, creating copilots, summarizing security alerts, and helping employees write queries or investigation reports.

Those features have value.

But they're largely using AI to make existing human-driven processes a little faster.

I believe that's the wrong starting point.

The future isn't about humans operating software with AI assistance. It's about AI operating software, executing workflows, validating results, and involving humans when necessary.

That requires a completely different approach to designing systems.

At Security Arsenal, we've spent the past four years building around this concept.

Rather than adding AI to our products after they were developed, we've designed an interconnected infrastructure in which autonomous AI agents can operate across our security platforms, management systems, development environments, and business operations.

We call them our AI employees.

Each has assigned responsibilities, available tools, operational knowledge, and defined permissions. They have email accounts, phone numbers, SMS capabilities, and can even participate in video conference calls.

They receive assignments, execute tasks, evaluate results, and escalate problems when appropriate.

And unlike conventional automation, they're capable of handling situations that weren't explicitly anticipated when the workflow was designed.

We didn't add AI to our cybersecurity company. We built our cybersecurity company around AI.

Four Years Building an AI Workforce

Our infrastructure spans numerous servers, AI computing clusters, security monitoring systems, endpoint management platforms, forensic investigation tools, and internally developed applications.

At the center is our Spark Management system.

Spark Management allows us to assign one-time jobs or ongoing responsibilities to different AI models.

I can communicate with these agents through a chat interface, email, SMS, video conference, or telephone.

I can assign a task from my desktop, continue monitoring it from my iPad, and intervene from my iPhone.

Every agent has a live activity view showing what it's doing.

If an agent becomes stuck, enters a loop, makes an incorrect assumption, or begins pursuing the wrong approach, I can intervene and redirect its work.

Our local AI models have access to a shared retrieval-augmented knowledge base containing our documented processes, tools, infrastructure, and security methodologies.

A significant amount of that material represents knowledge I've accumulated over more than three decades.

But the knowledge base doesn't remain static.

The agents conduct research, perform authorized experiments, document validated findings, and contribute new operational knowledge for review and reuse.

We've also built a framework allowing local models to consult more capable external AI systems when necessary.

Those requests pass through controls designed to remove sensitive information, and external models receive only the specific tools and context they're authorized to use.

Our local systems retain operational control.

External models don't receive unrestricted access to our infrastructure, internal knowledge base, or client environments. They serve as additional reasoning resources within defined boundaries.

When automated escalation isn't appropriate, the agents can contact a human manager.

This architecture gives us the capabilities of an increasingly sophisticated technical workforce without requiring a human operator to perform every individual action.

And the difference becomes obvious when you give these systems a complex objective.

The 30-Hour Experiment That Changed My Perspective

I gave our local AI system an assignment.

First, build a realistic enterprise demonstration environment.

Not a few empty virtual machines.

A functioning business network with realistic systems, data, security controls, and operational requirements.

The agents were instructed to deploy and configure:

A current Windows Server environment using documented security-hardening practices.
Windows 11 desktop systems.
Linux servers and a WordPress environment.
Realistic mock company records, database contents, shared files, and business documents.
Our AlertMonitor platform and associated SOC monitoring and forensic tools.
Network services, security configurations, logging, and supporting infrastructure.

Everything needed to be patched, configured, and validated against the defined requirements.

Then the agents needed to audit the completed environment to ensure it matched the specifications.

They were also instructed to perform controlled attack simulations to confirm that our SOC could detect and investigate the activity.

They completed the initial setup and validation work autonomously, with the environment prepared in approximately a day.

Think about that for a moment.

Systems administration, server deployment, endpoint provisioning, patch management, security hardening, monitoring integration, and configuration auditing had been coordinated by AI.

The agents didn't just report that their assignments were complete. They gathered evidence, checked configurations, identified problems, and corrected failures.

The difference between completing a command and proving that the intended result was achieved is enormous.

But building the environment was only the beginning.

The real assignment was next.

Find Something Nobody Has Reported

I wanted the system to go beyond scanning for known vulnerabilities.

Known CVEs are important, but sophisticated attackers don't limit themselves to published vulnerabilities.

State-sponsored groups, cybercriminal organizations, and advanced offensive security researchers continually investigate weaknesses that may not yet be publicly documented.

So I gave our agents a far more challenging research objective.

Identify potentially new attack methods, investigate weaknesses without relying exclusively on public CVEs, and evaluate whether combinations of those weaknesses could produce meaningful compromise paths.

The work took place in our isolated and authorized laboratory environment.

The agents conducted research, generated hypotheses, built test cases, evaluated results, and documented their findings.

They identified multiple potential attack paths worth further investigation.

Some involved combinations of behaviors rather than a single vulnerability.

That's an important point.

An attacker doesn't necessarily need one catastrophic vulnerability. Several smaller weaknesses combined in the right sequence can produce the same result.

Anyone who has conducted red-team engagements knows this.

You rarely walk in through a single critical CVE.

You chain things together: a misconfigured service account here, an overly permissive share there, a legacy protocol that nobody disabled because it would break a line-of-business application.

Individually, each finding might look like a low or medium on a report.

Combined, they can become a path from initial access to domain administrator.

The agents demonstrated that same chaining logic, autonomously, in a fraction of the time a human team would traditionally need.

What It Actually Found — and What We Did With It

I'm deliberately not publishing the specific techniques the agents identified.

Some of the findings involved behavior combinations we had not seen documented in public research. Others were known technique classes applied in ways our detection content didn't anticipate.

Potentially novel vulnerabilities require additional validation before they can be confidently classified as previously unknown security flaws.

We maintain proprietary offensive research as part of our red-team capabilities, while assessing appropriate handling of findings that could affect third-party systems.

The validated findings also became valuable inputs for our defensive engineering, hardening guidance, and internal test cases.

What I will share is what the exercise revealed about the process:

Speed compresses the offensive research cycle. Hypothesis generation, environment setup, testing, and documentation happened in hours. A human researcher performing equivalent work carefully might measure it in days or weeks.
Breadth exceeds individual expertise. No single engineer holds equally deep knowledge of every area of Windows internals, Linux services, web application security, Active Directory attack paths, and detection engineering. The agents drew on information across these disciplines from the shared knowledge base and their available research tools.
The agents validated their own work. Findings weren't accepted simply because a model claimed success. Candidate attack paths were tested in the lab, with observable evidence used to confirm or reject the results.
Human judgment still mattered at critical moments. The agents escalated twice: once when a test risked destabilizing a service other experiments depended on, and once when a finding appeared sensitive enough to warrant human review before further testing. Both escalations were appropriate.

That last point deserves emphasis.

The system didn't just execute. It recognized situations where it shouldn't proceed alone.

Why This Should Concern Every Defender

Here's the uncomfortable part of this article.

Everything I've described was built by one small company, using commercially available models and hardware, over four years, for defensive purposes.

There is no reason to assume well-funded threat actors aren't pursuing comparable capabilities.

Several already operate with the discipline and resources of professional engineering organizations.

The barrier isn't simply access to AI models. Models capable of substantial technical reasoning are increasingly accessible.

The real barrier is the surrounding infrastructure: orchestration, tool access, knowledge management, validation, operational permissions, and sandboxing that turn a chatbot into a workforce.

That barrier is falling.

The implications for defenders are significant:

Attack research timelines will compress. The gap between discovering a weakness and developing an operational attack may shrink dramatically. For vulnerabilities that remain undisclosed, defenders may never receive the warning that public reporting provides.
Vulnerability management alone won't save you. If attackers can chain minor misconfigurations into compromise paths faster than organizations can identify and remediate them, patching remains essential but is not a complete defense. Configuration hygiene, segmentation, least privilege, and detection depth become increasingly important.
Detection must account for novel combinations of behavior. If a SOC relies exclusively on known signatures or isolated indicators, chained attacks may be missed when their individual stages appear benign. Behavioral correlation across systems is essential.
The economics of offense are changing. Skilled offensive operators are scarce and expensive. Autonomous systems can operate continuously and increase the amount of research and testing a relatively small team can perform. As the cost of offensive capability falls, sophisticated techniques may become accessible to a wider range of attackers.

I've spent my career on both sides of this problem.

For the first time, I believe defenders may end up outpaced not simply by better human attackers, but by attacker infrastructure that never tires.

The Honest Counter-Arguments

I've made strong claims, so let me address the skepticism head-on.

Some of it is warranted.

"This was a controlled lab. Real environments are messier."

That's a fair challenge, and it's one we took seriously enough to test.

After the laboratory work, we ran the systems against a small number of client networks under authorized engagements.

These were real enterprise environments with existing IT staff, managed security operations, and the complications that come with production infrastructure.

The broader result was consistent with what we had observed in the lab: the agents were able to carry out complex testing workflows and adapt to conditions they hadn't encountered during the initial exercise.

Real networks have undocumented systems, operational constraints, change windows, and years of accumulated technical debt.

The messiness slowed the work.

It didn't invalidate the underlying approach.

The laboratory wasn't a perfect substitute for production testing. It was a foundation that we could use to evaluate capabilities before applying them in authorized client environments.

"AI hallucinates and can't be trusted with offensive actions."

This concern is legitimate.

Any vendor that dismisses it should be questioned carefully.

Our answer is architectural, not rhetorical.

We've designed workflows where different models can independently check each other's work, and significant results must be supported by observable evidence.

An agent cannot simply assert that a system was configured correctly or that an attack path succeeded.

It must produce evidence that can be evaluated.

Validation is incorporated into the workflow rather than added as an afterthought.

Actions are logged and reviewable, and Spark Management's live activity views allow human intervention.

Where operations support rollback, recovery mechanisms can be used to correct mistakes. For higher-risk actions, authorization and operational safeguards remain necessary because not every action can be safely reversed.

We don't assume that using multiple models automatically eliminates errors. Independent validation reduces risk, but it doesn't replace evidence or oversight.

You should demand proof-driven validation from any vendor claiming autonomous security capabilities.

"This is just automation with better marketing."

I understand the skepticism.

Our industry rebrands everything.

Traditional automation generally follows predefined rules and workflows. It performs exceptionally well when the situation matches those expectations.

But it often struggles when confronted with conditions that weren't anticipated.

The defining characteristic of what we observed was different.

The agents handled unexpected situations, generated hypotheses, selected new approaches, and corrected course based on their observations.

That's more than simply executing a fixed sequence of commands.

"Publicizing this helps attackers."

We've considered that carefully, which is why the specific techniques stay private.

This article does not provide exploit code, attack chains, or operational details that would reproduce our proprietary research.

But defenders cannot afford to ignore a capability shift simply because discussing it is uncomfortable.

Attackers aren't waiting for the cybersecurity industry to agree that autonomous offensive systems are becoming a serious threat.

Finding a Vulnerability Doesn't Mean the Customer Is Protected

There's another problem with traditional penetration testing that has concerned me for years.

What happens after the report is delivered?

A penetration test identifies a vulnerability.

The customer acknowledges the finding.

Then someone needs to schedule remediation, contact a vendor, test a patch, obtain approval for downtime, or change an application that the business depends on.

That process can take days, weeks, or months.

Some vulnerabilities don't have an available patch.

And when you're dealing with potentially undocumented security flaws, conventional vulnerability-management tools may not even recognize the problem.

The customer now knows there's a way into the environment, but knowing about it doesn't stop someone from exploiting it.

We needed a better solution.

That requirement became a critical part of how we designed the relationship between SwarmPT and AlertMonitor Sentinel.

AlertMonitor Sentinel: Learning From the Attacks That Actually Worked

One of the most important components we've built is AlertMonitor Sentinel.

Sentinel is designed to learn from normal website traffic and application behavior, helping establish a baseline of legitimate activity and identify suspicious deviations.

But we didn't stop there.

When SwarmPT conducts an authorized engagement, we gain information that conventional defensive products may not have.

We know which attack methods actually worked against that specific environment.

Not merely which vulnerabilities a scanner identified.

Not just which CVEs might apply.

We have evidence from the assessment showing which behaviors succeeded, which security controls detected them, and where protection was insufficient.

That information is extremely valuable.

We designed Sentinel to incorporate those findings and develop targeted protections against the demonstrated attack behavior.

This is especially important when SwarmPT discovers previously undocumented weaknesses or exploit combinations.

The customer may not have a patch available.

The software vendor may not yet recognize the issue.

Traditional signature-based detection may have nothing to match against.

But we have something different.

We have observed attack behavior that can be used to inform compensating controls.

Sentinel can apply protective measures based on the relevant findings, subject to validation that the controls are effective and don't interfere with legitimate activity.

Our goal is to provide protection while the customer and affected vendors work toward a permanent solution.

This is not a substitute for patching.

And no system can guarantee that every variation of an exploit will be blocked.

But it represents a fundamental shift in how penetration-testing intelligence can be used.

Instead of finishing a test and leaving the customer with a list of weaknesses, we can use what we've learned to help strengthen the environment.

Find the weakness. Prove the risk. Apply protection. Validate the defense. Remediate the underlying issue.

That's the cycle we're building around.

And it's one of the reasons we believe offensive and defensive security should no longer operate as separate disciplines.

AI vs. AI: A Continuous Offensive and Defensive Cycle

Consider how this changes security operations.

Traditional approaches often separate vulnerability assessments, penetration testing, detection engineering, incident response, and system remediation into different teams or products.

Information moves between them through reports, tickets, meetings, and manual processes.

That creates delays.

Our objective is to connect those functions through an integrated AI-driven framework.

SwarmPT investigates and validates attack paths.
AlertMonitor and our SOC observe relevant activity and collect forensic evidence.
Sentinel can use validated findings to improve protections.
Our AI employees can assist with investigations, configuration changes, remediation workflows, and retesting.
New research and verified findings can contribute to our internal knowledge base.

The process continues.

Research → Test → Validate → Protect → Monitor → Improve → Repeat

Rather than waiting for a periodic penetration test to identify the next weakness, the broader objective is continuous security improvement through authorized testing and operational feedback.

This is what I mean by AI versus AI.

Attackers are increasingly capable of using automation and AI to identify weaknesses, adapt techniques, and pursue opportunities.

Defenders need systems capable of investigating, correlating, and responding at comparable speed.

And those systems need sufficient controls to ensure that speed doesn't come at the expense of safety or accountability.

We Built More Than a SOC

Much of this infrastructure exists behind our AlertMonitor platform and the broader Security Arsenal environment.

Our AI employees assist with endpoint monitoring, forensic investigations, helpdesk operations, incident response, system administration, and operational maintenance.

They can use authorized tools to investigate and resolve issues across managed client environments.

Our systems also support secure remote access through Arsenal Tunnel and Arsenal Shield, enabling controlled access to internal resources without requiring cumbersome manual workflows.

We've built our own communications infrastructure, AI-driven email systems, customer management workflows, quoting, engagement management, and issue tracking.

Our website isn't simply a marketing page.

It is integrated with the operational systems supporting our company and our customers.

A customer can request a security engagement, move through automated quoting and onboarding, and enter an environment designed to support ongoing security services.

The same underlying infrastructure supports our offensive testing, managed monitoring, and defensive engineering.

Even our internal software development and security research workflows use specialized AI agents.

The purpose of all this integration is straightforward.

Remove unnecessary human intervention from repeatable processes while maintaining visibility, accountability, and control.

That doesn't mean humans become irrelevant.

It means skilled people can focus on the responsibilities that benefit most from experience and judgment instead of spending their days executing repetitive technical steps.

Our AI Employees Work Differently

One of the most interesting aspects of this transformation is how it changes the economics of operating a technology company.

Security Arsenal has developed substantial infrastructure without building a conventional large engineering or operations staff.

We've relied on revenue from existing client relationships to fund development while continuing to expand our capabilities.

Our AI agents handle many tasks that would otherwise require additional technical or administrative personnel.

They assist with research, engineering, investigation, documentation, customer operations, and software development.

They can notify me when they encounter a problem or need assistance.

And I can see what they're doing at any time.

This doesn't mean autonomous systems eliminate the need for skilled employees or human accountability.

It means the relationship between company size and operational capability may be changing.

A smaller organization equipped with deeply integrated automation can potentially perform work that historically required a much larger team.

That's a significant competitive shift.

But the real advantage isn't simply reducing staffing costs.

It's the ability to design workflows that would have been impractical or prohibitively expensive when every step required human execution.

Continuous investigations, repeated validation, coordinated testing, and rapid feedback between offense and defense become far more achievable.

What Organizations Should Do About It

You don't need to build your own AI workforce this year.

You do need to stop planning as if your adversaries won't have one.

Test against chained attacks, not just isolated vulnerabilities. Commission penetration tests and purple-team exercises that evaluate how smaller weaknesses combine into meaningful compromise paths. A vulnerability assessment identifies potential weaknesses. A well-executed penetration test demonstrates whether those weaknesses can actually be exploited and what the consequences would be. Make sure you understand the difference between the two.
Invest in behavioral detection and cross-system correlation. Move beyond relying exclusively on signatures and known indicators of compromise. Novel attack combinations may not have published signatures. Identifying relationships between events, systems, and behaviors becomes increasingly important.
Move toward zero trust and reduce your attack surface aggressively. Autonomous offensive systems benefit from accumulated misconfigurations, exposed services, and excessive privileges. Every orphaned service account, unnecessary network service, legacy protocol, and over-permissioned share creates another possible opportunity. Authentication-driven, least-privilege access can substantially reduce unnecessary exposure. For example, access systems that temporarily permit an authenticated device to reach a specific service can provide better control than broadly exposed management ports. A service that cannot be reached through an attacker's available paths presents a smaller exposure, although indirect access and other compromise routes still need to be considered.
Demand more than vulnerability reports. Ask what happens after an exploitable weakness is identified. Can your security provider help establish compensating controls while remediation is pending? Can those controls be tested against the demonstrated attack? Can the environment be retested after the underlying issue is corrected? Finding vulnerabilities is important. Reducing the actual risk is the objective.
Ask vendors hard questions about their AI claims. Is their AI operating the product or simply decorating it? Can it perform meaningful work autonomously? What evidence proves that an action succeeded? Are multiple models independently validating important results? Can a human intervene? How are permissions enforced? How are actions logged, reviewed, and recovered when necessary? Vague answers should concern you.
Establish AI governance before you deploy autonomous systems. Define what agents may do independently, which actions require human approval, and how results are verified. Autonomy without accountability creates its own security risks. We spent substantial effort developing the control architecture around our AI systems because the ability to execute actions is only part of the challenge. Being able to trust, supervise, and validate those actions is equally important.

The Human Role Is Changing

I don't believe cybersecurity professionals are disappearing.

But I do believe the days of humans manually driving every aspect of cybersecurity operations are numbered.

Our value will increasingly come from designing systems, defining objectives, establishing boundaries, evaluating evidence, supervising autonomous activity, and accepting responsibility for consequential decisions.

The best cybersecurity professionals won't necessarily be the ones who can manually execute the greatest number of commands.

They'll be the ones who understand how to engineer, supervise, and validate systems capable of doing far more than any one person.

After more than 30 years in cybersecurity, I find that both exciting and unsettling.

I've dedicated much of my career to understanding how attackers compromise systems and how to defend against them.

Now I've watched our own AI infrastructure apply that knowledge, conduct new research, and execute complex workflows at a speed I cannot personally match.

And I know we're nowhere near the limits of what these systems will eventually accomplish.

Bottom Line

The cybersecurity industry is adding AI features to products designed for human operators.

That's an incremental improvement to an operating model that I believe is approaching a fundamental transformation.

What we witnessed in approximately 30 hours — autonomous environment construction, self-directed offensive research, validated attack paths, and appropriate human escalation — convinced me that organizations treating AI as an operator rather than merely an assistant will help define the next era of both offense and defense.

And the follow-on testing in authorized client environments reinforced that this isn't simply a laboratory curiosity.

But it also reinforced something else.

Discovering new ways to compromise systems is only valuable to defenders if that knowledge can be turned into better protection.

That's why we've spent so much effort integrating SwarmPT, AlertMonitor, Sentinel, our SOC, and our autonomous AI workforce.

Finding the vulnerability is the beginning.

Protecting against it, validating the protection, and continuously improving the environment is the objective.

After more than 30 years in cybersecurity, I can no longer compete with the speed of what we've built.

And I've been doing this for three decades.

The question for every CISO reading this is simpler than the technology:

If a small cybersecurity company in Dallas can build this for defense, what do you assume your adversaries are building for offense — and how long are you willing to plan as if they aren't?

About the Author

Jason Romo is the founder of Security Arsenal, LLC, a cybersecurity company specializing in offensive security research, penetration testing, AI-driven security operations, and integrated defensive technologies. With more than 30 years of cybersecurity experience, he has spent the past four years developing the company's autonomous AI operational infrastructure and security platforms.

Security Arsenal, LLC SecurityArsenal.com

Security testing discussed in this article was performed in authorized laboratory and client environments. Specific offensive research methods and proprietary exploitation techniques are intentionally omitted.

Related Resources

Security Arsenal Red Team Services AlertMonitor Platform Book a SOC Assessment Threat Intelligence Blog