Architecture & Trust

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 MCP Manager’s security posture, compliance reports (SOC 2 Type 2 + HIPAA, ISO 27001:2022, TISAX Level 3), and live controls at the MCP Manager enterprise security page — and the broader Usercentrics Trust Center for infrastructure-level controls. For teams that want to constrain the network path, the gateway can present static egress IP addresses, which you can find at enterprise/ip-ranges (a machine-readable JSON feed is also available). 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.

​

An example: Okta SSO, an AWS Bedrock guardrail, a SIEM

Security teams almost always ask the same two questions: where does MCP Manager run, and when does our data leave our network? This example traces a common enterprise setup — sign-in through Okta, content inspection through an AWS Bedrock guardrail, and log forwarding to your SIEM — and marks every point where data crosses a trust boundary. The short version: MCP Manager runs entirely in Usercentrics’ Google Cloud Platform (GCP) — the gateway, the encrypted credential vault, and the audit log all live there. It deploys nothing inside your environment: not in your Okta, not in your AWS. Your systems stay yours, and MCP Manager only crosses into them at the points you configure. Three kinds of data sit at rest inside MCP Manager, all in GCP: the encrypted credential vault, the audit log, and your configuration (the gateways, servers, identities, rules, teams, and roles you set up). Everything else in the diagram is traffic in transit. Five boundary crossings move data between MCP Manager and the systems you control — and nothing else does: Reading the crossings in order:

• ① Identity stays in Okta. When someone signs into MCP Manager, Okta authenticates them and asserts a verified identity — an OIDC ID token carrying their email, name, and subject — to Usercentrics’ Auth0 broker, which signs them into MCP Manager. Their Okta password never leaves Okta, and no business data crosses on this leg. MCP Manager accepts the sign-in only when Okta marks the email verified. The full redirect sequence is on the SSO page.
• ② MCP traffic enters at the gateway. The moment an AI client makes an MCP tool call (or accesses resources/prompts), that call travels from the employee’s device to the gateway over TLS — this is when MCP traffic enters MCP Manager. Two things follow: the AI client (e.g. Claude Code) holds only an MCP Manager access token, so your upstream tokens are never on the laptop (see Authentication & Identity); and ordinary chat that never invokes a tool never reaches the gateway at all. This does not contain raw prompts; only MCP traffic reaches the gateway.
• ③ The Bedrock guardrail is one of the AWS-reaching paths. If you attach a Bedrock guardrail, then on each tool call where that rule fires, the gateway extracts the configured tool response text on its GCP leg and sends that text to your AWS Bedrock ApplyGuardrail endpoint over HTTPS (it always evaluates the response leg — source: OUTPUT); Bedrock returns a pass / modify / block verdict that the gateway acts on and records in the log. You own the guardrail, its region, and the decision. The call is authenticated with a bearer token — a long-lived Bedrock API key you generate in the AWS console, not a temporary session token — which MCP Manager keeps as an encrypted rule-engine secret header (AES-256-GCM) and decrypts only for the outbound call. If Bedrock is unreachable or errors, the rule fails closed (the message is blocked) by default, bounded by a 30-second timeout (custom rule engines). One AWS-side caveat worth raising in a security review: if you enable Bedrock’s own model-invocation logging, blocked content can be stored in plaintext in your AWS logs — an AWS setting, separate from MCP Manager (see Amazon Bedrock).
• ④ Upstream calls to your MCP servers leave from a known address. To reach Bitbucket, Jira, Slack, or any other MCP server, the gateway opens an outbound TLS connection and attaches the brokered per-user credential it pulls from the vault at call time. Because this traffic originates from MCP Manager’s static egress IP, you can allowlist it at the upstream or its firewall. Many enterprise-focused MCP servers will also allow you to allowlist specific callback URLs, enabling you to lock them to only allow connections from MCP Manager.
• ⑤ The audit trail flows downstream to your SIEM. If you configure SIEM export, MCP Manager streams structured log records and per-request traces over OpenTelemetry (OTLP/HTTP) to the one collector you nominate — Splunk, Microsoft Sentinel, Datadog, Grafana Cloud, or your own OpenTelemetry Collector, whether that runs in your AWS or as a SaaS tenant — so the MCP audit trail lands alongside the rest of your security data. Two things matter for a security review. First, the export is fire-and-forget: it is asynchronous, so it never adds latency to a tool call, and there is no buffering — a record emitted while the collector is unreachable is not retried. Second, you control what leaves: you choose whether the request and response bodies of MCP calls are exported at all, and whether the content sent is the raw message or the version after your gateway rules have redacted or masked it — so you can keep sensitive payloads out of the export entirely, or forward only the already-sanitized form. The collector headers you supply for authentication are stored encrypted at rest and are never shown back to you in plaintext; treat the destination as a sensitive, compliant one regardless.

​

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.

​

Response size limits

To catch a leaked secret or a poisoned payload, the gateway reads each tool result in full before passing it on — and reading it in full means holding it in memory for a moment. That trade-off is why responses have a size limit. The gateway accepts a response of up to 16 MB, which is far more than a tool result needs in normal use, so legitimate traffic flows straight through. A response larger than that is turned away with a standard MCP error rather than half-delivered. The ceiling matters because every response has to be buffered before it can be inspected, and an unbounded one — whether from a runaway tool call or a misbehaving server — could crowd out the other customers sharing the same infrastructure. 16 MB stays well clear of that while still fitting comfortably inside the audit log, so anything the gateway accepts is also something it can record in full.

​

Further reading