MCP security best practices: how do we secure local AI tools?

Local inference can reduce external processing when the whole workflow stays within your agreed boundary. It is a sensible choice only if the connected tools also have enforceable, limited permissions. A constrained hosted integration can be safer than a local connector holding an unrestricted administrator credential.

Which MCP security best practices should we apply first?

Start by limiting the server process and the operations it can perform. Model Context Protocol (MCP) connects an assistant to tools and data; the connection still needs an independent decision about each caller's authority.

Use the editable MCP security checklist and test record to review one connector. It separates controls to configure from tests that have actually run.

For a fair local-versus-hosted comparison, hold the tool operations, identities, data and acceptance cases constant. Then compare processing destinations, retention and operating responsibility. Changing both hosting and permission scope would obscure why one configuration performs better.

Which risks change when inference moves locally and which remain in the tools and servers?

Moving inference changes who processes prompts and responses. It does not decide which records a connected tool may read or which actions it may perform.

Map the assistant host, model runtime, retrieval index, MCP server and business application separately. Include logs, backups, administrators and update downloads. A remote tool can still transmit information outside your organisation while the model runs on a workstation.

The OAIC’s AI deployment guidance recognises the privacy benefit of limiting third-party access through local deployment. That supports a narrower processing boundary, not a general security certification. Assess the actual information, organisation and proposed use before drawing a privacy-law conclusion.

Malicious instructions can also arrive in ordinary source material. OWASP describes indirect prompt injection through files and websites. A locally processed document remains capable of influencing a model. Design the connector so that an unsafe suggestion cannot acquire extra authority.

Who starts each MCP server, and what files, network services and credentials can it access?

For stdio, the client starts a subprocess; for HTTP, it connects to an endpoint. The MCP transport overview distinguishes these paths. Establish the HTTP service’s launcher and operating account from its deployment configuration.

Before enabling a local server, record its executable, revision, startup arguments and update owner. Inventory its readable directories, writable locations, network destinations and inherited credentials. An approved tool name does not constrain the executable’s operating-system privileges.

The MCP local-server guidance recommends installation consent and restricted execution. Apply those controls to the actual launcher. A stdio connection does not by itself create a filesystem sandbox.

For a proposed record-lookup service, give its process only the configuration and credentials needed for that service. Keep personal SSH keys, unrelated repositories and production administrator credentials outside its reach. An operator should be able to identify and stop the process without relying on the assistant’s cooperation.

How do identity, consent and token audience remain separate across the assistant, MCP server and business application?

Check who is calling, what they approved, which service accepts their credential and which records they may access. Those are separate decisions.

The MCP authorisation specification covers HTTP-based transports. It requires the target resource in authorisation and token requests, with server validation that a token was issued for that server. The audience is the intended recipient of a token. It does not grant access to every record behind that recipient.

Downstream access needs its own appropriately issued credential. The MCP security guidance forbids token passthrough and requires per-client consent in the OAuth proxy scenario it describes. Do not treat a previous approval for a business application as approval for every assistant client.

In the proposed connector, derive user identity from verified authentication. Reject a model-supplied username as an authority signal. Enforce the user’s record permissions before returning results, including when a broad service account performs the underlying lookup. Prefer a narrower credential where the application supports it.

The HTTP flow does not apply unchanged to stdio, which uses environment credentials. Review that process environment separately. The diagram shows the proposed HTTP pilot only.

Which tool arguments and returned content should be treated as untrusted?

Treat model-generated arguments and externally supplied results as untrusted. This includes instructions embedded in a document returned by an otherwise authorised lookup.

The MCP tools specification requires server-side input validation and access controls. An input schema can constrain the shape of a request; your application still needs to decide whether the caller may perform it.

For the pilot, expose a named read-summary operation with bounded identifiers and result size. Exclude arbitrary SQL, shell execution and unrestricted destination URLs. Enforce the limits on the server; hiding a tool in the interface is insufficient.

OWASP’s output-handling guidance explains the danger of passing generated content directly into shells, database queries or rendered pages. Use parameterised queries and encoding appropriate to the destination. Do not turn a returned instruction into a new trusted command.

A hypothetical document could ask the assistant to export staff records. Even if the model follows that instruction, the connector should reject the forbidden operation. Future write tools would need a separate design for exact-change approval and permission rechecking.

How do we test that a malicious document cannot cause a tool to exceed the user's authority?

Test the enforcement layer directly, then repeat the cases through the assistant. A model refusal alone does not establish an access-control boundary.

Propose a one-week evaluation using one non-production record store, two disposable users with different record grants and synthetic documents. The security engineer owns the test run; the application owner approves expected access. Use an authenticated HTTP MCP endpoint, one search tool and one read-summary tool. Keep production credentials and write operations out of scope.

Inputs should include an ordinary lookup, a document containing hostile instructions and requests for another user’s records. Also try missing, expired and wrong-audience tokens; spoofed identity arguments; access revoked between requests; and unexpected tool names or arguments. If the application uses workflow handles, test a handle issued to the other user. The current MCP guidance says possession of such a handle must not replace authentication.

The output is a sanitised record of each request, expected decision, actual decision and returned content. Acceptance requires useful authorised lookups and denial of every defined forbidden path without restricted content leaking. Repeat the suite after connector, model or permission changes. Passing this finite suite would not prove resistance to every possible attack.

On an ambiguous identity or unavailable permission check, stop that request. Never retry with broader credentials. Any boundary breach stops the pilot. Rollback means disabling the integration, revoking its credentials and stopping the server; staff return to the existing application.

When would a tightly constrained hosted integration be safer than a broadly privileged local one?

Prefer it when external processing is acceptable and its demonstrated controls better match the task. Compare actual permission scope, retained data, operating responsibility and recovery arrangements, rather than the word “local”.

The strongest case for local inference is meaningful: sensitive information can remain on controlled hardware while narrowly scoped tools provide useful access. Choose that route when external processing is unacceptable and your team can maintain the boundary. Conversely, a hosted read-only connector may be preferable to a local process with broad credentials and no dependable owner. These are conditional architectural comparisons; no named vendor has been assessed here.

Budget hardware allocation, power, integration labour, any subscriptions, security maintenance, review and recovery. Cost equals those inputs over the chosen evaluation period. Prices, staff effort and savings remain unknown; model and runtime licences need separate checks once selected.

Proceed only when the chosen system demonstrates bounded authority and acceptable information handling. Otherwise, keep tool access disconnected and use the business application directly. Offline behaviour, residual attack risk, performance and production recovery remain unestablished.