MCP Security: minimum permissions for an AI to manage a VPS

Published on 2026-10-26 by frfrand

Design secure MCP tools with scopes, approvals, and auditing

An AI can help you deploy an app, but giving it admin access to all VPSs just to check a log is like handing out the master key to the building. The problem isn't that it's an AI; it's excessive permissions and scope.

Let's get down to earth: what it means, how to test it, and what happens when you use it with clients or real information. Most problems aren't fixed with a magic button, but with steps you can repeat and measure.

What Minimum Permissions for MCP Are and Why They Matter

A secure MCP integration needs authentication, server-side authorization, scoped actions, and auditing. Parameters supplied by a model or external text must not be considered trustworthy: the backend must validate permissions for every resource and operation.

One thing is for a demo to work for five minutes; another is to sustain a service every day. For that you need limits, permissions, activity logs, and procedures to resolve failures without improvising.

Implementation or Diagnosis Example

// Ejemplo conceptual de autorización
function canRestart(user, vps, service) {
  return user.companyId === vps.companyId
    && user.permissions.includes('service.restart')
    && service.vpsId === vps.id;
}
// La verificación real debe ocurrir en el backend

It is a didactic reference, not a template you should blindly run in production. Replace the example values, choose identities with minimum permissions, and make sure no sensitive key ends up in a log or repository.

How I Would Put It to Work

1. Start with query permissions; expand only when a real task requires it.
2. Separate logs.read, deploy.create, service.restart and vps.delete into distinct capabilities.
3. Verify that a Company A user cannot query Company B IDs.
4. Log every action and protect tokens with expiration and revocation.
5. Require human review for deletions, access changes, or irreversible modifications.

After each step, verify a concrete result: an authorized action, an HTTP status, a processed task, a recorded cost, or an established metric. If something does not work, check what the first failure was before retrying in a loop.

An example that may appear in a real project

A freelancer manages the servers of two clients. An agent preparing a deploy for client A should not be able to arbitrarily select client B's VPS ID. The server must check ownership and permissions on every call.

If that application has multiple clients, separate contexts and resources. It is especially important when a chatbot or an agent can query data: the ease of connecting tools must not bypass privacy and authorization limits.

The most common error

Do not trust a prompt instruction as a security barrier. Malicious text within logs or documentation may attempt to induce dangerous calls; rules must be on the server side.

A configuration with good defaults helps, but does not eliminate the need for testing. For services that write data or trigger actions, consider retries, duplicates, and mid-process failures.

Where does ArduMaker fit in?

ArduMaker organizes Companies, projects, and VPS. In MCP flows, take advantage of that separation with scopes and action logs so as not to give the agent more authority than necessary.

With ArduMaker you can host the backend on a VPS, deploy from Git, configure an HTTPS domain, and use database, service, and MCP tools according to the project. This makes it easier to bring operations together in one environment, although business and security rules remain the responsibility of the software.

What I would measure to know if it improved

I would not measure only "works/doesn't work." I would also review resource consumption, errors, response times, or API spending, depending on the functionality. Define a success metric before the change and compare it with the same scenario afterward.

If a piece of data seems strange, check the sample and the time window. An average can hide extreme cases, and a single successful execution does not prove that an automation can handle thousands of requests.

Frequently asked questions

Do I need a large infrastructure to get started? Not necessarily. First solve the problem with a simple architecture and measure the point where it starts to fall short.

What happens if the external provider fails? You need timeouts, a retry policy, and a useful response for the user. Do not assume external APIs are always available.

How do I maintain control? Log important events, separate permissions, and keep a proven procedure to undo changes or recover information.

References to follow

• Technical documentation
• Related ArduMaker guide
• ArduMaker tools and documentation

The final idea: automating and measuring is worth it when you also know how to detect an error, limit its effects, and recover.