Security in 2026: Attackers use customized LLMs while we're still fixing OWASP Top 10. Are we screwed?

[security_sam]

Between January and mid-February 2026, an AI-augmented threat actor compromised over 600 FortiGate devices across 55 countries using autonomous agents that never slept, never missed a misconfigured port, and adapted their tactics in real-time when defenses pushed back. No human operator sat there manually trying credentials—the AI did it all, iterating through attack vectors faster than any SOC could respond.

I’ve spent the last eight years in security, from Stripe’s payment infrastructure to CrowdStrike’s threat intelligence teams, and now consulting with African fintech startups. The asymmetry I’m seeing in 2026 is unlike anything in my career. We’re not just facing a skill gap or a resource gap anymore—we’re facing a fundamental capability gap.

The Attacker’s Arsenal Has Evolved

Threat actors aren’t using AI as a productivity tool. They’ve entered a new operational phase:

Autonomous AI agents that execute the full intrusion lifecycle—reconnaissance, exploitation, credential theft, lateral movement, data exfiltration—across many targets simultaneously. These aren’t scripts. They’re adaptive systems that respond to defensive countermeasures and keep trying until they succeed or get shut down.

Customized LLMs purpose-built for attack. Chinese nation-state actors created frameworks that abuse Claude for large-scale automated attacks. We’re seeing malware families like PROMPTFLUX and PROMPTSTEAL that use LLMs during execution to dynamically generate malicious scripts and obfuscate their own code to evade detection.

Memory poisoning attacks that implant false or malicious information into an agent’s long-term storage. Unlike standard prompt injection that ends when you close the chat, poisoned memory persists. The agent “learns” the malicious instruction and recalls it in future sessions. Research from December 2026 found that in simulated systems, a single compromised agent poisoned 87% of downstream decision-making within 4 hours.

The scale is staggering: AI agents enabling 10,000 personalized phishing emails per second, crafting zero-day exploits instantly, deploying ransomware across thousands of endpoints in under a minute.

Meanwhile, On The Defense Side…

We’re still rolling out DevSecOps. Don’t get me wrong—shift-left security, SAST→SCA→IAST→DAST pipelines, software supply chain security—these are good practices. But they’re designed for a threat landscape that moved on six months ago.

The stats from 2026 AI security research are brutal:

• Only 34% of enterprises have AI-specific security controls in place
• Less than 40% of organizations conduct regular security testing on AI models or agent workflows
• Only 24% of enterprises have a dedicated AI security governance team
• Alert fatigue is real: 1,000+ alerts per scan with most being false positives

Even when organizations try to defend against AI threats, they run into the chicken-and-egg problem: you need AI to triage the AI-generated alerts about AI-powered attacks. But can you trust the AI security tools when attackers are poisoning AI systems?

The Question That Keeps Me Up At Night

I’m consulting with fintech startups in Lagos, Nairobi, Cape Town. These teams are 5-10 engineers trying to build secure payment systems. They don’t have budgets for enterprise security platforms. They can’t hire a dedicated AI security team.

When attackers have autonomous agents and custom LLMs, and defenders have limited budgets and overstretched security teams, are we fundamentally outgunned?

Here’s what I’m wrestling with:

1. Should small teams even try to compete on AI tooling? Or is there a different defensive strategy that doesn’t require matching attacker AI sophistication?

2. Do “boring” fundamentals still matter? Network segmentation, least privilege, zero trust architecture—are these enough when facing adaptive AI agents? Or are they now just speed bumps?

3. What’s the minimum viable AI security posture for a startup? If 66% of enterprises don’t have AI-specific controls, what should a 10-person team prioritize?

4. Is the answer better tools or better architecture? Can we design systems that are resilient to AI-powered attacks without needing AI-powered defenses?

What I’m Seeing Work (Sort Of)

The teams that seem least panicked are doing a few things:

• Input sanitization and prompt injection defense as first-class concerns, not afterthoughts
• Secure AI development lifecycle starting with Phase 1: verifying data integrity and origin to stop poisoning at the source
• Risk-scoring and AI-powered triage to cut through alert fatigue—yes, using AI to defend against AI, but at least making the 1000+ alerts actionable
• Human awareness training on deepfakes and AI-generated social engineering (now a critical skill for IT support handling password reset requests)

But I’ll be honest: these feel like interim measures while we figure out the real answer.

What’s your team doing about this? Are you seeing the same asymmetry? And more importantly—do you have strategies that are actually working against AI-augmented threats, or are we all just hoping we’re not the next target?

---

Sources: Stellar Cyber on agentic AI threats, Northwave on AI-driven cyberattacks, Barracuda on agentic AI as threat multiplier, Practical DevSecOps AI security statistics

[priya_security]

The identity layer is exactly where this AI asymmetry hurts the most, and I’ve had a front-row seat to it.

At Auth0 and Okta, we spent years building behavioral analysis engines, device fingerprinting, impossible travel detection—all the smart signals to catch fraudsters. Then in 2025-2026, I watched all of it start to break down.

What Changed

