The Model Context Protocol provides a more consistent way to connect AI applications, data and tools. That convenience does not determine which operations are safe: an MCP server runs tools with the permissions actually available in its environment. If it is given administrative credentials, broad filesystem access and an unrestricted network, the exposed tools give the assistant a far wider scope of action than its task requires.
MCP grants capabilities, not merely a connection
In an MCP architecture, the host coordinates one or more clients that communicate with servers capable of exposing resources, prompts and tools. Tools may query a data store, read files, create a ticket, send a message or modify a record. Connecting a server therefore means deciding which actions fall within the assistant’s operational scope.
The specification recommends keeping a person in the loop, allowing them to deny tool invocations and clearly showing them sensitive operations. The approval interface matters, but it follows a more fundamental choice: neither the server nor its technical identity should possess capabilities that are unnecessary for the stated purpose.
When a configuration becomes unnecessarily dangerous
A fragile configuration uses an operator’s personal or administrative account, broad scopes, generic tools such as SQL or shell execution, read and write access on the same server, and disabled approvals. If the local process runs with all of the user’s privileges and has unrestricted access to the network and filesystem, every mistake or hostile instruction has a disproportionate blast radius.
The problem is not limited to explicitly malicious actions. The model may select the wrong tool, misinterpret an objective, repeat a non-idempotent request or combine two capabilities that seemed harmless in isolation. Without limits enforced outside the model, a phrase in the prompt such as “never modify the data” remains a preference, not a security control.
Least privilege: grant only what is required
The configuration should start with an identity dedicated to the server or delegated to the user, never a shared personal or administrative account, together with revocable credentials, short-lived tokens, minimal scopes and an allowlist containing only the required tools. Access can be limited to specific tenants, views, tables, directories or document sets. If the use case requires analysis, a sensible starting point is a read-only credential over minimised data.
Reading and writing should remain separate even when they belong to the same process. The reader may query a view, replica or controlled snapshot; the writer exposes narrowly scoped domain actions with a precise schema and deterministic validation instead of generic commands. Privileges are elevated only when the operation requires them and the user approves the actual target and parameters.
Read-only access protects integrity, but does not address every risk
A genuinely read-only credential reduces the risk of modifying or deleting the data source, but it may still read excessive information. It may also run expensive queries or transfer results to another tool. Field minimisation, row-level filters, record limits, timeouts, rate limits and outbound network controls protect confidentiality and availability as well as integrity.
MCP annotations such as readOnlyHint, destructiveHint, idempotentHint and openWorldHint are useful descriptions, not a sandbox. An untrusted server may declare them incorrectly, and a client may not enforce any policy. The read-only guarantee must exist in the credential, OAuth scopes, API or database permissions, filesystem and runtime.
Data being read may itself contain hostile instructions
Documents, emails, web pages and results returned by tools are untrusted data. Content may attempt to persuade the model to ignore its objective, retrieve confidential information or invoke another tool. This is indirect prompt injection; it does not disappear merely because the server that read the document was authorised.
Where possible, extract structured fields instead of passing raw content, separate internal sources from open content, and technically prevent the most dangerous combinations. Authorisation, input validation, minimisation, treating outputs as untrusted data and decisions about permitted actions must live in code and policy, not in the model’s interpretation.
Approvals and audit records must describe the actual action
A generic confirmation granted at the start of a session is not approval for every subsequent effect. For writes, external messages, sensitive exports and irreversible operations, the person should see the tool, destination and parameters that will be used. The approver must be able to stop the action without losing the context needed to decide.
Useful logs record the actor, server build or version and, where available, the version or hash of the tool definition, together with the timestamp, correlation ID, decision, outcome and error. Tokens, cookies, secrets and unnecessary personal data must not enter the logs; identifiers required for audit purposes should be minimised and protected through appropriate access controls and retention periods. Audit records support investigation and improvement, but do not replace preventive controls: knowing who deleted a record is less effective than preventing the reader from being able to delete it.
A practical pattern: separate collection from presentation
For an analytics dashboard, a prudent approach is to use official APIs with read-only credentials, collect data outside the web process, validate and minimise it, and then install a canonical snapshot that the interface can only read. If an MCP assistant were later asked to analyse those metrics, it could query the snapshot rather than the original sources.
Future actions involving CRM records, tickets or campaigns should be exposed on a separate plane, with separate credentials, specific tools, approval and traceability. This separation reduces risk and makes the system easier to understand: first observe, then propose, and finally let an authorised person approve any change.