The Trust-Signal Forgery Economy: Why "It Came From Inside the Channel" Stopped Meaning Anything
Written by the Rafter Team
A line that has shown up in every social-engineering incident postmortem Rafter has covered this quarter: the attacker's payload was delivered through a channel the user had been trained to trust. The Robinhood phishing emails went out from authenticated Robinhood-controlled infrastructure. The PyTorch Lightning impersonation packages were published under maintainer accounts users had been clicking "install" on for years. The Canvas breach used in-platform messaging — the same channel the platform tells users is safe. The MCP impersonation incidents put attacker code under names users had been told to trust by name.
The pattern is not phishing in the classical sense. Classical phishing required the attacker to spoof a channel — typo-squat a domain, forge a sender, fake a website. The current pattern is the inverse. The channel is real. The trust signals are real. The content delivered through the channel is the attack.
User training that emphasizes "look for the right channel" is now actively misleading. Every workflow that depends on the user evaluating channel-authentication signals as a proxy for content trust has a hole the size of the channel itself. Threat-model the content, not the channel.
The shape
A trust signal is a property the user observes that the platform has trained them to interpret as "safe." Examples:
- A blue verified badge.
- A sender address on a domain the user has known for years.
- A package published under a maintainer's official namespace.
- An in-platform message inside a session the user already authenticated.
- A code repository inside an organization the user is a member of.
- An IDE extension the IDE itself recommended.
Classical attackers tried to fake these signals from outside. Modern attackers do not bother. They acquire the ability to use the real signal — by compromising a maintainer credential, by reaching the platform's authenticated send channel, by getting a member-of role inside an organization, by getting a recommendation slot inside an editor — and then send their payload through the real channel.
The user's trust evaluation looks at the channel, sees the signal, evaluates correctly that the channel is genuine, and proceeds to act on the content as if the content were also genuine. The error is in the inferential leap from channel authenticity to content authenticity. The platforms taught the leap. The attackers learned it.
Five incidents, one shape
The Robinhood trusted-channel phishing was the cleanest case. Email sent from a sender path that DMARC and DKIM both verified as Robinhood-controlled. The content asked the recipient to act on instructions that Robinhood would not actually send. The defender posture that worked — "don't act on email instructions, log in directly to verify" — was the defense, but the attack succeeded by routing around users who skipped that step. The channel did not lie. The content did.
The PyTorch Lightning Claude Code impersonation compromised maintainer accounts and published payloads under publisher names users had pre-trusted. The package signature was valid. The maintainer name on the publish record was the real one. The user's npm install or pip install ran the payload under the same trust they would extend any package from that publisher.
The Canvas / Instructure breach used the platform's own internal messaging. The student sees a message from "Canvas" because it is, literally, from Canvas — sent through the platform's internal channel, on a session the student is already authenticated to. The content is not what Canvas would have sent. The channel-authentication is intact.
The MCP impersonation and sandworm-mode worm cases use the same shape applied to AI tool surfaces: agents trust an MCP server because the server name matches what the README told the user to install, the server is reachable, the protocol handshake completes. The trust is in the surface. The content delivered over the surface is the attack.
The Hermes-px stolen-prompt incident is the inverse case where the attacker exfiltrated trust-relevant content rather than delivering an attack through trust — but the same property is in play. The trusted channel was treated as a safe transport for sensitive content, because the channel was authenticated. The content's confidentiality did not survive the channel's compromise.
Why this is structurally hard
Two reasons.
The first is that the user's mental model of trust is built around channel authentication, because for thirty years that is what the security industry told users to look for. "Check the URL bar." "Look for the lock icon." "Verify the sender." Every one of those is a channel-authentication check. None of them speaks to content trust.
The second is that the platforms make channel signals visible by design and content signals hard to evaluate. The platform shows you "Verified" because it can; it cannot show you "this verified party is asking you for something they would not normally ask, you should be suspicious," because that requires modeling content semantics across every send.
The result is an asymmetry. Channel signals are cheap to display and easy to read. Content evaluation is expensive to display and hard to read. The user defaults to the cheap signal. The attacker exploits the gap.
What defenders can actually do
The defenses are coarse but real.
Don't ship workflows that depend on user trust evaluation alone for high-stakes decisions. Every action whose blast radius is large enough to matter needs an out-of-band verification step that does not depend on the channel that initiated the action. The customer support call-back pattern is the prototype. The user calls the published support line, not the number in the email. The transaction confirmation pattern is similar — the user confirms in a UI the inbound message cannot reach.
Make content provenance as visible as channel authenticity. This is the harder ask. Platforms need to surface, at the message level, "this came from inside the channel, but the channel does not vouch for the content." Most platforms surface the channel-vouch and elide the content-disclaim. The first platform to make this difference visible at scale will win a real safety advantage.
Audit your own outgoing trust signals. Every channel your product makes available — verified sender, official publisher, recommended extension — is a surface an attacker can compromise to send through. Treat them as authenticated input surfaces, not as proof of content safety. The GitHub issue as attack surface and postinstall hooks as a bug class posts cover the technical end of this discipline.
Watch the maintainer-credential economy. The single largest production input to this attack class is compromised maintainer credentials. Every credential takeover that leads to a malicious publish enables a trust-signal forgery. Hardware 2FA on every publishing credential is the highest-leverage single intervention available. It is also the one most maintainers have not enabled.
The Rafter angle
Rafter's contribution to this class is in the code-side audit: are your code paths assuming that "the request came from inside our network" or "the package came from our official publisher" is a sufficient authorization signal? rafter run flags conditional checks that gate sensitive operations on channel-origin properties without re-verifying content-level claims. --mode plus traces the data flow to see whether channel-origin trust crosses a boundary it shouldn't.
The economic and product-design problems above are not in the scope of any scanner. The code-level problems are. Both have to move for the trust-signal forgery economy to stop being the most reliable attack vector of 2026.