Are these MCP and AI agent security myths true? Eight myths vs facts

Most common beliefs about MCP and AI agent security are only half true. An agent is not safe just because it asks permission, a standard is not a safety guarantee, and a clear instruction does not stop a trick. This post checks eight myths against public sources.

TL;DR

• Standards and prompts help, but they do not replace limits, approvals, and logs.
• Most serious problems come from access and combination, not from one clever attack.
• Each myth below has a fact and a next step you can take this week.
• If you remember one thing: give agents the least access that works, and keep a record.

Definition box. A myth here is a belief that sounds sensible and is partly or fully wrong. MCP is the Model Context Protocol, an open standard for connecting AI applications to external systems. An AI agent is a program that uses a language model to choose its own steps and use tools.

Myth 1: "MCP is a security feature, so MCP servers are safe."

Fact. MCP is a standard way to connect things. It is not a safety seal. The MCP introduction describes it as like a USB-C port: a standard way to plug devices in. Nobody assumes every device with a USB-C plug is safe to connect.

The MCP security best practices page lists real attack paths, including confused deputy problems, token passthrough, SSRF (tricking a client into reaching internal addresses), session hijacking, local server compromise, and over broad scopes.

Do this. Review each server before you connect it, as you would a new software package.

Myth 2: "If I tell the agent to ignore bad instructions, I am protected."

Fact. A written instruction helps a little. It is not a hard limit. OWASP lists "constrain model behavior" as one mitigation among several, next to input and output filtering, least privilege, human approval for high risk actions, labeling untrusted content, and adversarial testing.

NIST's agent hijacking work shows why one try is not the right test. When each attack task was repeated 25 times, the average success rate rose from 57 percent to 80 percent. A rule that holds once may fail on a later attempt.

Do this. Do not let a prompt be your only safety control. Add limits the model cannot talk its way past.

Myth 3: "Only attackers cause agent problems."

Fact. OWASP's description of excessive agency says damaging actions can follow from unexpected, ambiguous, or manipulated model outputs, whatever causes the malfunction. A plain mistake can do as much harm as a trick.

Do this. Cap the size of each action and test in a sandbox. Anthropic recommends extensive testing in sandboxed environments along with appropriate guardrails.

Myth 4: "A confirmation prompt makes everything safe."

Fact. The MCP tools specification says there should always be a human in the loop with the ability to deny tool invocations, and that clients should show tool inputs before calling a server. That is good practice. But a prompt only works if the person reads it. If there are twenty prompts an hour, people click yes.

Do this. Keep prompts for the actions that matter, such as sending, deleting, and spending. Let low risk read actions run without a prompt, and keep the log.

Myth 5: "Read only access means no risk."

Fact. Read only access removes the ability to change things, which is a big win. It does not remove the ability to see private data. Simon Willison's lethal trifecta names three ingredients: access to private data, exposure to untrusted content, and the ability to communicate externally. Read only removes some of the ways to communicate out, but if the agent can also fetch web pages or make network calls, a path may remain.

Do this. Check all three ingredients, not just write access.

Myth 6: "The tool description tells me what the tool does."

Fact. The MCP tools specification says clients must consider tool annotations to be untrusted unless they come from trusted servers. A description is text written by the server's author. It may be wrong, out of date, or written to steer the model.

Do this. Review what a tool actually does, not only what it says, and watch for tools whose lists change after approval.

Myth 7: "Local MCP servers are safe because they run on my own machine."

Fact. The MCP security best practices say a local server runs with the same privileges as the client that starts it, and that a malicious startup command or a malicious server can run arbitrary code, hide what it does, steal data, or cause data loss. Clients should show the exact command before running it and run servers in a sandbox with minimal default privileges.

Do this. Treat a local server like any program you download. Check who made it, read the command, and sandbox it.

Myth 8: "Logs can wait until we scale up."

Fact. Logs are what turn a mystery into a story. The MCP tools specification says clients should log tool usage for audit purposes. OWASP notes that logging and monitoring will not prevent excessive agency, but they limit the damage.

Do this. Start logging tool calls on day one, tied to a named agent identity, even if you only read them once a week.

How do the eight compare?

Worked example: a one page self check

The scores are invented to show the method. Mark each myth "we believe it," "we partly believe it," or "we have moved past it," and give 0, 1, or 2 points.

Total: 8 out of 16. The two zeroes are the place to start. The team writes a short rule that no safety control may rely on a prompt alone, and asks a developer to list which tools were approved on the strength of their descriptions. A month later they score again. The number matters less than the habit of checking each belief.

For more on one of these, read agents rule of two: untrusted input, private data, actions or AI agent permissions: myths versus facts. For local servers specifically, see sandbox local MCP servers before you run them.

Where does Safeguard fit?

Safeguard offers MCP Guardrail, which governs traffic between agents and MCP servers, agent identity, which tracks which agent holds what access at what level, and asset discovery, which helps find agents and servers in use. Policies and gates enforce rules at checkpoints, and compliance and evidence automation helps keep records. You can try the free scan at gold.safeguard.sh/scan.

Try it yourself

In the demo, watch a guardrail check calls between an agent and a tool server. As you click, ask which of the eight myths each step is protecting you from.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• What is the Model Context Protocol (MCP)?
• MCP security best practices
• MCP tools specification
• OWASP LLM01 Prompt Injection
• OWASP LLM06 Excessive Agency
• The lethal trifecta (Simon Willison)
• NIST CAISI technical blog on agent hijacking evaluations
• Building effective agents (Anthropic)

Last reviewed: 19 October 2026.