The Universal Adapter: AI and Model Context Protocol Architecture

Model Context Protocol (MCP) can reduce the cost of connecting an AI application to tools and data, but it does not turn every connector into a trusted capability. The useful architectural move is to separate protocol interoperability from authorization, policy, execution, and evidence. MCP standardizes how a host discovers and calls a server; the application still decides who may do what, with which data, under which conditions.

This article is for platform, security, and product teams designing production MCP integrations. It uses the final MCP 2026-07-28 architecture as the current baseline. That revision makes the protocol core stateless, carries version and capability information with requests, and retains a host-client-server model. Those changes improve routing and operations, but they do not remove application state, access-control, or recovery responsibilities.

Start with the host, client, and server trust boundaries

The current MCP architecture has three relevant participants. A host is the AI application that coordinates model interaction. It creates a client connection for each MCP server. A server exposes tools, resources, or prompts. Local servers often run as child processes over standard input/output; remote servers normally use HTTP.

Treat every boundary as a security decision:

User to host: establish the requesting person, tenant, purpose, and active session.
Host to model: limit which context and tool descriptions enter the model’s prompt.
Host to MCP client: filter the capabilities visible for this task rather than publishing the entire registry.
Client to MCP server: authenticate both sides, bind tokens to the intended resource, and apply network policy.
MCP server to downstream system: use a separate service identity and a separately issued credential.

The host is the policy-enforcement center. It should not assume that a server’s tool name, description, or annotations are truthful. The protocol’s metadata helps interoperability; it is not an attestation that readOnly is actually read-only. Server provenance, package signing, deployment ownership, and observed behavior belong in the integration registry.

Separate protocol compatibility from production permission

MCP answers questions such as “How does this client list a tool?” and “What schema describes its arguments?” It does not answer “Should this employee refund this customer?” A production gateway needs a policy decision that combines user identity, workload identity, tenant, resource, tool, argument constraints, time, risk, and approval state.

For example, invoice.lookup may be generally readable, invoice.draft_credit may be allowed only for assigned accounts, and invoice.issue_credit may require a finance approver above a monetary threshold. The same JSON schema can support all three, but the authorization decision is different. Keep these actions separate instead of exposing one broad invoice_manage tool with a mode parameter.

This design also limits prompt injection. An untrusted document may persuade a model to request a tool, but it cannot grant the caller a new capability. Teams building this layer should align it with a dedicated tool-permission security model rather than embedding scattered permission checks in prompts.

Discover capabilities cautiously and detect drift

Dynamic discovery is convenient, yet a changing tool list is also a supply-chain and policy event. Store an approved snapshot containing the server identity, protocol version, tool name, schema hash, meaningful annotations, owner, review date, and allowed environments. Compare every discovery response with that snapshot.

Changes should be classified before publication to models:

a description-only correction may need a lightweight review;
a new optional field may require compatibility tests;
an expanded enum, new outbound destination, or changed destructive behavior requires security review;
a new tool starts disabled until policy, observability, and recovery are defined.

Do not rely on a model to notice a subtle schema change. Validate inputs against a pinned schema at the gateway and again at the server. Bound string length, collection size, recursion depth, file paths, URLs, and query complexity. Where output schemas exist, validate responses before they become model context. This avoids treating malformed or adversarial tool output as trustworthy memory.

Design authorization for the exact resource

For remote HTTP servers, use the MCP 2026-07-28 authorization specification as the wire-level baseline. It builds on OAuth discovery and requires clients to identify the target resource. The practical rule is simple: a token issued for the MCP server must be accepted only by that MCP server, for the scopes and subject intended.

The OAuth 2.0 Security Best Current Practice recommends restricting token privileges and using stronger protections against replay. Never forward the user-facing MCP token unchanged to a downstream CRM, repository, or payment API. Token passthrough destroys audience separation, confuses audit records, and can make the MCP server a deputy for an attacker. The server should exchange or acquire a distinct downstream token for its own client identity and the specific delegated operation.

Use short lifetimes, secure storage, explicit audience validation, exact redirect URI validation, PKCE where applicable, and rapid revocation. A local stdio server needs a different control: launch it in a sandbox with restricted filesystem, process, environment, and network access. “Local” describes placement, not trustworthiness.

Put policy and approval ahead of execution

The model should propose a typed action; deterministic software should authorize and execute it. Before a state-changing call, render a human-readable preview from the validated arguments: target, consequence, scope, price or volume, external recipient, and rollback path. Approval must bind to that exact action digest. If arguments change after approval, ask again.

Risk-tier the workflow:

