MCP Security Considerations for No-Code App Builders

A protocol for connecting AI models to external tools turned those models from text generators into things that take action: reading databases, calling APIs, triggering workflows, chaining one operation into the next. Anthropic introduced the standard in November 2024, pitching it as the USB-C of AI: one plug instead of a custom wire for every tool pairing. For a no-code builder, that's the whole appeal. Connect a model to a spreadsheet, a CRM, an email service, and it just works, no integration code required.

But an agent that can act is an agent that can be told to act badly, and the person who built the workflow in a drag-and-drop interface often has no way to see that happening. This piece walks through the specific ways that goes wrong, in language that doesn't require a computer science degree to follow.

By mid-2026, MCP had moved well past experimental status. The SDKs were pulling over 97 million downloads a month, combined TypeScript and Python downloads had crossed 1 billion all-time, and more than 10,000 public MCP servers were live, with Fortune 500 companies running the protocol in production. Multiple clients now speak the same protocol, from desktop AI apps to code editors to remote OAuth setups. That's a lot of surface area, and attackers look for surface area.

How large and how fast the security gap has grown

Censys, a firm that scans the internet for exposed services, counted 12,520 internet-accessible MCP servers on April 28, 2026. Eight days later, on May 6, that number had passed 21,000. Nearly double, in a little over a week.

Of those publicly reachable servers, roughly a quarter, 24 to 25%, have no authentication. Anyone who finds them can just start issuing commands.

Among the servers that do require some form of login, the picture isn't much better. Fifty-three percent rely on static API keys: one long-lived credential, no expiration date, no limit on what it can do once it's in. Only 8.5% use OAuth with short-lived tokens, which limits damage if a key leaks. Security researchers had logged more than 40 CVEs (publicly disclosed vulnerabilities) across MCP SDKs, servers, clients, and marketplaces by April 2026, roughly one every four days since the protocol launched. That's about one every four days since the protocol launched.

None of this is theoretical decay over years. It's a brand-new standard, adopted fast, with security maturing slower than deployment.

Tool poisoning: when what the AI reads becomes a weapon

Tool poisoning is simple to explain and hard to catch: a tool's description, the text the AI reads to decide what the tool does and when to use it, contains hidden instructions. The model reads that text as trusted guidance. The person using the tool never sees any of it, because that description lives in metadata, not in the chat window.

MCP makes this worse by design, not by accident. Models discover tools dynamically and treat their descriptions as instructions to follow, with no human checkpoint in between by default. Attackers use this in two ways. One is naming a tool something misleading, so the model picks the wrong tool for the job. The other, more patient version is the "rug pull": ship a tool that looks harmless during review, then quietly update the description later to start collecting data or firing off unauthorized actions.

The postmark-mcp case shows how patient an attacker can be. A package on npm presented itself as the official email integration for Postmark, mimicking the real Postmark integration closely enough to pass. For fifteen straight versions, it behaved exactly like the legitimate tool. Then version 1.0.16 shipped with one new line: a BCC field that silently copied every outgoing email to a domain the attacker controlled. Security firm Koi Security caught it after the package had racked up around 1,500 downloads, hitting roughly 300 organizations. Fifteen clean releases bought the trust. One line spent it.

Prompt injection: how a sentence in a document can take over an AI agent

Prompt injection doesn't need stolen passwords or malware. A sentence buried in a document, a webpage, or a code comment can redirect what an AI agent does next, and the agent has no built-in way to tell that instruction apart from a legitimate one.

There are two flavors worth knowing apart. Direct injection is instructions sent straight to the AI, in a message or a form field. The malicious text sits inside something the agent fetches on its own, a support ticket it's asked to summarize, a contract it's asked to review, a webpage it browses while running a task, which makes indirect injection sneakier. The builder never typed the dangerous words. The agent found them on its own and followed them anyway.

HackerOne's 9th Annual Hacker-Powered Security Report clocked a 540% jump in reported prompt-injection vulnerabilities, calling it the fastest-growing threat category in AI security right now. One attack pattern researchers named "agentjacking" hijacks AI coding agents through injectable Sentry DSNs (the connection strings apps use to report errors to Sentry's monitoring service). Tested against 2,388 organizations, it succeeded 85% of the time across three major coding agents. The attack succeeds because the injection point sits outside what any single component in the chain can fully control, meaning the fix has to live somewhere else in the chain.

Credential misuse and the confused deputy: what happens when an agent holds your keys

