Architecture & Trust

Documentation Index

Fetch the complete documentation index at: https://docs.mcpmanager.ai/llms.txt

Use this file to discover all available pages before exploring further.

An MCP Manager gateway sits in the path of every call between your AI clients and your MCP servers. That position is the entire point — it is what lets the gateway authenticate the caller, broker the right identity upstream, run rules on requests and responses, and log every hop. A component that sits in the middle of sensitive traffic has to earn trust, so this page sets out exactly how that path is secured: what is encrypted, what is stored, where it runs, and what it costs in latency.

​

The gateway is an intentional control point, not an accident

The gateway terminates the connection from the client and originates a fresh one to each upstream server. It does this deliberately. A pass-through proxy that simply forwarded bytes could not inspect a tool result for leaked secrets, attribute an action to a real person, swap in a per-user credential, or block a poisoned tool call — the capabilities that make MCP safe to adopt only exist because the gateway is a participant in the exchange rather than a bystander. The trade is straightforward: you route MCP traffic through one governed boundary that you control and can see into, instead of leaving every client to talk to every server directly with credentials scattered across laptops. The rest of this page is how that boundary is hardened.

​

Encryption in transit

Every network hop is encrypted. Clients reach the gateway over HTTPS (TLS), and the gateway connects to each upstream MCP server over HTTPS (TLS) as well. Connections to external custom rule engines are held to the same bar: those endpoints are HTTPS-only, and private/internal IP addresses are rejected, so a rule engine call can’t be quietly downgraded to plaintext or pointed at an internal address. Credentials are attached to the upstream request only after the encrypted connection is established, and they are never placed in a URL.

​

Encryption at rest

Every credential you provide and every OAuth token the gateway obtains on your behalf is encrypted before it is stored, using AES-256-GCM — the authenticated-encryption standard recommended by NIST SP 800-38D. Concretely:

• 256-bit keys. Encryption uses a full 256-bit key; the service refuses to start with a weak or missing key.
• A unique IV per value. Each encrypted value gets its own random 96-bit initialization vector, as NIST recommends for GCM, so identical secrets never produce identical ciphertext.
• An authentication tag on every value. GCM is authenticated encryption: each value carries a tag that is verified on decryption, so any tampering with the stored ciphertext is detected rather than silently decrypted.
• Zero-downtime key rotation. The encryption key can be rotated without downtime — the gateway can decrypt with a previous key while values are re-encrypted under the new one — and OAuth tokens are themselves rotated automatically on a schedule.

Stored credentials are kept in a dedicated key vault, are never written to logs, and are not readable by other users — a Private identity’s secret is unreadable even to an administrator. Because secrets live in this central, encrypted, revocable store rather than in mcp.json files on individual machines, the most common real-world exposure — a long-lived token copied onto a laptop — is removed. The credential model is covered in full under Authentication & Identity.

​

What the gateway stores — and what it doesn’t

Keeping the two straight is the fastest way to reason about exposure: Because the audit trail can capture request and response content, you control what lands in it: gateway rules can redact, mask, or hash sensitive values on the response leg before they are logged or returned, and logs are retained per your plan and can be streamed to your own SIEM. For organizations that want the gateway to retain as little as possible, that combination — redact-before-store plus immediate export — keeps the in-platform footprint minimal. See Audit & Observability.

​

Where it runs and network isolation

MCP Manager is operated as a managed cloud service under Usercentrics’ security program. As a newer product in the Usercentrics family, it runs under that same program; Usercentrics maintains a comprehensive set of security and privacy certifications, and you can review its security posture, controls, and certifications at the Usercentrics Trust Center — including the infrastructure-security controls. For teams that want to constrain the network path, the gateway can present static egress IP addresses, which you can find at Security → IP addresses. Allowlist that traffic at your firewall and an upstream — or a Managed server you run yourself — accepts connections only from MCP Manager. Workstation servers never need an inbound hole at all: they reach the gateway through an encrypted outbound tunnel, so a local server is never exposed to the internet.

​

Identity, authorization, and break-glass

The security of the path is not only cryptographic. Every call is authenticated, authorized against the caller’s teams and roles, and brokered to the upstream under a specific identity — so each action is attributed to a real person in the log. And every layer of a connection carries an enabled toggle checked on every request with no caching, giving you instant break-glass cut-offs: disable an identity, a connection, a host, a server, or a whole gateway and it stops at once, with nothing deleted. See Runtime Protections.

​

Latency: what the gateway adds

Because the gateway is in the path, it adds some overhead — but in practice it is negligible next to the model’s own processing. For straightforward brokering and forwarding, gateway overhead is typically around 150 ms or less per call, a small fraction of the time an LLM spends generating a response. The one thing that meaningfully changes this is rule engines running inline as middleware. A regex rule runs in-process and is effectively free; but a rule that calls an external service — Microsoft Presidio, an AWS Bedrock guardrail, Lakera Guard, or your own webhook — adds the round-trip time of that service to the call. That is the expected cost of inspecting content in flight, and you decide where to spend it: apply heavyweight inspection only on the gateways, legs, and tools that need it. Custom engines are bounded by a request timeout (30 seconds) and a failure mode so a slow or unavailable engine fails the way you chose rather than hanging the call.

​

Further reading