Most security reviews still treat agent integrations like ordinary application integrations. That is the wrong frame. An ordinary integration has a predictable caller, a predictable workflow, and a bounded set of actions. An agent integration can receive untrusted instructions, retrieve volatile context, decide which tool to call, and produce an output that looks legitimate enough for a human to approve.
The model context server is where that ambiguity becomes operational risk. It may expose Jira, GitHub, Slack, Salesforce, internal search, file systems, browsers, and deployment tools. If the authorization model is lazy, every prompt injection becomes a potential action-injection problem.
If your agent can read untrusted content and call privileged tools, your MCP layer is part of the perimeter.
The review model
Evaluate each MCP server against five questions:
- Identity: whose authority does the tool call use?
- Scope: which actions are exposed, and can they be narrowed?
- Context: what untrusted content can influence the call?
- Runtime: where does the server run, and what else can it reach?
- Audit: can you reconstruct why the agent took an action?
The enterprise example
A support agent reads customer tickets, searches internal docs, updates CRM records, and creates engineering bugs. On paper, that looks low risk. In practice, a malicious attachment can instruct the agent to retrieve sensitive internal context, summarize it into a public ticket, or create a bug with manipulated priority.
The issue is not the model alone. It is the combination of context, instruction, identity, tool, output, and egress.
What good looks like
Production MCP servers should have explicit owners, narrow tool definitions, per-agent scopes, human approval for high-impact actions, structured logs, and adversarial tests tied to real workflows. The answer is not to block MCP. The answer is to treat it like a security-critical boundary.