Back to Intelligence

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

SA
Security Arsenal Team
October 13, 2026
13 min read

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 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.

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, 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 intended 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.

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.

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 looks like a low or medium on a report. Combined, they're a path from initial access to domain admin.

The agents demonstrated that same chaining logic, autonomously, in a fraction of the time a human team would 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. A small number were forwarded for responsible disclosure review through the appropriate channels, and the rest were converted into new detection logic, hardening guidance, and test cases inside our own platforms.

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 doing equivalent work carefully would measure it in days or weeks.
  • Breadth exceeds individual expertise. No single engineer holds deep knowledge of Windows internals, Linux services, web application security, Active Directory attack paths, and detection engineering simultaneously. The agents drew on all of it at once from the shared knowledge base.
  • The agents validated their own work. Findings weren't theoretical. Each candidate attack path was executed in the lab and confirmed or rejected based on observable results. False starts were discarded without anyone having to review them.
  • Human judgment still mattered at the margins. 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 believe well-funded threat actors aren't building comparable capability. Several already operate with the discipline and resourcing of professional engineering organizations. The barrier isn't the AI — models capable of this kind of reasoning are broadly available. The barrier is the surrounding infrastructure: the orchestration, tool access, knowledge management, and sandboxing that turn a chatbot into a workforce. That barrier is falling fast.

The implications for defenders are significant:

  • Attack research timelines will collapse. The gap between a weakness existing and an attacker weaponizing it will shrink. The window defenders have historically relied on — the time between disclosure and mass exploitation — is already narrow. Autonomous offensive research narrows it further, and for weaknesses that are never publicly disclosed, there is no window at all.
  • Vulnerability management alone won't save you. If attackers can chain minor misconfigurations into compromise paths faster than you can scan for CVEs, then patching cadence, while still essential, is not the whole answer. Configuration hygiene, segmentation, and detection depth become the actual battleground.
  • Detection must assume novel technique combinations. If your SOC only alerts on documented TTPs mapped neatly to MITRE ATT&CK, you will miss chained behaviors where each individual step looks benign. Behavioral correlation across systems is no longer aspirational; it's the minimum viable defense.
  • The economics of offense are changing. Skilled offensive operators are scarce and expensive. Autonomous systems don't sleep, don't bill by the hour, and scale horizontally. When offense becomes cheap, the volume of sophisticated attacks rises, and organizations that were previously "too small to be a target" get swept into reach.

I've spent my career on both sides of this problem. For the first time, I believe defenders may end up outpaced not 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, because 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 lab work, we ran the same systems against a small number of client networks — real enterprise environments with full IT staff and managed SOCs — under authorized engagement. The result was the same. Yes, real networks have undocumented systems, political constraints, change windows, and decades of accumulated technical debt, and the agents had to work through all of it. The messiness slowed the work down; it did not change the outcome. The lab wasn't a best-case scenario that collapses on contact with reality — it was a rehearsal.

"AI hallucinates and can't be trusted with offensive actions." This concern is legitimate, and any vendor who waves it away should not be trusted with autonomous capability. Our answer is architectural, not rhetorical: we designed the system so that hallucination has nowhere to hide. Different AI models independently double-check each other's work, and nothing advances to the next stage without proof — an agent cannot simply assert that a system was configured correctly or that an attack path succeeded; it has to demonstrate it with observable results. Validation is built into the workflow itself rather than bolted on afterward. On top of that, every significant action our agents take is logged, reviewable, and reversible, and the live activity views in Spark Management let a human intervene at any point. You should demand this same standard of proof-driven validation from any vendor claiming autonomous capability.

"This is just automation with better marketing." I understand the skepticism — our industry rebrands everything. But traditional automation fails the moment it hits an unanticipated condition. The defining characteristic of what we observed was the opposite: the agents handled situations nobody scripted, generated their own hypotheses, and corrected course. That's not a workflow engine.

"Publicizing this helps attackers." We've considered that carefully, which is why the specific techniques stay private. But defenders cannot afford to ignore a capability shift because discussing it is uncomfortable. Attackers won't wait for our permission.

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.

  1. Test against chained attacks, not isolated vulnerabilities. Commission penetration tests and purple team exercises that explicitly chain minor weaknesses into compromise paths. If your last assessment produced a list of independent findings with no attack-path analysis, you bought a scanner report, not a security evaluation.
  2. Invest in behavioral detection and cross-system correlation. Move beyond signature and IOC-based alerting. The chained techniques that matter most will have no signatures because nobody has documented them yet.
  3. Move toward zero trust and reduce your attack surface aggressively. Autonomous offense thrives on accumulated misconfiguration and exposed services. Every orphaned service account, legacy protocol, open port, and over-permissioned share is a link in a chain someone else's AI will eventually assemble. The strongest form of surface reduction we've seen is zero trust architectures that use authentication-driven access — where firewall ports are opened for a single authenticated device, for a defined period of time, and closed again by default. If a service isn't reachable, it isn't exploitable. The more you can reduce what's visible and reachable on your network, the smaller the target an autonomous attacker has to work with.
  4. Ask your vendors hard questions about their AI claims. Is the AI operating the product or decorating it? Can it act autonomously, and if so, what supervision, logging, cross-model validation, and rollback exist? Vague answers tell you what you need to know.
  5. Establish AI governance before you deploy AI. Define what autonomous systems may do, what requires human approval, and how every action is audited. We spent as much time on control architecture as on capability, and that ratio should not be unusual.

Bottom Line

The cybersecurity industry is adding AI features to products designed for human operators. That's an incremental improvement to a model that is about to be obsolete.

What we witnessed in 30 hours — autonomous environment construction, self-directed offensive research, validated novel attack paths, and appropriate human escalation — convinced me that the organizations which treat AI as an operator rather than an assistant will define the next era of both offense and defense. And the follow-on testing in live client environments convinced me this isn't a laboratory curiosity.

I can no longer compete with 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 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?

Related Resources

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

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.