Step-by-Step Guide: How MCP Servers Handle Data Retention & AI Agent Security

How do MCP servers handle data retention and security for AI agents? The answer dictates whether your enterprise AI integration passes a 90-minute InfoSec review or dies instantly in procurement. MCP servers handle data retention in one of two distinct ways: they either cache your customers' highly regulated payloads in their own databases (creating massive, direct SOC 2 and GDPR liability), or they operate as stateless, zero-data-retention proxies that process data entirely in-memory and forward the response to the model without persistence.

If you are shipping AI agents into enterprise accounts in 2026, only the second model survives a serious InfoSec review. When your AI agent connects to an external system—for instance, when you connect Claude to SaaS APIs via MCP to read Salesforce pipelines, mutate BambooHR records, or create Jira tickets—that data flows through an infrastructure layer. If that layer retains a copy of the data, your compliance scope expands exponentially, and enterprise security teams will flag your application as an unacceptable vendor risk.

This step-by-step architectural guide is built for B2B SaaS product managers, engineering leads, and security architects who need to prove—with diagrams, code, and control mappings—that their AI agent integrations will not leak, cache, or retain sensitive enterprise data. We will cover the mechanics of Zero Data Retention (ZDR), dynamic tool generation from API schemas, JSON-RPC protocol handling, secure OAuth token lifecycles, and how to properly hand rate-limit responsibility back to the caller instead of absorbing it.

The Enterprise Security Gap: Why MCP Server Architecture Matters

AI agents have officially escaped the sandbox. They are moving from experimental, read-only chat interfaces into operational systems capable of autonomous, multi-step reasoning. As these agents gain write access to external systems on behalf of end users, the integration layer connecting them quietly becomes the highest-value attack surface in the stack. Agent adoption has outrun governance, and the security data reflects that massive shift.

A few critical numbers anchor the enterprise risk model:

• Ubiquity of the Attack Surface: Wiz Research found that MCP servers were present in at least 80% of observed cloud environments in early 2026, meaning this is no longer a niche protocol—it is ambient infrastructure. Wiz positions MCP servers as a critical new trust boundary, emphasizing that MCP grants LLMs ambient authority that traditional perimeter controls do not cover.
• The Cost of Failure: A 2025 IBM Cost of a Data Breach Report found that 97% of organizations that experienced an AI-related breach lacked proper AI access controls. The financial impact is escalating rapidly; the average cost of an AI-powered breach hit $5.72 million, a 13% increase from the prior year.
• Scope Creep: Enterprise Management Associates (EMA) reported in 2026 that 65% of enterprises have seen AI agents act beyond their intended scope, creating massive enterprise risk.
• Systemic Vulnerabilities: The risks of poorly architected MCP infrastructure are not theoretical. In April 2026, OX Security disclosed a systemic architectural flaw in Anthropic's official MCP SDKs that exposed roughly 200,000 vulnerable instances across the ecosystem.

The pattern is consistent: agents get shipped fast, the middleware caches too much data, and the breach cost lands on the SaaS vendor whose integration layer touched the payloads. When you build MCP servers for AI agents, your architecture is your ultimate security boundary. Zero Data Retention is the architectural response—the ironclad guarantee that no prompt, response, or tool payload is written to persistent storage at any point in the request lifecycle. That guarantee is what turns a nine-week procurement stall into a signed contract.

How Do MCP Servers Handle Data Retention?

At an architectural level, an MCP server translates JSON-RPC 2.0 requests from an AI model into HTTP requests against a destination API. There are two dominant architectures in the wild for how the server manages the payload during this translation. The one you choose determines your compliance surface for the next decade.

Model A: Stateful Caching MCP Servers (High Risk)

Many early MCP implementations rely on stateful caching. In this model, the MCP server sits between the AI client and the upstream SaaS API and stores tool call inputs, outputs, or both. The server queries the upstream API, writes the JSON response to a local database (often a vector database or a relational store), and then serves the data to the LLM.

Engineers often adopt this pattern with good intentions: to optimize LLM context limits, to speed up subsequent reads, to build audit logs for debugging, or to attempt to manage API rate limits. However, every one of those decisions drags regulated data into your database.

