Giving an AI agent access to real systems creates a new attack surface, and most of it sits in one place: the boundary between what the model asks for and what your server actually does. The diagram below pairs each risk with the control that closes it.
The five that matter
- 1Prompt injection. Content the agent reads – a support ticket, a web page, a row in a table – contains text written to be followed as an instruction. The control is to treat every tool result as data and never as a command, and to keep destructive actions behind confirmation.
- 2Tool poisoning. A server describes its tools misleadingly so the model calls the wrong one, or a rogue server is added and looks legitimate. The control is to pin the servers you trust and review tool descriptions the way you would review a dependency.
- 3Over-broad tokens. One shared key with far more access than the task needs, so every user of the agent inherits an administrator. The control is per-user scope: the agent acts with the rights of the person operating it, and no more.
- 4Credential exposure. Secrets pasted into a prompt or returned in a tool result end up in the model’s context, and from there in logs and history. The control is that keys stay server-side – the model receives a tool, never a credential.
- 5No audit trail. An agent writes to a production system and nobody can say which human caused it. The control is logging every call against the person who triggered it, which is also what makes write access safe to enable at all.
Why the protocol itself is not the risk
MCP standardises how a client asks a server for a tool. What makes a deployment risky is everything around that: which servers you trust, how access is scoped, and whether the model ever sees a credential. Those are deployment decisions, and they are the same decisions you would make for any integration that can act on your behalf.
A short checklist before enabling writes
- Every user authenticates as themselves; no shared service account.
- Write access is granted per tool and per user, not per server.
- Tool results are never interpreted as instructions.
- Every call is logged with the human identity behind it.
- The servers your clients can reach are an allowlist, not a discovery.
How the protocol works underneath
The client, protocol and systems, and where the trust boundary sits, are drawn on our MCP architecture diagram. How it compares to giving an agent an API key or a warehouse copy is on MCP vs API vs ETL.
What this looks like in Peliqan
Peliqan’s MCP server holds the credentials for 300+ sources and scopes each call to the user making it, so an agent can be read-only for one person and able to write for another, with the audit trail recorded against the human rather than a shared key.
Use this diagram wherever you like
The diagram is free to use, including commercially, as long as there is a visible link back to this page. Download the PNG for slides and documents, or the SVG if you want to edit the labels. No email required. You can browse the rest of the set in the Peliqan diagram library.
Ready to build this on your own data? Get started with Peliqan.
