Re-evaluate them whenever a tool can both read source material and write back decisions, code, or documentation. Traditional reviews often focus on static application access, but MCP changes the unit of control to a session with tool calls. That makes periodic recertification too coarse unless it includes the reachable action set.
Why This Matters for Security Teams
MCP changes the review unit from a single app entitlement to a live session that can read context and then write code, documentation, or operational decisions. That means a “clean” quarterly access review can still miss a tool that has quietly become capable of broader actions than the original approval covered. Security teams should treat MCP permissions as dynamic exposure, not static membership.
This is why guidance from OWASP Agentic AI Top 10 and NHIMG research such as the State of MCP Server Security 2025 matters: the risk is not just who can log in, but what the session can reach, compose, and persist. In the same research, only 18% of MCP server deployments implement any form of access scoping for tool permissions, which shows how often review processes lag behind actual tool reach. Practitioners also need to align this thinking with the OWASP Non-Human Identity Top 10, because MCP tools are effectively non-human workloads with delegated authority.
In practice, many security teams discover the review gap only after a tool has already been allowed to write back into a repository, ticketing system, or knowledge base.
How It Works in Practice
Re-evaluation should be triggered by capability change, not by calendar alone. If an MCP-based development tool can move from “read only” to “read and write,” that is a material change in the reachable action set and should prompt an immediate access review. The same is true when a tool gains a new connector, broader repository scope, elevated token, or access to production-adjacent data. Current best practice is evolving toward intent-aware review, where approvers evaluate what the tool can do in a session, not just what group it belongs to.
Operationally, teams should review MCP tools in the same way they would scrutinise privileged non-human identities: short-lived credentials, explicit tool scoping, and documented ownership. The Ultimate Guide to NHIs is useful here because it frames identity as a lifecycle problem, not a one-time setup. For development tools, that lifecycle should include:
- re-certification whenever tool permissions expand, especially from read-only to write-capable
- re-certification when a new MCP server, connector, or plugin is added
- re-certification when the tool gains access to source control, CI/CD, secrets, or documentation systems
- session-level logging so reviewers can see the actual tool calls made during use
In this model, recertification should ask whether the tool still needs the reachable actions it has been granted, whether those actions are time-bound, and whether the approval matches the current workflow. The NHI Lifecycle Management Guide reinforces that access decisions should be revisited at enrolment, change, and revocation, not just at periodic review. These controls tend to break down when MCP servers are shared across teams because one team’s legitimate expansion can silently broaden another team’s effective access.
Common Variations and Edge Cases
Tighter review triggers often increase operational overhead, requiring organisations to balance faster change control against developer friction. That tradeoff is real, especially in engineering environments where MCP tools are being iterated weekly and permissions shift often. There is no universal standard for this yet, but current guidance suggests treating write capability, production adjacency, and secret access as hard review triggers.
One edge case is a tool that is technically read-only but can still influence decisions by summarising or ranking content that later drives human approvals. Another is an MCP workflow that writes only documentation, but from the wrong context that documentation becomes an indirect control plane for code or deployment decisions. Vendor research from Analysis of Claude Code Security illustrates why code-adjacent tooling needs closer scrutiny than ordinary collaboration tools, because small permission changes can have outsized downstream impact. For broader agentic context, the OWASP Top 10 for Agentic Applications 2026 is a useful reference point, though best practice is still maturing.
Where organisations have strong change management, access reviews can be event-driven. Where they do not, quarterly reviews are usually too slow for MCP-based tools that can start as assistants and end up as decision-making actors.
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 define the specific risk controls and attack patterns relevant to this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | MCP tools are non-human identities with permissions that change over time. |
| OWASP Agentic AI Top 10 | A-04 | Agentic tool use requires review of what the session can do, not just who is signed in. |
| CSA MAESTRO | IAM-02 | MAESTRO emphasises runtime control for autonomous tool-using systems. |
Tie access review to capability changes, connector additions, and session-level audit evidence.