This approach creates massive compliance liabilities. If your MCP server caches a BambooHR payload, you are now storing employee salaries, social security numbers, and home addresses. You have effectively cloned your customer's HR database into your own infrastructure. Your SOC 2 scope now includes the storage layer, GDPR Article 28 obligations apply to the cached PII, and any downstream breach becomes your breach. This violates GDPR data minimization principles and instantly fails enterprise procurement reviews.

Model B: Stateless Pass-Through Proxies (Zero Data Retention)

Zero Data Retention (ZDR) is the governing principle for enterprise AI. The MCP server holds only credentials and routing metadata. When a tool call arrives, it authenticates the request, maps it to an upstream API call, streams the response back to the model, and drops the payload from memory when the request completes. No cache. No log of the body. No copy of the data at rest.

Industry leaders are rapidly standardizing on this approach. CData Software advocates for stateless processing at the data connectivity layer to ensure prompts and contexts are never written to persistent storage. Vercel enforces team-wide ZDR policies at the AI Gateway layer, automatically routing requests only to providers with negotiated ZDR agreements. OpenAI offers ZDR for its frontier models as an enterprise trust mechanism, ensuring prompts and responses are not retained or used for training.

The stateless model is not entirely free. You give up some latency wins from response caching, you cannot serve tool calls when the upstream API is down, and every request pays the full round-trip cost. Those are real trade-offs, and honest architecture reviews should acknowledge them. However, the immense upside is that your integration layer stops being a data controller and reverts to being what it should always have been: a secure transport.

Truto's MCP servers operate on the stateless model by default, executing tool calls directly against the integration's native resources without caching or retaining the underlying data payloads. For a deeper walk-through of the compliance implications, see Zero Data Retention MCP Servers: Building SOC 2 & GDPR Compliant AI Agents.

Step-by-Step: Architecting a Zero Data Retention MCP Server

Building a zero data retention MCP server requires specific engineering patterns. You cannot rely on hardcoded tool definitions or stateful middleware. Here is the blueprint. Every step is enforceable, and every step maps to a specific InfoSec control.

Step 1: Generate Tools Dynamically from Schemas

Do not hardcode tool definitions. Storing static JSON schemas for hundreds of external APIs inevitably leads to state drift, where your tool definitions fall out of sync with the upstream API. Worse, hardcoded tools often tempt engineers to cache example payloads or customer-specific configurations in the database "just to make the LLM smarter."

Instead, derive tool definitions dynamically at runtime from two inputs: your integration's resource definitions (what endpoints exist) and a documentation registry (JSON Schema for query and body parameters, plus a human-readable description). When a client requests tools/list, the server should read the upstream OpenAPI specification and derive the tools on the fly.

A tool only exists if it has a matching documentation entry. That single rule doubles as a quality gate and a curation mechanism—undocumented endpoints never leak into an LLM's tool list.

// Example: Dynamic schema-driven tool generation (Zero Cached Payloads)
function buildDynamicTool(integrationLabel: string, resource: string, method: string, docs: APIDocRegistry[]) {
  // A tool only exists if it has a matching documentation entry.
  // This acts as a strict quality gate and curation mechanism.
  const doc = docs.find(d => d.resource === resource && d.method === method);
  if (!doc) return null; // No documentation = no tool exposed to the LLM
 
  let toolName = '';
  if (method === 'list') {
    toolName = snakeCase(`list all ${integrationLabel} ${resource}`);
  } else if (method === 'get') {
    toolName = snakeCase(`get single ${integrationLabel} ${resource} by id`);
  } else {
    toolName = snakeCase(`${integrationLabel} ${resource} ${method}`);
  }
 
  return {
    name: toolName,
    description: doc.description,
    query_schema: parseSchema(doc.query_schema),
    body_schema: parseSchema(doc.body_schema),
    tags: doc.tool_tags ?? [],
  };
}

Step 2: Build a Flat Input Namespace Parser

When an MCP client calls a tool via tools/call, all arguments arrive as a single flat JSON object. The LLM does not inherently know the difference between a URL path parameter, a query string parameter, and a POST body payload.

