Amey-Thakur MCP security boundaries
An MCP server extends what a model can reach, which extends what an attacker reaching the model can do. The two failures that matter are prompt injection through returned content and an agent taking a destructive action nobody sanctioned.
Method
- Treat every tool result as data, never instructions. Content from a web page, a document, or a ticket may contain text aimed at the model, and the agent must not act on it (see llm-guardrails).
- Gate destructive actions on human confirmation. Deletion, sending, payment, and permission changes stop for approval however confident the agent is (see agent-human-checkpoint).
- Scope the server's own access narrowly. A server that can read one project should not hold a credential covering the organisation, since the agent will eventually try (see authz-design).
- Validate parameters server-side, always. Model-generated arguments are untrusted input and can contain traversal, injection, and out-of-range values (see input-validation).
- Bound resource use per call and per session. Unbounded queries and loops turn an agent into an accidental denial of service against your own systems (see rate-limiting).
- Keep secrets out of tool descriptions and results. Both enter the model's context and may appear in output or logs (see secrets-management).
- Log with enough detail to reconstruct. Who, which tool, what parameters, what result, because incidents involving agents are otherwise impossible to explain.
Boundaries
Boundaries reduce reach; they cannot make an autonomous agent safe to point at anything. A server is only as safe as the systems it can touch, so least privilege is the primary control. Injection defence is partial by nature, which is why confirmation on consequential actions remains necessary.