Smithery MCP Security: Connect and Uplink Acceptance Matrix

Smithery MCP has two production paths that deserve separate approval. Connect offers a REST interface with managed OAuth flows and credentials across the connection lifecycle and sessions, while Uplink opens a persistent WebSocket from Smithery to a local MCP server or subprocess and bridges JSON-RPC across that tunnel. One moves credential and session custody into a managed service. The other keeps local execution behind a remotely reachable bridge.

Smithery changed ownership when Arcade announced its acquisition on August 5, 2026. I would refuse a security packet that still lists Smithery as an unchanged standalone vendor. Put the current legal and operational owner in the top-right corner, beside the service and support contacts. Acquisition state belongs in the control record.

TL;DR

• Review Smithery Connect and Uplink as different architectures, with separate data paths and credentials. Document failure modes and audit joins, then run rollback tests.
• Verify publisher provenance and the remote or package destination. Confirm namespace ownership, tool permissions, and every identity translation.
• Treat token scoping as a preview control. Test metadata isolation server-side and set a session-specific TTL below the 24-hour maximum.
• Smithery sessions and tunnels are outside DeepInspect's LLM boundary. Tool calls also remain outside it; only separate routed HTTP model calls enter it.

Smithery is now part of Arcade

Arcade's acquisition announcement says it acquired Smithery on August 5, 2026 and describes Smithery as a public registry and hosting platform for MCP. The announcement also says Smithery co-founder Anirudh Kamath joined Arcade. That dated statement establishes the ownership change, but it does not answer how every existing Smithery contract, namespace, credential, or hosted server migrated.

The acceptance record should name the contracting entity and service operator, along with the support route and incident contact. It should also identify the applicable terms, data-processing agreement, subprocessor list, and current product documentation. Ask for written confirmation when public material leaves a field unresolved. Keep the Smithery namespace and publisher identity in the record even if billing or support now routes through Arcade.

Link this review to the broader MCP security best practices, then retain a vendor-specific matrix. Generic MCP guidance cannot tell you who operates a hosted Smithery server or which service holds an OAuth credential. It also cannot tell you where an Uplink subprocess runs.

Connect centralizes credentials and sessions

Smithery's Connect documentation describes a REST interface for connecting to MCP servers while Smithery handles OAuth flows and credentials across the connection lifecycle and sessions. It states that credentials are encrypted and write-only, so they can be used for requests but cannot be read back. The same page describes short-lived scoped service tokens for browser or mobile clients.

That design creates a custody review. For every connection, record the namespace and MCP server, then the publisher and remote URL. Include the authentication method, credential owner, granted scopes, and connection metadata, and finish with session behavior and the deletion path. Test credential rotation and revocation rather than accepting an encryption statement as proof of lifecycle behavior.

Create one connection with a dedicated read-only test identity, call an allowed tool, then attempt a write. Revoke the upstream credential and repeat the read. Capture Smithery's connection status and API response, preserving the source-system event and elapsed time too. After deleting the connection, test the old service token again.

The write-only property changes recovery too. If the enterprise cannot retrieve a stored secret, rollback needs either a retained upstream credential under enterprise custody or a repeatable reauthorization flow. Put that dependency in the exit plan.

Scoped tokens need adversarial isolation tests

Smithery's token-scoping documentation labels the feature preview and warns that its API surface may change. The page says a token can restrict namespaces and resources, operations, and metadata. It documents server-side metadata constraints and a maximum TTL of 24 hours, then recommends shorter tokens for each session.

Treat preview status as a change trigger. Pin the tested API behavior and client release, then rerun acceptance after scope syntax or enforcement changes. Use two users and two workspaces with deliberately similar connection names. Put a visual marker such as ORANGE-WORKSPACE-B in the second user's test resource.

Mint a token for user A with the minimum execution operation and a short TTL. Try the permitted connection and user B's connection ID. Then try a namespace outside the scope and a write operation before repeating the same request after expiry. Every denied attempt should produce a stable error and an audit event that identifies the evaluated constraint without exposing the credential. A successful read of ORANGE-WORKSPACE-B is a release blocker.

