TL;DR: Pre-Mythos models still enable end-to-end exploit development, according to Intruder, after its engineer used a token-driven workflow to find a SQL injection flaw affecting 300,000-plus sites, and says the practical constraint is operator skill rather than model availability. The lesson for defenders is that AI-assisted attack capability is already present, so exposure reduction and patch speed matter more than debating model bans.
At a glance
What this is: Intruder says AI-assisted exploitation can still identify and weaponise real vulnerabilities, including a SQL injection flaw on 300,000-plus sites.
Why it matters: This matters to IAM and security teams because AI-assisted attack workflows increase the speed of credential, application, and service abuse, which raises the bar for discovery, patching, and access governance.
By the numbers:
- 200 WordPress plugins and the first exploit it, ordPress plugins and the first exploit it produced was CVE-2026-3985 on more than 300,000 sites.
- Intruder says AI-powered checks made up 90% of the new detections it shipped in its first month of building them.
👉 Read Intruder's analysis of AI-assisted 0-day discovery and NHI abuse
Context
AI-assisted exploit development is moving from theory to repeatable workflow. The core governance gap is not whether a model can think like an attacker, but whether an operator can chain scanning, proof-of-concept generation, and exploitation into a usable attack path faster than defenders can detect and remediate it. That is relevant to identity security because the same acceleration can be applied to exposed secrets, vulnerable control planes, and overprivileged service access.
Intruder frames the issue through its own testing, the pullback of one model from public access, and a broader claim that capability already exists in earlier models. The practical implication is that policy debates about model access do not remove the underlying attack pattern. For practitioners, the problem is exposure management, privileged access control, and the speed at which weak internet-facing services can be turned into entry points.
Key questions
Q: How should security teams respond when AI can generate exploit chains from dormant vulnerabilities?
A: Security teams should stop treating exploitability as a human bottleneck and start proving whether a flaw is reachable in their own environment. That means combining patching with attack-path validation, privilege reduction, and containment controls that limit blast radius if an exploit chain appears. Severity scores alone are no longer enough to guide prioritisation.
Q: Why do exposed service keys become more dangerous when AI features are added?
A: Because the key remains easy to reuse while the service it unlocks becomes more valuable and more expensive to abuse. A public key that once meant routine API access can now trigger metered AI usage or content retrieval. That turns a simple secret into a combined identity, cost, and confidentiality risk.
Q: What do security teams get wrong about banning AI models?
A: They often treat model access as the main control, when the real risk is the attack workflow. If comparable capability exists in other models or local tools, banning one system does not remove the ability to scan, reason about, and weaponise vulnerabilities.
Q: Who should own response when AI-assisted exploitation hits internet-facing applications?
A: Application security, infrastructure, and identity teams should share ownership, because the fix spans patching, asset exposure, and credential containment. If the exploited service can reach sensitive backend roles, privileged access and non-human identity owners need to be in the containment chain immediately.
Technical breakdown
How AI-assisted exploit chains turn discovery into working code
AI-assisted offensive workflows usually combine three steps: reconnaissance, vulnerability reasoning, and payload generation. A scanning layer identifies likely targets, the model helps interpret code or configuration patterns, and the operator iterates until a proof of concept works. The key point is that the model does not need perfect autonomy to be dangerous. Even partial automation can compress tasks that once required specialist time, especially when the flaw is deterministic, such as SQL injection or exposed secrets.
Practical implication: reduce the number of internet-exposed services and make exploit validation faster than attacker iteration.
Why exposed services and weak secrets management are the real multiplier
The value of AI in attack work scales with the quality of exposed inputs. Public services, leaked credentials, and predictable application flaws give a model something concrete to optimise against. Once an attacker has a foothold, weak IAM, stale tokens, and overbroad service permissions let them move from discovery to abuse quickly. This is why the NHI layer matters even in a broadly application-security story: secrets and service identities are the bridge from first exploit to meaningful impact.
Practical implication: treat exposed credentials and service accounts as high-priority attack surface, not back-office hygiene.
Why model restrictions do not equal risk reduction
Restricting access to one AI model does not remove the technique if similar capability exists elsewhere, including open models, locally hosted systems, or chained tooling. Security risk sits in the workflow, not just the model name. That workflow can be reproduced with code search, vulnerability reasoning, and automated proof-of-concept generation. Defenders should therefore assume attackers will continue to mix general-purpose AI with conventional offensive tooling rather than depend on a single banned system.
Practical implication: focus control design on detection, exposure reduction, and privilege containment instead of relying on model availability decisions.
NHI Mgmt Group analysis
AI-assisted offence is now a workflow problem, not a model problem. The article shows that the offensive value lies in chaining tools, reasoning, and execution, not in any single model release. That means the market conversation should shift from model bans to control points around exposure, privilege, and validation speed. For security teams, the useful question is whether their environment can withstand an attacker who iterates faster than a human analyst.
Application exposure remains the easiest place for AI to create leverage. A SQL injection discovered across 300,000-plus sites is a reminder that deterministic flaws are ideal targets for machine-assisted abuse. This is where application security, internet-facing asset inventory, and vulnerability prioritisation intersect with identity governance, because exposed services often lead directly to service credentials or backend access. Practitioners should assume the first compromise step is only useful if the surrounding access model is weak.
Secret sprawl turns AI-assisted exploitation into identity compromise. When scanners, proof-of-concept generators, and exploit runners can be chained together, leaked API keys and service credentials become the shortest path to impact. That is the same governance failure OWASP NHI guidance tries to address: unmanaged non-human identities with standing access and weak lifecycle control. The named concept here is AI exploitation compression, meaning the shrinking time between flaw discovery and usable compromise. Teams should shorten that window with tighter secret hygiene and faster revocation.
Control effectiveness will matter more than access policy theatre. The article implies that if a team cannot observe exposed services, validate remediation quickly, and remove high-risk credentials fast, the attacker already has the advantage. Frameworks such as NIST CSF, NIST SP 800-53, and OWASP NHI all point toward continuous monitoring, access restriction, and authenticated asset visibility. The practitioner takeaway is straightforward: prove that your controls reduce exploitability in hours, not weeks.
AI-assisted attack capability will keep spreading even if public model access changes. The source’s main warning is that the capability already exists in accessible models and tooling. That means defenders should expect more commodity attackers to adopt parts of the same workflow, especially against weakly governed internet-facing systems. Security programmes that still separate application exposure from identity governance will miss the point.
From our research:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
- For the next step, read OWASP Agentic AI Top 10 to connect agent behaviour risks to a practical control model.
What this signals
AI-assisted offence will pressure teams to connect exposure management with identity governance. If a service can be reached from the internet, and that service can reach sensitive back-end systems, the attack path is already partially built. The right response is not just faster patching but better control of the identities behind exposed applications and automation.
The named concept here is AI exploitation compression: the shrinking time between vulnerability discovery and exploitable proof of concept. That compression makes stale secrets, overprivileged service accounts, and weak revocation processes more valuable to attackers. It also means detection engineering must assume bursts of machine-assisted probing rather than slow manual reconnaissance.
As AI-enabled workflows become more common, teams should align their exposure review with guidance from OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0. The practical signal to watch is whether your programme can turn a newly exposed service into a contained issue before it becomes an access event.
For practitioners
- Prioritise internet-facing services with exploitable code paths Build a patch queue around services that expose deterministic flaws such as SQL injection, command injection, and auth bypass, then validate fixes with live exploit testing.
- Map exposed services to the identities they can reach For each externally reachable application or API, identify the service accounts, API keys, and backend roles it can access so compromise paths are visible before attackers test them.
- Shorten revocation windows for non-human credentials Rotate and revoke API keys, tokens, and certificates that are tied to internet-facing workloads as soon as they are suspected to be exposed, with ownership assigned in advance.
- Instrument detection for AI-shaped attack behaviour Look for rapid scan-and-exploit sequences, repeated proof-of-concept attempts, and bursty requests against the same vulnerable endpoint, then feed those patterns into detection rules.
Key takeaways
- AI-assisted exploitation is most dangerous when it shortens the path from flaw discovery to usable code.
- The biggest business risk is not model access itself, but exposed services and weak non-human credential governance.
- Teams need to treat patch speed, secret revocation, and internet-facing exposure as one control problem.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0001 , Initial Access; TA0006 , Credential Access; TA0040 , Impact | The article centers on exploit-driven entry and downstream abuse. |
| NIST CSF 2.0 | PR.AC-4 | The post stresses controlling access to exposed systems and backend resources. |
| NIST SP 800-53 Rev 5 | AC-6 | Least privilege is central when compromised services can reach sensitive systems. |
| OWASP Non-Human Identity Top 10 | NHI-03 | The article links exploit speed to secret exposure and non-human credential abuse. |
| NIST AI RMF | MANAGE | AI-enabled attack workflows require ongoing risk treatment and monitoring. |
Map exposed services and stolen secrets to attack tactics, then prioritise detections that break the chain early.
Key terms
- AI-assisted exploit chain: A sequence of attack steps where an AI system helps an operator find, validate, or weaponise a vulnerability. The model may not act autonomously, but it can still compress reconnaissance and proof-of-concept work enough to make exploitation faster and more repeatable.
- Internet-Facing Exposure: Internet-facing exposure is the condition where a system, interface, or management plane is reachable from the public internet. In vulnerability management, that exposure sharply increases urgency because scanning, exploitation, and follow-on compromise can begin almost immediately after disclosure.
- AI exploitation compression: The reduction in time between vulnerability discovery and a usable exploit because AI accelerates reasoning, coding, and iteration. This matters because defenders lose time advantage, especially when exposure is already public and remediation is slow.
- Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
What's in the full article
Intruder's full analysis covers the operational detail this post intentionally leaves for the source:
- A step-by-step walkthrough of how the 0-day vending machine chained scanning, reasoning, and proof-of-concept generation.
- The specific WordPress plugin analysis that led to CVE-2026-3985 on more than 300,000 sites.
- Intruder's own breakdown of what AI-powered checks are detecting and how the coverage is changing.
- The wider commentary from its security team on model restrictions, attacker capability, and midmarket patching realities.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is built for practitioners who need to connect access control, lifecycle management, and operational risk across their programmes.
Published by the NHIMG editorial team on August 18, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org