Notifications
Clear all
Topic starter
12/06/2026 9:54 pm
TL;DR: LLM platform abuse is a fraud trend built on reverse proxies, prompt scraping and impersonation workflows that help attackers bypass restrictions and scale phishing, deepfake creation and downstream malicious services, according to Arkose Labs. The governance gap is that generic bot controls and standard abuse monitoring were not designed for AI assistant ecosystems that can be abused at platform level.
NHIMG editorial — based on content published by Arkose Labs: A New Threat Vector Emerges
Questions worth separating out
Q: How should security teams detect LLM platform abuse across proxy networks?
A: Teams should look for correlated behavioural signals rather than single indicators.
Q: Why do AI assistant platforms create new fraud risks for identity teams?
A: AI assistant platforms can be abused as infrastructure for phishing, impersonation and prompt harvesting.
Q: What do security teams get wrong about prompt scraping?
A: They often treat prompt scraping as a model issue only.
Practitioner guidance
- Instrument AI assistant traffic for proxy behaviour Correlate IP rotation, country hopping, request bursts and repeated challenge failures so you can separate legitimate usage from distributed abuse services.
- Treat prompts as sensitive operational data Log and review unusual prompt extraction patterns, especially where repeated queries suggest scraping, abuse automation or model-output harvesting.
- Link bot management to fraud response Route AI assistant abuse signals into fraud, IAM and threat operations workflows so phishing, impersonation and deepfake preparation are handled as one problem.
What's in the full article
Arkose Labs' full analysis covers the operational detail this post intentionally leaves for the source:
- Threat research evidence on how the proxy ecosystem was organised across multiple countries and data centres
- Arkose GPT Protection mechanics for detecting and stopping malicious reverse proxy traffic
- Examples of workflow anomaly detection and API instrumentation used to identify abusive assistant access
- The specific challenge design techniques, including image perturbation, used to resist machine vision and AI solvers
👉 Read Arkose Labs' analysis of LLM platform abuse and AI assistant proxies →
LLM platform abuse: what it means for IAM and fraud teams?
Explore further
13/06/2026 12:18 am
LLM platform abuse is becoming a fraud supply chain, not a one-off misuse problem. The article shows two attacker classes: those who build proxy infrastructure to bypass restrictions and those who consume that infrastructure for phishing and other downstream abuse. That means defenders are no longer dealing with a single malicious session, but with a reusable ecosystem that can be sold, repackaged and redirected. The practitioner implication is that abuse controls must target the service layer and the distribution layer, not only the user interaction layer.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, according to the same research.
A question worth separating out:
Q: Who should own response when LLM abuse becomes a phishing channel?
A: Ownership should sit across fraud, IAM, security operations and bot management, with clear escalation paths. If AI assistant abuse can produce phishing, impersonation or deepfake material, then it is no longer a niche model risk. It is an enterprise abuse and identity governance issue.
👉 Read our full editorial: LLM platform abuse is exposing gaps in AI assistant security
