AI agents and bot fraud are reshaping sharing platform trust

At a glance

What this is: Arkose Labs argues that sharing platforms are facing fraud patterns that blend bots, fake accounts, account-sharing abuse, and AI-assisted attacks into a single trust problem.

Why it matters: This matters because platform IAM, fraud controls, and account governance are now tightly coupled, and teams that treat them separately will miss abuse that looks legitimate at the point of access.

By the numbers:

• 33% of consumers have been fraud victims on sharing platforms.
• 74% of gig economy companies leverage AI to speed up response times.
• 53% of platforms lack personnel with AI and cybersecurity expertise.

Context

Sharing platforms depend on a trust layer that decides whether a user is real, whether an action is legitimate, and whether an account should be allowed to proceed. When that layer is weak, fraud moves from obvious abuse into ordinary-looking platform activity.

The article frames this as a governance problem, not just a bot problem. Sharing platforms have to reconcile account sharing, fake account creation, and AI-assisted abuse with identity controls that were designed for authentic users and human review.

The operational gap is clear: platforms can no longer rely on traffic filtering alone. They need controls that evaluate behaviour, account lineage, and legitimacy together, because the abuse pattern is now mixed, adaptive, and economically motivated.

Key questions

Q: What breaks when sharing platforms rely on one account per user assumptions?

A: Those assumptions break when accounts are rented, sold, or reused across people and devices. The platform loses identity lineage, attribution becomes unreliable, and trust scoring can no longer distinguish legitimate use from fraud. Once that happens, enforcement and investigation both become weaker, even if authentication technically succeeds.

Q: Why do AI-assisted fraud tactics create more risk than static bot activity?

A: AI-assisted fraud creates more risk because the attacker can vary behaviour quickly enough to stay ahead of fixed rules and manual review. That changes the problem from spotting known bad patterns to assessing whether your decision logic can adapt without collapsing precision or creating too many false positives.

Q: How should teams decide whether a platform user is legitimate or shared?

A: Teams should decide by combining account history, device context, behavioural consistency, and transaction patterns, not by login success alone. A legitimate credential can still be misused by a different actor, so the control has to evaluate whether the current use matches the expected identity lineage and risk profile.

Q: Should fraud, IAM, and platform security teams use the same trust signals?

A: They should use a shared trust model, but not necessarily identical thresholds. IAM, fraud, and security teams need a common view of account ownership, device context, and behavioural legitimacy so that policy, detection, and escalation stay aligned when abuse crosses team boundaries.

How it works in practice

Why platform trust breaks down when identity is the attack surface

Sharing platforms expose a trust decision at every onboarding, login, listing, and transaction step. Bot fraud, synthetic identities, and account sharing all exploit the fact that the platform must decide quickly whether the actor is legitimate. Traditional perimeter and traffic controls see volume and velocity, but fraud often hides inside plausible session behaviour. Once fraud becomes identity-led, the relevant control question shifts from blocking bad traffic to proving that the account, device, and behaviour belong together. That is why fraud prevention, identity assurance, and governance increasingly overlap in the same control plane.

Practical implication: treat platform trust as an identity decision problem, not a network filtering problem.

How AI assistance changes fraud patterns on sharing platforms

AI-assisted fraud increases speed, scale, and adaptation. Instead of one fixed abuse pattern, the attacker can vary account creation, message content, device signals, and session timing to stay below static thresholds. That makes rule-only systems brittle because the adversary learns the policy surface faster than teams can tune it. The article’s focus on AI and fraud reflects a broader shift: attack automation now adapts in real time to whatever the platform uses for trust scoring. Security and fraud teams therefore have to understand how behavioural signals are combined, not just whether any single signal is blocked.

Practical implication: validate whether your fraud stack can adapt to changing attacker behaviour rather than only known bad patterns.

What account-sharing abuse reveals about governance gaps

Account sharing is not just policy violation. It shows that the platform may be relying on the assumption that one account maps to one person and one device context. When workers rent or sell access, the platform loses the ability to tie activity back to a stable identity owner, which weakens enforcement, investigations, and trust scoring. That is an NHI-like governance failure in a consumer setting: the account becomes a reusable access token shared across multiple actors. The result is poor attribution and poor control over who is actually using the privilege.

Practical implication: anchor enforcement to identity lineage and usage context, not to the account name alone.

NHI Mgmt Group analysis

