Treat each MCP server as a governed NHI boundary. Teams should define scope, ownership, expiry, and revocation for every non-human identity used by the protocol, then restrict tool registration to approved servers and validate every call server-side before execution.
What should govern NHI access at the MCP server boundary?
MCP changes the control point, not the security obligation. If internal tools are exposed through MCP, the server becomes the place where non-human access must be named, bounded, and revocable. The practical question is not whether an agent can reach a tool, but whether each server, credential, and tool action has a clear owner, approved purpose, and server-side enforcement.
That boundary matters because MCP often concentrates many downstream capabilities behind one protocol surface. If access policy lives only in the client, prompt, or agent workflow, teams lose the ability to prove which non-human identity was allowed to do what, for how long, and under which approval. Govern the server as a security boundary, not just as an integration endpoint.
In practice, that means treating every MCP-facing integration as a distinct access relationship with its own scope and expiry. Ultimate Guide to NHIs is useful here because the underlying governance pattern is the same one that applies to other non-human access paths: define ownership, inventory the identity, and keep the access model narrow enough to review.
How should scope, ownership, and revocation work for MCP-connected tools?
Scope should be tool-specific, not server-wide by default. If one MCP server exposes multiple tools, each tool still needs an explicit access purpose and a bounded permission set. A broad registration model is a common failure mode because it makes every connected tool look equally trusted, even when only one operation was intended for a given workflow.
Ownership should follow the server and the exposed capability, not the model or the user who triggered the request. Security teams need a named business or technical owner who can answer three questions quickly: who approved the access, what is the expected use, and when must it be removed. That ownership model is the difference between governed automation and orphaned access.
Revocation must be operational, not theoretical. For MCP, that means the team can disable a server, revoke its credential, or remove a tool from registration without waiting for application changes downstream. A server-side control plane is therefore more important than relying on downstream tool behavior, because revocation only matters if it can be enforced where execution actually happens.
Service Account Security Guide supports the same governance principle for machine access, and the lesson transfers directly to MCP: the identity must be discoverable, scoped, and administratively removable before it becomes a standing path into internal tools.
NHI Ownership and Accountability Guide reinforces the operational point that access cannot be governed well if no one is accountable for the identity’s creation, use, and offboarding.
What server-side controls matter most before a tool can execute?
Security teams should prefer server-side validation over trust in the client, agent, or prompt layer. Every call should be checked against the approved server registration, the allowed tool list, the expected identity, and the current policy before the action is executed. If the server cannot explain why the request is allowed, it should not perform the action.
That control pattern aligns well with MCP authorization guidance because the server is the enforcement point that can bind tokens, validate audience, and reject overbroad delegation. Model Context Protocol: Authorization specification is the clearest external reference for that design, especially where HTTP transports and audience-bound access tokens are involved.
For teams exposing internal tools, the practical requirement is to separate registration approval from runtime approval. A server may be approved, but a tool call still needs its own policy decision. That distinction prevents a single approved integration from becoming a blanket pass to everything the server can reach.
Risk and Threat Considerations
MCP can widen the blast radius of non-human access if teams treat protocol exposure as a convenience layer instead of a governed boundary. The main risk is that one overbroad server registration, long-lived credential, or weak server-side check can turn a narrow internal tool into a reusable access path across systems.
Failure mechanism: A compromised agent, token, or server registration can be reused to invoke internal tools that were never meant to be broadly callable, especially if approvals live in the client or if the server does not revalidate each request.
Impact: That creates excessive privilege, poor auditability, and faster lateral movement from one exposed tool to many related systems. The safer pattern is to assume the server boundary can be attacked and to make every request prove its current entitlement before execution.
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 Agentic AI 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 |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | MCP server identities must be revocable when access ends. |
| NHI-05 — Overprivileged NHI | Exposed tools need narrow scopes to avoid excessive server authority. | |
| NHI-07 — Long-Lived Secrets | Persistent MCP credentials raise exposure and revocation risk. | |
| Recommendation — Define offboarding triggers and revoke MCP-linked NHI access promptly. Limit each MCP server and tool to the minimum required permissions. Replace long-lived MCP secrets with short-lived, tightly governed credentials. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | MCP exposes delegated tool use and privilege boundaries for agents. |
| ASI02 — Tool Misuse | Registered tools can be abused if scope and approval are too broad. | |
| Recommendation — Enforce server-side authorization before any agent tool action executes. Register only approved tools and validate each call against policy. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | MCP servers and tool callers are machine-to-machine identities. |
| AC-3 — Access Enforcement | MCP requires runtime enforcement of who may invoke which tool. | |
| IA-5 — Authenticator Management | MCP depends on governing credentials, expiry, and revocation. | |
| Recommendation — Authenticate MCP servers and callers before allowing tool invocation. Enforce tool-level authorization at the server before execution. Manage MCP authenticators with expiry, rotation, and revocation controls. | ||
Practitioner Guidance
What to prioritise: Start by inventorying every MCP server as a separate access boundary, then map each exposed tool to an owner, a purpose, and a revocation path. If the team cannot remove access quickly, the identity is already too persistent for safe operational use.
What to verify: Confirm that runtime checks happen on the server side, not only in the agent workflow. The control should reject calls that are outside the approved server, outside the registered tool set, or outside the current policy window.
What good looks like: Approved servers are few, their tools are explicit, their credentials expire, and every execution can be traced back to a named non-human identity with a current authorization decision.
Practitioner takeaway: Treat MCP as an access governance problem first and an AI integration problem second, because the security outcome depends on how tightly you bound and revoke the server-side authority.
Related resources from NHI Mgmt Group
- How should security teams govern non-human identities that have persistent access?
- How should security teams govern API keys used for generative AI access?
- How should security teams govern AI agents that access APIs through GraphQL and MCP?
- How should security teams govern access requests through IT service management tools?