The MCP Trust Framework: A Security Standard for Agent Tools

The question enterprises ask about MCP servers is always the same: “Should I trust this in my production environment?” Before the MCP Trust Framework, there was no structured way to answer it. You could read the source code if it existed. You could check GitHub stars. You could hope the author was competent and honest. None of that scales to an enterprise deploying dozens of MCP servers connected to production CRMs, databases, and cloud infrastructure.

The MCP Trust Framework (MTF) replaces hope with measurement. Published at mpaktrust.org, MTF is an open security standard that evaluates MCP servers across five dimensions and assigns a trust level that enterprises can use as policy. Here is how it works, why each dimension matters, and how organizations are using it in production.

Why a Trust Framework

The MCP ecosystem has over 3,000 servers in the official registry and thousands more in unofficial directories. The quality range is enormous, from well-engineered servers built by security-conscious teams to weekend projects with hardcoded credentials and unaudited dependency trees. Our analysis found that only 8.5% use OAuth, 15.4% have no source code available, and most registries perform zero security scanning.

Enterprises need a way to separate signal from noise. Not every MCP server is dangerous, and not every MCP server is safe. The missing piece was a standardized evaluation framework: consistent criteria, automated scoring, and trust levels that map to deployment policies.

NimbleBrain built MTF because we needed it. We’ve built 21+ MCP servers and operate them in production for clients across multiple industries. When a client asks whether a particular server is safe for their environment, “we think it’s probably fine” is not an acceptable answer. We needed structured evaluation criteria that produce a defensible assessment. MTF is that structure, published as an open standard so the entire ecosystem benefits.

The Five Trust Dimensions

MTF evaluates every MCP server across five dimensions. Each captures a distinct category of risk that matters for production deployment.

1. Provenance: Who Built This

Provenance answers the identity question. Is the publisher known? Can the source be verified? Is the package signed?

A server published by a verified organization with a traceable development history carries different risk than an anonymous upload to an unofficial directory. Provenance doesn’t guarantee quality, reputable teams ship bugs too, but it establishes accountability. If something goes wrong, there is a known entity responsible for the fix.

MTF provenance evaluation checks: verified publisher identity, signed packages (cryptographic verification that the published artifact matches the source), traceable source repository with commit history, and consistent identity across versions. Anonymous servers aren’t automatically rejected, they receive a lower provenance score that feeds into the overall trust level.

2. Permissions: What It Can Access

Permissions evaluation measures the gap between what a server states it does and what system access it actually requests. This is the dimension that catches the most common vulnerability in the ecosystem: overpermissioned servers.

A Slack notification server that declares itself as “sends messages to Slack channels” but requests read access to files, environment variables beyond the Slack API key, and outbound network access to arbitrary endpoints is overpermissioned. The stated purpose doesn’t match the actual access surface. MTF flags the gap.

The evaluation checks: declared capabilities versus actual permission requests, adherence to least-privilege principles (does the server request only what it needs?), scope of credential access (does it read all environment variables or just its own?), and network access patterns (does it declare which external endpoints it connects to?).

Permission scoping is where most servers fail their first MTF evaluation. Not because of malicious intent, because developers default to broad access during development and never narrow it for production. The fix is usually straightforward: declare the specific permissions, remove the extras, document why each one is needed.

3. Behavior: What It Actually Does

Static analysis tells you what the code looks like. Behavioral analysis tells you what it does at runtime. The gap between the two is where rug-pull attacks live, servers that pass code review and then deviate at runtime.

MTF behavioral evaluation runs the server in an instrumented environment and monitors: network requests (does it connect to endpoints not declared in its manifest?), filesystem access (does it read or write files outside its declared scope?), resource consumption (does it consume CPU, memory, or disk beyond reasonable limits?), and data handling (does it retain, cache, or transmit data beyond what its tool responses require?).

Behavioral analysis catches patterns that static analysis misses. A server whose source code looks clean but makes undeclared HTTP requests at runtime (sending tool response data to an external endpoint) would pass a code review but fail behavioral evaluation. This dimension is what separates MTF from simpler scanning approaches that only look at the code.

4. Maintenance: Is It Actively Supported

A server with known vulnerabilities in its dependency tree that hasn’t been updated in six months is a different risk profile than one with active maintainers who respond to CVE disclosures within days. Maintenance tracks the operational health of a server over time.

MTF maintenance evaluation checks: dependency freshness (are dependencies reasonably current, and are known CVEs addressed?), update frequency (is the server actively maintained or abandoned?), CVE response time (when a vulnerability is disclosed in a dependency, how quickly is it patched?), and version history (is there a consistent release cadence with changelogs?).

Maintenance scoring is dynamic ;it changes over time. A server that scored well at initial evaluation can degrade if its dependencies accumulate unpatched CVEs and the maintainer stops responding. This is deliberate. Trust is not a one-time assessment. It reflects the current state of the software.

5. Transparency: Is the Code Inspectable

Transparency measures how much visibility you have into what the server does. Open-source servers with documented architecture are more transparent than closed-source remote services where you can only observe inputs and outputs.

