Operational controls

Stop or limit gateway traffic when something goes wrong. Operational controls are the levers an administrator pulls when the normal governance path (rules and tool customization) isn't the right tool. They stop traffic rather than shape it, take effect across the entire organization or an entire resource, and leave a clear trail in the audit log.

Choose the right control

Control	Scope	Use when
Gateway kill switch	All gateway traffic, organization-wide	Suspected credential compromise, runaway activity, or an investigation that needs everything stopped
Access policy change	One Virtual MCP (VMCP)	You need one VMCP out of service while you investigate
Tool disable	One tool	A single tool is behaving badly and nothing else needs to stop
Connector restart	One hosted connector	A connector is stuck, leaking logs, or holding a stale secret
Bearer credential rotation	One credential	A shared token may be leaked
Secret provider external ID rotation	One AWS trust pairing	The external ID or role trust policy may be compromised
User suspension (via IdP)	One user	An individual should not be using anything

Gateway kill switch

The kill switch is a single toggle under Enterprise Settings → Danger zone that immediately disables all gateway traffic for the organization. When it is enabled:

• Every MCP tool call routed through a Virtual MCP (VMCP) is rejected.
• MCP clients receive a JSON-RPC InvalidRequest error with the message "Gateway calls are currently disabled for this organization." Existing sessions fail on their next request (there is no grace period).
• The OpenAPI tool-call endpoints, used by agents that speak HTTP rather than MCP, return HTTP 403 with the same message.
• Both per-user and per-agent authentication paths are blocked, so human users and agent machine-to-machine flows stop together.

The kill switch does not affect:

• The admin UI itself. You can still log in, browse the app, and flip the switch back.
• Audit log reads. Live Activity, the admin audit log, and OTLP export keep working, which is critical for investigating whatever caused you to flip the switch.
• MCP Store browsing and VMCP configuration. You can still create, edit, or reconfigure Virtual MCPs, but they won't serve traffic until you re-enable.
• The Admin MCP. That server is reached through a different path than gateway tool calls, so admin-side tooling keeps working.
• Other MintMCP organizations on the same cloud control plane. The switch is scoped to your organization alone.

Enable the kill switch

1. Navigate to Enterprise Settings in the sidebar.
2. Scroll to the Danger zone at the bottom of the page.
3. Find the Gateway Kill Switch card. The toggle labeled Gateway traffic is on under normal operation.
4. Toggle it off. A confirmation dialog explains that all gateway calls will be immediately rejected and that existing connections will fail on their next request.
5. Click Disable Gateways.

The change takes effect immediately: there is no propagation delay, so the next request through any Virtual MCP gets the rejection. The card's subtitle updates to confirm the new state ("All gateway calls are currently disabled").

Re-enable traffic

Same place, same toggle, opposite direction. Flip it back on, confirm in the dialog ("Re-enable Gateway Traffic"), and traffic resumes immediately. Most MCP clients reconnect on demand, so clients that were failing succeed on their next attempt without user action.

Who can toggle it

The kill switch is gated on the enterprise settings permission. If you don't see the Danger zone section on the Enterprise Settings page, you don't have the required admin permission, and the control is not reachable through the admin API either.

Disable a Virtual MCP

From the Virtual MCP's detail page, set the access policy to a narrower audience (for example, "only organization admins") to pull a VMCP out of service for non-admins while you investigate. Rotating users out of an access policy is not instantaneous for in-flight sessions, but it stops any new calls immediately.

For a harder stop on a single VMCP (when the kill switch is too broad but you need the whole VMCP off), delete it from the Access policy tab. Deletion is destructive and requires re-creation, so treat it as a last resort, not a pause.

See Administration for access policy configuration.

Disable a tool

On a Virtual MCP's Tool customization tab, disable a single tool without touching the rest. Agents lose the tool immediately: it no longer appears in tools/list, and any attempt to tools/call it is rejected.

You can also flip the VMCP's Update policy from Enable new tools by default to Require manual approval, which freezes the tool set at the current list. Use this if you're worried an upstream MCP server might push a surprise tool while you can't watch the deploy.

Restart or reconfigure a hosted connector

If a hosted connector is in a bad state (stuck, leaking logs, holding a stale secret), the Admin MCP and the admin UI both expose restart_hosted_connector and environment-variable editing. Restart is the first move for a stuck or misbehaving connector.

Rotate a bearer credential

For shared bearer tokens sourced from a secret provider, rotation happens in the upstream secret store (for example, AWS Secrets Manager). MintMCP picks up the new value within the provider's cache window (around five minutes) without any UI action.

For shared bearer tokens pasted directly into MintMCP, rotate the value in the connector configuration form and the new value is used on the next call. See authentication models for how shared credentials are configured. (Gateway bearer keys, the keys clients use to reach a VMCP, rotate from the VMCP's key management screen instead.)

Rotate the external ID on a secret provider

Rotate the trust pairing between MintMCP and your AWS account on your own schedule: generate a new external ID on the secret provider, update the role's trust policy in AWS to match, and save. The new pairing takes effect as soon as the AWS trust policy propagates, and the previous external ID stops working immediately, so you stay in full control of the trust relationship.

Suspend a user

Suspend a user in your identity provider (Okta, Microsoft Entra ID, and similar) and the change propagates through SCIM to MintMCP automatically: the user is deactivated and their active sessions are invalidated. Your IdP stays the single source of truth for who has access.

See Configure SSO and SCIM for how IdP provisioning connects to MintMCP.

Audit trail

Every operational-control toggle is an administrative event and is written to the admin audit log:

• Kill switch enable and disable, with the actor's identity and the before/after state
• VMCP access-policy changes, including removing users or groups
• Tool enable and disable
• Connector restart, environment-variable changes, and redeploys
• Secret provider lifecycle events: create, update, rotate external ID, delete
• Credential updates: the fact of the change, never the credential value itself

These events flow into OTLP export alongside gateway activity, so they show up in the same SIEM as the traffic they're responding to. When a post-incident review asks "at what point did we disable the gateway?", the answer is one query in the tool your security team already uses.

Next steps

• Export to SIEM: stream audit events to your security tooling
• Administration: day-to-day VMCP and access policy management
• Admin MCP: run controls like connector restarts through an MCP client