Fifty-three percent of MCP servers currently in production rely on long-lived static secrets — API keys and personal access tokens with no expiry, no scope ceiling, and no rotation schedule. That figure, from Astrix Security’s State of MCP Server Security 2025, reflects an ecosystem that has scaled faster than the security practices around it. As AI coding agents gain write access to codebases, databases, and deployment pipelines through MCP integrations, misconfigured permissions are no longer a hygiene concern. They are the primary lateral movement vector available to any attacker who reaches an MCP endpoint.
Why MCP Permissions Require a Different Approach
Unlike standard REST APIs, MCP servers execute arbitrary tool calls on behalf of AI agents that can be manipulated through prompt injection and tool poisoning. The MCP specification includes no native permissions model — security depends entirely on how each server limits access to the underlying systems it exposes.
The 2026 MCP specification update formally classified MCP servers as OAuth Resource Servers and introduced incremental scope consent — a significant structural shift that brings the protocol in line with enterprise authorization standards. But adoption lags dangerously: only 8.5% of MCP servers currently implement OAuth, leaving the remaining 91.5% operating without the authentication architecture the spec now mandates.
Research published on arXiv (MCPTox threat modeling study, 2025) evaluated 20 LLM agents across 1,312 malicious test cases and found tool poisoning attack success rates as high as 72.8%. The highest refusal rate across all evaluated models remained below 3%. Permission gaps do not stay theoretical for long.
Step 1: Audit Your Credential Inventory
Before any remediation is possible, you need a complete map of how each connected MCP server authenticates and what it can reach. Build a credential register with these fields for every server: authentication method, credential age, expiry date, scope surface, and rotation cadence.
Red flags to prioritize: static API keys with no expiry, personal access tokens with organization-wide scope, and — most critically — unrestricted network access. Security analysis found that 33% of MCP servers allow unrestricted network access — meaning a compromised agent operating through those servers has an unrestricted egress path out of your environment.
Your audit output should answer four questions: which systems does each server have access to; which agent identity can invoke which tools; what credential is in use and when does it expire; and which servers have received a security review in the last 90 days. If you cannot answer all four for every connected server, that gap is your current risk surface.
Step 2: Migrate to OAuth 2.1 with PKCE
The MCP authorization specification designates OAuth 2.1 as the standard authentication mechanism for HTTP transport. OAuth 2.1 mandates PKCE (Proof Key for Code Exchange) using the S256 challenge method, prohibits the implicit grant flow, and requires short-lived access tokens scoped per MCP server using Resource Indicators (RFC 8707). If your MCP servers are still using static API keys or long-lived PATs, migrating to OAuth 2.1 is the highest-leverage single security action available.
The migration path has four concrete steps:
Register each MCP server as an OAuth Resource Server with your authorization service, issuing a unique resource identifier per server.
Configure the authorization server to support PKCE — the S256 code challenge method is mandatory when technically feasible under the 2025 spec revision.
Replace long-lived PATs with authorization code flow tokens. Set access token expiry to 60 minutes or less and implement refresh token rotation on every use.
Assign a separate client credential to each agent identity rather than sharing a pool credential. Per-agent credentials mean a compromised agent can be revoked without affecting others.
GitGuardian’s analysis of emerging OAuth patterns for MCP enterprise deployments identifies per-agent credential isolation and explicit user consent flows as the most important architectural decisions at this stage of MCP maturation.
Step 3: Enforce Incremental Scope Consent
Requesting all permissions at session initialization is a pattern inherited from early API integrations, and it is architecturally wrong for agentic workloads. The 2026 MCP specification introduced incremental scope consent precisely to address this: clients request only the minimum access needed for each individual operation, not a blanket grant at startup.
In practice, this means maintaining a scope-to-tool mapping in your governance runbook. A code-review agent reading a PR diff needs read:files but has no operational need for write:files or deploy:trigger until a human approves a merge action. Granting broader scope upfront because it might be needed later is how privilege accumulation begins.
Define separate OAuth scopes for tools that logically should not coexist — for example, sendEmail and readContacts should require separate explicit grants. The scope map also forms the foundation of your audit log: every tool invocation can be validated against the scopes the calling token actually carries.
Step 4: Validate Tool Calls at Runtime
Static permission configuration addresses who can call what. Runtime validation addresses whether a specific call, with specific parameters, from a specific agent identity, should be permitted at a given moment. This layer stops tool poisoning attacks that have already cleared authentication.
The threat is concrete. Security analysis found that 43% of MCP servers contain command injection vulnerabilities opening the path to remote code execution, and 5% of open-source MCP servers are already seeded with tool poisoning payloads. Attackers do not need to breach authentication if the tool call itself carries the payload.
Runtime validation should enforce four checks on every tool invocation:
Tool name matches the server’s published allowlist — reject any call to an undeclared tool name
Parameters conform to the declared schema — type, range, and structure validation, not just presence checks
Caller token carries the required scope for that specific tool — token validation at the call layer, not only at session establishment
Request rate is within expected bounds for that agent identity — high-volume tool calls are a reliable indicator of data exfiltration attempts
Any call that fails validation should be rejected with a logged event, not silently dropped. Silent rejection makes exfiltration attempts invisible.
Step 5: Implement Audit Logging and Role-Based Access Control
Permissions without an audit trail are unverifiable. Every tool invocation should produce a log record containing: timestamp, tool name, agent identity, token scope presented, parameter hash (not raw parameters for sensitive calls), and response status. This log is both a security artifact and compliance evidence.
Layer role-based access control on top of OAuth scopes to restrict destructive tool categories. Tools that can delete data, trigger deployments, or modify access policies should require an explicit admin or privileged role assignment — not just any authenticated agent. RBAC and OAuth scopes are complementary: scopes gate what a token is allowed to request; roles gate which identities can receive tokens with those scopes.
Anomaly signals worth alerting on: off-hours high-volume read operations, scope elevation attempts, calls to admin-tier tools from agent identities that have not used them before, and repeated parameter validation failures from the same identity. Eurostat enterprise security incident data consistently identifies security misconfiguration as the most frequently encountered incident class across enterprise technology deployments — audit logging is the primary detection mechanism, not prevention controls alone.
Retain MCP tool invocation logs for a minimum of 90 days. For organizations subject to SOC 2, ISO 27001, or EU AI Act Article 12 logging requirements, align retention to the applicable compliance window — often 12 months.
Step 6: Govern Third-Party and Open-Source MCP Servers
First-party MCP servers — those your team builds and controls — can be hardened through the five steps above. Third-party servers introduce a different threat: you are trusting code and configuration you did not write, cannot fully audit, and do not control at runtime.
The Supabase/Cursor incident of mid-2025 illustrates the failure mode clearly. A privileged service-role MCP integration was processing support tickets that contained user-supplied input. Attackers embedded SQL instructions in those tickets, which the AI agent executed through the privileged connection, exfiltrating sensitive integration tokens. The permissions were real. The governance of what those permissions should process was absent.
Before connecting any third-party MCP server, require it to clear five criteria:
Published security disclosure policy with a named contact and defined response SLA
Known and accountable ownership — avoid anonymous open-source MCP packages that lack a maintainer with verifiable business identity
Source code accessible for internal review before any production use
Pinned to a specific version with hash verification — no automatic updates that bypass your security review process
Network egress scoped to declared endpoints only — the unrestricted egress problem cited above is disproportionately concentrated in third-party server packages
The Governance Layer These Steps Require
Steps 1 through 6 address the configuration layer. Each step is technically tractable for an individual server or integration. The harder operational problem is enforcement at scale: ensuring these controls are consistently applied across every MCP server, every agent identity, and every deployment environment — and producing auditable evidence that the controls are working as configured.
Without a governance layer that captures every tool invocation against a policy, security relies on engineers manually reviewing logs after the fact. That model does not scale past a handful of integrated servers, and it cannot produce the enforcement evidence that compliance audits require.
This is the problem re-entry.ai was built to solve. The platform provides real-time policy enforcement across AI coding agent interactions, audit-ready logs of every tool invocation, and governance controls that operate continuously — not as a post-incident review. If your team is expanding MCP-connected tooling and needs assurance that permissions are enforced as configured, request a demo at re-entry.ai.
The Remediation Path Is Well-Defined
MCP permissions are a concrete, solvable problem. The 2026 MCP specification has given engineering teams the right primitives — OAuth 2.1, PKCE, incremental scope consent, and formal Resource Server classification. What the spec cannot do is implement those primitives in your environment or maintain them as your agent surface grows.
The six-step sequence — credential audit, OAuth 2.1 migration, incremental scope consent, runtime validation, audit logging with RBAC, and third-party server governance — covers the full permission surface. Each step is independently deployable: you do not need to complete all six before the first three deliver meaningful risk reduction. Start with the credential audit. The findings will determine exactly where to focus next.