Model Context Protocol Security and Audit Logging

Model Context Protocol (MCP) has rapidly become the standard open interface connecting AI systems like Claude, Claude Code, and autonomous coding assistants to internal databases, development environments, and APIs.

While MCP standardises how models discover tools and query data, it fundamentally expands the blast radius of an AI agent. An agent with unrestricted MCP server access can execute code, modify files, trigger remote webhooks, and exfiltrate internal records if tool boundaries and audit trails are not explicitly defined.

Quick answer

Treat every Model Context Protocol (MCP) server as an untrusted client integration. Enforce the principle of least privilege: default all MCP tool bindings to read-only mode, segregate production database connectors from conversational clients, validate all tool parameters before execution, enforce explicit human-in-the-loop approval gates for write or mutating actions, and capture structured JSON audit logs for every tool invocation.

Why this keeps happening

Teams adopt MCP because it solves the context fragmentation problem with minimal setup. Developers and business teams run local stdio or SSE-based MCP servers to let tools like Claude Code query local Git repositories, Jira backlogs, or SQL databases.

However, three distinct vulnerabilities emerge in business environments:

1. Tool Description Poisoning: If an MCP server connects to untrusted external inputs (like customer tickets or public web pages), indirect prompt injections embedded in the data can manipulate the model into invoking sensitive tools with malicious arguments.
2. Excessive Tool Permissions: An MCP database connector often uses a single high-privilege service account instead of scoped, read-only credentials, giving the model the capability to insert, update, or drop tables.
3. Missing Audit Visibility: Default stdio connections output directly to client process terminals without piping invocation payloads, timestamps, or tool arguments to central SIEM or compliance logs.

Fix path

Securing MCP integrations in a UK business requires separating the transport layer, the execution boundary, and the audit trail.

Tool permission boundaries

Never expose generic command execution or raw shell evaluation tools to an agent that processes untrusted text. Restrict tool surfaces to deterministic, parameter-validated endpoints:

• Read-Only by Default: Expose read queries (e.g., get_customer_summary, search_knowledge_base) without write counterparts.
• Strict Parameter Schemas: Validate all incoming tool parameters using strict JSON Schema definitions. Reject unexpected fields, nested shell metacharacters, or path traversal tokens (../).
• Human Approval for State Changes: Require interactive confirmation before executing any tool that mutates records, sends an email, or modifies cloud infrastructure.

Transport and authentication controls

• Local stdio Isolation: For developers using Claude Code or desktop tools, keep MCP servers isolated to local Unix sockets or stdio streams. Do not expose local MCP servers on network interfaces without mutual TLS (mTLS) or bearer tokens.
• Remote MCP Authorization: If hosting shared MCP servers across an internal network, require Bearer token authentication and terminate transport over HTTPS. Ensure each connected agent authenticates with a distinct identity.
• Environment Variable Sandboxing: Never store database passwords or API keys in world-readable client configuration files. Pass credentials securely into the MCP server process via environment variables or secret vaults.

Practical SME workflow

For a UK business introducing MCP-connected assistants, follow a structured four-stage evaluation:

1. Map the Tool Surface: Document every tool name, description, schema, and backend capability exposed by the MCP server before enabling it for staff.
2. Review Descriptions for Ambiguity: Ensure tool descriptions clearly describe what the tool does and what it must never do. Models rely on descriptions to decide which tool to call; vague wording increases misfires.
3. Enforce Two-Person Rule on High-Impact Tools: Any tool capable of transferring financial funds, wiping data, or modifying production code must require human sign-off before completion.
4. Centralise Invocation Logging: Configure the MCP runtime or wrapper to log the calling user, agent identifier, timestamp, tool name, parameters, execution status, and duration to a write-only log repository.

Risk and control

The primary operational risk is unintended side effects resulting from model hallucination or indirect prompt injection.

What good evidence looks like

When demonstrating governed AI tooling for internal compliance, ISO 27001, or client audits, prepare the following evidence:

• MCP Configuration Inventory: A catalog of all approved MCP servers, transport protocols, and target data sources.
• Tool Schema Definitions: Exported JSON schemas demonstrating strict parameter types and input validation rules.
• Audit Log Samples: Redacted log extracts showing timestamp, agent identity, tool invoked, and confirmation that parameter sanitisation occurred.
• Human Review Records: Proof that modifying actions require interactive human authorization before execution proceeds.

Keep the change reversible

Before deploying a new MCP connector into daily workflows, verify that you can instantly revoke tool access without breaking the primary AI client. Test disabling an MCP server in the client configuration, confirm that the model fails gracefully with a notification that the tool is unavailable, and verify that no cached authentication tokens remain in local temporary storage.

The common mistake

The most common mistake is trusting the model to self-regulate its tool usage through system prompt instructions alone. Prompts like "never call the delete tool without asking" can be bypassed by indirect prompt injection or complex multi-step reasoning chains. True security must be enforced by deterministic code gates at the tool execution boundary.

Related field note

To understand how to establish company-wide boundaries for artificial intelligence deployments, read our AI governance guide.

Source basis

• Model Context Protocol Specification: Architecture and Tools
• Anthropic: Introducing the Model Context Protocol
• NCSC: Principles for the Security of Machine Learning and AI