This is an attack surface that rumbles around in my head enough that I have started to pull back on how much I ask Claude to do for me.
I have been thinking about two aspects of this issue. Authentication answers whether this is really my Gmail, my GitHub, my browser fetch. Content trust is about what is in the payload. Was the email body, the readme, the webpage written to manipulate an agent reading it. And there is a harder version. Will I be the one who makes the mistake and hands it over. Both concepts are understood. Authentication is the more mature of the two.
The reason it matters is that prompt injection does not care about your auth. An attacker does not need to spoof your Gmail to get instructions in front of your agent. They only need to write something your agent will be asked to read. A README on a public repo. A comment on a Reddit thread. A line of hidden text on a webpage. You may trust the channel. What is certifying the payload riding on it is a separate question, and most stacks do not have an answer.
The structural fix is to treat trust as a separate label on every piece of content the agent ingests. Where did this come from. User typed, agent generated, or external source. Trust only degrades, never upgrades. A summary of an untrusted document is still untrusted. A tool call influenced by untrusted content needs human confirmation.
None of that is in the default LLM API. It has to live in the layer you build around it.
If your team is integrating agents into daily workflows, where does content trust live in your stack? In a column on the data, in the prompt, somewhere else? I have not seen a default answer yet.
Written by Duane Grey
AI Strategy & Implementation
Independent AI consultant helping companies cut through hype and deploy systems that produce real results.