Mostly MCPs, Tools and Skills are being compared with focus on convenience - which one is faster to build, which uses fewer tokens, which is easier for users to configure. But a security person would probably ask first: “what is the blast radius if this goes wrong?” That question changes the ranking completely, and it is worth working through properly, because these three layers each open a genuinely different door.
Tools: narrow doors, but you cut every key yourself
A plain function-calling tool is the smallest attack surface of the three, simply because it does one specific thing with a fixed schema and nothing else. The risk with tools is almost entirely on the implementation side - how carefully you validate inputs before your code executes them, and whether you have quietly given a model a tool that can do more than the task in front of it actually requires. A “send email” tool that technically accepts any recipient and any attachment is a tool doing far more than the use case in front of it needs, and that gap is where trouble tends to start.
MCP: the layer that got authentication right, and the one attackers are learning fastest
MCP’s real contribution to this conversation is not the protocol elegance, it is that remote MCP can use a proper auth model - including OAuth - rather than relying on a static shared secret by default. Rather than handing a model one API key that can do anything the underlying account can do, a properly implemented remote MCP server lets the user authenticate through the service’s own login flow, and the token that comes back is scoped to that user and that service. Local stdio servers still need careful secret handling. Either way, scoped access is a meaningfully better security posture than secrets sitting in a config file or a prompt.
The trade-off is trust in the server itself. When you connect an MCP server, you are trusting not just the protocol but whoever wrote and is hosting that particular server - and MCP servers are frequently third-party or community-built. A malicious or careless MCP server sitting between your agent and, say, your email or your CRM can see everything that passes through it, and a poorly scoped one can combine access to several sensitive systems in a single session in a way that would never have been granted to a human employee without sign-off. This is the confused-deputy problem in a new outfit: the agent has legitimate access to multiple tools, and a bad actor’s job is simply to get the agent to misuse that access on their behalf, not to break in directly.
Skills: the quiet one, and possibly the sneakiest
Skills look the least dangerous, because a skill is “just markdown.” That is precisely why it deserves more scrutiny than it usually gets. A skill is natural-language instructions that get loaded into an agent’s context and followed with real trust, and unlike an MCP tool call, there is no schema forcing a particular shape of output, no server-side validation, and often no built-in credential handling at all. If you have ever seen a skill quietly ask for a “global” API key pasted somewhere in plain text because there is no OAuth pattern for skills yet, you have seen the gap. A skill downloaded from an untrusted source can also carry instructions that steer an agent toward doing something it should not, buried in a file few people read carefully before installing.
What this means for how people should be thinking about their own exposure
The same logic that applies to enterprise agent architecture applies, in miniature, to how any individual manages their own footprint online. Connecting more services, granting broader scopes “just in case,” and trusting unfamiliar intermediaries because they are convenient is exactly the pattern that turns a small mistake into a large one - whether the intermediary is an MCP server with too much access or an untrusted network sitting between your device and the internet. Encrypting your own traffic through a reputable VPN, such as our own PyramidVPN, is a comparatively simple and low-cost way to close off one of those exposure points: it stops your traffic from being visible to whatever network you happen to be connected to, which matters more, not less, as more of your daily activity runs through AI agents making calls on your behalf in the background. It is not a substitute for scoping MCP permissions properly or auditing which skills you trust, but it is one less door left open while you get the rest of your house in order.
The practical checklist
For anyone building or approving agent architecture with security in mind, the ordering that has held up in practice is: prefer MCP over static-key tools wherever OAuth-scoped access is available, because a token tied to a specific user and service beats a blanket key every time. Treat every third-party MCP server as a vendor relationship requiring the same scrutiny you would give a SaaS integration with access to sensitive data - because that is exactly what it is. Read skills before installing them, the same way you would read a script before running it with your own credentials, because nothing about the markdown format makes a skill inherently safer than a shell script. And keep the basics of your own network hygiene in place, because agents inherit whatever exposure the humans and networks around them already have.