Most teams deploying MCP servers think about what the AI can access. Fewer think about who else can access it. A recent piece in The Hacker News documented exactly how MCP servers leak enterprise secrets — and the pattern is almost always the same: a server stood up quickly, connected to real company data, and left open in ways no one intended.
This post covers the concrete architecture decisions that separate a secure MCP deployment from a liability.
What makes MCP server security different from ordinary API security
An MCP server is a standardized interface that lets AI agents — Claude, ChatGPT, Cursor, Codex — query and act on external data sources. Connect one to Slack, Notion, or Salesforce and the agent can pull real company context on demand.
The security problem is structural. Traditional API security assumes a human on one end making deliberate requests. MCP servers talk to autonomous agents that plan their own queries, chain tool calls together, and operate without a human reviewing each step. As Sysdig's CISO in Residence noted, this shifts the security model from static boundaries and human behavior to dynamic, credentialed non-human identities — a category most enterprise security tooling was never designed for.
The practical consequence: a misconfigured MCP server does not wait for a human to make a mistake. An agent with overly broad permissions will query everything it can reach, and it will do so at machine speed.
Bitsight's research on exposed MCP servers found publicly reachable MCP instances with no authentication at all — connected to internal tooling, databases, and communication systems. The question their headline asks is worth sitting with: at 2 AM, do you know which AIs your MCP server is talking to?
The four failure modes that expose company data
Most MCP security incidents trace back to one of four architectural mistakes.
No authentication on the transport layer. An MCP server running over plain HTTP with no token validation is reachable by anyone who can find the endpoint. Tyk's enterprise security guide documents a CVSS 9.4 critical vulnerability in Anthropic's own MCP Inspector tool — attackers could execute arbitrary code on developer machines just by getting them to visit a malicious URL. If the tooling from the protocol's creator ships with critical vulnerabilities, assuming your own server is safe by default is not a reasonable posture.
Flat permissions across all data. Many teams connect an MCP server to a data source using admin credentials because it is the path of least resistance. The agent then has access to everything in that source — HR records, financial data, confidential deal terms — regardless of what the actual query needed. This is the enterprise secrets leak pattern The Hacker News described.
No audit trail. Agents make many tool calls per session. Without logging what was queried, when, and by which agent or user, there is no way to detect anomalous access or satisfy a compliance audit after the fact.
Prompt injection via retrieved content. An agent that reads documents or messages can be manipulated by content embedded in those documents. A malicious instruction inside a Notion page or a Slack message can redirect the agent's behavior mid-session. Palo Alto Networks' security analysis identifies this as one of the primary attack vectors in agentic MCP deployments.
What a secure MCP architecture actually looks like
Security here is not a single control — it is a stack of decisions that each reduce blast radius.
Authentication and transport
Every MCP server exposed beyond localhost needs mutual authentication. OAuth 2.0 with short-lived tokens is the current standard for remote servers. HTTPS is table stakes; it does not replace token validation. The DBASolved guide on enterprise MCP security makes the point directly: HTTPS encrypts the channel, but it tells you nothing about whether the client on the other end should have access.
For local MCP servers (running on a developer's machine), the transport is stdio, which limits exposure — but the risk shifts to what credentials are stored in the server's configuration and who else can read that machine.
Scoped, least-privilege permissions
Each MCP server should connect to its data source with the minimum permissions the intended use case requires. If the agent's job is to answer questions about open support tickets, it does not need read access to financial records or HR data.
This means resisting the temptation to use a single admin service account for all MCP connections. Separate credentials, scoped to specific data, make it possible to revoke access to one domain without affecting others — and make audit logs meaningful.
User-level permission propagation
The harder problem is ensuring that the AI agent respects the same access controls the human user has. If a sales rep asks an AI agent a question, the agent should only surface data that sales rep is authorized to see — not everything the MCP server's service account can reach.
This requires the MCP server to propagate the requesting user's identity into its data queries, not just authenticate the agent itself. It is the difference between "this agent is authorized" and "this agent is authorized to act on behalf of this specific user, with this user's permissions."
Logging and anomaly detection
Every tool call an agent makes through an MCP server should be logged: which tool, which user or agent session, what parameters, what was returned. This is what makes it possible to answer "did anything access the Q3 board materials last night" after the fact.
Proofpoint's MCP security platform frames this as unified MCP discovery, authorization, and monitoring — the point being that you cannot monitor what you have not inventoried. Many teams do not have a complete list of the MCP servers running in their environment.
Prompt injection mitigations
Retrieved content should be treated as untrusted input. Architecturally, this means separating the channel through which instructions arrive (the system prompt, the user turn) from the channel through which retrieved data arrives (tool results). Agents that blur these boundaries — treating document content as potential instructions — are vulnerable to injection attacks embedded in the data they read.
How Gyld approaches this by design
The security concerns above are real, and they are also solvable at the architecture level. The reason many teams run into them is that they build MCP servers quickly, connecting whatever credentials are at hand, without a permission model designed for multi-user, multi-sensitivity-level company data.
Gyld's approach starts from the opposite direction. When a company connects Slack, Gmail, Notion, HubSpot, or Salesforce, the owner chooses exactly what gets indexed — nothing is ingested without explicit selection. Knowledge is permissioned at three levels: private (only the person who added it), team, and company-wide. When an AI agent queries through Gyld's MCP server, it gets back only what the requesting user is authorized to see, with the source document cited.
That source citation matters for security as well as transparency. When an agent tells you something, you can see exactly where it came from — which makes it possible to spot if the answer drew on data it should not have reached.
There is no fine-tuned model to protect, no hand-built RAG pipeline to audit separately. The knowledge base stays current as the connected apps update, and the permission model travels with the data. You can read more about how this compares to building your own pipeline in the Gyld vs RAG comparison and the broader context layer overview.
For teams evaluating whether to build or buy the MCP layer, the build path means owning all of the security decisions above. The managed path means those decisions are made once, at the infrastructure level, for every team that uses it.
The practical checklist
Before putting any MCP server in front of real company data:
- Inventory every MCP server running in your environment, including local developer instances
- Enforce authentication on every remote server — OAuth 2.0 with short-lived tokens, not static API keys
- Scope credentials to the minimum data the use case requires; no admin service accounts
- Propagate user identity into data queries so the agent inherits the human's access level
- Log every tool call with enough context to reconstruct what happened in a session
- Treat retrieved content as untrusted — do not let document content override system instructions
- Audit regularly — the MCP landscape is moving fast, and a server that was safe last quarter may have new exposure vectors today
Takeaways
- MCP servers introduce non-human identities with broad data access; the security model has to account for that explicitly
- The most common failures are flat permissions, missing authentication, and no audit trail — all fixable at the architecture level
- User-level permission propagation is the hardest and most important control: the agent should see what the user sees, nothing more
If you want AI agents that understand your business without creating a data exposure problem, start building your company brain with Gyld — the permission model and source citations are built in from the first connection.
Frequently asked questions
What is MCP server security and why does it matter for enterprise?
MCP server security is the set of controls — authentication, authorization, logging, and injection mitigations — that govern what an AI agent can access through a Model Context Protocol server and who else can reach that server. It matters for enterprise because MCP servers connect AI agents to real company data: CRM records, internal communications, financial systems. A misconfigured server can expose that data to unauthorized agents, external attackers, or users who should not have access.
How do MCP servers leak enterprise secrets?
The most common paths are: no authentication on the server endpoint (anyone who finds the URL can query it), overly broad service account credentials (the agent can reach data far beyond what the task requires), and prompt injection via retrieved content (malicious instructions embedded in documents redirect the agent's behavior). The Hacker News documented this pattern in detail for enterprise deployments.
What is the difference between authenticating the agent and propagating user permissions?
Authenticating the agent confirms that the MCP client is a recognized system. Propagating user permissions means the agent's data queries are further scoped to what the specific human user is authorized to see. Both are necessary. Without user-level permission propagation, any authenticated agent can access everything the service account can reach — regardless of who is asking the question.
Do I need a separate security tool for MCP, or can I use existing API security?
Existing API gateways can handle transport-layer authentication, but MCP introduces agent-specific risks — prompt injection, autonomous multi-step tool chaining, non-human identity management — that standard API security was not designed for. Vendors like Proofpoint now offer MCP-specific security platforms. The more fundamental answer is to choose a context layer that builds these controls in rather than adding them as an afterthought.
How does Gyld handle permissions across different sensitivity levels?
When a company connects a data source through Gyld, the owner selects what gets indexed. Each piece of knowledge is assigned a permission level: private (only the person who added it), team, or company-wide. When an AI agent queries through Gyld's MCP server, it returns only what the requesting user is authorized to see, with the source cited. Nothing is indexed without explicit selection, and no fine-tuning or custom RAG pipeline is required.