Treat MCP servers as privileged trust boundaries, not simple data sources. Security teams should classify each server by the authority it can influence, sanitize any user-generated or third-party content before delivery, and limit the agent’s tool access so malicious context cannot easily become destructive action.
Why This Matters for Security Teams
MCP servers are not neutral plumbing. When an AI coding assistant can read from a server, the server can also shape the agent’s decisions, suggested code, and downstream actions. That makes MCP a trust boundary with real privilege implications, especially when the server is fed by user prompts, tickets, repositories, or third-party content. Current guidance suggests treating this as an agentic risk problem, not just an integration problem, consistent with the OWASP Agentic AI Top 10 and NIST’s broader risk framing in NIST Cybersecurity Framework 2.0.
Security teams also need to account for the reality that MCP content can be weaponised through prompt injection, poisoned context, or unsafe tool chaining. NHIMG has documented how agentic systems fail when authority and context are blended without guardrails in OWASP Agentic Applications Top 10 and in the Analysis of Claude Code Security. In practice, many security teams encounter MCP abuse only after an assistant has already suggested or triggered an unsafe change, rather than through intentional review.
How It Works in Practice
Governance starts by classifying each MCP server by the authority it can influence, not by the data it returns. A documentation server, a build server, and a production change server should not share the same trust tier or tool permissions. The more an MCP server can affect secrets, code execution, deployment, or identity workflows, the more it should be handled like a privileged workload. That aligns with NHIMG guidance on NHI lifecycle and auditability in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the Ultimate Guide to NHIs — Regulatory and Audit Perspectives.
At implementation level, security teams should reduce standing permissions and prefer short-lived, task-bound access. For agentic workloads, static RBAC alone is usually too coarse because the agent’s behaviour changes with the task, the prompt, and the tool chain. Better practice is emerging around intent-based authorisation, policy-as-code, and just-in-time credential issuance for the exact action being attempted. That means the assistant gets only the credentials, scopes, and tool permissions needed for the current step, then loses them when the task ends. This is also where workload identity matters: the server and the agent should prove who they are cryptographically, rather than relying on network location or a shared token. In environments with sensitive code or regulated data, teams should pair this with content sanitisation, allowlisted tools, and logging that captures both the MCP request and the resulting tool action. For implementation patterns, OWASP Top 10 for Agentic Applications 2026 remains a useful reference point, especially when read alongside NIST Cybersecurity Framework 2.0.
- Classify each MCP server by the authority it can influence, not just the data it exposes.
- Use JIT, ephemeral credentials with tight TTLs for agent tasks.
- Scope tool access per action and per context, not per broad user role alone.
- Sanitise untrusted content before it reaches the model or tool router.
- Log prompt, tool call, and outcome for audit and incident response.
These controls tend to break down when one MCP server serves both low-risk documentation and high-risk operational actions because the permissions model becomes too blunt to contain privilege escalation.
Common Variations and Edge Cases
Tighter MCP governance often increases developer friction and operational overhead, so organisations have to balance safety against speed. Best practice is evolving here, and there is no universal standard for whether every MCP server needs the same level of isolation, approval, or review. The right answer depends on whether the server can only retrieve reference material or can also trigger code generation, secret access, or deployment actions.
One common edge case is a server that looks read-only but influences a downstream agent that has write privileges. Another is a shared MCP service used across teams, where one workflow needs high trust and another should remain heavily restricted. In those cases, policy should be evaluated at runtime, not frozen at onboarding. That is where NIST’s AI risk framing and the Top 10 NHI Issues are useful together: they both highlight how authority, lifecycle, and audit controls must follow the actual workload behaviour. For regulated environments, teams should also look at the Analysis of Claude Code Security to understand how coding assistants inherit risk from their tool chains.
Where teams get into trouble is assuming that “trusted internal server” means safe. With agentic systems, a trusted server can still become a malicious context source if its inputs are compromised or its outputs are not constrained. That is why MCP governance should be reviewed alongside agent permissions, secret handling, and change controls, not in isolation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Agent tool abuse and prompt injection map directly to MCP server governance. |
| CSA MAESTRO | MAESTRO-3 | MAESTRO addresses agentic runtime controls and trust boundaries for tool use. |
| NIST AI RMF | AI RMF supports governing autonomous behaviour, accountability, and risk treatment. |
Assign ownership, assess agentic risk, and enforce runtime policy checks for MCP actions.