MCP servers hold the keys to whatever they connect to: API keys, OAuth tokens, service account secrets, usually sitting right in the server's configuration file. That makes the server itself worth breaking into, since it often guards several doors rather than just one.

A single MCP server frequently holds credentials for multiple systems, aggregating access across them. A single server frequently holds credentials for multiple systems, and it's often granted more access than the job needs, like full mailbox permissions when read-only would've covered it. Compromise one server, and you've potentially opened a path into everything it touches, not just the one task it was built for.

Plenty of early MCP setups use a single shared API key across every user and every agent connected to them. No audit trail showing who did what. No way to isolate one user's access from another's. One leaked key exposes every user's data.

CVE-2026-21852 (CVSS score 5.3) shows how quietly this can happen. The flaw redirects API requests to a proxy the attacker controls, capturing the full authorization header, plaintext API key included, before the user ever sees a trust prompt asking them to approve anything. The theft happens before the safeguard even loads.

Supply chain risk: the threat that arrives through tools you didn't write

OX Security disclosed a structural flaw in April 2026 affecting an estimated 200,000 vulnerable instances across a supply chain touching more than 150 million package downloads. Anthropic's response was to call the command-execution behavior "expected behavior," not a vulnerability, and leave it unpatched. Whatever you call it, it's shipping in code that no-code builders never see, let alone audit.

A separate scan, VIPER-MCP, checked 39,884 real-world MCP repositories and turned up 106 zero-day vulnerabilities, previously undisclosed flaws nobody had caught. That's a rough measure of how much MCP code is running in the wild without ever being reviewed.

Attackers already know this, and they're looking. A diary entry from a security research organization, dated July 13, 2026, counted around 200 scanning requests over two weeks specifically hunting for exposed MCP servers and agent config files, coming from 49 distinct IP addresses probing MCP handshake endpoints. Exposed MCP configs are becoming background noise, much like exposed .env files (files that often leak API keys and passwords) have been on the internet for years.

The corruption compounds across a chained workflow. In a multi-step agentic workflow, each tool call feeds the next one's input. A single bad link and the corruption travels downstream through every step after it. Anyone trusting the final output without checking the steps in between has no way of knowing where the compromise actually got in.

Why no-code builders face different risks than developers

The NSA published guidance on this: the agency flagged that MCP environments can allow AI systems to move data between systems and decide on their own to use new tools or take new actions in ways that may not be adequately controlled. Both of those things run uncontrolled unless someone deliberately locks them down.

That's a deliberate choice in how MCP was specified. Authentication, authorization, isolation, logging: none of that is guaranteed by the protocol itself. It's left to whatever platform implements it. If a no-code platform hides that layer from its users, entirely reasonable, since that's the whole pitch of no-code, users are left with zero visibility into whether authentication, authorization, isolation, and logging are actually happening, because that layer sits underneath what the platform shows them.

Even trained developers struggle with this. Survey data on AI-generated code found 96% of developers don't fully trust it, yet only 48% say they always verify it before shipping. If people who can read the code still skip verification close to half the time, a no-code builder who can't read the underlying output at all is working from a weaker position, not a stronger one.

And this isn't confined to obscure corners of enterprise software. CVE-2025-49596, found in Anthropic's own MCP Inspector tool, scored a 9.4 out of 10 on the CVSS severity scale, a remote code execution flaw in a tool meant to help people build with MCP safely.

What good MCP security looks like in practice

No-code builders can't implement OAuth with short-lived tokens (a more secure approach to authentication than static API keys) themselves. But they can ask their platform whether it's doing that, and the answer matters more than most people realize.

On authentication and credentials: does the platform issue short-lived, scoped tokens, or is everyone running on one static API key? Is each user's access isolated, or shared through a single service account? And is there an audit log showing which agent did what, using which credential, so a problem can actually be traced back to its source?

On tool and server trust: are you shown the actual tool descriptions and schemas before you approve connecting to a server? Does the platform tell you if a tool you already approved changes its behavior or its description later, the rug-pull scenario? Is there any separation between sensitive servers, the ones touching payments or email or database writes, and the general-purpose ones just reading data?

On input and scope: does the platform screen content coming in from outside sources before an agent acts on it, or does anything an agent reads get treated as trustworthy by default?

None of these questions require technical fluency to ask. They require knowing that the answer matters, and knowing that "it's handled" isn't actually an answer. The gap between 12,520 and 21,000 exposed servers in eight days reflects a trajectory that requires deliberate action to change. The builders who ask these questions before connecting their data are the ones who won't end up as a line in next year's disclosure count.