Engineering field guide

Secure the path from agent to tool.

A defensive baseline for Model Context Protocol integrations that can read sensitive data, execute code, change records, contact external systems, or create business impact.

MCP standardizes connectivity. It does not remove the need to authenticate the actor, authorize the action, validate every input, isolate execution, constrain egress, and preserve evidence.

Reference control path

Resolve identity: Identify the human, application, agent, workflow, model, client, and MCP server involved.
Establish delegated authority: Issue a short-lived, narrowly scoped capability for the exact task.
Verify tool integrity: Confirm approved publisher, server, version, schema, description, dependency set, and integrity value.
Evaluate policy: Consider action, parameters, target, data class, tenant, destination, amount, timing, workflow state, and novelty.
Constrain execution: Validate inputs, isolate processes, limit filesystem and network access, and bound resource consumption.
Require approval: Pause consequential actions until an accountable human reviews sufficient context.
Preserve evidence: Record identity, authority, inputs, tool version, policy, approval, execution, outputs, and downstream effects.

1. Bind every request to identity

A tool call should never be authorized solely because it came from a trusted application or model endpoint.

Preserve the initiating human or service identity across the complete agent and tool chain.
Assign a distinct, stable identity to each production agent and MCP client.
Authenticate the MCP server and verify that the client is authorized to use it.
Reject requests with missing, ambiguous, expired, or unverifiable identity context.

2. Use narrow, short-lived authority

Long-lived API keys and passthrough user tokens allow a compromised agent to become a confused deputy.

Use current standards-based authorization flows appropriate to the deployment, with proof-of-possession protections where supported.
Exchange broad user authority for a tool-specific token limited to the exact action, resource, tenant, and duration.
Keep secrets out of prompts, model-visible memory, tool descriptions, logs, error messages, and untrusted configuration.
Rotate, revoke, and audit credentials independently for each server, agent, environment, and customer boundary.

3. Treat tool metadata as executable input

Descriptions, schemas, examples, and server-provided instructions can influence agent behavior before a tool is called.

Approve and version tool names, descriptions, parameters, examples, schemas, and server instructions.
Cryptographically verify or otherwise integrity-check approved metadata before use.
Alert on drift in tool descriptions, schemas, publisher identity, package dependencies, or transport settings.
Do not allow a server to silently register new tools or broaden existing capabilities in production.

4. Validate inputs at the tool boundary

The model is not an input validator. Every parameter must be treated as untrusted regardless of how confidently it was generated.

Use strict schemas, allowlists, canonicalization, length limits, type validation, and business-rule validation.
Separate data from commands, queries, templates, file paths, shell arguments, interpreters, and code.
Reject path traversal, command injection, query injection, unsafe deserialization, server-side request forgery, and malformed encodings.
Validate downstream responses before returning them to the agent or using them in subsequent tool calls.

5. Isolate execution

Assume that a tool implementation or dependency may eventually be compromised.

Run risky tools in an isolated process, container, sandbox, or ephemeral environment with a minimal base image.
Use read-only filesystems where possible and mount only the files needed for the current task.
Remove unnecessary system capabilities, package managers, interpreters, shell access, metadata services, and host mounts.
Limit CPU, memory, process count, execution time, output size, disk usage, retries, and concurrent operations.

6. Constrain network egress

A compromised tool should not be able to scan internal networks, call arbitrary destinations, or exfiltrate data through redirects.

Allowlist required destinations by service identity, hostname, protocol, port, and expected path where practical.
Resolve and validate redirects, DNS changes, private address ranges, callback URLs, and user-provided endpoints.
Block access to instance metadata, control planes, internal administration interfaces, and unrelated data services.
Inspect or constrain outbound payloads containing sensitive data, credentials, large volumes, or unexpected encodings.

7. Enforce business policy outside the model

Tool availability is not the same as permission to use the tool in every context.

Authorize the exact action, record, tenant, destination, amount, and workflow state before execution.
Set rate, volume, transaction, spend, destination, and aggregate exposure limits outside the agent prompt.
Require human approval for high-value, irreversible, regulated, externally visible, or unusual actions.
Prevent the agent from modifying the policy, approval criteria, evidence requirements, or identity used to evaluate itself.

8. Protect the supply chain

MCP servers inherit risk from packages, images, build systems, registries, update channels, and publisher identities.

Maintain an inventory of server source, packages, images, model dependencies, tool schemas, and build provenance.
Pin versions, verify signatures or checksums, scan dependencies, and review high-risk updates before deployment.
Separate development, test, and production publishers, credentials, registries, and deployment authority.
Monitor for abandoned packages, ownership transfers, typosquatting, dependency confusion, unexpected network calls, and new capabilities.

9. Build a complete action record

Basic request logs are insufficient when an agent chains multiple tools and changes a business system.

Record initiating identity, agent, client, server, model reference, tool and version, parameters, policy result, approval, output, and downstream effect.
Preserve a reference to retrieved content and prior tool results that materially influenced the action.
Protect evidence from alteration, synchronize time, control access, and retain it according to risk and legal requirements.
Detect unusual tools, parameters, destinations, data volume, failures, retries, execution time, and action chains.

10. Test containment before production

The ability to disconnect the entire platform is not an adequate response plan.

Revoke a specific client, server, tool, credential, user delegation, tenant, destination, or action class.
Move affected workflows to read-only, human-approved, or deny-by-default safe mode.
Preserve tool metadata, packages, logs, identity context, prompts, parameters, outputs, and downstream records.
Practice detection, revocation, evidence collection, remediation, validation, and controlled restoration.

Common anti-patterns

“The model decides whether a tool is safe.” Models can supply signals, but authorization must be deterministic and enforceable outside the model.
“The server is internal, so it is trusted.” Internal services, dependencies, metadata, and credentials can still be compromised or misconfigured.
“The user already logged in.” Authentication to the application does not define what the agent may do through every downstream tool.
“We log the chat.” Conversation history alone does not prove identity, authority, policy, approval, execution, or downstream effect.
“We can turn off AI.” Effective containment should isolate the affected action path without creating a full business outage.

Review questions for every MCP server

Who publishes, owns, operates, reviews, and can update this server?
Which agents and users can connect, and how are they authenticated?
Which exact tools and downstream actions are available?
What credentials, data, filesystem paths, network destinations, and processes can the server access?
Where are parameters validated and business rules enforced?
Which actions require human approval, and what evidence does the approver see?
How are metadata, schema, dependency, and version changes detected?
What complete record is generated for each action?
How is a compromised client, tool, server, credential, or destination revoked?
When was the control path last adversarially tested?

Next step

Use the AI Agent Exposure Checklist to assess the surrounding identity, data, approval, evidence, and governance controls. For a focused technical engagement, request an MCP security review.