How to secure MCP servers for cloud AI agents
Model Context Protocol (MCP) makes it easier to connect an AI agent to business tools, data stores, and services. That convenience changes the security boundary. A chat request can now reach a file system, CRM, ticket queue, cloud API, or deployment pipeline through a tool call. If the connection is too broad, a bad instruction can become a real action.
The practical goal is not to make every agent harmless. An agent that cannot act is not very useful. The goal is to limit what each connection can do, make sensitive actions deliberate, and leave enough evidence to explain what happened later. This guide lays out a deployment pattern for teams running MCP servers behind cloud AI agents.
Start with the trust boundary
An MCP server sits between a model-facing client and a real system. Treat it as an application gateway, not a thin adapter. It parses requests, exposes tools, handles credentials, and returns data that the model may use in its next decision. Each of those steps deserves its own controls.
Draw the boundary before you write policy. List the client, MCP server, identity provider, downstream APIs, secret store, logs, approval service, and any queue or worker that performs actions. Mark which connections cross an account, network, or tenant boundary. This simple diagram usually exposes the first problems: shared credentials, direct internet access, or one server serving unrelated teams with the same permissions.
The MCP authorization specification uses established OAuth patterns for HTTP transports. Follow the current specification rather than inventing a custom token exchange. Authentication proves who is calling. Authorization still has to decide what that caller can do.
Use one identity per workload
Do not give several agents a shared API key. Give each deployed workload its own service identity, then bind that identity to a narrow tool set. A customer support agent might read account status and create a ticket. It should not inherit the billing team’s refund permission because both agents use the same CRM.
Short-lived credentials are easier to contain than static secrets. Keep refresh tokens and downstream credentials in a secret manager, not in prompts, tool descriptions, environment dumps, or model-visible logs. Rotate credentials on a schedule and immediately after a suspected leak. If a server serves several tenants, require a tenant identifier from trusted identity context rather than from free-form model input.
Design tools around minimum capability
Tool design is where least privilege becomes concrete. Avoid a generic tool such as run_command, call_api, or execute_sql unless the environment is heavily sandboxed. Prefer small operations with typed fields: get_order_status, create_support_ticket, or restart_staging_service. The server can validate these requests before anything reaches the downstream system.
Keep read and write operations separate. A tool that retrieves a record should not silently update it. For writes, use allowlists for resource types, destinations, file paths, and permissible state transitions. Put hard limits on batch size, request frequency, data volume, and execution time. These limits protect against mistakes as well as hostile instructions.
| Control | Weak implementation | Safer implementation | What to verify |
|---|---|---|---|
| Identity | One shared key | Identity per agent workload | Credential cannot access another workload |
| Tool scope | Generic command execution | Small typed operations | Unknown fields and actions are rejected |
| Write access | Immediate execution | Policy check and approval for sensitive actions | Approver sees exact action and target |
| Network | Open outbound access | Destination allowlist through an egress proxy | Unlisted hosts cannot be reached |
| Logging | Full prompts and secrets | Structured events with redaction | Events support investigation without exposing credentials |
Do not trust tool output
Prompt injection does not have to come from the user. It can arrive in a document, web page, issue comment, email, database field, or tool response. The model may treat untrusted content as a new instruction unless the surrounding system keeps data and authority separate.
Label tool results as untrusted data in the agent orchestration layer. Do not let returned text grant permissions, change policy, reveal secrets, or choose a new tool endpoint. Validate structured responses against a schema, cap their size, and remove active content that the next component does not need. For retrieval tools, keep the source URL or record ID so reviewers can trace a claim back to its origin.
This is also why human approval must show the proposed action, not a vague message such as “continue?” A useful approval screen includes the tool name, target, changed fields, side effects, and expiration time. The agent should not be able to alter the action after approval.
Add a policy gate before side effects
Put a deterministic policy check between the model’s tool request and the executor. The check should use trusted attributes: workload identity, user role, tenant, environment, tool name, resource, requested operation, and current risk level. The model may explain why it wants an action, but its explanation should not decide authorization.
Low-risk reads can run automatically. Reversible changes may run within a small scope. External messages, production changes, deletion, payments, credential updates, and bulk exports usually need stronger approval. Deny requests when required context is missing. A fail-open policy turns a temporary identity or policy outage into an access-control failure.
Contain the runtime
Assume a tool implementation will eventually contain a bug. Run the MCP server with a non-root account, a read-only base file system, limited temporary storage, and no host socket access. Apply CPU, memory, process, and request limits. If a tool needs code execution, isolate each job in an ephemeral sandbox with a fixed timeout and no inherited credentials.
Control outbound traffic. Many incidents become worse because a compromised process can call any internet host. Route traffic through an egress proxy, allow only known API destinations, resolve DNS through a controlled service, and block cloud metadata endpoints. Separate development, staging, and production servers so a test agent cannot discover production credentials or tools.
Log decisions without logging secrets
Record a structured event for every tool request: timestamp, request ID, workload identity, user or initiating job, server and tool version, tool name, normalized target, policy result, approval reference, execution result, latency, and error class. Link the events across the agent, gateway, MCP server, and downstream API with one correlation ID.
Do not dump credentials, authorization headers, raw tokens, or unrestricted prompt content into logs. Redact sensitive fields before storage and restrict who can query the audit trail. Define retention based on investigation and compliance needs. Test that operators can reconstruct an action from the event record without reading secrets.
NIST’s Generative AI Profile provides a broader risk-management frame for generative AI systems. The OWASP Agentic AI threats and mitigations material is useful when turning threat scenarios into tests. Neither replaces a system-specific threat model.
Test the failure paths
A normal demo proves only that the happy path works. Security testing should try to cross boundaries. Send malformed tool arguments, oversized content, encoded path traversal, unexpected redirects, stale tokens, cross-tenant identifiers, prompt injection inside tool results, and requests that change after approval. Confirm that the server rejects each case and produces a useful audit event.
Run revocation drills. Disable one workload identity and measure how quickly access stops across caches and downstream services. Simulate a policy service outage and confirm that sensitive writes fail closed. Restore from a clean server image. These exercises expose hidden dependencies before an incident does.
A practical rollout sequence
- Inventory every MCP server, exposed tool, downstream system, credential, and owner.
- Split shared servers or identities where teams, tenants, or environments have different permissions.
- Replace broad tools with typed operations and explicit limits.
- Add deterministic authorization and approval rules before writes.
- Sandbox execution and restrict outbound network access.
- Introduce structured, redacted audit events with correlation IDs.
- Test injection, isolation, revocation, and service-outage scenarios before production access.
- Review permissions and unused tools on a recurring schedule.
Start with one workflow that has a clear owner and reversible actions. Measure denied requests, approval frequency, tool errors, and time saved. If people routinely approve requests without reading them, narrow the workflow or improve the approval detail before expanding access.
Frequently asked questions
Does MCP make an AI agent less secure?
MCP does not automatically make an agent insecure. It gives the agent a consistent way to reach tools, which makes access design more important. Security depends on identity, permissions, tool design, isolation, validation, and monitoring around the server.
Should every tool call require human approval?
No. Requiring approval for routine reads creates fatigue. Reserve approval for actions with meaningful side effects or high data sensitivity. Use policy to automate low-risk requests within narrow limits.
Can one MCP server support several tenants?
It can, but tenant context must come from trusted identity data and be enforced on every operation. Separate servers or worker pools may be safer when tenants need different network paths, credentials, retention rules, or compliance controls.
Where should MCP credentials be stored?
Store them in a managed secret system and inject them only into the component that needs them. Do not place secrets in prompts, tool descriptions, source repositories, or model-visible logs. Prefer short-lived tokens over static keys.
What should an MCP audit log contain?
Capture the caller identity, tool, normalized target, policy decision, approval reference, result, timing, and correlation ID. Redact credentials and sensitive payload fields before the event reaches storage.
Build useful agents with a smaller blast radius
A secure MCP deployment is not one product or checkbox. It is a chain of small controls: narrow identities, limited tools, deterministic policy, runtime containment, careful approvals, and useful evidence. If one layer fails, the next layer should still limit the damage.
SmaugBrain helps teams run cloud AI agent workflows with explicit tools and operational controls. Explore SmaugBrain to plan an agent workflow that can act without receiving blanket access to your systems.