MCP Server Security: Run AI Agents Without Leaking Secrets

In short

An MCP server should be treated like a privileged production backend, not a harmless AI add-on. It can connect models to files, databases, APIs, internal tools, and credentials, so a weak design can turn prompt injection or excessive permissions into a real infrastructure incident.

The safest architecture keeps secrets outside model context, exposes narrowly scoped tools, validates every action, isolates the MCP service from unrelated workloads, and records sensitive operations for review.

Raff can provide the Linux VM, firewall controls, private networking, backups, and recovery access underneath this architecture. The customer remains responsible for the MCP implementation, tool permissions, application security, secrets, logging, and incident response.

Why MCP servers create a different risk

Traditional APIs expose predetermined endpoints. MCP servers allow an AI system to discover and call tools based on user input and model reasoning.

That creates three linked risks:

1. Prompt injection: untrusted content influences which tool the model calls.
2. Over-privileged tools: one tool can read, write, delete, or administer more than the task requires.
3. Secret exposure: credentials appear in prompts, logs, tool output, files, or environment dumps.

A secure MCP design assumes the model can make a bad decision and limits the damage that decision can cause.

Keep secrets outside model context

Do not place API keys, database passwords, private tokens, or administrator credentials in prompts or tool descriptions.

Use a backend execution layer that retrieves credentials only when an approved tool action is executed. The model should request an operation such as create_support_ticket or read_invoice_status, not receive the raw credential used to perform it.

Also review logs. Debug logging can unintentionally capture headers, environment variables, tool arguments, user data, and full third-party responses.

Use narrow tools instead of broad access

Avoid tools such as:

• run_any_sql
• execute_shell_command
• read_any_file
• call_any_api
• manage_all_users

Prefer task-specific tools such as:

• get_customer_by_id
• create_draft_invoice
• read_deployment_status
• restart_staging_service
• search_approved_documents

Each tool should define allowed inputs, output limits, authorization rules, timeouts, and failure behavior.

Put a policy layer between the model and external systems

A practical architecture is:

User request
    |
    v
AI model
    |
    v
MCP server
    |
    v
Policy and validation layer
    |
    +-- Authentication
    +-- Authorization
    +-- Input validation
    +-- Rate limits
    +-- Approval rules
    +-- Audit logging
    |
    v
Approved API, database, or internal service

The model proposes an action. The policy layer decides whether that action is allowed.

High-impact actions such as deleting data, changing permissions, sending payments, publishing content, or accessing sensitive records should require additional checks or human approval.

Isolate the MCP service

Run production MCP services separately from unrelated applications and development environments.

A stronger deployment normally includes:

• a dedicated VM or isolated service boundary;
• no unnecessary public ports;
• restricted outbound access;
• private connectivity to internal services;
• separate development and production credentials;
• non-administrator service accounts;
• independent logs and monitoring.

Private networking reduces public exposure, but it does not replace authentication or authorization. A private service can still be abused by a compromised internal workload.

Defend against prompt injection

Prompt injection cannot be solved with one system prompt.

Reduce risk by combining:

• strict tool schemas;
• untrusted-content labeling;
• allowlisted actions;
• output validation;
• data-access boundaries;
• human confirmation for destructive operations;
• separate read and write tools;
• monitoring for unusual tool sequences.

Never let content retrieved from a webpage, email, uploaded document, or database record automatically redefine security policy.

Logging without leaking data

Audit logs should answer:

• who initiated the request;
• which tool was called;
• what resource was targeted;
• whether the action was approved;
• when it occurred;
• whether it succeeded;
• which policy rule applied.

Logs should not store raw secrets, unnecessary personal data, full authentication headers, or unrestricted model context.

Backups and recovery still matter

Security controls reduce risk but do not eliminate mistakes. An agent may still modify the wrong record, trigger a faulty integration, or expose an application bug.

Plan:

• database backups;
• versioned configuration;
• snapshots before major changes;
• rollback procedures;
• credential rotation;
• a method to disable tools quickly;
• restore tests for critical systems.

How Raff fits

Raff Linux VMs can host MCP services with root access, NVMe storage, firewall controls, private networking, snapshots, backups, and browser console access.

Raff provides the infrastructure layer. Customers remain responsible for application code, model behavior, MCP tool design, secrets, permissions, monitoring, and compliance decisions.

Review Linux VM, Private Cloud Networks, Security, and Data Protection when designing the environment.

:::cta Explore Security Build stronger boundaries around agents, tools, secrets, and services. :::

Production checklist

Before launching an MCP server, confirm:

• secrets never enter prompts or model-visible output;
• tools are narrowly scoped;
• destructive actions require stronger approval;
• development and production are separated;
• public exposure is minimized;
• outbound network access is restricted;
• logs exclude sensitive values;
• tool usage is auditable;
• credentials can be rotated quickly;
• backups and rollback have been tested.

The central principle is simple: the model should never have more authority than the task requires.