MCP Per-Message Authentication Patterns for Production RCS Agents

Introduction

The MCP security crisis is accelerating. In 60 days, the Model Context Protocol ecosystem has logged 30 CVEs — with 36% of deployed MCP servers running zero authentication. That's not a theoretical risk. That's a production emergency.

But here's the conversation nobody's having: what happens when MCP connects to messaging infrastructure?

If you're building RCS messaging agents that use MCP as their orchestration layer, the per-message authentication gap becomes a compliance issue. Brand-validated content flowing through carrier networks needs auditability. MCP's session-based model doesn't natively provide that.

This post breaks down the attack surface, hardening patterns, and what teams need to implement before going to production.

The Problem: Why Per-Message Auth Matters for RCS

MCP's Session-Based Model

MCP tools operate on a session authentication model. Once connected, any tool call within the session passes through. The auth happens at session start — not per request.

This works fine for many use cases. But for RCS messaging, it creates a gap:

Session hijacking: If a session token is compromised, every message in that session is exposed
Payload tampering: No per-message integrity check means requests can be modified after the session authenticates
Compliance risk: Brands sending through carrier networks need to prove message integrity — MCP's model doesn't support this natively

The Numbers

30 CVEs in 60 days in the MCP ecosystem
36% of MCP servers running with zero authentication
Per-message auth gap confirmed across Microsoft AutoGen, LangChain, and Vercel AI GitHub issues

Attack Surface Analysis

Session Hijacking Scenarios

Token exfiltration: Session tokens stored in logs or memory dumps
Man-in-the-middle: Unencrypted traffic interception during session establishment
Cross-site replay: Valid session tokens reused from cached requests

Payload Tampering

MCP tool calls pass JSON payloads. Without per-message signing, an attacker who gains session access can:

Modify message content after validation
Inject additional recipients
Alter metadata (timestamps, sender IDs)

Carrier Accountability

RCS messages travel through carrier infrastructure. Brands are accountable for content that enters that network. MCP's session auth provides no mechanism to:

Prove a specific message wasn't tampered with
Demonstrate chain of custody for audit purposes
Verify the request originated from the expected agent

Hardening Patterns That Work

1. Session Token Rotation

What: Short-lived tokens with frequent refresh cycles.

// Rotate session tokens every 5 minutes
const SESSION_TTL_MS = 5 * 60 * 1000;
const lastRotation = Date.now();
const needsRotation = Date.now() - lastRotation > SESSION_TTL_MS;

Why it helps: Limits exposure window. Even if a token is compromised, it's only valid for a short window.

RCS-specific: For high-volume messaging agents, rotate between message batches, not just by time.

2. HMAC Request Signing

What: Add a cryptographic signature to each message payload, independent of the MCP session.

// Sign each message payload with a secret key
const signPayload = (payload, secret) => {
  const hmac = crypto.createHmac('sha256', secret);
  hmac.update(JSON.stringify(payload));
  return hmac.digest('hex');
};

Why it helps: Even with session access, tampering is detectable because signatures won't match.

RCS-specific: Include RCS-specific fields (destination address, brand ID) in the signed payload to prevent redirect attacks.

3. Tool Permission Tiers

What: Separate MCP tools into read-only and write permissions. Messaging tools require elevated permissions.

const TOOL_PERMISSIONS = {
  read: ['get_conversation_history', 'get_contact_info'],
  write: ['send_rcs_message', 'send_rich_card'],
  admin: ['update_brand_settings', 'manage_webhooks']
};

Why it helps: Limits blast radius. Compromised session can only access permitted tools.

RCS-specific: Carve out separate tool permissions for different message types — transactional vs. marketing vs. authentication messages.

4. Audit Trail Requirements

What: Log every message with session ID, timestamp, payload hash, and signing key ID.

const auditLog = {
  timestamp: new Date().toISOString(),
  sessionId: context.sessionId,
  payloadHash: sha256(payload),
  signerKeyId: context.activeSigningKey,
  toolName: context.toolName,
  destination: payload.destination
};

Why it helps: Provides evidence chain for compliance audits. Proves messages weren't modified.

RCS-specific: Retain logs for carrier audit requirements (typically 90+ days).

RCS-Specific Considerations

Brand vs. Carrier Accountability

When a brand sends an RCS message, both the brand and the carrier have accountability:

Brand: Responsible for content and consent
Carrier: Responsible for delivery and spam filtering

MCP hardening helps brands maintain the accountability chain on their side. If a dispute arises ("this message was sent without our consent"), signed payloads prove the request came from the expected agent.

Rich Media Content Integrity

RCS rich cards, carousels, and AI suggestions include visual assets (images, CTAs). These need integrity verification too:

const signRichMedia = (card, secret) => {
  const mediaHash = sha256(card.imageUrl + card.imageData);
  return signPayload({ ...card, mediaHash }, secret);
};

Compliance Documentation

Enterprise deployments typically need:

Security architecture diagram
Key rotation policy
Incident response procedures
Audit log retention policy

Implementation Checklist

Session Governance

Session tokens expire within 5 minutes
Token rotation happens automatically
Sessions are invalidated on error conditions
No session tokens in logs or error messages

Request Signing

Every message payload is HMAC-signed
Signature includes destination and brand ID
Signatures are verified before sending
Invalid signatures trigger alerts

Permission Tiers

Read vs. write tool separation implemented
Elevated permissions require additional auth
Permission denials are logged
Least-privilege default for new sessions

Testing

Simulated session hijacking detected
Payload tampering detected
Permission escalation blocked
Audit logs capture required fields

What Comes Next

MCP Spec Evolution

The MCP community is aware of the per-message auth gap. Proposals for native per-message authentication are under discussion. Until then, hardening patterns are the responsibility of the implementing team.

Native Per-Message Auth

Future MCP versions may include:

Built-in payload signing
Per-request authentication tokens
Native audit log support

Security Best Practices

The 30 CVEs in 60 days is a wake-up call. Teams deploying MCP in production need to:

Assume zero trust by default
Add layers on top of the MCP session model
Test security assumptions, not just functional behavior