Avoid putting account isolation entirely in a client-supplied connection ID. Smithery recommends metadata constraints because the service enforces them server-side. Verify that claim with the crossed-user test and preserve the result.

Uplink exposes a local execution path

Smithery's Uplink documentation says the CLI registers an Uplink-backed connection and opens a persistent WebSocket scoped to it. The CLI connects to a local HTTP server or spawns a command as a subprocess, bridging JSON-RPC between the WebSocket and the local process. Stateful sessions and server-initiated messages can pass through the tunnel, along with progress notifications and streamed responses.

This path needs a host review in addition to a service review. Record the host and operating system, then the user account and CLI version. Include the command or local URL, working directory, and environment variables. Document filesystem access and network egress, plus the restart policy and log destination, and pin any package or binary by an immutable version and digest where the distribution method supports it.

Run Uplink under a low-privilege account. Then place a file named do-not-open.txt outside the approved directory and attempt access through a test tool. Block one outbound destination and capture the denial. Stop the CLI during a stateful session and observe the interruption, then restart it and observe reconnection and session behavior. Disable the connection from the service side. Verify that the local process can no longer receive remote requests.

The AI runtime security controls guide helps assign host and network controls, plus process controls. Smithery's tunnel does not turn a local subprocess into an LLM request boundary.

Publisher and destination provenance

Registry discovery is a starting point. Approval should resolve the listed server to the artifact or remote endpoint that will run. Record the namespace owner and publisher identity, then identify the repository or package, including the version and digest or commit where available. Add the hosted destination, declared tools, and update mechanism.

Test a change in each mutable element. A moved package tag or redirected remote server should expire the prior approval, as should a growing tool manifest or a namespace changing hands. The matrix needs an explicit response. It can block automatically or hold for review. It can also allow changes within a documented version range. A dashboard badge cannot answer that decision for your environment.

Separate publisher identity from runtime operator. A publisher may own the namespace while Smithery or another host runs the server, Uplink may expose code operated by your own team, and Connect may reach a third-party remote service. Those combinations create different incident contacts and evidence sources.

I think a one-click install is the wrong success metric for production MCP. The useful metric is how quickly the team can identify the exact server bytes or endpoint and its credential. The same record should identify the caller and tool, plus the destination and result after one disputed action.

Acceptance matrix and rollback

One row should cover one Smithery connection in one environment. Include:

• Ownership: current vendor and contract; namespace and publisher; runtime operator and business owner; review date.
• Route: Connect or Uplink; client and Smithery endpoint; remote MCP URL or local command; final destination.
• Credentials: custody and scopes; rotation and revocation; recovery and deletion evidence.
• Token: operations; namespace and metadata constraints; TTL and issuance owner; expiry result and preview-version trigger.
• Tools: manifest version; read or write classification; target authority; approval requirement and denied-action test.
• Host controls: account and filesystem; subprocess and network; resource and patch controls; log controls for Uplink.
• Evidence: caller and connection; tool and arguments classification; source or destination outcome; timestamp and join identifiers.
• Rollback: disable connection; revoke token and credential; stop tunnel; restore prior artifact and verify the withdrawn route stays closed.

Run rollback as a timed exercise. Delete or disable the connection, revoke the token and upstream credential, and stop Uplink where used. Call the old route and preserve every denial in the test record. Restore only the approved version and repeat one permitted read. MCP server authorization patterns provides the adjacent resource-server tests.

DeepInspect

DeepInspect fits beside Smithery only on a distinct authenticated HTTP call from an agent to an LLM that the customer deliberately routes through the proxy. It can evaluate supplied caller identity and prompt classification, as well as the model destination and policy, then preserve the decision for that request and response.

Smithery and Arcade are responsible for their documented services. The MCP server and destination retain tool authority. Your host controls Uplink subprocesses and local data. Keep these evidence streams separate and join them with correlation identifiers where the application supports it. Book a technical deep dive at deepinspect.ai.