MCP Integration Security: OAuth 2.0, PKCE, and SSRF Defenses Explained

"An AI chatbot connecting to internal systems" sounds great to the business side — and to the IT department, it sounds like a new attack surface.

Our introduction to MCP covered the mechanics and benefits. This follow-up covers the security architecture needed to run MCP integration safely, based on OneBot's implementation. Use it as a vendor-evaluation checklist.

Four New Risks MCP Introduces

MCP integration means "AI calls tools on external servers" — creating risks classic chatbots never had:

Here's how each should be addressed — and how OneBot implements it.

Defense 1: OAuth 2.0 + PKCE as the Authentication Standard

The anti-pattern to avoid: "hand over an API key in plaintext and call it done."

OneBot supports three authentication modes: none (closed test environments only), header auth (API keys via headers), and OAuth 2.0 (recommended).

OAuth mode follows the standards that matter:

• Authorization Code + PKCE — the standard defense against authorization-code interception
• RFC 8414 (server metadata discovery) — auto-discovers the authorization server and validates issuer consistency
• RFC 7591 (dynamic client registration) — safe client registration without manual setup on supporting servers

Access and refresh tokens are stored encrypted and auto-renewed on expiry. The dashboard displays each connection's redirect URI with one-click copy for provider-side registration.

Checklist angle: don't just ask a vendor "do you support OAuth?" — ask about PKCE, encrypted token storage, and automatic refresh.

Defense 2: SSRF — Validate Where the Server May Connect

SSRF is MCP's most overlooked weak point. Because the platform sends requests to admin-registered URLs, a malicious (or mistaken) URL becomes a doorway into internal networks.

OneBot layers its defenses:

• URL & IP-range validation — resolves the target and blocks connections into internal address space
• DNS pinning — connects only to the validated IP, defeating DNS-rebinding (IP swapped between check and connect)
• Redirect re-validation — redirect targets are re-checked against the same rules
• Outbound header policy — restricts headers sent to connected servers, preventing internal data leakage
• Protected connection testing — the dashboard's "test connection" feature itself is rate-limited and logged

Checklist angle: any tool that lets admins register arbitrary URLs must answer the SSRF question. This is where vendors differ most.

Defense 3: Execution Limits — Brakes Built into the Agent

The most realistic operational risk isn't attackers — it's overexecution. Unbounded tool chains mean load on connected systems and unintended repeat actions.

OneBot's agent loop ships with structural brakes:

At the cap, the AI answers with what it has and stops. "Worst case is numerically bounded" is exactly the sentence your IT reviewer wants to hear.

Defense 4: Logging & Visibility

Incident response starts with records. OneBot provides as standard:

• Which tool was called, when, how many times — logged per conversation
• AI usage consumed by tool calls — counted in the token usage dashboard
• Configuration changes — server additions, auth changes, and other admin operations

"We can't explain what the AI did" is a non-starter for internal controls and audits alike.

Platform-Level Security

Evaluate the platform beneath the MCP layer too. In OneBot's case:

• Training data encrypted at rest
• Tenant isolation enforced at the application layer
• Chat-history retention management — automatic deletion past the configured period
• Anti-bot protection (reCAPTCHA) on public forms
• Data location — processed and stored on servers located in Japan, supporting APPI-compliant operation

The IT Reviewer's MCP Vendor Checklist

• OAuth 2.0 with PKCE supported
• Tokens stored encrypted, auto-refreshed
• SSRF defenses: IP validation, DNS pinning, redirect re-validation
• Numeric execution caps (count and time) documented
• Per-conversation tool-call logging
• Encryption at rest for training data and credentials
• In-Japan data residency and APPI compliance stated explicitly

FAQ

Q1. If we don't enable MCP, do these risks exist?

No. Without registered MCP servers, the chatbot answers from documents only. Enable integration when you need it.

Q2. Can we restrict integration to read-only?

Effectively yes — expose only query-type tools on the MCP server side. If write tools are included, design around the execution limits and logging.

Q3. Is header auth acceptable for systems without OAuth?

Practical for closed environments and pilots. For production connections to externally reachable systems, we recommend moving to OAuth 2.0.

Q4. What if a connected MCP server is compromised?

Impact is bounded by that server's exposed tools. Execution caps and per-call logging support detection and scoping.

Q5. Is traffic encrypted?

MCP server communication runs over HTTPS; stored data is encrypted at the platform level.

Q6. Can we get security documentation for our IT review?

Yes — after a trial signup we can provide technical documentation mapped to this checklist. Contact us.

Summary

• MCP's four core risks: credentials, SSRF, runaway execution, over-privilege
• OneBot implements OAuth 2.0 + PKCE, layered SSRF defenses, numerically bounded execution, per-conversation logging
• Platform level: encryption, tenant isolation, servers located in Japan for APPI-compliant operation

Inspect the actual dashboard, security settings included, in a free trial — 14 days, no credit card.

👉 Start your free trial