Rather than caching schemas in a request-side store to figure this out, your MCP server must split these arguments into distinct query and body payloads entirely in-memory at the moment of execution, using the dynamically generated JSON Schemas. If a query schema and a body schema both define a property with the same name, your parser needs a deterministic resolution rule (e.g., the query schema takes precedence). This keeps the request path stateless and predictable, allowing you to construct the upstream HTTP request without storing the payload in a staging table.

Step 3: Handle JSON-RPC 2.0 Without Logging Payloads

The MCP protocol runs over JSON-RPC 2.0 with a small set of methods: initialize, tools/list, tools/call, and a few housekeeping calls. When you implement tools/call, you must enforce strict logging hygiene.

Log only metadata: tool name, tenant ID, request ID, latency, and HTTP status. Never log the request body or response content.

sequenceDiagram
    participant Client as MCP Client (Claude, ChatGPT)
    participant Server as Stateless MCP Proxy
    participant Upstream as Upstream SaaS API (Salesforce, BambooHR)

    Client->>Server: POST /mcp/:token (tools/call via JSON-RPC)
    Server->>Server: Validate token via HMAC lookup in memory
    Server->>Server: Parse flat args into query/body using schema
    Server->>Upstream: HTTP GET/POST with tenant OAuth token
    Upstream-->>Server: JSON Response Payload (PII)
    Server-->>Client: JSON-RPC Response Streamed
    Note over Server: Payload immediately dropped from memory.<br/>No persistent caching or payload logging.

Step 4: Delegate Execution to a Proxy Layer

When a tool is called, the request should map directly to the upstream API—same fields, same shape, same authentication. Adding a unified-model transformation in-line either forces you to cache mapping tables per-request or invites severe state drift.

Truto's MCP execution path deliberately routes tool calls through the proxy API surface: the caller's arguments map to the vendor's native schema, and the response streams back unchanged. This proxy API handler executes the HTTP request against the destination API and streams the response directly back to the MCP client.

Step 5: Never Persist Arguments or Responses

This is the control that gets audited heavily during procurement. Your request handler must terminate the payload lifecycle at the exact moment the response is sent. No debug logs of the body. No asynchronous pipelines that fan out payloads for analytics. The memory reference must be immediately dropped.

Securing the MCP Transport Layer and Authentication

Zero Data Retention is necessary but not sufficient. The JSON-RPC protocol itself is just a transport layer. If anyone with a URL can call your tools, you have merely replaced a data-at-rest problem with a data-in-motion problem. The transport layer needs robust, multi-layered controls to ensure only authorized AI agents can invoke tools.

Cryptographic Server Tokens with Hashed Storage

Each MCP server should be scoped to a single integrated account (a connected instance of an integration for a specific tenant) and addressable by a URL like /mcp/:token, where :token is a long random hex string.

Never store raw tokens in your database or key-value store. The raw token should be returned exactly once at creation. Server-side, generate the token, hash it using HMAC with a strong signing key, and store only the hashed value. On every request, hash the incoming token from the URL and perform a lookup against the hashed value in your storage layer. If your storage layer is ever exfiltrated, the tokens themselves are not recoverable. Token compromise stays a single-tenant blast radius, not a systemic breach.

Conditional API Token Auth for Shared Environments

By default, an MCP server's token URL is the only authentication required. URL-only auth is fine for machine-to-machine flows where the URL lives securely in a secrets manager. However, for enterprise environments where the server URL might be pasted into shared configurations or visible in logs, you must add a second layer of authentication.

Implement conditional middleware—an opt-in flag—that requires the MCP client to also provide a valid platform API token as a Bearer token in the Authorization header. This ensures that possession of the MCP URL alone is insufficient; the caller must also be authenticated as an active user in your system.

Short-Lived Servers with Automatic Cleanup

Most enterprise MCP use cases are temporary. A contractor might need three weeks of access, or an automated workflow might need a one-hour token. MCP servers should support Time-to-Live (TTL) parameters for temporary access.

Expiration must be enforced at multiple levels to close the "forgotten credential" risk:

