Organisations should approve MCP servers with the same discipline used for third-party software. Review the source, the permissions requested, and the behaviors the server declares before allowing it into an agent configuration. Then monitor runtime activity to see what the server returns and how the agent acts afterward, because installation-time trust is not enough.
Why This Matters for Security Teams
mcp server are not just integrations. For coding agents, they become executable trust boundaries that can read repositories, reach APIs, and return content the agent may immediately act on. Approval decisions therefore need to treat the server as a third-party workload with real blast radius, not as a harmless productivity add-on. That distinction is central to current guidance from the OWASP Agentic AI Top 10 and NHIMG research on Analysis of Claude Code Security, which both show that the real risk is not just what a server can technically access, but how an agent may chain that access into unintended actions.
The most common failure is approving servers based on developer convenience or a short security questionnaire, then assuming prompt constraints will contain the agent. In practice, MCP tool access can amplify a small permission mistake into repository modification, secret exposure, or external system calls. NHIMG’s The State of MCP Server Security 2025 notes that only 18% of MCP server deployments implement any form of access scoping for tool permissions, which helps explain why approval should start with least privilege and not end there. In practice, many security teams encounter misuse only after an agent has already chained tools in ways the original review never anticipated.
How It Works in Practice
Organisations usually approve MCP servers by combining source review, permission review, and runtime validation. Source review answers who built the server, whether it is maintained, and whether the implementation shows safe handling of secrets and inputs. Permission review asks what the server can do, which tools it exposes, and whether those tools are narrowly scoped to the coding task. Runtime validation then checks whether the server behaves consistently with its declared purpose once an agent begins using it. That sequence aligns with the emerging control logic in NIST AI Risk Management Framework and CSA MAESTRO agentic AI threat modeling framework.
A practical approval checklist often includes:
- Confirm the server’s maintainer, update cadence, and repository integrity.
- Review declared tools for write, delete, exfiltration, or credential-handling capability.
- Prefer short-lived credentials and task-scoped access over long-lived tokens.
- Separate read-only coding support from any tool that can modify production data.
- Test the server with benign and adversarial prompts before broader rollout.
- Log tool calls, returned data, and downstream agent actions for auditability.
For coding agents, this is especially important because an MCP server can return code, diffs, file contents, or API responses that the agent treats as authoritative input. NHIMG’s Amazon Q AI Coding Agent Compromised illustrates why security teams cannot stop at installation-time trust when downstream behaviour is still dynamic. These controls tend to break down in fast-moving developer environments where teams approve servers locally, bypass central review, and connect the same agent to multiple repositories without re-evaluating scope.
Common Variations and Edge Cases
Tighter MCP approval often increases friction for developers, so organisations must balance speed against containment. That tradeoff is real, especially when teams want flexible agent workflows but security needs predictable blast radius. Current guidance suggests there is no universal standard for every MCP server type yet, so approval depth should vary by the server’s privileges, data sensitivity, and whether it can write to production systems.
Read-only servers that only search documentation are lower risk than servers that can open pull requests, manage cloud resources, or access secrets managers. Likewise, a server that is safe in a sandbox may not be safe when pointed at live codebases or authenticated SaaS tools. This is why security review should be repeated whenever the agent’s task changes materially. NHIMG research such as CoPhish OAuth Token Theft via Copilot Studio and Replit AI Tool Database Deletion shows how quickly agent tooling can move from helpful to harmful when permissions are broader than the task requires.
Security leaders should treat MCP approvals as living decisions, not one-time sign-offs, and re-test them after server updates, scope changes, or new tool additions.
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, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | MCP approval hinges on limiting unsafe tool use by autonomous agents. |
| CSA MAESTRO | TRUST-02 | MAESTRO covers trust and control boundaries for agent toolchains. |
| NIST AI RMF | GOVERN | Approval decisions need governance, accountability, and documented oversight. |
| OWASP Non-Human Identity Top 10 | NHI-03 | MCP servers often expose or mishandle secrets during agent operations. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access control is the core control for approving MCP servers. |
Assign an owner, define approval criteria, and track MCP server risk through governance reviews.
Related resources from NHI Mgmt Group
- How do organisations decide whether AI governance is strong enough for autonomous agents?
- How do organisations decide whether MCP should use OAuth, mTLS, or federation?
- How can organisations decide whether to start with MCP, A2A, or both?
- How should organisations decide whether to allow MCP in sensitive systems?
