A Reference Architecture and Review Method for Secure MCP Use

MCP separates an AI host, client, and server while exposing resources, prompts, and tools. This creates useful interoperability and a clear place to reason about trust, but the protocol cannot decide whether a particular server or action is appropriate for an organization. We propose TABS—Trust, Authority, Behavior, and State—as a review method and reference architecture for a defined MCP deployment.

TABS is design research: an original synthesis intended for architecture workshops and controlled testing. It does not present vulnerability prevalence, comparative product testing, incident statistics, or proof that the architecture prevents compromise.

Zone one is the host and user boundary. It identifies the human or workload requesting a task and presents consent using concrete resource and action names. Zone two is the connection boundary. It maintains a server registry, validates origin and transport, binds authorization to the intended server, and stores no broader token than required. Zone three is the tool boundary. A broker assigns a stable internal ID, validates typed arguments, restricts filesystem and network destinations, separates read and write scopes, and routes high-impact actions for approval. Zone four is the resource boundary, where operating-system, cloud, database, and SaaS controls enforce the final authorization independently of model text.

State spans all zones. Logs should link requester, host, client, server identity, protocol operation, tool version, parameters or safe parameter digest, authorization decision, result class, and approval. Secrets and unnecessary sensitive content should not be copied into logs. Local servers should run with sandboxing and limited process, file, and network access.

Trust: inventory every client and server, establish ownership and distribution path, record transport, version, update method, and dependencies, and define removal criteria. Authority: trace token issuance, audience, scopes, redirect handling, delegation, consent, service identity, and revocation from user to underlying resource. Behavior: review tool descriptions and schemas against implementation, then test malformed inputs, path and command injection, server-side request forgery, cross-server confusion, tool-description changes, hostile resource content, and repeated approval prompts. State: inspect session separation, caches, elicited information, logs, token storage, restart behavior, revocation propagation, and incident evidence.

For each test, capture the exact component versions, preconditions, expected control, observed result, evidence, and residual risk owner. Begin with a laboratory configuration and synthetic resources. Introduce production identities only after the customer approves boundaries and rollback. Re-run affected tests when a server, client, authorization flow, tool schema, or downstream resource changes.

TABS is not a protocol conformance suite and has not been empirically validated. MCP evolves, and individual SDKs and hosts may implement features differently. Source review does not prove the distributed package is identical; dynamic tests cover only exercised paths. A cooperative test server will not reproduce every malicious server strategy, while production testing can create real side effects. The method must be adapted to current specification text, deployment architecture, legal requirements, and organizational risk decisions.

The MCP specification defines the protocol roles and operations, while its security guidance discusses authorization and attack considerations. OWASP’s agentic guidance informs the wider model-and-tool threat context. The TABS acronym, four-zone arrangement, and review record are Alexa Cybersecurity’s proposed synthesis, not requirements claimed by those sources.