MTF transparency evaluation checks: source code availability (is the full source published and inspectable?), architecture documentation (is the server’s design documented well enough to understand its behavior?), build reproducibility (can you build the published artifact from source and get the same result?), and dependency declaration (are all dependencies explicitly listed, or are there hidden transitive dependencies?).

15.4% of MCP servers in the official registry have no source code available. They’re opaque: you cannot audit them, scan them, or verify their behavior. MTF doesn’t ban opaque servers. It scores them accordingly, giving enterprises the signal to make an informed decision.

Trust Levels

The five dimension scores combine into an overall trust rating from 0 to 100. MTF maps these ratings to four trust levels, each with a clear meaning for deployment decisions.

Untrusted (no evaluation). The server has not been evaluated against MTF. This is the default state for any server that hasn’t been submitted for scanning. Most servers in unofficial directories sit here. Deploying an untrusted server in production is equivalent to running unaudited code with access to your enterprise systems.

Scanned (automated analysis). The server has passed automated evaluation: dependency audit against known vulnerability databases, static analysis for malicious code patterns, and permission surface analysis. Scanned servers have cleared the baseline, no known CVEs in dependencies, no obvious data exfiltration or backdoor patterns, and permission requests that roughly match stated purpose. Suitable for non-sensitive use cases and development environments.

Reviewed (manual code review). The server has passed automated scanning plus manual code review by a qualified reviewer. The reviewer has verified the architecture, confirmed that the code matches the declared behavior, and assessed the overall quality. Reviewed servers are appropriate for production use in environments where the data sensitivity is moderate.

Verified (full evaluation with known author). The server has passed all automated checks, manual code review, and behavioral analysis, plus the publisher is a verified entity with a traceable identity. This is the highest trust level. Verified servers have been evaluated end-to-end: the code is clean, the behavior matches the declaration, the publisher is accountable, and the server is actively maintained. Enterprises requiring SOC 2, HIPAA, or similar compliance standards should target Verified servers for production data access.

Using MTF in Practice

MTF is designed for three enterprise use patterns: procurement evaluation, runtime policy enforcement, and vendor requirements.

As a Procurement Checklist

When evaluating MCP servers for deployment, MTF provides a structured framework. Instead of ad hoc code reviews that vary by reviewer, the five dimensions ensure consistent evaluation. A security team can say: “We evaluated this server against MTF. It scores 74. Provenance is strong (verified publisher). Permissions are clean (minimum viable access). Behavioral analysis shows no undeclared network activity. Maintenance is active. Source is fully transparent.” That’s a defensible assessment for a risk committee.

As Runtime Policy

Enterprises can encode MTF trust levels into their deployment pipelines. “Only servers at Reviewed or above deploy to staging. Only Verified servers access production data.” This is the same pattern as requiring minimum test coverage or blocking deploys with known vulnerabilities, except applied to the agent tool layer. The NimbleBrain Platform’s MCP operator enforces these policies automatically: a server below the required trust level does not deploy.

As Vendor Requirements

Organizations working with AI vendors or consultancies can require MTF compliance as part of their contracts. “All MCP servers deployed in our environment must carry an MTF trust level of Reviewed or above.” This gives procurement teams a concrete, measurable standard instead of vague assurances about security practices.

Automated Scoring Through mpak

mpak.dev is the MCP server registry built on MTF. Every server published to mpak runs through an automated security pipeline that evaluates each trust dimension: dependency audit against CVE and OSV databases, static analysis for malicious patterns, permission surface analysis, and behavioral monitoring. The trust score appears on every listing. Enterprises can filter by trust level and enforce minimum thresholds.

Business-as-Code intersects with security here. The trust evaluation is codified and automated, not a manual process that scales linearly with the number of servers. The security standard becomes structured data that feeds into enterprise decision-making. An MCP server’s MTF score is as queryable and enforceable as its version number.

NimbleBrain has published 21+ MCP servers through mpak. Every one carries an MTF trust level. They serve as reference implementations for what secure MCP server distribution looks like, not toy examples, but production servers connected to CRMs, databases, communication platforms, and cloud APIs.

An Open Standard

MTF is published at mpaktrust.org as an open standard. Any registry, tool, or organization can adopt it. We built it as a standard rather than a proprietary feature because MCP security is a baseline the entire ecosystem needs. The CoSAI MCP Security Framework, OWASP Top 10 for Agentic Applications, and SAFE-MCP are all addressing overlapping concerns. The more frameworks converge on shared evaluation criteria, the better the ecosystem becomes for everyone building and deploying agent tools.

The Anti-Consultancy model means we don’t hoard competitive advantages behind a paywall. We publish the standard, build the tooling, and help clients implement it, then leave them with the capability to evaluate and enforce trust independently. MTF is the security layer. mpak is the enforcement mechanism. The methodology compounds whether NimbleBrain is in the room or not.

For the current threat picture that MTF addresses, see The State of MCP Security in 2026. For a practical guide to deploying secure agent tools, see Securing Agent Tools.