MCP Security: Securing AI Agents Through the MCP Layer

• May 19, 2026
• Rohit Singh
• Artificial Intelligence, Natural Language Processing

Every tool call your AI agent makes is a potential attack surface. When building AI systems, robust MCP security is the complete architecture that separates hobbyist deployments from production-grade agentic systems.

---

Architecture Overview: Request Flow

1. 🤖 AI Agent / LLM Host (Claude Desktop, Cursor, LangChain, CrewAI, Custom Agents)
2. 🔐 MCP Gateway — Control Plane (OAuth 2.1 + PKCE token validation, single auth entrypoint)
3. 🚦 Rate Limiter (Per-agent, per-tool, per-org quotas)
4. 🛡 Input Guardrails (Pre-tool hooks, prompt injection scan, tool poisoning detection, RBAC)
5. 📋 Audit Logger (Cryptographic trace IDs, SIEM export)
6. 🔍 Output Guardrails (Post-Tool Hook: PII redaction, secrets scanning)
7. ⚙ MCP Tool Servers (CRM, GitHub, Database, File System, Email)

---

01 — The Problem: Why MCP Security Is Non-Negotiable

MCP — Model Context Protocol — is Anthropic’s standard for connecting AI agents to external tools. Think of it as USB-C for AI: plug anything in and it works. That’s the magic. That’s also the problem.

When your AI agent can call a database, send emails, write to GitHub, and query your CRM, every one of those tools is a privilege escalation vector. The agent doesn’t distinguish between your instruction and a hidden command smuggled inside a tool description or a document it retrieved.

Real incident — 2025: Supabase’s Cursor agent was running with privileged service-role access. Attackers embedded SQL commands inside support tickets. The agent read them as instructions, exfiltrated integration tokens, and leaked them to a public thread. Three factors combined: privileged access, untrusted input, external channel. Classic MCP blast radius.

Threat Landscape

• Prompt Injection: Malicious instructions hidden in user input, documents, tickets, or web pages the agent retrieves. The agent can’t distinguish legitimate commands from attacker commands. OWASP #1 threat for LLM apps in 2025.
• Tool Poisoning: Hidden instructions embedded inside tool descriptions (the metadata an agent reads to understand a tool). Invisible to users but the LLM sees it as a system instruction.
• Rug Pull Attacks: A tool appears benign at approval time, then its description is dynamically updated to contain malicious instructions mid-session.
• Credential Sprawl: Without a gateway, each agent stores its own credentials for each tool. N agents × M tools = N×M attack surface.
• Agent Runaway / DoS: A misconfigured or compromised agent loops on a tool indefinitely, burning through API quotas and budget.
• Supply Chain / Shadow MCP: Developers connect unvetted public MCP servers to their agents. With 18,000+ servers in the wild, the supply chain risk is real.

---

Pillar 01 — Gateway: Your Single Control Plane

The MCP Gateway solves the N×M problem. Instead of every agent managing credentials to every tool, you register all your MCP servers with a gateway. Agents authenticate once to the gateway; the gateway handles everything downstream.

1. Agent authenticates to Gateway — OAuth 2.1 token exchange.
2. Gateway validates the token — Checks scopes, expiry, and RBAC policy.
3. Request passes security pipeline — Rate limiter → Input guardrail → Policy check.
4. Gateway injects tool credentials — The agent never sees the downstream API keys.
5. Response passes output guardrail — PII scrubbed, secrets redacted.
6. Everything logged — Cryptographic trace ID on every interaction.

Pillar 02 — OAuth 2.1 + PKCE: Not Optional Anymore

As of March 2025, OAuth 2.1 with PKCE is required for all HTTP-based MCP servers — not a best practice, a specification requirement. PKCE (Proof Key for Code Exchange) acts as a secure handshake that verifies both parties even under surveillance.

// OAuth 2.1 PKCE Flow — what your gateway enforces

// 1. Agent generates a code verifier + challenge
const codeVerifier = generateSecureRandom(128);
const codeChallenge = sha256(codeVerifier); // S256 method

// 2. Auth request includes the challenge
GET /authorize?client_id=agent&code_challenge={codeChallenge}

// 3. Token exchange proves possession
POST /token code={authCode}&code_verifier={original verifier}

Pillar 03 — Rate Limiting: Cost Control Meets Security Control

Everyone treats rate limiting as a cost control mechanism. It’s also a security detection system. Sudden spikes in tool calls, off-hours activity hitting sensitive tools, repeated access patterns that no human would produce — these are compromise signals.

• Per-agent & Per-tool limits: Restrict how often a specific tool can fire per agent.
• Hybrid in-memory + Redis: Sub-3ms enforcement in-memory for speed; Redis as fallback.
• Budget quotas: Dollar-cost limits per agent per day.

Pillar 04 — Guardrails: Pre-Tool & Post-Tool

Guardrails are the security hooks that run synchronously in the request pipeline — before a tool executes and after it returns.

Pillar 05 — Governance: Human In The Loop

The official MCP specification states: “there SHOULD always be a human in the loop with the ability to deny tool invocations.” Most deployments ignore it. Don’t.

• Approval workflows: For destructive actions (e.g. Delete, Deploy).
• Task-Based Access Control (TBAC): Dynamic authorisation based on the current task.
• Least-privilege scopes: Scope tool permissions to the minimum required.
• Server registry: Only vetted, approved MCP servers can connect.

---

🏗 THE PRINCIPLE THAT HOLDS IT ALL TOGETHER

Whether you’re building agentic commerce, AI-assisted workflows, or autonomous pipelines — the design principle is:

Agents decide. Services execute. Security validates everything in between.

The gateway is the fulcrum. Get it wrong and MCP is a blast radius. Get it right and it’s the safest, most auditable way to connect AI to the real world.

What’s your MCP security posture today?

Are you running agents that connect directly to tools without a gateway?

#AIAgents #MCP #AIInfrastructure #SecurityEngineering #GenAI #AgentSecurity #ProductEngineering #LLMOps