Platform trust is now an identity governance problem, not a fraud-only problem: Sharing platforms are no longer dealing with isolated bot traffic. They are dealing with blended abuse that crosses account creation, access, and transaction legitimacy, which means fraud controls and identity controls have converged. The practitioner implication is that trust scoring, account governance, and behavioural assurance have to be designed together.

Account-sharing abuse exposes a reusable-access model that consumer platforms are still under-governing: When one account is rented or sold to another person, the platform loses the identity lineage that ties activity to a real owner. That breaks attribution, weakens enforcement, and makes trust signals harder to interpret. The implication is that account ownership and usage context now matter as much as authentication success.

Trust control debt: This article shows that platforms have accumulated a gap between what their access controls assume and how users actually share and reuse accounts. The problem is not only malicious bots, but governance built around a one-user-one-account assumption that no longer holds in many shared-economy environments. Practitioners should treat that assumption as broken and redesign the trust layer accordingly.

AI-driven fraud compresses the attacker adaptation cycle below static fraud operations: When attackers can vary onboarding behaviour, session patterns, and account activity at machine speed, manual review and fixed heuristics become less reliable. The control challenge is no longer simply detection volume, but decision quality under rapid variation. Practitioners should prioritise control designs that can absorb changing abuse patterns without losing precision.

The lack of AI and cybersecurity expertise is itself a platform risk multiplier: If 53% of platforms lack personnel with AI and cybersecurity expertise, the issue is not just staffing. It is whether the organisation can interpret new abuse patterns quickly enough to keep trust controls aligned with attacker behaviour. Practitioners should read this as a capability gap that affects detection, policy design, and escalation decisions.

From our research library:

• 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Maturity Model

What this signals

Trust-control debt: Platform abuse becomes harder to manage when governance assumes stable, single-owner accounts in environments where sharing and reuse are common. The practical shift is from checking whether a user signed in successfully to checking whether the current actor matches the account’s expected identity lineage.

The more AI accelerates fraud adaptation, the less reliable static rules become. Teams need decisioning that can absorb behavioural variation without forcing every anomaly into the same response path, especially where onboarding, listing creation, and payment actions all sit on the same trust boundary.

For practitioners

• Map trust decisions to account lineage Identify where your platform assumes one account equals one person and one device context, then test those assumptions against real usage patterns such as account sharing, multi-device access, and delegated use.
• Tune fraud logic for adaptive abuse Review whether static rules, fixed thresholds, and manual review queues can still separate genuine users from AI-assisted abuse when attackers vary behaviour in real time.
• Separate identity assurance from traffic filtering Treat onboarding, login, and transaction legitimacy as identity decisions rather than only bot-detection events, so the platform can evaluate account authenticity and behavioural legitimacy together.
• Build controls for shared-account misuse Add enforcement and investigation paths for rented, sold, or otherwise reused accounts, because shared access destroys the stable identity trail that traditional platform controls expect.
• Close the AI and cybersecurity skill gap Assess whether fraud, IAM, and security teams have enough shared expertise to tune trust controls, interpret attack variation, and respond before fraudulent behaviour scales.

Key takeaways

• Sharing platforms are facing a trust problem that blends bot abuse, fake accounts, account sharing, and AI-assisted fraud into a single governance challenge.
• The article cites 33% consumer fraud victimisation on sharing platforms, 74% AI use by gig economy companies to speed response times, and 53% of platforms lacking AI and cybersecurity expertise.
• Practitioners should govern identity lineage, shared-account misuse, and adaptive fraud behaviour together, because traffic filtering alone cannot preserve trust.

Key terms

• Account Sharing: Account sharing is the practice of multiple people using the same login credentials to access a system, application, or privileged function. It reduces friction in the short term but destroys individual attribution, weakens auditability, and makes identity assurance depend on the group rather than the person.
• Trust Control: A trust control is any mechanism that decides whether a user, session, or action should be allowed to proceed on a platform. In fraud-heavy environments, it combines identity signals, behavioural signals, and risk scoring to determine whether the current actor matches the expected account context.
• Adaptive fraud detection: A fraud control approach that updates its decision logic as new abuse patterns appear. Instead of waiting for scheduled retraining or manual rule changes, the system incorporates fresh signals into its model behaviour so that detection can keep pace with changing attacker tradecraft.
• Identity Lineage: Identity lineage is the traceable relationship between a human owner and the non-human identities that person creates, authorises, or depends on. It allows security teams to connect service accounts, API keys, tokens, and AI agents back to accountable ownership for review, audit, and retirement decisions.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.