MCP Security in Production: Authentication, Tool Permissions & Data Leakage

Before connecting an MCP server to a production agent, write down what it can read, what it can change and whose authority it uses. A useful review produces evidence for each boundary. A list of exposed tools is an inventory, not proof that the implementation enforces its permissions.

1. Map the connection and trust boundaries

Record the server version, transport, operator, tool names, downstream systems and credential owner. Distinguish a local process from a remote service: a local server can inherit filesystem and environment access, while a remote service introduces network and identity boundaries. Review the actual deployment configuration as well as the source.

The official MCP security guidance addresses token passthrough, proxy consent, SSRF, session hijacking and local server compromise. Use the guidance matching your deployment and protocol version. Tokens intended for another service must not be accepted as MCP access tokens; proxy consent must remain specific to the requesting client. Session identifiers do not replace authentication. Discovery URLs also need network protections against access to internal services.

2. Turn the tool list into an authorization matrix

For each tool, record the permitted actor, tenant, resources, effect and approval policy. Verify these rules at execution time. A tool name such as read_customer does not prove that it is read-only, and an annotation saying an operation is harmless does not constrain its implementation.

Tool: create_booking
Actor: authenticated scheduling user
Resource: calendar owned by the current tenant
Inputs: permitted calendar ID, start time, contact ID
Effect: one booking, with a durable operation ID
Approval: required when the agreed workflow calls for it
Evidence: booking receipt plus a read-back from the calendar

Attempt a request for another tenant’s resource in a test environment. The server should reject it even if the model supplies a valid-looking ID. Repeat for expired credentials, revoked access and a user whose role changed after the conversation began.

3. Inspect parameters and business rules

• Check types, required fields, length limits and rejection of unexpected parameters.
• Validate resource ownership independently of supplied tenant or user IDs.
• Constrain file paths, destinations and query capabilities to the intended operation.
• Test malformed inputs and valid inputs that violate business rules, such as an unavailable calendar slot.

A schema can reject the wrong type without rejecting the wrong customer. Keep shape validation, authorization and business validation separate in the evidence you collect.

4. Exercise untrusted descriptions and tool results

Create synthetic fixtures where a retrieved document or tool response asks the agent to export contacts or ignore its task. The expected result is no unauthorized action. Test the full agent and its execution boundary, rather than only checking whether a keyword detector recognizes the fixture. Repeat after tool-description changes.

Prompt instructions can guide behavior, but sensitive operations also need application-enforced permissions. Where approval is required, bind it to the exact action and parameters; changing the destination or payload should invalidate that approval.

5. Check data leakage and destructive actions

Use synthetic secret markers and inspect tool output, user-visible responses, exceptions and telemetry. A redacted UI can still leak through a trace exporter. Review what gets retained and who can read it. For deletion or other irreversible effects, test the refusal and approval paths with mock resources before exercising a sandbox integration.

6. Test failure recovery and record evidence

Inject an API timeout after a simulated successful write. The agent should report an uncertain outcome and reconcile it using the operation identity, rather than blindly issuing another write. Also inject an explicit rejection: a conversational success response is a failed test when no effect occurred.

• Capture the fixture, server revision, actor permissions and expected effect.
• Record actual calls, redacted results and final persisted state.
• Assign each finding an owner, reproduction procedure and retest criterion.
• Mark untested controls as unknown; do not turn missing evidence into a clean bill of health.

The agent testing guide shows how to turn these cases into repeatable checks. VenueX AI provides context for the scheduling and multi-channel workflow examples; the fixtures here are illustrative, not a disclosure of that system’s internals.

Need a review before connecting customer systems?

My AI Agent Testing & Production Readiness service covers tool behavior, permissions, failure recovery and regression coverage. Start with the integrations and actions you need reviewed, then agree the evidence required for launch.