Deepfake-powered account takeovers: Voice deepfakes good enough to bypass customer service authentication. Video deepfakes that defeat liveness checks. The old “call the user back” defense? AI agents now spoof caller ID and synthesize convincing real-time conversations.

Synthetic identities at scale: We’re seeing identity packages (name, SSN, address, employment history, credit history) that are entirely fabricated but pass all traditional verification checks because they were trained on real data patterns. Not one synthetic identity—thousands generated per hour.

Automated credential stuffing with context awareness: Traditional credential stuffing was easy to detect (same IP, rapid attempts, no session history). Now? AI agents rotate IPs, mimic human browsing patterns, wait realistic intervals between attempts, even interact with the site like a real user before trying credentials. The behavioral signals we relied on are being gamed.

The Defense Playbook Isn’t Working

At my current fintech, we tried implementing 2FA everywhere. Attackers used AI-generated phishing that was personalized to each user’s role, included company-specific context, and arrived at times when people were most likely to click (AI-analyzed from leaked email patterns). Our 2FA adoption went up, but so did successful phishing.

Behavioral biometrics? Keystroke dynamics, mouse movement patterns, scroll behavior—all can be mimicked by adaptive agents trained on real user data.

What Might Actually Help

I’m cautiously optimistic about a few approaches, though none are silver bullets:

Zero-knowledge proofs for identity verification: Instead of sharing identity data that can be deepfaked or synthesized, prove you possess certain attributes without revealing them. It’s cryptographically harder (maybe impossible?) for an AI to fake what it doesn’t have access to in the first place. But this is complex to implement and requires infrastructure most startups don’t have.

Blockchain-based identity with decentralized verification: Distributed trust models where no single AI can poison the entire verification chain. Think multiple independent verifiers that would each need to be compromised. Again, expensive and complex.

Physical hardware tokens with biometric binding: Combining something you have (hardware token) with something you are (fingerprint/face on the device itself, not transmitted). Harder for remote AI agents to attack. But terrible UX and limited to certain use cases.

The brutal reality? These are all expensive, complex solutions that require significant technical lift. The fintech startups I talk to—teams of 5-10 engineers like Sam mentioned—they can’t implement zero-knowledge proof systems or blockchain identity infrastructure.

The Painful Question

So here’s what keeps me up: If the sophisticated identity defenses are too expensive for small teams, and the traditional defenses (2FA, behavioral analysis) are being actively defeated by AI agents, what do you actually do?

Maybe Sam’s point about fundamentals is key—if you can’t compete on AI sophistication, can you at least design systems where identity compromise has limited blast radius? Segment aggressively, implement least privilege so thoroughly that even a compromised identity can’t do much damage?

I don’t know. But I do know that every week I hear about another startup that lost their entire user database because one support rep got social-engineered by an AI agent that sounded exactly like their CEO.

For teams without million-dollar security budgets: what’s your realistic identity protection strategy in 2026?

[eng_director_luis]

I’m wrestling with a version of this same question from the enterprise side, and honestly, I’m starting to think the answer might be less about AI sophistication and more about architectural discipline.

The Enterprise Paradox

At my Fortune 500 financial services company, we have resources most startups would kill for. Dedicated security team of 20+, enterprise security platforms, compliance frameworks, the works. You’d think we’d be better positioned against AI threats.

We’re not.

Why? Because we’re running critical banking systems built in the late 1990s and early 2000s. COBOL cores wrapped in layer after layer of integration middleware. These systems can’t integrate modern AI security defenses. They don’t speak the same language as AI-powered threat detection. They were designed in an era when “sophisticated attack” meant someone manually trying SQL injection.

When I read about memory poisoning attacks on AI agents, my first thought is: “At least AI agents have memory we can monitor.” Our legacy systems have undocumented state scattered across mainframes, message queues, and batch processes that run at 2 AM for reasons no one remembers.

What’s Actually Working For Us

Here’s the uncomfortable truth: The things keeping us relatively secure aren’t cutting-edge AI defenses. They’re boring fundamentals executed with obsessive discipline.

Network segmentation so extreme it’s painful: Our payment processing core can’t talk to the internet. Period. It can’t talk to our web servers directly. Every interaction goes through multiple DMZs with hardware-enforced rules. If an AI agent compromises our customer-facing web app, it hits a wall. The architecture assumes breach and limits blast radius.

Least privilege enforced at the infrastructure level: No human (or AI agent) can directly access production databases. Every query goes through stored procedures with role-based permissions. Yes, it’s slow. Yes, developers complain. But when AI-powered attacks try lateral movement, they find doors that don’t open without multiple cryptographic keys physically distributed across different people.

Change control that would make a startup cry: Every deployment requires security review, compliance sign-off, rollback plans tested in production-equivalent environments. An AI agent that compromises a developer’s machine can’t push malicious code to production because the CI/CD pipeline has human checkpoints (for now—we’re actively debating if AI will bypass those too).

Regulatory compliance as accidental defense: SOX, PCI-DSS, SOC 2—all these frameworks demand audit trails, separation of duties, multi-party authorization. They were designed to prevent insider fraud, but they’re also pretty effective at slowing down AI agents that need to execute complex attack chains rapidly.

The Uncomfortable Question

