Security overview

Built to be audited.

MCP Gateway centralizes a powerful trust decision: who may ask which tool to do what. The controls below describe implemented product behavior; deployment controls and optional features are called out separately.

Control plane Default posture

Identity resolve

Grant evaluate

Policy enforce

Outcome record

01 · Trust boundary

Every request crosses the same governed endpoint.

The gateway authenticates the caller, resolves the organization, evaluates token scope and exact tool grants, applies configured screening or approval policy, and only then routes an allowed call upstream. Denials stop at the gateway.

Untrusted edge

MCP clients and incoming credentials are untrusted until verified.

Trusted gateway

Identity, policy, encrypted settings, and audit state live at the control plane.

Semi-trusted tools

Upstream servers receive only calls that pass current gateway policy.

02 · Identity & MFA

Two-layer authentication is the default—not the only supported mode.

By default, POST /mcp requires a gateway token and an OAuth access token that resolve to the same user. Operators can explicitly select API Key mode for clients, such as some CI systems, that cannot present both layers.

Local-auth deployments expose public organization signup. Managed K2-ID deployments own the login, password, and MFA routes instead. A customer-configured OIDC or SAML provider is different: it is an optional additional login door on a self-hosted local-auth instance, so the local routes remain available. Password reset is a separate, default-off local-auth option.

Forced onboarding follows the active MFA policy

For local-auth accounts, administrators must enroll in TOTP. The per-instance policy defaults to mandatory for every local user, but operators may make enrollment optional for non-admin members. Managed K2-ID deployments do not require a second local TOTP secret: the gateway mirrors the provider’s MFA state while fresh step-up verification still protects privileged actions.

03 · Authorization

Access is resolved at call time.

Organization isolation

Tenant-scoped records fail closed when an organization is not resolved.
Token scope

Read, write, or combined scope limits what a credential can invoke.
Exact grants

Product, server, and tool grants are checked against the acting user.
Immediate revocation

Revoked or expired credentials and grants stop authorizing new calls.
Admin boundary

Administrative routes and tools retain hard authorization checks; permission branches are not cosmetic UI.
Discovery policy

Imported resources remain subject to allow/block and approval policy before connection.

Gateway admin tools are a guarded subset of product operations, not a mirror of every web-console action. Destructive native tools require fresh step-up proof, and administrator promotion remains outside that MCP path.

04 · Credential handling

Provider credentials stay behind the gateway.

Reversible secrets

Configured provider client secrets, refresh tokens, access tokens, TOTP seeds, and other secrets needed at runtime are encrypted at rest with the application key.

Gateway tokens

A gateway token is shown once. The database retains a deterministic one-way SHA-256 digest for lookup—not a salted password hash and not a reversibly encrypted copy.

When provider-account brokering is configured, the gateway injects the active user’s upstream credential server-side. Required credentials fail closed when missing or revoked. Raw tool arguments and provider tokens are not intentionally placed into audit metadata.

05 · Approvals & screening

Privileged intent can pause before execution.

Control	What it does	Availability
Inline step-up	A current TOTP code travels as a privileged tool argument.	Default mode
URL elicitation	A supported operation can return a single-use browser challenge bound to the exact call.	Configurable
Browser approval	A privileged call parks while the same human signs in, completes fresh MFA, and approves its redacted intent.	Configurable
Async approval policy	A tool can require an administrator allow/deny decision before the exact call is released.	Per tool

LLM screening is optional and operator-controlled

Screening can monitor or enforce and can be configured to fail open or fail closed when its classifier is unavailable. Unavailable outcomes are recorded; the operator kill switch is an explicit incident action, not an automatic response.

06 · Network & tenancy

Outbound destinations are treated as security decisions.

HTTP destinations are screened against loopback, link-local, private, and cloud-metadata ranges, with redirect and DNS-rebinding defenses in the guarded client path.
Private Connect is a deliberate allowlist capability for vetted private hosts. It does not make arbitrary private-network egress safe by default.
Local-process servers are disabled by default, administrator-only, executable-allowlisted, and launched with a scrubbed environment.
Private Connect and bring-your-own identity are configuration capabilities. This public page does not claim that a commercial entitlement is already provisioned.

07 · Audit evidence

Security-relevant outcomes produce a tenant-scoped trail.

Authentication events, OAuth and gateway-token lifecycle, access changes, administrative mutations, approval decisions, and tool-call outcomes are recorded. Tool-call auditing is on by default and can be disabled independently by a self-hosted operator. Arguments are redacted before storage; raw results are not stored in the uniform tool-call record.

Who

Acting user or preserved actor label

What

Typed action and outcome

Where

Tenant, source address, and bounded client context

08 · Deployment duties

Secure software still needs a secure deployment.

The repository includes production checks and a documented hardening baseline. That checklist is guidance—not a guarantee about any running instance.

Terminate TLS correctly and set secure-cookie/proxy configuration.

Protect and rotate the application key and database credentials.

Back up tenant data and test restoration procedures.

Patch the operating system, PHP, Node build chain, and dependencies.

Constrain network egress and review every private-host allowlist entry.

Monitor audit, application, queue, and infrastructure health.

09 · Assurance scope

Implemented controls are not certifications.

The engineering process includes automated tests, dependency checks, static analysis, secret scanning, and adversarial red-team exercises. This page does not claim an external audit, SOC 2 report, penetration-test attestation, DPA availability, universal MCP-client compatibility, or a contractual SLA. Request current evidence and contract terms directly for your evaluation.

10 · Responsible disclosure

Report security issues privately.

Please avoid a public issue for an unpatched vulnerability. Send reproduction steps, affected versions, and impact to support@k2-tek.com. We will triage the report and coordinate next steps.