Draw the trust boundary before anything else
Write down every path by which text reaches your model's context: the user's message, retrieved documents, tool and API results, conversation history, files you parse, and tool descriptions supplied by third-party servers.
Everything on that list except your own system prompt is untrusted. Teams consistently miss tool results and retrieved documents, which is exactly why indirect prompt injection keeps working: the payload arrives through a channel nobody classified as input.
Severity comes from the permission model
Assume the model can be influenced. The useful question is what it can do once it is, and that is answered by reading credentials and scopes rather than by prompting the model.
A tool that reads public data is a content issue. A tool that sends mail, moves money, or reads another tenant's records is an incident, and the difference is entirely in what the credential behind it carries.
- Every tool, function and MCP server the agent can invoke, enumerated rather than assumed
- The scope each credential actually carries, compared to what the tool needs
- Which actions are irreversible or externally visible
- Whether human approval sits between the model's decision and the effect
- Whether tool calls are logged with arguments, outside the agent's own process
- Whether one user's or tenant's context can leak into another's
Output handling is an old bug in new clothing
Model output is untrusted input to whatever consumes it. Rendered as HTML it is a cross-site scripting path; passed to a shell, command injection; interpolated into a query, injection.
The reassuring part is that the fix is the one you already know. Escape on output, parameterize queries, never hand model output to an interpreter. The only novelty is that the untrusted string came from your own model.
What buyers will ask you
The questions are becoming standard, and they are answerable only if someone has looked: what can the agent access, who approves irreversible actions, is prompt injection tested, where does customer data go, and is any of it used for training.
Having tested answers shortens the sales cycle. CyberArc's AI and agent security service exists for this, and the supporting tools are public: agent-shield for prompt-injection detection and agent-permission-graph for mapping what agents and MCP servers can touch.
Where your customer data goes during the test
Testing an AI product means handling whatever that product handles. Client data is processed on local AI models by default, and cloud AI tools are used only with the client's written consent.
That is a relevant commitment for a company whose own customers are asking the same question, because the engagement should not create the exposure it was hired to find.