Impersonation and Fake Account Detection Prompt

This prompt is designed for identity and account integrity engineers who need a programmatic, auditable method to assess whether a user profile is impersonating a brand, public figure, or another user. It is intended to sit at the ingress layer of an account creation or profile update workflow, acting as a gate before the account is granted platform access. The core job-to-be-done is to transform unstructured profile data—display names, bios, avatar descriptions, and behavioral signals—into a structured impersonation risk score with supporting evidence and a recommended verification action. This output can then trigger downstream enforcement logic such as identity verification, shadowbanning, or human review queues.

Use this prompt when you need a deterministic classification that can be logged, audited, and used to justify automated enforcement actions. It is most effective when you have a clear definition of what constitutes impersonation on your platform and can provide the model with a taxonomy of protected entities (e.g., verified brands, public figures, internal employees). The prompt requires structured input fields: the profile's display name, bio text, avatar description, and any available behavioral signals like account age or recent activity. Do not use this prompt for real-time chat moderation or content-level abuse detection; it is specifically scoped to account-level identity assessment. It is also not a replacement for cryptographic identity verification or KYC processes—it is a risk-scoring layer that informs those heavier interventions.

Before deploying this prompt, ensure you have defined the escalation paths for each risk tier. A low-risk score might result in automatic approval, a medium-risk score might trigger an email verification challenge, and a high-risk score should route directly to a human review queue with the evidence extracted by the prompt. Avoid using this prompt in isolation without a human review fallback for high-risk classifications, as false positives on impersonation can block legitimate users and create support burdens. The next section provides the copy-ready prompt template you can adapt to your platform's specific impersonation taxonomy and enforcement thresholds.

The following prompt template is designed to be integrated directly into your trust and safety pipeline. It accepts a list of protected entities (brands, public figures, internal executives) and a target profile's data, then returns a structured JSON risk assessment. The prompt is engineered to request evidence and a recommended action but explicitly stops short of making a final enforcement decision, ensuring that high-stakes account actions always pass through a human review queue when confidence is below a defined threshold.

textCopy
System: You are an identity integrity analyzer. Your task is to compare the provided [PROFILE_DATA] against the [PROTECTED_ENTITY_LIST] to detect potential impersonation. Analyze display names, usernames, bios, avatar descriptions, and any available behavioral signals. Do not make a final enforcement decision.

Input Data:
- Protected Entity List: [PROTECTED_ENTITY_LIST]
- Profile Data: [PROFILE_DATA]

Output Requirements:
- Return a single valid JSON object conforming to the [OUTPUT_SCHEMA].
- The `risk_score` must be an integer between 0 (no risk) and 100 (definite impersonation).
- The `evidence` array must contain specific, quoted strings from the profile data that support your assessment.
- The `recommended_action` must be one of: `clear`, `verify`, `escalate`.
- If `confidence` is below the [CONSTRAINTS] threshold, the `recommended_action` must be `escalate` for human review.
- Do not include any text outside the JSON object.

To adapt this template for your production environment, replace the placeholders with your actual data structures. The [PROTECTED_ENTITY_LIST] should be a pre-processed, structured list of names, aliases, and known profile attributes you want to safeguard. The [PROFILE_DATA] should be a serialized JSON object containing all available signals from the account under review. The [OUTPUT_SCHEMA] placeholder should be replaced with your exact JSON Schema definition, including required fields like risk_score, confidence, evidence, and recommended_action. The [CONSTRAINTS] placeholder should specify your operational thresholds, such as a minimum confidence score of 85 before automated clear or verify actions are permitted. Before deploying, run this prompt against a golden dataset of known impersonation and legitimate accounts to calibrate the risk scoring.

This prompt is designed to be a synchronous decision point within an identity verification pipeline. It should be invoked during account registration, profile updates (display name, bio, avatar), and after any reported impersonation event. The model is not a replacement for a deterministic rules engine but a classifier for ambiguous cases where brand names, public figure names, and parody accounts require nuanced judgment. Before invoking the model, assemble the [PROFILE_DATA] object from your user service, including user_id, display_name, username, bio, avatar_description, account_age_days, and verification_status. Assemble the [PROTECTED_ENTITY_LIST] from your trust and safety database, which should include verified brand names, public figure names, and previously flagged impersonation targets. Sanitize all user-supplied strings to remove prompt injection payloads—strip null bytes, escape curly braces, and truncate inputs to a reasonable length (e.g., 1000 characters per field) before inserting them into the prompt template.

After receiving the model response, validate the JSON against the output schema. The risk_score must be an integer between 0 and 100, confidence must be a float between 0.0 and 1.0, and evidence must be a non-empty array of strings. If validation fails, retry once with a repair prompt that includes the original input, the malformed output, and the schema validation error. If the retry also fails, log the failure and route to a human review queue. For successful classifications, implement a decision matrix: if risk_score > 80 and confidence > 0.9, trigger an automated action such as requiring identity verification or temporarily suspending the account. If risk_score > 50 and confidence < 0.7, route to a human review queue with the full evidence payload. For low-risk scores, allow the account action to proceed. Log every classification decision with the model_version, prompt_hash, input_profile_id, risk_score, confidence, action_taken, and timestamp for auditability.

Choose a model that supports structured output and has low latency for real-time account actions. GPT-4o and Claude 3.5 Sonnet are suitable defaults. Avoid using smaller, faster models that may misclassify nuanced impersonation cases. Implement a timeout of 5 seconds for the model call; if it exceeds this, fall back to a rules-based check and flag the account for asynchronous review. Do not cache impersonation classifications, as protected entity lists and user profiles change frequently. Monitor the distribution of risk scores and confidence levels in production to detect drift in model behavior or changes in adversarial patterns. If the rate of high-confidence, high-risk classifications spikes unexpectedly, investigate for coordinated impersonation campaigns rather than assuming a model failure.