Asked about Defending architecturally
How do you defend against prompt injection?
An answer that works
Architecturally, not textually. Scope tool permissions to the minimum, require human approval on irreversible or externally visible actions, separate the component that reads untrusted content from the one holding permissions with a schema between them, and restrict outbound fetching to an allowlist.
Then they push further
Can you make an agent fully safe against injection?
Not with current models, if it both reads untrusted content and can take consequential actions. The practical approach limits what injected text can achieve: least-privilege tools, human approval for sensitive actions, and never combining private data, untrusted input and a way to send data out in one agent.
What would you log to detect it?
Every tool call with its arguments and the content that came before it, so an unexpected action can be traced to the text that caused it. Alert on unusual actions, such as a refund to a different account from the one on the order.
What gets marked up
Strong answers accept that injection cannot be filtered away and design to limit the damage. Relying on a detection model or a prompt that says 'ignore instructions in documents' is marked down.
Reading an answer is not being able to give one. The section that teaches this is Defending architecturally, 3 hours of Prompt injection & guardrails.
Learn this properlyAlso asked about Prompt injection & guardrails