Accountability usually sits with the platform owner for the control design, with operational responsibility shared across trust and safety, fraud, and identity teams. When platforms allow low-assurance onboarding and weak escalation paths, they create the conditions for abuse. Governance should define who owns detection, who owns intervention, and who owns user communication.
Why This Matters for Security Teams
AI-enabled romance fraud is not just a social engineering problem. It is a governance problem that spans onboarding, identity proofing, abuse detection, and escalation handling. When a platform lets an actor create believable personas at scale, the failure is rarely one control. It is usually a chain of low-assurance decisions that makes manipulation cheap and intervention slow. That is why accountability cannot stop at the fraud case review.
From an NHI perspective, the platform is accountable for the identity and trust fabric that made the abuse possible. The question is less about who typed the messages and more about who approved the risk controls that enabled persistence, impersonation, and cross-channel escalation. Current guidance from NIST Cybersecurity Framework 2.0 supports shared accountability across governance, protection, detection, and response, but it does not remove the need for a clear owner.
NHIMG research on the Ultimate Guide to NHIs — The NHI Market shows how identity sprawl and weak control boundaries create durable abuse paths. In practice, many security teams encounter accountability gaps only after victims report harm, rather than through intentional prevention design.
How Accountability Should Be Assigned in Practice
The accountable party is usually the platform owner because that function controls product design, policy enforcement, and risk acceptance. Trust and safety, fraud, identity, and customer support may all share operational responsibility, but one business owner must be answerable for outcomes. Without that clarity, every team can point to another team when low-assurance onboarding or poor escalation routing is abused.
A workable model assigns ownership across the lifecycle:
- Platform product owner: accountable for onboarding risk, profile verification standards, and feature design that may be exploited.
- Trust and safety: responsible for detection rules, content signals, and abuse workflows.
- Fraud operations: responsible for case triage, pattern review, and escalation thresholds.
- Identity and access team: responsible for assurance levels, step-up checks, and session controls.
- Legal and compliance: responsible for regulatory reporting, evidence handling, and victim communication obligations.
That structure should be mapped into a RACI so that detection, intervention, and user communication are explicitly assigned. The DeepSeek breach is a reminder that once trust is lost, remediation is harder than prevention. For platforms, the analog is the same: weak identity controls make impersonation scalable, and scalable impersonation makes fraud response reactive. Best practice is evolving, but current guidance suggests treating abuse prevention as part of core platform governance, not as an after-the-fact moderation task.
These controls tend to break down when large platforms rely on outsourced moderation and loosely coupled product teams because no single owner can enforce consistent escalation decisions across regions and channels.
Where the Model Breaks Down and What to Document
Tighter accountability often increases operational overhead, requiring organisations to balance faster product growth against stronger abuse controls. That tradeoff becomes acute in marketplaces, dating apps, and creator platforms where anonymity, pseudonymity, and rapid signup are part of the product value proposition. There is no universal standard for how much identity friction is acceptable in these environments.
Document the decision points that matter most:
- What assurance level is required before a profile can message at scale?
- Who can suspend accounts, and what evidence is needed?
- Who approves exceptions for high-risk geographies, VIP users, or legacy accounts?
- What threshold triggers human review versus automated action?
When AI is used to generate messages, images, or voice content, the platform should also define whether the risk owner is the AI product team, the fraud team, or the trust and safety function. The answer may differ by architecture, but the accountability line must still be visible to auditors and incident responders. Current practice is still maturing, so organisations should record these choices explicitly rather than assume policy intent will be understood during a live abuse event. That becomes especially important when the fraud path spans multiple tools, vendors, and support channels at once.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Identity sprawl and weak assurance enable abusive impersonation paths. |
| NIST CSF 2.0 | GV.RM-03 | Accountability depends on explicit risk ownership and governance decisions. |
| NIST AI RMF | AI-generated abuse requires governance for accountable, human-led oversight. |
Assign ownership for NHI lifecycle controls and verify assurance before accounts can act at scale.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
