Both, but the governing lens matters. The recurring failures in the article show that input validation and sandboxing are necessary, yet the compromise becomes material because identities and tokens are too broad, too reusable and too hard to offboard. Teams should therefore manage MCP access like privileged identity, not like ordinary app configuration.
How to classify MCP failures when the same issue looks like an app bug and an access problem
MCP issues should not be forced into a single bucket. The protocol can fail as application software, but the security outcome is often driven by how the server authenticates, scopes, and reuses access. That means teams need to separate local code defects from the broader question of whether an MCP deployment is granting tool access, tokens, or delegated authority too freely.
For agentic workflows, that distinction matters because a harmless-looking integration bug can become a material security event once the connected identity can reach production tools, data, or administrative APIs. Treat MCP as a boundary between application behaviour and governed access, not as a simple plugin configuration.
MCP security sits at the intersection of protocol correctness, OAuth-style authorization, and the permissions carried by the connected identity. If teams only test whether the server responds correctly, they can miss the more important question of whether the agent, user, or service behind the call is allowed to do what the tool makes possible.
An MCP implementation can be technically stable and still be unsafe if token forwarding, audience handling, or credential scope is loose. That is why identity-aware controls belong in the design discussion from the start, especially for MCP Security Guide patterns such as authorization, token passthrough, and gateway design. For deeper protocol context, the Model Context Protocol: Authorization specification shows why MCP servers should behave as OAuth resource servers rather than as open token relays.
Why the identity lens usually becomes the governing one
The practical reason security teams keep rediscovering MCP as an identity problem is simple: the failure mode is rarely “the app returned the wrong JSON,” it is “the connected identity could act with more authority than it should.” Broad, reusable, or long-lived credentials make that exposure persistent, and offboarding or revocation becomes the real control point. See also IAM and IGA Basics for the lifecycle and access-governance mechanics behind that distinction.
That lens also changes the control objective. Input validation, sandboxing, and request filtering reduce app-level risk, but they do not by themselves answer who can invoke the tool, under what conditions, and with what blast radius. When MCP is wired to production systems, identity governance becomes the deciding factor in whether a defect remains local or turns into a privilege event.
The same logic applies to access reviews and role design. If the MCP-connected identity can reach multiple tools, environments, or tenants, then the relevant control question is whether that access was intentionally granted, periodically reviewed, and limited to the smallest viable scope. The strongest operational lesson is to manage the connection like a privileged integration, not like ordinary application configuration.
That is also why lifecycle controls matter. A token that is never rotated, an integration that is never recertified, or a service credential that survives a project change creates a standing path into the agentic stack. The Ultimate Guide to NHIs, Lifecycle Processes for Managing NHIs is useful here because it frames provisioning, rotation, and offboarding as the control cycle that limits hidden access growth.
What security teams should do differently in practice
Security teams should evaluate MCP through two review tracks at once: application security for the server and authorization governance for the connected identity. If a control only reduces malformed input or prompt abuse, it is necessary but incomplete. If a control only reduces privilege, it is also incomplete unless the implementation is hardened enough that the access path itself cannot be trivially abused.
What to verify: confirm which identity is presenting the token, what audience it is bound to, which tool scopes are actually granted, and how fast those credentials can be revoked. If the answer is “shared,” “implicit,” or “hard to tell,” treat the deployment as higher risk than the code review suggests.
What good looks like is a short-lived, purpose-bound credential model with clear ownership, explicit revocation, and separate controls for development, staging, and production. The most common mistake is to let an AI toolchain inherit broad user or service privileges and then assume sandboxing alone will contain the impact.
Practitioners should also decide early whether MCP access belongs in the same governance process as service accounts, privileged APIs, and other non-human access paths. If the connection can execute actions that matter, then it needs the same review discipline as other privileged integrations, including recertification and exception handling.
Practitioner takeaway: The correct operating model is dual control, but the risk decision should usually be owned by identity and access governance because that is where scope, revocation, and blast radius are actually decided.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | MCP tool calls rely on service-to-service identity and token handling. |
| AC-6 — Least Privilege | MCP becomes risky when tools and tokens carry excess authority beyond task scope. | |
| IA-5 — Authenticator Management | MCP deployments depend on issuing, rotating, and revoking the credentials that enable access. | |
| Recommendation — Bind MCP servers and clients to service authentication and audience-scoped tokens. Restrict MCP-connected identities to the minimum tool and data permissions needed. Rotate and revoke MCP credentials on a short lifecycle and track their ownership. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | MCP authorization failures often start with weak token handling or identity proofing. |
| API5 — Broken Function Level Authorization | MCP tools can expose actions that need explicit authorization beyond basic login. | |
| Recommendation — Harden token validation and prevent credential forwarding across MCP boundaries. Authorize each MCP tool action separately instead of relying on coarse access. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | MCP identities can accumulate broad reusable access that exceeds the task need. |
| Recommendation — Trim MCP identities to task-scoped privileges and remove standing excess access. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org