It is not inherently safe, nor is it necessarily dangerous. The controls around the connection are what matter. MCP standardizes exchanges among agents, data, and tools, but it does not automatically limit data scope, remove tool side effects, or replace human approval. A secure deployment must protect host and credential boundaries, workspace scope, capabilities, human approvals, activity records, and recovery together.
“It can connect” and “it may act” are different questions
An MCP server that can list tables and accept queries proves that its transport and protocol work. It does not prove that the connection is read-only, or that the model's selected tool, parameters, and data scope match the user's intent.
The stable MCP specification treats tools as capabilities that may provide arbitrary data access or code execution and calls for explicit user consent, data protection, and tool safety. It also explains that these principles cannot all be enforced by the protocol layer; hosts and integration implementers must build authorization, user interfaces, and access controls.
Security review should therefore cover the entire path, not only whether the server is trusted:
User → Agent host → MCP client → credential → MCP server → tool/data → result and side effects
Excessive scope at any layer can make consent at the preceding layer meaningless.
Five layers of defense, from connection to inspectable evidence
Layer one: Host boundary and credential
First establish where the endpoint is exposed. A server meant only for local use should not bind directly to a public network. A remote server needs transport encryption, authentication, and a clear trust boundary. Tokens must not appear in chats, issues, screenshots, ordinary activity logs, or model context.
The MCP Security Best Practices call out risks including token passthrough, token theft, and confused-deputy attacks. OAuth-based HTTP connections should validate token audience and use PKCE, short-lived tokens, refresh rotation, and secure storage. A local bearer credential should at minimum support rotation, revocation, and expiry, and be shared only with the intended local client.
Acceptance questions:
- Is the endpoint exposed only to the required network boundary?
- Where is the token generated, displayed, stored, and redacted?
- Can it expire, rotate, and be revoked? What ends existing sessions after revocation?
Layer two: Workspace and data scope
Least privilege for data cannot be summarized as “read-only.” An agent that can see every customer, workspace, or schema still exceeds the task's needs even if all its tools only read.
Break scope into three questions:
- Source scope: Expose only the necessary databases, schemas, folders, or materialized tables.
- Work scope: Is the connection fixed to one workspace, or may it select across workspaces?
- Output scope: Which client may receive results, and can they be exported externally?
The first deployment should use test data or a single workspace. If work genuinely spans workspaces, require an explicit selection for each session rather than silently inheriting the last context.
Layer three: Capability and access mode
The same data can be paired with different capabilities: read schema, execute SELECT, create analysis artifacts, export results, modify knowledge, or administer connections. A secure design enforces the capability ceiling outside the model instead of relying on an instruction such as “do not modify anything.”
One useful three-level model is:
| Level | Capability | Suitable setting |
|---|---|---|
| Observe | Read the environment and artifacts | Inventory, low-trust trial, accompanied review |
| Execute | Create analysis artifacts and run the formal workflow | Controlled analysis in one workspace |
| Admin | Execute plus high-trust configuration and organizational operations | Validated agents performing explicitly authorized administration |
The key is a hard capability ceiling. An agent cannot elevate its own permissions through a prompt, Plan state, or its own judgment. OWASP Excessive Agency likewise recommends minimizing extensions, functionality, and permissions to limit damage caused by agent mistakes or manipulation.
Layer four: Human approval and formal evidence
Human-in-the-loop does not mean displaying a button for every SELECT. Excessive, vague confirmations lead to mechanical approval, while too few confirmations allow high-impact actions to occur directly. Approval points should reflect risk:
- Low-risk schema exploration can proceed within the established scope.
- Formal data retrieval used in a report should follow approval of the Plan's question, denominator, time window, and checkpoints.
- Administrative settings, external exports, and irreversible actions need separate confirmation that displays the destination and parameters.
Approval cannot be reduced to “Allow the agent to continue.” Reviewers need to see the upcoming scope, and afterward they need to trace key numbers to SQL or other evidence. Plan approval authorizes a task; it does not elevate connection permissions.
Layer five: Activity, audit, and recovery
A log that says only “Agent completed” cannot support an investigation. Minimum observability includes which connection called which tool in which workspace and when, the policy or approval outcome, affected artifacts, and whether the call succeeded.
Audit must not become a duplicate data leak. Credentials, sensitive full text, and complete results need redaction or separate storage. Recovery must also distinguish types of actions:
- Text-only artifact edits can be reverted safely when their content hash has not diverged.
- Side-effecting queries, exports, permissions, and lifecycle events cannot all be restored by pretending an Undo button reverses reality.
- When an anomaly is detected, operators need to terminate the session, unexpose the endpoint, or revoke the credential.
A pre-launch threat-review table
| Review area | Minimum requirement | Common mistake |
|---|---|---|
| Host | Explicit endpoint boundary | A local test server is accidentally public |
| Credential | Expiry, rotation, revocation, redaction | Token pasted into a prompt or issue |
| Scope | Only the data required for one task | Read-only access to every workspace |
| Capability | Least capability enforced outside the model | System prompt used in place of permissions |
| Approval | High-risk actions show clear approval details | Every dialog says “Allow” without parameters |
| Evidence | Formal results are traceable | Only an agent summary is saved |
| Audit | Tools, policies, and artifacts are recorded | Complete sensitive data is written into logs |
| Recovery | Termination, revocation, and limited rollback | Claiming all side effects can be undone |
If any row lacks an owner, do not connect production data yet. Repeat the review whenever the server, client, or data scope changes; it is not a one-time procurement checklist.
How Lantide Data implements these boundaries
When Lantide Data acts as a local MCP Server, it binds only to 127.0.0.1. A Quick connection generates its credential when exposed and stops displaying it after the user leaves the screen. If it is lost, the user must Unexpose and Expose again to obtain new settings. Persistent connections support expiry, Expose/Unexpose, Rotate, and Revoke. A connection can be restricted to one workspace, and its Observe/Execute/Admin access mode is a hard capability ceiling.
In the Execute workflow, an external agent creates or revises a Plan. It gains the formal execution scope for that Plan only after the user selects Approve & Execute in the GUI. This approval does not upgrade Observe to Execute or Execute to Admin. External MCP Activity records tool calls, policy/review outcomes, and artifact changes. Supported content rollback first compares the after-hash and refuses to overwrite when later changes exist. See the External Agent integration guide and User Guide, section 13 for detailed limits.
The boundaries matter here as well. Lantide's server is a local analysis workspace, not a remote multi-user API. Admin remains a high-trust mode and should not be enabled casually just because Activity is present. Connection, recovery, and client compatibility must be verified for the actual installed version. If you connect an external model, MCP server, or database, review that provider's data-handling and credential policies separately.
Conclusion: prove the need with Observe before adding capability
For a first MCP connection, start with one workspace, test data, a short-lived credential, and Observe. Verify which tools the agent actually needs, whether reviewers understand the approvals, and whether audit can reconstruct events before moving to Execute. Least privilege is not a one-time setting. It is an operating process of proving the need before incrementally granting access.