How to Audit an MCP Server Before Installing It at Your Company

How to Audit an MCP Server Before Installing It at Your Company

To audit a third-party MCP server, confirm who maintains it and where the code comes from, list what it can read and execute, find out what data leaves your environment, and decide who reviews each update. Only then install it, first in an isolated environment with least-privilege credentials. An MCP server gives an AI agent the ability to act on real systems, so the review should look more like the one you would run for software that touches company data than for an ordinary plugin.

Key takeaways

• Origin: prefer identifiable maintainers, open source code you can read, and a public maintenance history.
• Permissions: every exposed tool is a possible action. Keep only what the workflow needs, with read-only access wherever that is enough.
• Data: map what enters the model's context and what the server sends to external services, including logs and telemetry.
• Updates: pin versions, read the changes before approving them, and keep a rollback path.
• Pilot: test one real workflow, with call logging and a stop condition, before expanding use.

What is an MCP server, and why does it need its own audit?

The Model Context Protocol (MCP) is an open standard for connecting AI applications to tools and data sources. In practice, an MCP server is a program that exposes tools (actions the agent can call), resources (data it can read) and sometimes ready-made prompts. The AI client reads the descriptions of those tools, and the model decides when to use them.

That changes the risk. A traditional connector does only what it was programmed to do, in the order it was programmed. With MCP, a model decides the call, based on text that may come from untrusted sources: an incoming email, a web page, a customer message on WhatsApp. The server also runs with whatever credentials you hand it. If it runs on an employee's machine, it inherits that machine's access. If it runs somewhere else, your data goes there.

For that reason the audit covers four areas: origin, permissions, data and updates. It also helps to separate three things in your report: what the project documents, what you verified (read in the code or tested), and what is only a hypothesis. Whoever approves the installation needs to know the difference between a vendor's claim and your own evidence.

Origin: who maintains it and where does the code come from?

The review starts before you download anything. Answer these questions and keep the answers:

• Who is the maintainer? Prefer a company or person you can identify, with a track record on other projects and a channel for reporting security issues.
• Is the repository open, and does the published package match it? Compare what the package manager installs with the code you read.
• Is there ongoing maintenance, with open issues being handled and releases that come with change notes?
• Is the package name the official one? Names that closely resemble well-known projects are a common way to distribute malicious code.
• Which dependencies does it pull in? A small server with many dependencies widens the attack surface.
• Does the license allow commercial use in your company?

If the server comes from the maker of the system you want to connect, trust tends to be higher, but the remaining steps still apply. If it is an unmaintained solo project, treat it as untrusted code: either you read the parts that matter, or you do not install it.

You do not need to review every line. Focus on four points: how authentication is handled, where secrets are stored, which network calls the code makes, and whether it executes operating system commands. Calls to domains the documentation does not mention, and reads of environment variables beyond what is needed, are signals to stop and ask questions.

Permissions: what can the server do with the access you give it?

Build an inventory of tools. For each one, note the name, description, parameters and effect: read, write, delete or send outside. Then classify each tool with a simple decision guide:

• Reading non-sensitive data: can be approved after the pilot.
• Reading personal or financial data: approve only with a defined purpose and a record of every access.
• Reversible writes, such as creating a draft or opening a ticket: approve with logging and the ability to undo.
• Irreversible writes or actions with external effects, such as sending a message, making a payment or deleting records: require human approval on every call, or do not approve.
• Command execution or broad file system access: deny by default and allow only inside a sandbox.

The authorization principle is the same as for any system: deny by default and grant the least privilege possible, as the OWASP authorization guidance describes. In practice, create a service account dedicated to the server, never an employee's personal account. If the server uses OAuth, review the scopes it requests and refuse any that do not match the tools you will actually use.

Disable the tools the workflow does not need, when the client lets you restrict the list. On the client side, permission and isolation rules are the second layer of defense. It is worth reading the guide on Claude Code security: permissions, sandbox and secrets for teams and defining an approval policy for AI agents for the actions that must never happen without a person.

What data moves, and where does it go?

Draw the data path in three segments: from your system to the server, from the server to the model (what enters the context), and from the server to third parties (external APIs, telemetry, logs, analytics services). The second segment is often forgotten: everything a tool returns becomes part of what the model reads and, depending on the client, may continue on to an AI provider.

To verify rather than assume, run the server in a test environment with network monitoring and compare the destinations it contacts with what the documentation declares. Any unexplained destination is an open item in the audit.

