I've been building threat models for a few agent deployment patterns here, and a pattern keeps showing up in the community examples. The primary concern is almost always data leaks and PII exposure (confidentiality). While that's valid, I think we're letting it overshadow a more critical agent-specific risk: integrity.

An agent that retrieves and acts on data is a decision engine. If its inputs, logic, or tool outputs are tampered with, it will take wrong actions *confidently*. The business impact of a wrong action is often higher than a leaked piece of data.

Consider a customer service agent with RAG:
* **Confidentiality breach:** Customer's order history is exposed. Bad, repairable with notification and credit monitoring.
* **Integrity breach:** RAG context is poisoned, causing the agent to issue a fraudulent full refund or delete the account. Direct financial loss, broken process, loss of trust.

My STRIDE tables for agents are now heavily weighted toward Spoofing, Tampering, and Repudiation. The attack trees get dense around:
* Prompt injection that alters execution flow
* Tool response manipulation
* Corrupted vector DB entries leading to malicious instructions
* Unvalidated, privileged tool use (e.g., "delete user X")

Are we stuck in a traditional appsec mindset? In an agentic system, where is the balance for you? I'm starting to draft templates where the first question is "What actions can this agent take, and what's the worst *wrong* action it could be tricked into performing?"

Ray