Cyber-Extinction? Nah. The Machine Still Needs a Mechanic.

The argument keeps arriving in the same form: AI will automate security research, close the vulnerability gap, flag the misconfigurations, and eventually render the human analyst redundant. The field will be solved. The mechanic will be automated out.

Don't buy it.

AI is producing more vulnerable code than any previous technology in history and handing it to organizations that have neither the budget nor the staff to audit it. Phishing works better now than it did in 2010 because the social engineering layer has access to the same language models defenders do. Supply chains are a distributed trust disaster and getting worse. When you give an AI agent CLI access and tell it to solve a problem autonomously, it does not solve the problem — it automates the chaos at scale and logs everything it did for the attacker to read later.

The attack surface is growing faster than the silicon choir can defend it. More code, more dependencies, more AI-generated logic that passed a linter but never passed a human with context. The security researcher is not being replaced. The security researcher's inbox is getting larger.

---

The Patch Gap and the Detection Gap

Most organizations still do not treat security as an engineering discipline. It is a compliance function, a cost center, a box that gets checked before the auditor arrives.

The patch gap is the distance between when a vulnerability is publicly disclosed and when an organization applies the fix. In practice that gap is measured in weeks. Attackers weaponize within hours. The mathematics of that equation do not favor the defender.

But the patch gap is not what actually kills you. The detection gap is.

# Simple illustration: check installed packages against known CVEs
# In practice: integrate with your SIEM, run on a schedule

import subprocess
import json
import urllib.request

def get_installed_packages():
    result = subprocess.run(['pip', 'list', '--format=json'],
                          capture_output=True, text=True)
    return json.loads(result.stdout)

def check_against_osv(package_name, version):
    """Query OSV (Open Source Vulnerabilities) API"""
    payload = json.dumps({
        "version": version,
        "package": {"name": package_name, "ecosystem": "PyPI"}
    }).encode()

    req = urllib.request.Request(
        "https://api.osv.dev/v1/query",
        data=payload,
        headers={"Content-Type": "application/json"}
    )
    with urllib.request.urlopen(req) as response:
        data = json.loads(response.read())
        return data.get("vulns", [])

# Run it — find what's vulnerable in your own environment
for pkg in get_installed_packages():
    vulns = check_against_osv(pkg['name'], pkg['version'])
    if vulns:
        print(f"VULNERABLE: {pkg['name']} {pkg['version']}")
        for v in vulns:
            print(f"  → {v.get('id')}: {v.get('summary', 'no summary')}")

The output of that script tells you your patch gap. What it does not tell you is whether someone is already in the gap. That requires monitoring — and monitoring is where the human judgment cannot be delegated.

A SIEM rule fires when a pattern matches. A human analyst looks at the pattern and asks why it's happening at 2:47am from an IP address that has never appeared before, against a service that should not be internet-facing, in a sequence that matches the reconnaissance phase of a campaign documented three months ago. Those three observations, combined, in context — that is pattern recognition that runs on experience, not on a rule set someone wrote in 2023.

# Auth log anomaly pattern — the sequence that should make someone's phone ring
# Not a rule. A starting point for a human to investigate.

# Failed auth attempts followed immediately by success — credential stuffing that found a hit
grep "Failed password" /var/log/auth.log | \
  awk '{print $11}' | sort | uniq -c | sort -rn | head -20

# New account creation outside business hours
grep "useradd\|adduser" /var/log/auth.log | \
  grep -v "09:[0-9][0-9]\|10:[0-9][0-9]\|11:[0-9][0-9]\|12:[0-9][0-9]\|13:[0-9][0-9]\|14:[0-9][0-9]\|15:[0-9][0-9]\|16:[0-9][0-9]\|17:[0-9][0-9]"

# Successful SSH login followed by privilege escalation attempt within 60 seconds
# This is the LPE chain — phishing landed, now they're going for root
grep -A5 "Accepted publickey\|Accepted password" /var/log/auth.log | \
  grep "sudo\|su -\|NOPASSWD"

The last pattern is the one that matters most right now.

---

The LPE Chain: Where the Real Damage Starts

"Local only" exploits sound minor. They are not minor.

The attack chain in 2026 is consistent: phishing or credential stuffing lands user-level access. That access looks limited — the attacker is in a low-privilege shell, a service account, a developer's compromised credentials. The AI-powered EDR sees a legitimate login and does not flag it.

Then the Local Privilege Escalation happens. A misconfigured SUID binary. An unpatched kernel vulnerability that the patch gap left open. A writable cron job running as root. A service running with more privilege than it needs because nobody audited the deployment configuration when the service was spun up two years ago.