If the server is hosted by a third party, that vendor starts receiving your data. Read the privacy policy and ask in writing about retention, subprocessors, storage location and whether the data is used for other purposes. Record the answers.

If personal data is involved, Brazil's LGPD comes into play: defined purpose, legal basis, minimization, and a record of who accessed what. Customer data arriving through WhatsApp, such as name, phone number and conversation content, is a common example. The article on LGPD compliance for AI on WhatsApp: legal basis, consent and records covers this part in detail. The practical rule is to send the server only the fields it needs, for example a database view without personal documents, instead of the full table.

How to test safely: an isolated environment and prompt injection

Once origin, permissions and data are mapped, set up the test. This is an execution plan, in order:

• Create a separate environment with no real data, using fictional data that resembles the real thing.
• Use disposable credentials with the narrowest scope possible.
• Turn on logging for every call: tool, parameters, response and who approved it.
• Read the tool descriptions as if they were instructions to the model. Look for text that tells it to ignore rules, call another tool or send information somewhere.
• Simulate hostile content: place a hidden instruction in a test document or message and watch whether the agent tries to act outside the agreed scope.
• Trigger errors on purpose and check whether the returned messages expose secrets, internal paths or infrastructure details.
• At the end, revoke the test credentials and keep the logs as evidence.

The reason for the hostile content step is prompt injection. OWASP describes how input text can change a model's behavior, and the result returned by a tool is also input. Filters help, but they do not solve the problem alone. The most reliable defense is to limit what the agent can do when it is fooled: few tools, read-only access where possible, and human approval for external effects.

Updates: how do you keep a new version from changing the risk?

A server approved today may behave differently in its next version. Treat every update as a new risk change:

• Pin the exact version and, when possible, the commit identifier or package hash. Avoid automatically installing the latest version every time.
• Read the change notes and the diff before updating. Focus on new tools, new scopes, new dependencies and new network destinations.
• Re-approve whenever a tool, a scope or a data destination changes, even in a small release.
• Name an owner and a periodic review routine. Without an owner, the server gets forgotten with its access still active.
• Have a rollback plan and a fast shutdown plan, including revoking the credentials.
• For a vendor-hosted server, you do not control the version. Require advance notice of changes, or accept that the risk is ongoing and compensate with call monitoring.

This is also where monitoring pays for itself. The logs from the test period become your baseline: if an update starts calling tools or destinations that never appeared before, the difference is visible.

Illustrative scenario and how we apply the method

Illustrative scenario: a distributor wants an agent to check order status in its ERP through an open source MCP server found in a public repository. The maintainer is an individual with no other known projects, and the repository has not been updated in a long time. Reading the code shows two order lookup tools and a third that runs free-form SQL. The team decides not to use the server as it is: it removes the free-form SQL tool in its own copy, pins the version, creates a read-only database user on a view that omits personal documents, and runs the pilot with call logging. If maintaining the copy looks too heavy, the alternative is to write a small server of their own with just the two lookups.

The method we apply to this kind of work has four moves. Map: inventory the tools, the data and the current process, with a baseline of how the work is done today. Limit: reduce permissions, fields and actions to the minimum the workflow needs. Pilot: run one real workflow, with logs and a success metric agreed in advance, as described in the piece on how to measure an AI automation pilot. Hand over: document what was decided, name the owner, and decide whether use will be expanded, adjusted or ended.

Frequently asked questions

Does an official MCP server from the vendor make the audit unnecessary? No, but it simplifies it. The origin tends to be clearer, but you still need to review permissions, the data sent and the update policy. An official server may expose more tools than your workflow needs.

Is a local MCP server safer than a remote one? It depends on what each one does. A local server keeps data on your machine or network, but it runs with the access of whoever started it and can contact the internet on its own. A remote server hands data to another environment, which calls for a review of the contract, retention and privacy terms. In both cases, reviewing permissions and network destinations is still necessary.

Who in the company should approve the installation? Ideally the decision is shared between the owner of the process, whoever is accountable for security and, if personal data is involved, whoever handles data protection compliance. One person should be the named owner of the server after approval. Without that assignment, updates and credential revocations have no owner.

How often should I re-audit? Re-audit whenever a tool, scope, dependency or data destination changes, and on a periodic routine set by your company. If the server is vendor-hosted and changes without notice, compensate with more frequent reviews of the call logs.

Sources

• Model Context Protocol: introdução
• OWASP Top 10 for LLM Applications
• OWASP: prevenção de prompt injection
• OWASP: guia de autorização