Both, but not equally. MCP servers behave like mutable non-human identities because they authenticate, hold scope, and act on behalf of workflows, so NHI governance is essential. At the same time, their execution paths need application-style testing for injection, SSRF, and path traversal. Use both lenses where the server is part of delegated automation.
Why MCP Server Governance Needs Two Lenses
mcp server sit in a hybrid category: they are software services, but they also hold scope, authenticate, and act with delegated authority on behalf of workflows. That makes pure application testing incomplete. If you only test code paths, you can miss governance failures such as excessive scope, weak ownership, token handling problems, or unclear offboarding when the server is no longer trusted.
The identity side matters because an MCP server is not just a passive endpoint. It can represent a durable access relationship that should be discovered, owned, reviewed, and revoked like other machine-facing access paths. The application side matters because the server’s tool surface still has to withstand injection, request manipulation, SSRF, and path traversal. Treating it as one or the other alone leaves a gap in how teams assess control coverage.
For teams building out the identity view, the most useful baseline is to compare MCP servers with other machine-facing access paths, not with a generic application widget. NHIMG’s MCP Security Guide and IAM and IGA Basics both help frame why delegated access, entitlement review, and lifecycle control belong in the conversation alongside engineering testing.
What “NHI Governance” Means in the MCP Context
An MCP server can behave like a mutable non-human identity because it is authenticated, scoped, and capable of acting independently once trust is established. The governance questions are therefore familiar: who owns it, what does it touch, how is its scope limited, how are credentials issued and rotated, and what happens when the integration is retired or replaced?
That is also why lifecycle control is not optional. If the server can access production tools or sensitive data, the operational risk is similar to other non-human access paths: stale trust, long-lived credentials, forgotten ownership, and access that outlives the original use case. The right governance model should assume the server can become a standing privilege point unless it is deliberately bounded.
Teams often underweight the ownership problem. A server that sits between an agent and multiple tools can look “owned” by engineering, platform, and product at the same time, which means it can end up owned by nobody. NHIMG’s NHI Ownership and Accountability Guide and Guide to NHI Rotation Challenges are useful reference points for the accountability and credential-lifecycle side of the problem.
At scale, governance also has to account for reuse and sprawl. If multiple MCP servers share the same back-end identity, token pattern, or service principal, the blast radius expands quickly. That is why identity-style inventory, scope review, and rotation discipline are not nice-to-have additions, they are core controls.
Where Application Testing Still Has to Lead
Even when governance is strong, MCP servers still need application-style testing because the runtime attack surface is very real. The main risks are not abstract policy failures, they are concrete exploit paths: prompt or tool injection, server-side request forgery, path traversal, unsafe parsing, and authorization bugs in the server’s own logic.
Testing should therefore focus on the places where model-driven or workflow-driven inputs reach code, files, URLs, or downstream tools. A server can have clean ownership and sensible scoping and still be exploitable if an attacker can manipulate a tool call, coerce the server into fetching untrusted content, or traverse into data outside the intended boundary. The governance layer reduces exposure, but it does not replace security testing of the execution path.
That is why application security references still matter here. NHIMG’s MCP Security Guide is the most direct internal anchor for the protocol-specific controls, while the OWASP ASVS and OWASP Web Security Testing Guide provide the appsec verification lens for authentication, authorization, input handling, and server-side abuse cases.
For protocol-level authorization behaviour, the OAuth model also matters when MCP runs over HTTP transports. RFC 9728 and the MCP authorization specification are useful because they show how discovery and token handling should work when the server is being treated as a protected resource.
Risk and Threat Considerations
MCP servers are attractive targets because they concentrate delegated trust. If an attacker can steal a token, exploit the server, or manipulate a tool call, they may inherit access that was meant to be narrowly scoped and workflow-specific. The practical risk is not just compromise of one service, but lateral movement through the toolchain and data exposed behind that service.
Failure mechanism: Weak governance leaves standing credentials, overbroad scope, or unclear ownership in place, while weak application testing leaves injection, SSRF, path traversal, or request-manipulation flaws in the server path.
Impact: An attacker or malicious integration can turn a single MCP server into a durable pivot point, exposing downstream systems, sensitive data, or privileged actions that were never intended to be broadly reachable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack surface, OWASP ASVS and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | MCP servers act with delegated scope and can accumulate excess privilege. |
| NHI-07 — Long-Lived Secrets | MCP servers often rely on persistent tokens or keys that should not linger. | |
| NHI-01 — Improper Offboarding | MCP servers need retirement and revocation when workflows or trust end. | |
| Recommendation — Limit MCP server scope to the minimum required permissions and review grants regularly. Rotate MCP credentials aggressively and replace long-lived secrets with shorter-lived alternatives. Revoke and decommission MCP server access paths when the integration is no longer needed. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | MCP servers expose configurable execution and auth surfaces that are easy to misconfigure. |
| API7 — Server Side Request Forgery | MCP tool handlers can be abused to fetch attacker-controlled URLs or internal resources. | |
| Recommendation — Harden MCP server configuration and validate auth, routing, and transport settings before release. Test MCP tools for SSRF and block untrusted outbound request paths. | ||
| OWASP ASVS | V8 — Authorization | MCP servers need strong control over tool access and action boundaries. |
| Recommendation — Verify that every MCP tool enforces explicit authorization on each protected action. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | MCP servers depend on managed credentials, rotation, and secure secret handling. |
| AC-6 — Least Privilege | MCP servers should only hold the minimal privileges needed for delegated workflows. | |
| SA-11 — Developer Testing and Evaluation | MCP servers need application-style security testing for abuse paths and flaws. | |
| Recommendation — Apply IA-5 to manage, rotate, and protect MCP server authenticators and secrets. Constrain MCP server permissions to the minimum necessary for each workflow. Test MCP servers for injection, SSRF, and traversal before production deployment. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | MCP server access decisions require policy, scope, and enforcement discipline. |
| Recommendation — Define and enforce access rules for MCP servers and the resources they can reach. | ||
Practitioner Guidance
What to prioritise: Treat the MCP server first as a governed access relationship and second as a code surface. If the server can reach production systems or sensitive data, inventory it, assign a clear owner, define scope, and review its credentials before you debate implementation details.
What to verify: Confirm that the server has a bounded trust model, that credentials are not shared across unrelated use cases, and that revocation is operationally real. If you cannot quickly answer who owns it, what it can reach, and how to disable it, the governance posture is already weak.
Decision rule: If the issue is entitlement, ownership, rotation, or revocation, apply NHI-style governance. If the issue is code paths, parsing, redirects, file access, or downstream requests, apply application security testing. In most real deployments, you need both.
Practitioner takeaway: The mistake to avoid is forcing MCP into a single control model. The server’s identity and its execution path create different failure modes, and the control stack has to cover both if delegated automation is allowed to touch real systems.
Related resources from NHI Mgmt Group
- Should teams treat server-side application permissions as part of identity governance?
- Should teams treat MCP access to NHI data like privileged access?
- Should teams treat NHI, MCP, and agent governance as separate programmes?
- Should security teams treat MCP issues as application bugs or identity governance problems?