# What an attacker runs immediately after landing user access
# LPE enumeration — looking for the path to root

# SUID binaries that shouldn't be there
find / -perm -4000 -type f 2>/dev/null | grep -v "^/usr/bin\|^/bin\|^/usr/sbin"

# Writable files owned by root
find / -writable -user root -type f 2>/dev/null | grep -v proc

# Cron jobs running as root that reference writable scripts
cat /etc/crontab | grep root
ls -la /etc/cron.*/ 2>/dev/null

# Sudo rights — what can this user run as root?
sudo -l 2>/dev/null

The attacker runs these within seconds of landing. Most environments have at least one path. The user-level access that looked contained becomes a full system compromise. The breach that looked manageable becomes a breach that requires disclosure.

The AI that allowed the "legitimate" login to pass without flagging it does not get called to account for that decision. The human who signed off on the security architecture does.

---

Where AI-Generated Code Creates the Problem

The vibe-coding era is producing an unprecedented volume of code that has never been read by anyone who thinks adversarially.

A language model generating application code is optimizing for functional correctness — does this do what the prompt asked. It is not optimizing for what an attacker can do with the inputs the prompt did not mention. This is not a criticism of the models. It is a description of the problem that requires human review.

# AI-generated code that passes tests and ships vulnerable
# (This pattern appears constantly in LLM-generated web code)

def get_user_data(user_id):
    query = f"SELECT * FROM users WHERE id = {user_id}"  # SQL injection
    return db.execute(query)

def process_file(filename):
    path = f"/uploads/{filename}"  # Path traversal: ../../../etc/passwd
    with open(path) as f:
        return f.read()

def authenticate(username, password):
    # Timing attack: string comparison exits early on first mismatch
    stored = get_password_hash(username)
    return stored == hash_password(password)


# What a human reviewer with adversarial context writes instead

def get_user_data(user_id: int):
    query = "SELECT * FROM users WHERE id = ?"  # Parameterized
    return db.execute(query, (user_id,))

def process_file(filename: str):
    # Validate against allowlist, then resolve and check it stays in bounds
    safe_name = re.sub(r'[^a-zA-Z0-9._-]', '', filename)
    path = os.path.realpath(f"/uploads/{safe_name}")
    if not path.startswith("/uploads/"):
        raise ValueError("Path traversal attempt")
    with open(path) as f:
        return f.read()

import hmac
def authenticate(username: str, password: str):
    stored = get_password_hash(username)
    # Constant-time comparison — no timing oracle
    return hmac.compare_digest(stored, hash_password(password))

The AI wrote four lines of code with three vulnerabilities. A human with context rewrote them correctly. That review did not happen automatically. Someone with the right instincts had to read the output, think like an attacker, and fix what the model did not know it broke.

That skill does not become less valuable when more code is being written. It becomes more valuable.

---

Accountability Cannot Be Automated

There is a category of decision in security that cannot be delegated to a model because the model cannot be held responsible for the outcome.

When an organization decides to accept the risk of an unpatched vulnerability because patching requires a maintenance window that would violate an SLA — that is a human decision with legal and financial consequences. When a SOC analyst decides that a behavioral anomaly is a false positive and closes the ticket — and it turns out not to be a false positive — that is a human call with an audit trail that leads to a name.

AI systems making security decisions operate outside that accountability structure. They have no professional license to lose, no liability exposure, no career risk. Organizations that route critical security decisions through models and call it automation are not solving the accountability problem — they are obscuring it.

The fields that have gotten this right — medicine, law, aviation — all have in common that the human expert is legally required to be the accountable party at the critical decision point. AI assists. The human signs off. The human holds the license.

Security is not there yet. It needs to be. The current model of pouring budget into AI tooling while reducing the headcount of people who understand what the tooling is doing is the dot-com bubble logic applied to a field where the consequences of collapse are not a crashed portfolio but a leaked database, a ransomed hospital, a critical infrastructure event.

---

The Mechanic

Every technology era produces the same argument: this new thing makes the expert obsolete. The spreadsheet was going to eliminate accountants. The compiler was going to eliminate programmers. The AI security tool is going to eliminate the security researcher.

What actually happens: the technology raises the floor and raises the ceiling. More code ships. More vulnerabilities exist. More monitoring is required. The people who understand the full stack — who can read the log, trace the chain, understand why the AI flagged this and not that, explain the decision to a judge or a board — become more valuable, not less.

The machine produces the attack surface. The mechanic finds what broke.

That job is not going away. It is expanding. And the organizations that figure that out before the breach will spend a fraction of what the ones that figure it out after will pay.

---

GhostInThePrompt.com // AI doesn't reduce the attack surface. It relocates it.