The security risks of MCP servers cluster around a handful of concrete failure modes: authentication that assumes a trusted network instead of verifying callers, credentials scoped far wider than any single tool actually needs, tool descriptions that can manipulate the model reading them, third-party server code nobody reviewed before connecting it to production data, and logging thin enough that a security team can't reconstruct what actually happened after the fact. None of these are exotic. They're the same categories of risk that show up in any API integration, just arriving faster and in more places because MCP makes it so easy to stand up a new server and connect it.
Authentication built for local development, not production
Many MCP servers started life as local tools, running on a developer's own machine with no meaningful access control because the only caller was that developer's own client. That pattern is fine for local testing and dangerous once the same server gets deployed somewhere multiple users, tenants, or automated agents can reach it. A server that never checks who's calling can't enforce any authorization, no matter how carefully its tool logic was written.
Credentials scoped to convenience, not necessity
It's common for an MCP server to hold one broad credential, an admin database connection, a full-access API key, a service account with wide cloud permissions, because that's simpler to set up than provisioning narrow, tool-specific access. The problem is that every tool the server exposes now inherits that same broad access, even a tool that's only supposed to read a single record. A bug or a manipulated call against the narrow tool can still reach everything the underlying credential can reach.
Tool descriptions as an injection vector
MCP tool metadata includes descriptions meant to help the model decide when and how to use a tool. Those descriptions are just text the model reads, and a malicious or compromised server can write descriptions designed to steer the model toward calling tools it shouldn't, passing along data it shouldn't, or ignoring instructions from the actual application in favor of instructions embedded in the tool listing itself.
Data returned by tools carrying hidden instructions
The risk runs both directions. A tool that fetches a document, an email, or a web page can return content containing text crafted to look like an instruction, and a model reading that content in its context can treat it as one. This is indirect prompt injection delivered specifically through the tool-response channel, which is easy to overlook if a team is only thinking about validating what goes out to a tool, not what comes back.
Unreviewed third-party servers
Installing a third-party MCP server is often as easy as adding a line to a config file, which means teams connect to servers whose code they've never read and whose behavior they're trusting based on a README. That server can log everything it sees, exfiltrate data through its own outbound connections, or simply behave differently from what it advertises, and a team has no way to know without actually reviewing it.
Weak or missing audit trails
When something goes wrong, an audit trail of tool calls, arguments, and results is what lets a team figure out what actually happened. A lot of MCP deployments don't have one, either because the server doesn't log meaningfully or because logs live in a place nobody's watching. Without that trail, an incident becomes a guessing exercise instead of an investigation.
Why these risks compound in agentic workflows
Any one of these risks in isolation might be manageable. The trouble is that agentic workflows tend to chain multiple tools together in a single reasoning sequence, which means a weak authentication check on one server, a broad credential on another, and a manipulated tool description on a third can all line up in the same session. An agent that reads a document through one server, then acts on what it read through another, gives a single injected instruction the chance to travel across servers that were never designed with each other in mind. Reviewing servers individually misses this. The combination matters as much as any single server's own posture.
Where TELEON fits
TELEON addresses the authorization and audit gaps directly by enforcing policy at the tool-call boundary and recording a consistent audit trail of tool activity for calls that pass through the gateway, regardless of which MCP server ultimately handles the request. That gives a team visibility into tool call patterns even when a specific server's own logging is thin or nonexistent.
It doesn't fix a server's weak internal authentication or an overly broad credential baked into that server's own configuration. Those remain issues to fix at the server level, ideally before that server is trusted with anything sensitive.
A short checklist
- Confirm every MCP server your agents reach actually authenticates callers.
- Check what credential each server holds and whether it's scoped to just what its tools need.
- Review tool descriptions from any new server before connecting it, treating them as untrusted text.
- Treat data returned by tools as untrusted input to the model, not verified fact.
- Review the source or documented behavior of any third-party server before production use.
- Confirm tool calls are logged with enough detail to support an investigation.
- Track which servers hold which credentials, and rotate anything overly broad.
Most of these risks share a root cause: MCP servers get treated as trusted infrastructure by default, the same way a well-established internal API might be, when in practice a newly connected MCP server deserves the same skepticism you'd apply to any new, largely unaudited piece of software with real access to your systems.