MCP Security: What Enterprise Architects Need to Consider
A practical guide to Model Context Protocol security for enterprise architects, including tool risk, permission boundaries, prompt injection, and governance controls.
Model Context Protocol (MCP) is becoming one of the most important integration patterns in enterprise AI. It offers a clean way for models and agents to interact with tools, data sources, and external systems. But from a security perspective, MCP is not just a convenience layer. It is an expansion of the attack surface.
For enterprise architects, the key question is not simply whether MCP works. It is whether it can be introduced without creating a permission model, execution model, and audit posture that are weaker than the standards already expected elsewhere in the organisation.
Why MCP changes the security conversation
Traditional enterprise systems tend to have relatively explicit boundaries. Human users authenticate, applications call known APIs, and service accounts are scoped deliberately. MCP-connected AI agents introduce a different pattern: a language model can decide when to invoke a tool, how to structure the invocation, and what data to pass into it.
That means architects need to think about:
- prompt injection that manipulates tool use
- overly broad permissions in MCP servers
- insufficient parameter validation
- data exfiltration through connected tools
- weak logging and poor operator visibility
Core design principles
1. Bound every tool. Tools exposed over MCP should have explicit scope, strict input validation, and minimum necessary permissions. Avoid “god mode” connectors.
2. Treat prompts as untrusted input. If a model can be influenced by user content, documentation, websites, or retrieved material, then tool-invocation decisions can be manipulated too.
3. Preserve human control. High-impact actions should require approval, especially where an MCP-connected tool could change infrastructure, write data, or trigger downstream workflows.
4. Instrument everything. Tool calls, parameters, failure modes, and decision paths should be visible in logs and usable in incident review.
What enterprise teams should do now
Start with architecture review and threat modelling before rolling MCP broadly into production environments. Review each proposed tool integration, define the approval model, and check whether the audit trail would stand up in a regulated environment.
If you are evaluating MCP in conjunction with Claude, AWS Bedrock, or broader agentic AI adoption, this is exactly the point where an AI Agent Security assessment becomes useful. The goal is not to block progress. It is to make sure new capability is introduced with the same discipline you would expect from any other production control plane.