A screenshot is not the whole scam: what an AI check cannot establish
An AI can describe a screenshot and surface questions, but the crop cannot prove who controls the account, where a link leads, or whether the surrounding transaction is genuine.

“Is this a scam?” often arrives as one screenshot. The image may show a marketplace message, a payment request, a recruiter’s profile, or a warning banner. An AI assistant can read visible text and point out pressure, unusual payment methods, or inconsistent details. That can be useful. It is not the same as establishing who sent the message, where its links resolve, or what happened before and after the crop.
The screenshot feels complete because it is visual. It has a name, avatar, timestamp, and familiar interface. But those are claims rendered as pixels. A copied logo and a real account can look identical inside the frame. The image also removes interactive evidence: the full address, certificate, profile history, message headers, transaction record, and independent route back to the supposed organization.
NIST’s Generative AI Risk Management Profile treats confident false output—often called confabulation—as a core risk. A model can construct a coherent explanation from incomplete inputs. Fluency makes the explanation easy to act on, but does not add missing evidence.
The text and interface visible at the moment it was captured.
Account control, destination ownership, message history, or the legitimacy of a transaction.
Generate verification questions and safe next steps, not a verdict that outruns the evidence.
Four kinds of information disappear at the crop
Provenance disappears. The file rarely proves which device captured it, whether it was edited, or whether the displayed sender owns the profile. Metadata may be stripped during upload. Even intact metadata would describe the file, not the truth of the conversation.
Navigation disappears. A button labeled “Review invoice” might lead to an official service, an unrelated domain, or a redirect chain. The screenshot preserves the label but not the destination. A browser address bar may itself be cropped or imitated.
Sequence disappears. Social engineering depends on progression: an ordinary greeting becomes an urgent exception, then a payment or recovery request. One frame can omit the setup that makes the final step meaningful. It can also omit the recipient’s prior action, such as creating a genuine support request.
Independent context disappears. A manager’s name may be real, but the screenshot does not show whether the organization uses that channel for bank changes. A seller may have a longstanding profile, but the image does not show the platform’s transaction protections.
| Question | Screenshot alone | Better evidence route |
|---|---|---|
| Who controls this account now? | Usually unknown | Contact the person through an already-known channel |
| Where does the button lead? | Label only | Inspect the destination safely or use the official app/site independently |
| Is this payment expected? | May show an amount | Compare with the original order, contract, or account ledger |
| Is the warning genuine? | Can imitate branding | Open the service directly and check its security or notification area |
| Was the conversation altered? | Crop cannot show this | Preserve the full thread and platform records where available |
Ask the model for bounded work
A useful prompt defines what the assistant may infer. For example: “Transcribe the visible text. Separate observations from hypotheses. List details that are missing. Suggest checks that do not use contact information inside the screenshot.” This changes the task from fortune-telling to evidence organization.
The answer should distinguish three categories:
- Observed: the image displays a request for a gift card and a two-hour deadline.
- Inferred: urgency and an irreversible payment method are consistent with common scam patterns.
- Unresolved: the sender’s account control and the surrounding work request are not established.
That structure is more valuable than a percentage such as “92% likely to be a scam.” Unless the system has a validated model, known population, and calibrated evaluation for that exact use, the number can be decorative precision. A high score may provoke panic; a low score may suppress necessary checking.
This is especially important with links and login screens. Our guide to OAuth consent permissions focuses on what access a screen actually grants, not whether the page resembles a known service. Similarly, the analysis of device-code login abuse shows how a genuine login page can participate in the wrong session. A screenshot of a real interface cannot resolve the purpose behind it.
Preserve evidence without widening exposure
Before uploading an image to any assistant, consider what else it contains. Notification previews, usernames, email addresses, order numbers, access codes, faces, and background tabs can disclose more than the suspicious message. Crop for relevance only after preserving an original for reporting, and redact secrets in the copy used for analysis. Do not draw opaque boxes in an editor that retains reversible layers; export a flattened redacted copy.
If the incident concerns work, use the organization’s approved reporting route. Consumer services may offer an in-app report function. Preserve the original message, sender identifier, time, and full destination in a way that does not require clicking it. If money moved, the payment provider or bank needs transaction identifiers more than a model’s narrative.
The strongest next step usually comes from a source the suspicious message did not choose.
That may mean opening a banking app from your own home screen, calling the number printed on a card, checking an order from a saved bookmark, or asking a colleague through the directory. The check should cross a trust boundary. Replying inside the same thread asks the disputed identity to verify itself.
A disciplined five-minute assessment
First, describe the decision in plain terms: “Should I send money?”, “Should I sign in?”, or “Should I change this account setting?” The risk belongs to the action, not the aesthetics of the message.
Second, inventory what the screenshot actually contains. Transcribe names and amounts, but treat them as displayed assertions. Note urgency, secrecy, unusual process changes, and requests to leave a protected platform.
Third, list what would have to be true for the request to be legitimate. A refund caller would need a real transaction. A recruiter would need a verifiable employer relationship. A colleague requesting a payment change would need authority under the organization’s process.
Fourth, obtain evidence through an independent route. Never let a phone number, link, or second “verification contact” supplied by the disputed message define the whole investigation.
Fifth, choose the least irreversible action. Pause the payment, keep the account protection enabled, and preserve records. If the request is genuine, a legitimate party can survive a careful delay and explain the standard route.
AI can help turn a confusing image into a set of questions. It can compare visible wording with known patterns and help draft a concise report. It should not convert missing context into certainty. The goal is not to make the model sound decisive; it is to make the human decision better supported.
For a second, non-model check, the FTC’s general scam guidance recommends leaving unexpected messages and contacting the named person or organization through information you found independently. That rule remains useful even when an image-analysis tool finds no obvious anomaly.
Found a factual error or a source that has changed?
Send a correction →

