MCP cybersecurity depends on where you enforce access control. The Model Context Protocol (MCP) gives AI agents a standard way to call tools and read data across connected systems. The protocol leaves it to the platform to limit what each agent can touch. For a team wiring agents into its log and tool stack, the platform must set, hold, and record every boundary an agent respects.
A host application runs the AI model alongside an MCP client. The client connects to MCP servers, and each server wraps one system, such as a log store, a case queue, or an identity directory. The server lists the tools an agent can call and the data it can read.
MCP's authors are upfront that the protocol doesn't enforce security. In the specification, they write that "MCP itself cannot enforce these security principles at the protocol level." The host must provide every protection they describe, from vetting tool descriptions to obtaining user consent before an agent calls a tool.
The NSA's AI Security Center reached the same conclusion in its Cybersecurity Information Sheet on MCP security. When the agency announced the guidance in May 2026, it said the risks "are not isolated problems that can be patched at the interface or endpoint level." So the platform must draw a boundary around each agent, and that boundary must hold even when the agent misbehaves.
MCPs allow security teams to connect their existing data so AI agents can work across systems without the need for costly migrations.
That reach matters. In Strike48’s 2026 security leaders survey, 84% of the 100 security leaders we polled said their tools can't access all their log data. But MCP connectors can provide agents with access to that data to take action on it.
Strike48’s Flexible Data Foundation allows agents to access logs and telemetry where it lives, without moving the data. Strike48 supports over 300 MCP connectors, so agents can work off data from across your stack. The agent then checks identity context and past tickets, links the alert to the matching case, and either gives the human analyst the complete context or makes the determination on closing the case autonomously.
Those agents come from our customizable Pre-Built Agent Packages, where each micro agent has one bounded job and you choose when a person needs to approve critical actions such as endpoint isolation. We cover how they work through approved tools in our pieces on AI SOC agents and data access and AI-enabled incident triage.
By default, an agent can call every tool on every server its client connects to. WorkOS describes this as the common setup, with agents getting access to all tools for the whole session. One manipulated prompt, or one compromised agent, can then reach everything the connection can reach.
But the protocol doesn't prevent all-tool access. According to the NSA, MCP "currently lacks support for exchanging Role-Based Access Control (RBAC) permissions at instantiation," and authorization is optional. The agency also found that a trusted server can often gain new capabilities without anyone approving the change, so an agent approved for a few tools last month might hold more today.
Prompt injection makes that breadth dangerous. A phishing email, a log line, or a tampered tool description can carry instructions the model follows, and a hijacked agent can misuse every tool it holds. OWASP lists scope creep and weak authorization among the top risks in its MCP Top 10, and the Cloud Security Alliance advises treating every MCP server as untrusted.
The fix is to make two decisions separately. The first is which systems the platform connects. The second is which tools each agent may call on those systems. The NSA recommends the same, urging organizations to clearly define trust boundaries between agents, plugins, models, and end users.
Connection breadth is a coverage decision, and we make it once, at the platform layer. Our 300-plus MCPs form a library that a security team draws from. Connecting a log store, an identity directory, or the case queue adds those tools to the library, where they stay until someone adds them to an agent's grant.
Adding a connector doesn't change any agent's grant, which blocks the capability drift the NSA warns about. It also means least privilege never forces a team to connect fewer systems and leave its agents blind to evidence.
A tool grant is a per-agent privilege decision. In our Pre-Built Agent Packages, each agent gets only the tools its job requires through our MCP connectors, and model access runs separately through AWS Bedrock. If someone compromises an agent, the attacker inherits only its few tools.
We also give each agent a GraphRAG persona graph, a bounded map of the knowledge its job needs. That leaves less room to misuse a tool or invent an answer. It reduces hallucination risk without eliminating it, as we explain in our piece on reducing AI hallucinations in security.
Picture a phishing detection agent in an environment with hundreds of connectors. Its job is to triage reported emails: read the message, check senders and links against log data, and open a case. It can't isolate endpoints, disable accounts, or change firewall rules, even though those connectors exist.
An unscoped agent in the same environment holds every tool on every server. If a crafted email steers it, the attacker can reach account controls and endpoint actions. At worst, a scoped agent can misuse a few read and case tools.
When triage finds a compromised device, the agent hands off the case and a person approves isolation.
Scoped grants limit what an agent can reach. Approval gates and audit trails control what it does with that access and show what it did afterward.
Endpoint isolation and remediation should wait for human approval. We log every tool call so a reviewer can trace it later, which fills a gap the NSA found in implementations that "either omit logging entirely or record only minimal operational metadata."
MCP security best practices come down to enforcing limits outside the agent:
Before buying an MCP-connected platform, ask what each agent can touch and what the platform can reach. These five questions cover it.
No. MCP's authors leave security enforcement to implementers in the specification. The NSA notes that authorization in MCP is optional and that the protocol can't exchange RBAC permissions when a connection starts. Any limit an agent respects comes from the host or platform built on the protocol.
MCP becomes a security risk when agents get broad, unscoped tool access. By default, an agent can call every tool on every server its client connects to, and the protocol leaves access control to the platform. One manipulated prompt or compromised agent can then reach everything the connection can reach. Per-agent tool grants, human approval, and audit logging reduce that risk.
Secure it at the platform layer, since the protocol can't enforce access control on its own. Treat every MCP server as untrusted, as the Cloud Security Alliance advises, and give each agent only the tools it needs to do its job. Require human approval for risky actions and log every tool call.
Each agent has only the tools it needs, and the platform enforces that grant. The grant doesn't depend on how many systems the platform connects, so a team can connect its whole stack and still keep each agent's toolset small.
An MCP host can connect to many servers, so the platform's connector library sets the ceiling on reach. An agent's risk depends on how many tools it has in its grant. For a phishing triage agent, that's a handful, no matter how large the library grows.
Not inherently. In a traditional integration, a developer writes each call one system makes to another, so the available actions are fixed in code. With MCP, servers publish tools that an agent can discover and pick from during a session. The NSA lists this dynamic tool use among the protocol's new risks. Because the agent chooses at runtime, the platform must enforce limits outside the agent.
No. According to the NSA, MCP authorization is optional, and the protocol currently lacks support for exchanging role-based access control (RBAC) permissions at connection start. A platform built on MCP has to set and enforce each agent's permissions itself.
