Accountability sits with the organisation operating the MCP environment. Teams need clear ownership for token storage, token rotation, consent handling, and scope design across every server connection. If a client uses tens of tokens across multiple servers, governance should define who approves access, who monitors drift, and who can revoke credentials when risk changes.
Why This Matters for Security Teams
Least-privilege is harder to prove once one MCP client can reach multiple servers, because the access decision is no longer tied to a single app, a single API, or a single owner. The risk is not just overbroad permissions, but unclear accountability for who approves scopes, who stores secrets, and who revokes access when a server changes behaviour. Current guidance from the OWASP Non-Human Identity Top 10 is that NHI governance must be explicit at the token and workload level, not assumed at the application boundary.
NHI Management Group research shows the operational gap is already visible in MCP environments: in The State of MCP Server Security 2025, only 18% of deployments implemented any form of access scoping for tool permissions. That is a governance problem as much as a technical one, because least-privilege fails when no one owns the scope design across server connections. In practice, many security teams discover this only after a client has already accumulated far more reach than anyone intended.
How It Works in Practice
The organisation operating the MCP environment is accountable, but responsibility needs to be split into operational controls. One team should own token issuance and storage, another should define server-level scope policy, and a third should monitor drift and revoke credentials when trust changes. That separation matters because a client connecting to many servers often uses different tokens, consent grants, or delegated scopes, and those controls must be reviewed as one access chain rather than as isolated integrations.
For implementation, best practice is to treat each MCP connection as a workload identity problem, not a static user permission problem. The OWASP Agentic AI Top 10 and OWASP Agentic AI Top 10 both reinforce that autonomous or tool-using systems can expand access in ways traditional IAM does not model well. Security teams should therefore pair consent review with runtime policy checks, short-lived tokens, and explicit server-by-server scope definitions. NHI Management Group’s Ultimate Guide to NHIs frames this as an identity governance issue: know which non-human principal is acting, what it can reach, and what limits apply at each hop.
- Assign one accountable owner for MCP token lifecycle management.
- Require per-server scope definitions and documented approval for expansions.
- Use short TTLs and automatic revocation for unused or stale access.
- Log consent changes, token use, and server additions as audit events.
These controls tend to break down in federated MCP deployments where multiple teams independently register servers, because scope drift appears faster than central governance can review it.
Common Variations and Edge Cases
Tighter MCP scope control often increases operational overhead, requiring organisations to balance speed of integration against the cost of review, reconsent, and token rotation. There is no universal standard for this yet, so current guidance suggests adopting the least-privilege model that can be enforced consistently across all servers rather than chasing perfect granularity on day one.
Edge cases usually appear when one client serves several business units, or when a shared platform team brokers access to many downstream servers. In those setups, accountability should still remain with the operating organisation, but the practical controls may be split among platform, application, and security owners. Where permissions are inherited from human workflows, teams should not assume those models fit MCP. Tool permissions need explicit scope design, because a server connection can become overpowered even when the user-facing application looks narrow. Related NHIMG analysis such as 52 NHI Breaches Analysis shows that poor ownership and weak revocation discipline are recurring failure patterns in non-human access.
In environments with many ephemeral clients or rapidly changing server inventories, least-privilege tends to erode unless ownership, consent, and revocation are automated as one control loop.
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, OWASP Agentic AI Top 10 and CSA MAESTRO 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 Non-Human Identity Top 10 | NHI-03 | Covers secret rotation and lifecycle control for non-human access. |
| OWASP Agentic AI Top 10 | A1 | Addresses excessive tool access in agentic and MCP-driven workflows. |
| CSA MAESTRO | M2 | Focuses on identity and trust boundaries for autonomous workloads. |
| NIST AI RMF | Supports governance and accountability for AI-enabled access decisions. | |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access management aligns directly with this control area. |
Document ownership, monitoring, and escalation for runtime access decisions across MCP servers.
Related resources from NHI Mgmt Group
- Who should be accountable for risky non-human identity access when automation spans multiple platforms?
- Who is accountable when an IGA implementation fails to deliver least privilege and audit ready outcomes?
- How do access certification and identity governance and administration support least privilege in practice?
- How should teams enforce least privilege in MCP servers?
