> ## 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. # Architecture & Trust > How the MCP Manager gateway is secured as the control point in the path of every call: why it terminates and re-originates connections by design, encryption in transit and at rest (AES-256-GCM credential vault, key rotation), what it stores and what it never stores, network isolation and static egress IPs, the latency it adds, and where to review Usercentrics' security certifications. An **MCP Manager** [gateway](/mcp-gateway-concepts/mcp-gateways) 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](/features/gateway-rules/overview) 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. ```mermaid theme={null} %%{init: {'theme':'base','themeVariables':{'fontFamily':'Lato, sans-serif','lineColor':'#6a6b76','primaryColor':'#e0e2e8','primaryTextColor':'#12141d','primaryBorderColor':'#6a6b76','edgeLabelBackground':'#ffffff','textColor':'#12141d'}}}%% flowchart LR C["๐Ÿค–
AI client"] -->|"HTTPS / TLS"| GW["๐Ÿ›ก๏ธ
MCP Manager gateway"] GW -->|"HTTPS / TLS"| U["๐Ÿ–ฅ๏ธ
Upstream MCP server"] GW -.->|"AES-256-GCM"| V[("๐Ÿ”
Encrypted
credential vault")] GW -.-> L[("๐Ÿ—„๏ธ
Audit log")] classDef gateway fill:#0086ff,color:#ffffff,stroke:#062b4c,stroke-width:2px; classDef client fill:#80cbc4,color:#062b4c,stroke:#00796b,stroke-width:1.5px; classDef server fill:#aed8ff,color:#062b4c,stroke:#0b4880,stroke-width:1.5px; classDef datastore fill:#062b4c,color:#ffffff,stroke:#0086ff,stroke-width:1.5px; class GW gateway; class C client; class U server; class V,L datastore; ``` ## 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](/features/gateway-rules/custom-rules-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](https://csp.nist.gov/pubs/sp/800/38/d/final). 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](/security/authentication-and-identity#where-credentials-live-and-how-theyre-protected). ## What the gateway stores โ€” and what it doesn't Keeping the two straight is the fastest way to reason about exposure: | The gateway stores | The gateway does not store | | ---------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | | Brokered **credentials and OAuth tokens**, encrypted at rest with AES-256-GCM. | Your credentials in any reversible form outside the vault, or anywhere in logs. | | **Audit logs** of each call โ€” identity, server, tool, latency, and request/response content for the trail. | A separate copy of your business data; it is a transit and audit boundary, not a data warehouse. | | Configuration: gateways, servers, identities, rules, teams, and roles. | Another user's Private identity secret in any readable form, even for admins. | Because the audit trail can capture request and response content, you control what lands in it: [gateway rules](/features/gateway-rules/overview) 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](/enterprise/export-to-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](/security/audit-and-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](https://app.mcpmanager.ai/enterprise/security) โ€” and the broader [Usercentrics Trust Center](https://trust.usercentrics.com/) 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](https://app.mcpmanager.ai/enterprise/ip-ranges) (a [machine-readable JSON feed](https://app.mcpmanager.ai/enterprise/ip-ranges.json) is also available). Allowlist that traffic at your firewall and an upstream โ€” or a [Managed server](/mcp-gateway-concepts/mcp-servers/managed) 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](/mcp-gateway-concepts/mcp-servers/workstation), 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](#encryption-at-rest), and the [audit log](/security/audit-and-observability) 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. ```mermaid theme={null} %%{init: {'theme':'base','themeVariables':{'fontFamily':'Lato, sans-serif','lineColor':'#6a6b76','primaryColor':'#e0e2e8','primaryTextColor':'#12141d','primaryBorderColor':'#6a6b76','edgeLabelBackground':'#ffffff','textColor':'#12141d'}}}%% flowchart LR subgraph CUST["๐Ÿข Your environment โ€” customer-controlled systems"] direction TB DEV["๐Ÿค–
Employee device
Cursor ยท Claude ยท agent"] OKTA["๐Ÿ”‘
Okta
your identity provider"] subgraph AWS["โ˜๏ธ Your AWS account"] BR["๐Ÿ›ก๏ธ
Bedrock guardrail
ApplyGuardrail API"] end SIEM["๐Ÿ“Š
Your SIEM / OTLP collector
Splunk ยท Sentinel ยท Datadog ยท self-hosted"] end subgraph UC["โ˜๏ธ MCP Manager โ€” Usercentrics Cloud ยท Google Cloud Platform"] direction TB AUTH["๐Ÿ”Œ
SSO broker
Auth0 ยท Usercentrics"] GW["๐Ÿ›ก๏ธ
MCP Manager gateway
static egress IP"] V[("๐Ÿ”
Credential vault
AES-256-GCM")] L[("๐Ÿ—„๏ธ
Audit log")] end subgraph SAAS["๐ŸŒ Upstream MCP servers"] UP["๐Ÿ–ฅ๏ธ
Github ยท Jira ยท Slack ยท โ€ฆ"] end OKTA <-->|"โ‘  Verified identity (OIDC)
โ€” no business data"| AUTH AUTH -->|"signs the user in"| GW DEV -->|"โ‘ก MCP tool calls ยท HTTPS/TLS
device holds only an MCP Manager token"| GW GW -.->|"reads credential"| V GW -->|"โ‘ข Tool response text ยท HTTPS + bearer token
pass / modify / block verdict returns"| BR GW -->|"โ‘ฃ Brokered per-user credential ยท HTTPS/TLS"| UP GW -.-> L L -->|"โ‘ค Logs + traces ยท OTLP/HTTP (HTTPS endpoint)"| SIEM classDef gateway fill:#0086ff,color:#ffffff,stroke:#062b4c,stroke-width:2px; classDef client fill:#80cbc4,color:#062b4c,stroke:#00796b,stroke-width:1.5px; classDef server fill:#aed8ff,color:#062b4c,stroke:#0b4880,stroke-width:1.5px; classDef datastore fill:#062b4c,color:#ffffff,stroke:#0086ff,stroke-width:1.5px; classDef idp fill:#fff8e4,color:#12141d,stroke:#ffa535,stroke-width:1.5px; classDef sink fill:#c5e1a5,color:#1b3a1b,stroke:#558b2f,stroke-width:1.5px; class GW gateway; class DEV client; class UP,BR server; class V,L datastore; class OKTA,AUTH idp; class SIEM sink; ``` 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: | # | Boundary crossing | What crosses | Direction | How it's protected | | - | -------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | โ‘  | Okta โ†’ Usercentrics SSO broker | A verified identity assertion (OIDC ID token: email, name, subject). **No business data**, and no password. | Inbound to MCP Manager, at sign-in | OIDC over TLS; MCP Manager accepts the sign-in only if Okta marks the email verified ([SSO](/enterprise/sso)) | | โ‘ก | Employee device โ†’ gateway | MCP **tool calls** and their results. This is where MCP traffic enters MCP Manager. This does not contain AI prompts; only the MCP traffic passes. | Inbound to MCP Manager | HTTPS/TLS; the device holds **only** an MCP Manager access token, never your upstream credentials | | โ‘ข | Gateway โ†’ your AWS Bedrock guardrail | The tool's **response text** to be inspected (Bedrock always evaluates the response leg); a pass / modify / block verdict returns. | **Outbound from MCP Manager into your AWS** | HTTPS + `Authorization: Bearer ` (stored encrypted); **fails closed** (blocks) by default if Bedrock errors; 30 s timeout | | โ‘ฃ | Gateway โ†’ upstream MCP server | The brokered tool call, carrying the per-user credential. | Outbound from MCP Manager | HTTPS/TLS; credential pulled from the AES-256-GCM vault at call time; originates from a [static egress IP](https://app.mcpmanager.ai/enterprise/ip-ranges) | | โ‘ค | Audit log โ†’ your SIEM / OTLP collector | Structured **log and trace records** for each request (see [Viewing Logs](/features/viewing-logs)); you choose whether MCP call **bodies** are included, and whether content is sent **raw or after rule-engine redaction**. | Outbound from MCP Manager to a destination you nominate | OTLP/HTTP to the HTTPS endpoint you configure; auth headers stored encrypted; **fire-and-forget**; export content is **configurable** | 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](/enterprise/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](/security/authentication-and-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](/features/amazon-bedrock), 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](/features/gateway-rules/custom-rules-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](/features/amazon-bedrock#logging-and-encryption)). * **โ‘ฃ 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](/enterprise/export-to-siem), 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. **Every connection MCP Manager makes is *outbound*, to a public endpoint you provision โ€” it has no route into your private network.** Your clients and your IdP reach MCP Manager at *its* public endpoint over TLS (crossings โ‘  and โ‘ก), and that ingress terminates at MCP Manager โ€” it never reaches back into your network. The legs that touch your environment all run outbound from MCP Manager to a public surface: the **public AWS Bedrock API** for a guardrail (โ‘ข โ€” MCP Manager calls `bedrock-runtime..amazonaws.com`, and rule-engine endpoints must be public, with private/internal addresses rejected), an **MCP server you expose** (โ‘ฃ), or a **SIEM/OTLP endpoint you run** (โ‘ค). So calling Bedrock is MCP Manager dialing *out* to AWS's managed service โ€” **not** MCP Manager reaching *into* your VPC, your internal subnets, or anything behind your perimeter firewall. You never open an inbound firewall hole for MCP Manager, and you can tighten every outbound leg by allowlisting MCP Manager's [static egress IP](https://app.mcpmanager.ai/enterprise/ip-ranges) โ€” locking your AWS down to MCP Manager's traffic without restricting your own console or API access. ## 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](/deployment/rbac-and-roles/overview), and brokered to the upstream under a specific [identity](/security/authentication-and-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](/security/runtime-protections#break-glass-instant-kill-switches). ## 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](/features/gateway-rules/presidio), an [AWS Bedrock guardrail](/features/amazon-bedrock), [Lakera Guard](/features/lakera-guard), or your [own webhook](/advanced/building-a-custom-rule-engine) โ€” 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](/features/gateway-rules/overview#failure-mode-what-happens-when-a-detection-method-fails) 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 The credential vault, the two-authentications model, and token lifecycle. What the gateway is and the governance pipeline every call runs through. What every call records, retention, and forwarding logs to your SIEM. Inline inspection of live traffic and the break-glass kill switches.