Tier	Example	Default control
Read	Search approved knowledge	Log and apply row-level access
Reversible write	Create a draft ticket	Policy check, idempotency key, undo
External effect	Send a customer email	Preview and explicit approval
High impact	Payment, deletion, privilege change	Step-up authentication and independent approver

Approval is not a decorative “yes” button. It must show enough context to make a decision, expire promptly, identify the approver, and be recorded with the execution. For more detail, see our human approval design guide.

Make retries idempotent and state explicit

MCP 2026-07-28 is stateless at the protocol core, but business workflows remain stateful. Represent state with an explicit, opaque handle bound server-side to the authenticated user and tenant. Possession of a workflow ID is not authentication. The server must reauthorize every request and reject a handle presented by another principal.

Retries are inevitable because a client can time out after the downstream system commits. Every mutating operation should accept an idempotency key tied to the logical intent, not to one network attempt. Store the key with the validated request hash and final result. A repeated identical request returns the prior result; the same key with different arguments fails closed.

For multi-step work, persist checkpoints outside the model conversation. Define compensation for completed steps: revoke the created invite, cancel the pending order, restore the previous configuration, or open a manual incident when a physical or financial action cannot be undone. Never describe a compensating transaction as a perfect rollback; it may have its own risks and side effects.

Observe the decision, not only the HTTP call

A useful trace connects business intent to technical execution. Record:

request and correlation identifiers;
human and workload principals, tenant, and delegated subject;
server identity, tool name, schema version, and policy version;
validated arguments with sensitive fields redacted or tokenized;
retrieved evidence and its provenance;
model proposal, policy outcome, approval event, and approver;
downstream request identity, result class, latency, retry count, and compensation;
final business outcome and user correction.

The goal is reproducibility without turning logs into a secret warehouse. Encrypt sensitive traces, apply field-level retention, and keep credentials and full private prompts out of routine telemetry. Instrumenting this chain is part of agent observability, not an afterthought added when an incident occurs.

Defend the integration-specific attack surface

The official MCP security best-practices guide documents confused-deputy behavior, token passthrough, server-side request forgery, state-handle hijacking, local-server compromise, authorization URL abuse, and scope minimization. Translate each category into an executable control and a test.

For example, OAuth metadata discovery can cause a client to fetch attacker-controlled URLs. Use mature URL parsing, require HTTPS in production, block private and link-local destinations, validate every redirect hop, and route discovery through an egress proxy. Bind state handles to the verified caller. Display the exact command before installing a local server, then run it with minimal privileges. Require per-client consent when an MCP proxy uses a shared upstream OAuth client.

The OWASP Top 10 for Agentic Applications 2026 is a useful broader threat checklist, not a compliance certificate. Use it to test goal hijacking, excessive agency, tool misuse, memory poisoning, cascading failures, and insufficient traceability across the entire application, including non-MCP components.

Plan rollback at three different layers

“Disable the agent” is too coarse for most incidents. Build independent controls:

Capability rollback: remove one tool or revert its approved schema snapshot.
Credential rollback: revoke the affected client, user grant, or downstream token without stopping unrelated traffic.
Business rollback: reverse or compensate the actual change in the system of record.

Feature flags should be addressable by server, tool, tenant, action tier, and environment. Maintain a last-known-good registry and a tested path to downgrade a protocol or SDK integration if compatibility breaks. For high-impact tools, add a circuit breaker based on failure rate, abnormal volume, policy denials, or unexpected recipients. The breaker should stop new execution while preserving evidence and in-flight state for investigation.

Measure integration value and control quality together

An MCP program succeeds when it reduces integration work without expanding uncontrolled authority. Track both outcomes and guardrails:

median time to add an approved tool and reuse it in a second host;
successful task completion after downstream verification, not merely 200 OK;
policy-denial rate split by correct protection versus misconfiguration;
approval latency, abandonment, and argument-change reapproval rate;
duplicate side-effect rate after retries;
stale-schema detection time and time to disable a risky tool;
cross-tenant access attempts and unauthorized successful actions;
mean time to revoke, compensate, and restore service;
user correction rate and business cycle-time reduction.

Start with one reversible workflow, one owner, and a small tool surface. Red-team untrusted tool descriptions, poisoned resources, altered schemas, stolen tokens, malicious URLs, replayed approvals, repeated calls, and partial downstream failure. Expand only when both the business KPI and the safety KPI improve. Standard connectivity is valuable; disciplined boundaries make it dependable.

Source notes

Substantive review completed 2026-07-30. The architecture and protocol claims use the final MCP 2026-07-28 documentation. Security recommendations were checked against the current MCP authorization and security pages, IETF OAuth guidance, NIST’s current agent-standardization program, and OWASP’s 2026 agentic risk framework.