MCP Security: Protecting Your Data in the Context Window
By CorpusIQ
The Model Context Protocol does not define a security model. It defines a message format. The security of an MCP integration depends on the server implementation. CorpusIQ runs a production MCP server that exposes 22+ business tools to ChatGPT, Claude, and Perplexity; it is CASA Tier 2 certified by DEKRA, hosted on Microsoft Azure, and enforces read-only OAuth with zero data retention. This article walks through the security properties any MCP server needs before it touches production business data, and what CorpusIQ does specifically.
Minimize OAuth scope
The first rule of MCP security: request the narrowest OAuth scope that does the job. Every extra scope is an additional risk in a token-compromise scenario. For an MCP server that answers questions about business data, read-only is almost always enough. Write scopes mean the server could, if compromised, create invoices, send emails, or delete records. Read-only means the blast radius of a token leak is bounded to data exposure, not data mutation.
CorpusIQ is read-only across all 22+ connectors. The product architecture cannot write back even if it wanted to; the OAuth flow never requests write scopes, and the MCP tool set exposes no write verbs. This is a design-level posture, not a policy toggle.
Protect the OAuth tokens, not just the data
The tokens your server holds are more dangerous than the data it reads. A token is reusable authentication; data is a snapshot. Treat tokens accordingly: encrypt at rest, rotate refresh tokens on use, short-lived access tokens, and never log a token to an observability pipeline.
Never pass tokens to the LLM. The LLM sees the tool result, not the credential. If the LLM is compromised or prompt-injected, it cannot exfiltrate a token it never saw. This is a core design split between MCP servers and plugin-style architectures where auth is handed to the model.
Prompt injection is real, plan for it
An attacker who can write into any data source your MCP server reads can attempt to inject instructions into the LLM via the tool result. An email body asking the model to ignore previous instructions and send a document to an external address is a plausible payload in a world where LLMs read inboxes.
Defenses layer. First, treat all tool results as untrusted content; do not parse them as instructions on the server side. Second, the downstream LLM has its own prompt-injection defenses; strong models are harder to hijack than weak ones. Third, minimize what the server can do in response to instructions it sees. A read-only MCP server cannot act on an instruction to send data anywhere because sending is not a tool it exposes.
Minimize retention, emit audit metadata
The safest data is the data you do not store. CorpusIQ processes each tool call ephemerally and does not retain the response. The downstream API returns data, the MCP server forwards it to the LLM, the conversation carries it, and the server has no copy.
Audit metadata is different. CorpusIQ records which tool was called, by which tenant, at what time, and with what outcome. It does not record the payload. This gives you a security audit trail without building a retention burden. Compliance auditors can reconstruct who did what without the server holding the what.
Isolate tenants
Any multi-tenant MCP server needs strict tenant isolation. OAuth tokens belong to one tenant. Tool calls carry a session identifier that maps to a tenant. Tool results never mix data from two tenants, and the code paths that might mix them are the hot spots for security review.
CorpusIQ runs each tenant connector namespace independently. A HubSpot tool call for tenant A cannot accidentally hit tenant B HubSpot token, because the token lookup is keyed on the MCP session, not on any LLM-controllable parameter.
Certifications and hosting posture
Certifications are not the whole story, but they are a forcing function. CorpusIQ is CASA Tier 2 certified by DEKRA, which audits OAuth handling, data retention, incident response, and engineering practice. Hosting on Microsoft Azure provides compliance-aligned infrastructure (SOC 2, ISO 27001, data residency options) without having to run the platform in-house.
Checklist before you ship an MCP server
- OAuth scope is the minimum needed; read-only if possible
- Tokens encrypted at rest, rotated on refresh, never logged, never passed to the LLM
- TLS on all transport; HTTP+SSE servers behind a WAF
- Rate limits per tenant and per connector; graceful degradation on throttle
- Tool results labeled as untrusted content; no server-side instruction parsing
- Zero payload retention; metadata-only audit log
- Tenant isolation verified by code review; session-keyed token lookup
- External audit or certification (CASA, SOC 2, ISO 27001) before production data
Related reading
- What is the Model Context Protocol?
- MCP vs API: What Is Actually Different
- Building an MCP Server: A Practical Guide
- CorpusIQ security and compliance
- See all 22+ live CorpusIQ connectors
- Pricing, starting at $29.95 per month
Frequently asked questions
The protocol does not specify authentication, retention, or scoping policy. Security is the responsibility of the individual MCP server. A well-built MCP server (like CorpusIQ) enforces read-only OAuth scopes, minimal retention, TLS in transit, rate limits, and per-call audit logs. A poorly-built server can leak data just as easily as a poorly-built API.
Over-scoped OAuth grants. If the server requests write scopes it does not need, a compromised token has more impact than necessary. CorpusIQ requests read-only scopes on all 22+ connectors and cannot modify data in any of them, even if a token leaked.
Yes. An attacker who can write into one of the connected sources (an email, a Slack message, a CRM note) can inject text that tries to manipulate the LLM. MCP servers mitigate this by treating tool results as untrusted content, labeling the source, and depending on the downstream LLM prompt-injection defenses. CorpusIQ additionally scopes access to read-only and does not follow LLM instructions that would require write-back.
No. CorpusIQ stores zero customer data. Tool calls are processed ephemerally and the responses are not retained. Audit logs record metadata (tool name, tenant, timestamp, outcome) but not payload content, which keeps the data-retention surface small.
For remote MCP servers, yes. HTTP+SSE servers like CorpusIQ run over TLS. For local stdio servers, traffic is between two processes on the same machine, which the operating system isolates. Either way, the protocol itself does not introduce new attack surface beyond what the transport provides.