Does this mean the answer for startups is… move slower? Build bureaucracy? That feels wrong. Startups need velocity.

But maybe there’s a middle ground: Can you build architectural constraints that achieve the same isolation and least-privilege outcomes without the enterprise bureaucracy?

Some ideas I’m kicking around:

• Microservices with zero-trust networking from day one (not added later)
• Infrastructure-as-code with mandatory security policies enforced at deploy time
• Automated least-privilege through tooling, not manual ACL management
• Serverless architectures where the platform enforces isolation you’d have to build manually

To Sam’s Original Question

“Do boring fundamentals still matter?”

From where I sit: The fundamentals matter MORE, not less. AI-powered attacks are sophisticated in their tactics but they still need to move laterally, escalate privileges, exfiltrate data. If your architecture makes those steps harder through network segmentation, least privilege, and defense in depth, you’re not outgunned—you’re making the attacker work for every inch.

But—and this is key—you have to implement the fundamentals correctly and completely. Half-implemented network segmentation with exceptions for “just this one integration” is useless. Least privilege with “just this one admin account we all share” defeats the purpose.

Here’s my question back to the group: Can small teams implement real architectural security discipline without sacrificing the velocity that makes them competitive? Or is there an inherent trade-off where you have to choose between moving fast and being secure?

I want to believe there’s tooling and patterns that let you have both, but I haven’t seen it work consistently at scale yet.

[maya_builds]

Okay, this conversation is fascinating but I want to throw in a perspective that might be unpopular: maybe the problem isn’t that the security tools are too weak—maybe it’s that they’re too complicated for humans to actually use.

The Startup That Died By Security Theater

My last startup failed for a lot of reasons, but one contributing factor haunts me: we got breached because our security tooling was so cumbersome that developers routinely bypassed it.

We had implemented all the things you’re “supposed” to do:

• Secret scanning in git pre-commit hooks (slowed down commits to 30+ seconds)
• Mandatory security reviews for every PR (bottlenecked on one security-minded senior dev)
• VPN required for production access (constantly disconnected, broke local dev workflows)
• 2FA on everything (including internal tools we accessed 50x per day)

What actually happened?

• Developers found ways to skip the git hooks
• PRs got rubber-stamped to keep velocity up
• People shared the “team” production credentials to avoid VPN hassle
• The 2FA on internal tools trained everyone to auto-approve without reading

When we got breached, it wasn’t because our security tools were inadequate. It was because we designed security that fought against how humans actually work.

The UX Problem With AI Security

Now imagine layering AI-specific security on top of this already-hostile UX:

• Prompt injection scanners that flag false positives on 40% of legitimate AI calls
• AI model verification that adds 500ms latency to every inference
• Manual reviews of AI-generated code diffs (because you can’t trust the AI output)
• Multi-party authorization for AI agent actions (kills the whole point of autonomous agents)

Who’s actually going to use this? Developers are going to find workarounds. They always do when the tools create too much friction.

What If We Flipped The Problem?

Instead of asking “How do we add more security controls?” what if we asked:

“How do we make the secure path the easiest path?”

Luis mentioned serverless architectures where the platform enforces isolation—that’s exactly the kind of thinking I’m talking about. Security that’s invisible because it’s built into the infrastructure, not bolted on as a gate-keeping step.

Some ideas from a design perspective:

Guardrails, not gates: Instead of blocking developers from doing risky things (which they’ll bypass), make it so the risky things aren’t even possible. Can’t commit secrets to git if your secrets management system doesn’t let secrets exist outside encrypted stores. Can’t do lateral movement if your network architecture doesn’t allow it by default.

Progressive enhancement for security: Make the basic secure behavior zero-friction and automatic. Make the riskier behaviors require more effort. Right now we have it backwards—deploying insecurely is fast, deploying securely requires jumping through hoops.

AI security UX that respects developer flow: If you’re going to scan AI-generated code for security issues, integrate it into the IDE where developers already are, not as a separate review step that breaks their flow. Show contextual warnings inline, not 100 alerts in a dashboard no one looks at.

The Accessibility Angle

Here’s another way to think about it: accessible design makes things usable for everyone. If your security tooling is only usable by security experts, you’ve failed the 90% of developers who aren’t security experts but need to build secure systems.

What would “accessible security” look like for AI systems?

• Default-secure configurations that work out of the box
• Clear, actionable error messages when something’s risky (not cryptic warnings)
• Security controls that adapt to context (less friction for low-risk actions, more for high-risk)
• Documentation written for developers, not security teams

To Luis’s Question About Velocity vs Security

I actually think this is a false choice if you design it right. Security should increase velocity because it reduces the “oh shit we got breached” moments that grind everything to a halt.

But that only works if security is:

1. Built into the architecture (not added as process)
2. Invisible or low-friction for developers
3. Impossible to bypass (because it’s infrastructure-level, not policy-level)

Maybe the answer to AI security isn’t better AI detection tools. Maybe it’s designing systems where AI agents can’t do the dangerous things we’re worried about, regardless of how sophisticated the attack is.

Am I being too idealistic? Or is there a world where security tools are actually pleasant to use and developers don’t actively fight against them?