1. Storage Expiration: Store the hashed token in a key-value store with a built-in expiration timestamp. Once expired, the storage layer automatically drops the record, causing token lookups to fail immediately.
2. Automated Cleanup: Schedule a background job to clean up the relational database record and all cached routing metadata once the TTL expires. Truto schedules token expirations ahead of the deadline and deletes both the token record and its lookup entries when the scheduled time arrives, ensuring an expired server is genuinely gone, not just flagged as inactive.

Per-Server Scope Filtering

Method filters (e.g., read, write, individual HTTP verbs) and tag filters (e.g., support, directory, crm) restrict what an MCP server can do before the LLM ever sees the tool list. This is the practical implementation of least privilege for AI agents. A read-only support-desk agent gets an MCP server that cannot mutate anything, cannot even see the write tools, and cannot escalate its privileges.

Handling Rate Limits and Upstream Errors Safely

Here is where most MCP proxies quietly become stateful and nobody notices. A common mistake engineers make when building integration layers is attempting to handle upstream rate limits on behalf of the client. When an upstream API returns an HTTP 429 (Too Many Requests), a naive proxy will queue the request, apply exponential backoff, and retry.

If you build a queue, you are storing state. It holds the request body in memory or, worse, on disk, for as long as the retry window lasts. This violates Zero Data Retention entirely and breaks the caller's own retry semantics.

The correct, secure behavior is boring and safe: pass the 429 straight back to the caller. A ZDR-compliant MCP server does not retry, throttle, or apply backoff on rate limit errors. Do not absorb the error.

To make this behavior useful and actionable for the LLM or the agent orchestration framework (like LangChain, CrewAI, or AutoGen), the MCP server must normalize the upstream rate-limit signal into a consistent shape. The IETF RateLimit header specification defines three standardized headers every proxy should emit:

• ratelimit-limit: The maximum number of requests allowed in the current window (the quota ceiling).
• ratelimit-remaining: The number of requests remaining in the current window.
• ratelimit-reset: The time (in seconds) at which the rate limit window resets.

Different upstream APIs express rate-limit state differently. Salesforce sends Sforce-Limit-Info. HubSpot uses X-HubSpot-RateLimit-*. GitHub uses X-RateLimit-*. A well-built proxy translates whichever header the upstream sent into the IETF-standard headers, forwards the original 429 body, and lets the caller application decide whether to back off, degrade, or fail loud.

Truto follows this contract exactly: HTTP 429s pass through untouched, rate-limit headers are normalized to the IETF specifications, and the responsibility for retry logic sits strictly with the client application, preventing the middleware from absorbing stateful retry logic.

Passing the 90-Minute InfoSec Review

Enterprise procurement teams do not care about your marketing copy. They care about liability, vendor risk, and verifiable architectural guarantees. When you sell to SMBs, a generic status page is usually enough. Enterprise software procurement requires a completely different standard. Reviews are procedural: the security architect opens a spreadsheet, works through a control list, and stops the moment an answer smells vague.

A ZDR-compliant stateless MCP architecture lets you give crisp, verifiable answers to every question that matters during that 90-minute architecture review:

By adopting a stateless proxy architecture, dynamically generating tools, hashing cryptographic tokens, and strictly passing through rate limits, you remove the integration layer from the scope of data retention liabilities. You can confidently state that your infrastructure processes payloads entirely in-memory, satisfying the strictest SOC 2, HIPAA, and GDPR requirements. For the full baseline implementation checklist, work through our How Do MCP Servers Handle Data Retention and Security for AI Agents? guide.

Where This Leaves Your Roadmap

The security data is unambiguous. Agents are already in production at most enterprises, most of those deployments lack real access controls, and MCP is now ambient infrastructure. This means MCP servers are the primary audit target of 2026. Stateful caching architectures will keep failing procurement reviews, and stateful retry logic will keep pulling middleware vendors into breach scopes they did not intend to accept.

The path forward is a stateless, ZDR-compliant MCP layer that generates tools dynamically from schemas, executes them against upstream APIs without persisting payloads, secures the transport with hashed tokens and TTLs, and hands rate-limit responsibility back to the caller. Build it, buy it, or partner for it—but do not ship agents to enterprise accounts without it. If you are building AI agents for enterprise customers and need a compliance-ready integration layer, you need infrastructure designed specifically for Zero Data Retention.