TL;DR: Enterprise MCP servers should be judged on ten readiness checks, including OAuth 2.1 SSO, JWT audience validation, audit logs, scope-level authorisation, observability, and signed releases, according to Archestra, because laptop-grade setups do not survive procurement, governance, or production exposure. The checklist shows that MCP becomes an identity and control-plane problem once it reaches enterprise data and workflows.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Archestra's blog post: Ten enterprise MCP requirements define pass or fail criteria, with identity, scopes, audit logging, residency, isolation, and signed builds as the core checks.
Why it matters: It matters because MCP governance shifts from developer convenience to enterprise access control, auditability, and supply chain assurance as soon as real data and real users are involved.
Context
Enterprise MCP deployments fail when teams treat a server that works on a laptop as if it were ready for enterprise governance. The underlying issue is not the protocol itself, but the assumption that identity, scope, logging, and release integrity can be improvised after rollout, when procurement and risk review depend on them from day one.
An MCP server becomes part of the identity perimeter the moment it can call tools on behalf of users, reach sensitive systems, or move data across boundaries. That means the readiness conversation is really about whether the server can be governed like any other access-bearing service, including non-human identity authentication and auditability.
Key questions
Q: What should teams reject first when evaluating an MCP server for enterprise use?
A: Reject any server that depends on a static API key, a local login form, or a permission model that cannot map to the organisation's identity provider. The first enterprise test is whether the server can fit into normal access governance, not whether it can be made to work in a demo.
Q: Why do scope boundaries matter so much for MCP deployments?
A: Because a valid identity with overly broad scopes can still do far more than it should. If read and write actions are bundled together, teams lose least privilege and make every client request carry unnecessary destructive power, which raises both operational risk and blast radius.
Q: What does missing audit logging break in an MCP environment?
A: It breaks incident reconstruction, accountability, and change review. If security teams cannot see who called which tool, when they called it, and what arguments were passed, they cannot investigate misuse, confirm data handling, or prove that controls worked after an event.
Q: How should teams evaluate an MCP server before production use?
A: Check maintainer identity, documentation quality, update recency, and dependency posture, then validate that the client can be limited to specific tools and actions. A directory score or popularity rank is not enough for production decisions. The real test is whether the server can be governed as a bounded identity relationship.
Technical breakdown
Why OAuth 2.1 and PKCE are the first enterprise gate
Enterprise MCP access should not begin with a static API key or a custom login form. OAuth 2.1 with PKCE lets the server integrate with the organisation's identity provider, preserve user identity, and avoid secrets that cannot be governed through joiner/mover/leaver processes. The important point is that authentication is not just proving a client can connect. It is proving the server can anchor every session to a known enterprise identity and consume tokens in a way that is compatible with policy, lifecycle, and revocation. See the NHI Authentication Guide.
Practical implication: Treat OAuth 2.1 plus PKCE as the minimum authentication baseline for enterprise onboarding.
Why JWT validation and scope enforcement are separate controls
A token that arrives at the server is not trustworthy until the server validates its signature, issuer, expiry, and audience against the identity provider. That is authentication integrity. Scope enforcement is different: it determines which tools and resources a valid identity may use once admitted. If those controls collapse into a single broad permission, the server can accept a legitimate token and still overreach at runtime. Enterprise design needs both layers because one proves who is calling and the other constrains what that caller may do.
Practical implication: Verify JWTs against the IdP and enforce granular scopes at the resource server, not just at login.
Why audit logging and signed releases are procurement controls, not extras
Enterprise reviewers are not only asking whether the server works. They are asking whether its actions can be explained after the fact and whether the binaries they deploy are the binaries the vendor shipped. Structured logs for every tool call support incident review, while signed releases and provenance attestation support supply chain trust. In practice, an MCP server without durable telemetry or verifiable build integrity cannot be treated as production software, because security teams lose both forensic visibility and release confidence. See the Cloud Logging and Audit Trail Guide.
Practical implication: Require immutable tool-call logs and release signing before any production approval.
Threat narrative
Attacker objective: The attacker aims to use a trusted MCP connection to reach enterprise data or tools with more authority than the session should allow.
- Entry occurs when a user or service connects to an MCP server through weak or non-enterprise authentication, such as a static API key or an unvalidated token.
- Escalation follows when broad scopes or missing audience checks let the server accept requests it should have rejected, turning a valid session into overbroad tool access.
- Impact occurs when the server can call downstream systems with excessive authority, letting a compromised or mis-scoped session exfiltrate data or trigger destructive actions.
Breaches seen in the wild
- Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Enterprise MCP is now an identity governance problem, not just a protocol problem. Once a server sits between users and business systems, it inherits the same accountability expectations as any other access-bearing service. That means procurement must ask whether identity, scopes, logs, and release controls exist before rollout, not after the first incident. The practical conclusion is simple: if the server cannot be governed, it cannot be trusted in production.
Scope design is the difference between controlled delegation and accidental privilege expansion. MCP servers that bundle read and write operations into coarse permissions force teams to over-authorise every caller. That is not a small implementation choice. It turns least privilege into a paper exercise because the protocol surface itself creates unnecessary blast radius. The practitioner takeaway is to treat scope granularity as a design requirement, not a later policy overlay.
Auditability and provenance define whether an MCP deployment can survive a real review. If a tool call cannot be reconstructed and a build cannot be verified, security teams lose both incident forensics and supply chain assurance. This is where enterprise readiness often fails first, because visibility and release integrity are easy to defer during pilot stages. The operational implication is that logging and signing are not paperwork controls, they are the evidence layer for every other control.
Hosted MCP infrastructure creates a shared-trust problem that procurement cannot ignore. When a vendor hosts servers for many tenants, the organisation is no longer only evaluating application behaviour. It is also evaluating the isolation model, the tenancy boundary, and the vendor's ability to preserve customer-specific identity and data separation. That is why enterprise review has to include tenancy, residency, and downstream authorisation together, not as separate checkboxes.
From our research library:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Read next: MCP Security Guide
What this signals
Enterprise readiness for MCP will be defined by governance evidence, not feature count. The next phase of adoption will reward servers that can prove who called them, what they were allowed to do, where data flowed, and how the release was verified. That shifts buying criteria from capability demos to control evidence, which is exactly how identity programmes mature in regulated environments.
Identity proof, scope control, and release integrity now belong in the same review cycle. Teams that assess MCP authentication without checking build provenance or logging will keep finding gaps after deployment. The more useful operating model is to review the access path, the execution path, and the software supply path together, because all three define whether the server can be trusted in the enterprise.
For practitioners
- Require enterprise identity integration Reject any MCP server that depends on a shared username/password page or a static API key. Require OAuth 2.1 with PKCE, identity provider integration, and a clear fit with joiner/mover/leaver processes.
- Test token validation and audience checks Ask the vendor to explain how the server validates JWT signatures, issuer, expiry, and especially the audience claim. If the answer is vague, treat the server as unfit for enterprise trust.
- Separate read and write scopes Insist on granular scopes for tools and resources so a client can request only what it needs. Do not accept a single broad permission that forces destructive access into every session.
- Demand durable audit evidence Make structured tool-call logs a prerequisite for rollout, including authenticated subject, tool name, timestamp, and redacted arguments. Confirm the logs can export to a SIEM and support retention policies.
- Verify build provenance before deployment Check for signed releases, provenance attestations, and a documented verification process for container images or packages. If the release cannot be verified, do not move it into enterprise use.
Key takeaways
- Enterprise MCP servers need enterprise identity and governance controls before they touch real data, not after the first incident.
- The biggest practical gaps are usually scope design, token validation, auditability, and release provenance rather than core functionality.
- A pass fail onboarding rubric is the right way to separate laptop-grade MCP usage from production-ready deployment.
Related NHI Mgmt Group resources: MCP Security Guide · NHI Authentication Guide · Cloud Logging and Audit Trail Guide · Identity Security Programme Guide
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 MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 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-04 — Insecure Authentication | The article centres on MCP servers that must authenticate with enterprise identity providers rather than static keys. |
| NHI-05 — Overprivileged NHI | The checklist repeatedly warns against broad scopes and shared accounts that expand tool access beyond need. | |
| NHI-07 — Long-Lived Secrets | Static API keys and unrevised credentials are explicitly called out as non-starters for enterprise deployment. | |
| Recommendation — Require federated authentication and reject static secrets as the primary login path. Enforce granular scopes and separate read from write permissions for every MCP tool. Eliminate long-lived secrets from MCP onboarding and move to short-lived, revocable credentials. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The post focuses on credential lifecycle, token handling, and revocation for enterprise MCP access. |
| Recommendation — Apply authenticator management controls to rotate, validate, and revoke MCP credentials. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Scope-level authorisation and least privilege are core requirements throughout the checklist. |
| Recommendation — Map MCP tool scopes to least-privilege entitlements and verify enforcement before rollout. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The article describes how stolen or overbroad MCP access can pivot into downstream enterprise systems. |
| Recommendation — Hunt for token abuse that could expand into lateral movement through connected tools. | ||
Key terms
- MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
- Scope authorisation: Scope authorisation is the documented permission that makes testing defensible and operationally clear. It defines which assets researchers may assess, who owns the reporting relationship, and whether findings should be handled by the customer, the supplier, or both.
- On-behalf-of access: On-behalf-of access means the server acts downstream using the caller's identity or delegated authority rather than a shared service account. For MCP, this preserves accountability and keeps enterprise permissions aligned with the actual user, not a generic bot credential.
- Release provenance: Release provenance is the evidence that a deployed package or container image came from the intended source and has not been altered in transit. For MCP deployments, provenance matters because unsigned or unverified builds can undermine every other control by replacing trusted code with unknown code.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org