The system should provide a trustworthy source indicator

What it is

An authenticated provenance indicator is generated by the receiving system from evidence the message author cannot self-assert. It communicates which account or organization sent through which verified channel. Its value comes from the evidence chain and consistent presentation, not from a shield, avatar, or the word “official” by itself.

Why it happens

Ordinary content is copyable, while a system-controlled interface region and account or cryptographic result are harder for one malicious message to forge. A signal remains discriminative when it appears only with evidence and its absence is legible. If third parties can draw the same badge, or most mail gets a green icon, meaning collapses. A compromised account also shows why authentic source does not imply legitimate request.

Studying it

Test the indicator across legitimate, lookalike-domain, display-name-spoofed, and compromised-genuine-account messages. Ask what participants think it proves and excludes, then measure calibrated judgment, recognition of absence, and independent review of high-risk actions. Adversarial testing should confirm that content cannot cover, imitate, or redirect attention from the trusted region. Visibility alone does not establish semantic understanding.

Where it stops holding

The indicator warrants only its evidence scope—such as domain control, account identity, or delivery through an authenticated application. It cannot guarantee harmless content, an uncompromised account, or an authorized transaction. Forwarding, screenshots, and printouts lose live verification and must visibly degrade. A new organization or individual without a badge is not automatically malicious.

Applying it

• Place the signal in a fixed receiver-controlled region that message content cannot draw, with an expandable explanation of evidence.
• Distinguish verified, unverified, verification-failed, and forwarded-copy states instead of leaving badge absence ambiguous.
• Require transaction-level confirmation for anomalous high-risk requests from verified accounts; do not expand source authentication into content endorsement.
• Red-team copied screenshots, similar icons, and interface overlays, and revoke trusted state for compromised accounts.

Related

• Same group: O3.04.1 Source-verification burden · O3.04.2 Weak source cues · O3.04.7 Contextual warning
• Adjacent: O3.06 Trusted path · O3.14 Trusted-path spoofing
• Search terms: authenticated provenance indicator · verified sender UI · trust signal semantics