Secure Agentic AI: Key Takeaways for MCP Servers

In a recent presentation, Tun Shwe, AI Lead at Lenses, and Jeremy Frenay, an AI Engineer at Lenses, discussed the critical security considerations for building robust agentic AI systems. They highlighted the inherent challenges in designing and deploying MCP (Model Context Protocol) servers, emphasizing that security must be a foundational element, not an afterthought.

Meet the Experts

Tun Shwe, as AI Lead at Lenses, brings a wealth of experience in guiding the development of AI-driven solutions. Jeremy Frenay, an AI Engineer at Lenses, focuses on the practical implementation of these systems. Their combined expertise provides a deep dive into the technical and security aspects of agentic AI.

Why Most MCP Servers Aren't Great (And Why That Is Dangerous)

Shwe kicked off the discussion by pointing out that agents deserve purpose-built interfaces, not just a standard REST API in disguise. He stressed that a poorly designed MCP server is inherently insecure. "A badly designed MCP server is also a badly secured one," Shwe stated. Agents differ from humans in several key dimensions, each with a security implication, or "security shadow."

The first dimension is discovery. For humans, discovering tools is easy, but for agents, it's expensive. Agents must enumerate every tool on every handshake, consuming valuable tokens. This process itself is a surface for tool poisoning, where malicious instructions can be embedded in tool descriptions and executed by the model. Shwe emphasized that every tool exposed is a potential door that needs to be secured.

The second dimension is iteration. For humans, iteration is fast. For agents, every call sends the full conversation history over the wire, which can be slow and a chance for data leakage. If a script fails, re-running it sends the entire history again. This means each round trip is a chance for sensitive data to be exposed.

The third dimension is context. Humans have decades of memory and intuition, but agents are limited by their context window, typically around 200,000 tokens. This limited context, combined with potential context injection and over-sharing, means that an agent could be tricked into exfiltrating sensitive data if the server dumps unfiltered information into its context window. Shwe warned, "If some of that hay is poisoned, the agent won't notice." The key takeaway here is to curate MCP tools and expose only the minimum necessary information to agents.

Five Rules for Secure Agentic Design

Frenay then outlined five key rules for designing secure agentic systems:

1. Design for the Desired Outcome: Every tool you expose is a door. Bury orchestration in one tool with a clear outcome. This means shrunken attack surfaces by design, with fewer doors and fewer locks to manage.

2. Constrain Inputs at the Schema Level: Use top-level primitives, enums over free-text strings, and avoid nested dictionaries. This makes inputs easier to validate and harder to exploit.

3. Treat Your Documentation as a Defensive Layer: Document every tool and use examples carefully, as agents will mirror them exactly. This is crucial for preventing tool poisoning.

4. Return Only What the Agent Needs: Be mindful of what is continually being stored in the agent's context window. Over-sharing data in tool responses can lead to vulnerabilities.

5. Minimize the Blast Radius: Scope agent permissions at the tool and resource level, not the session level. Use read-only annotations and consider tools that don't require broad access.

Frenay stressed that building an interface is different from building a tool. "An insecure interface is worse than no interface at all, because the agent will use it confidently and without suspicion."

Local vs. Remote MCP Servers and OAuth

The presentation then shifted to the practical differences between local and remote MCP server setups. A local MCP server runs on the user's machine, connecting via STDIO, and requires the user to manually set the API key. This is suitable for single-player developer productivity.

However, production environments require a StreamableHTTP transport for remote deployment, multiple clients, horizontal scaling, and centralized governance. This is where MCP adds significant value. Remote MCP servers can be protected by an authorization server, and clients can register themselves, receiving a new ID with every registration.

Frenay explained that implementing OAuth for MCP servers is genuinely hard due to the numerous RFCs involved, including authorization framework, token exchange, token revocation, discovery metadata, and access control. He highlighted that many MCP servers are configured with static credentials, which is insecure. A more robust approach is to use OAuth, where clients register themselves with an authorization server, obtaining client IDs and secrets. This allows for finer-grained control over permissions and can be essential for securely managing thousands of ephemeral agents at scale.

He elaborated on the challenges of implementing OAuth, noting that dynamic client registration (DCR) can create problems, especially at scale. While DCR can be a good starting point, it has vulnerabilities. A more preferred dynamic default is URL-based client identity, where the client owner exposes a client ID on a public URL, and the MCP server fetches this metadata during authorization. This approach offers better security by allowing the authorization server to validate the client and its metadata, including scopes and redirect URIs, more securely.

Finally, he touched upon RBAC (Role-Based Access Control) at the tool level, data masking, audit logging, and observability and telemetry as crucial components of enterprise-grade security for agentic AI. The key is to trace what agents do, mask sensitive data, and ensure that only necessary information is shared.