Why GateRook is safer than raw MCP servers

An AI assistant connected to infrastructure needs more than a list of callable tools. It needs a limited scope, a way to stop risky actions, protection for credentials and returned data, and a record of what actually happened. GateRook brings those controls into one local application, between your AI clients and the systems they use.

The practical advantage is straightforward: an agent can investigate an incident, inspect a database or search logs without receiving the underlying credentials, while actions that require review stop at an enforceable approval boundary. You can see and change that boundary without rebuilding every integration.

This article describes GateRook 0.7.0. The screenshots are genuine captures of the macOS application, taken on November 4, 2026, using demo connections and synthetic data. They are cropped for readability and contain no mouse cursor. The approval example is a previously completed demo action from November 3; no production data was changed to illustrate this article.

What “raw MCP servers” means here

MCP is a protocol for discovering and invoking tools. It can be implemented securely, and many servers and clients already provide useful authentication, confirmation and logging. The MCP tools specification (opens in a new tab) recommends human control over tool invocation and requires clients to treat annotations from untrusted servers as untrusted.

Here, raw MCP means connecting an AI client directly to individual MCP servers without a shared enforcement layer. In that arrangement, security depends on the combination of each server's implementation, its credentials, the client's approval settings and the operator's configuration. Adding a second client or a fifth server can create another place where those settings diverge.

GateRook adds a consistent point at which access is checked, actions are classified, approvals are enforced, output is masked and activity is recorded. The comparison is about this architecture, not a claim that every direct MCP connection is unsafe.

The architecture: a small, explicit grant of authority

A GateRook connection describes a resource: a database, log service, SSH host, HTTP API or external MCP server. It holds the resource configuration and credential reference. An endpoint exposes a selected set of those connections and tools to an AI client. A policy constrains what those calls may do.

The request path is:

AI client
  → authenticated GateRook endpoint
  → connection scope, tool mode, policy and limits
  → exact-action approval when required
  → connector with the required service credential
  → resource
  → masking, bounded output and audit
  → AI client

The showcase endpoint connects Codex to five demo resources. Its overview makes the route through tool modes, development policy and limits visible before any tool is called. Select any screenshot to view it at full size.

This separation is useful even with a single AI assistant. You can give a troubleshooting endpoint access to logs and selected database reads, keep unrelated systems out of its catalog, and expose reviewed changes through a different endpoint. The core checks the current scope at dispatch; a remembered tool name is not a continuing grant of access.

Connection and endpoint switches also let you pause future resource access quickly. Pausing a connection applies across its endpoints; pausing an endpoint affects access through that endpoint. These controls do not cancel work that has already started. The behavior is documented in the GateRook 0.7.0 architecture (opens in a new tab).

Credentials stay behind the gateway

A database password is permission to use a database, not information the language model needs to reason about an order or an error. GateRook keeps these responsibilities separate: the agent names the connection and submits structured tool arguments; the connector obtains the credential needed to execute the allowed operation.

Locally stored secrets use AES-256-GCM envelope encryption, with a separate data key for each secret version and authenticated data binding the encrypted value to its identity and version. The master key is kept outside the application database. Saved-secret APIs expose metadata rather than a way to retrieve the original value.

The MySQL demo connection shows “Encrypted version 1” in place of its saved password. The visible user and loopback address identify a local demo account, not a production credential.

GateRook also supports references to Vault/OpenBao, AWS Secrets Manager and Google Secret Manager. This lets an existing secret-management system remain the source of credentials. Native unlock options include macOS Touch ID or password and Windows Hello where available; behavior depends on the platform and configuration.

Client authentication is separate from service authentication. Supported local bridge integrations obtain short-lived tokens automatically, while endpoint credentials are scoped, checked for expiry and revocation, and stored as hashes. Revoking a client's access therefore does not require distributing a new database password to every other client.

Encryption and secret custody reduce accidental disclosure and credential sprawl. They do not make a compromised operating-system account safe: GateRook runs on your computer and relies on its local security boundary. See the versioned security and secrets architecture (opens in a new tab) for the precise model.

Four tool modes make authority visible

GateRook lets you choose the behavior of each tool on each connection within an endpoint:

Two different decisions in one screen: Redis key scanning is automatic, but reading a key value requires approval. SQL inspection is automatic while sql_execute requires approval. Read access can itself warrant review.

The core's action classification matters here. A connection × tool pair in Read only mode does not silently authorize a mutation; it still requires approval. A read-only endpoint is a stronger boundary that blocks mutations and Bypass altogether. For built-in mutating tools, the UI disables the Read only choice to make the intended configuration explicit.

For development work, temporary Bypass can cover one endpoint × connection × tool for a fixed duration. It is available for DEV and STAGE, expires back to the underlying mode, and does not approve requests that were already waiting. It is a deliberate convenience with an explicit reduction in review, not a different name for a safe operation.

This granularity reduces unnecessary prompts without forcing a choice between approving everything and trusting everything. Keep predictable, appropriately scoped reads automatic; reserve attention for changes and sensitive disclosures.

Approval is bound to the action that will run

A chat message saying “the user approved this” is not an authorization mechanism. GateRook prepares the action, records its canonical arguments and digest, and holds the executable payload while review is pending. Before execution, it checks the relevant policy, integrity and definition state again. It executes the stored approved payload rather than accepting replacement arguments from the agent.

For example, this is the synthetic MySQL update recorded in the screenshots:

UPDATE orders
SET status = 'shipped'
WHERE id = 1001 AND status = 'pending';

The exact request identifies the connection, database and predicate. An approval for that action does not authorize a different order, a different connection or an unqualified update of the entire table. Definition or configuration changes that invalidate the prepared action require a new review.

The MCP approval handle is a reference to a pending request, not a capability to approve it. The agent can display a card and poll for its status; the card can open GateRook or decline. The decision must come through GateRook's authorized review flow; the MCP card cannot approve the action. Expiry means the request does not run. A tool description, model-generated justification or previous approval cannot substitute for that decision.

The existing demo audit event records the policy decision, notification, human approval and execution. It reports that the executed action matches the approved action byte for byte, followed by the actual one-row update result.

This is protection against a particularly costly class of mistakes: the operator reviews one action while a different action is dispatched. It does not establish that an approved action is correct or reversible. If a resource times out after receiving a write, its outcome may be uncertain; inspect the resource and audit record before deciding whether a retry is safe.

Read-only access is implemented at the connector boundary

A method name such as query or an MCP readOnlyHint cannot establish safety on its own. GateRook's built-in connectors apply controls appropriate to the underlying system:

• SQL: query validation, database/schema/table scope, row and time limits, and rollback of read transactions. PostgreSQL, MySQL and Oracle use read-only transactions. SQL Server validates SELECT forms and known functions; use a SELECT-only database login for database-enforced read protection.
• MongoDB: bounded find and aggregation operations, with write-producing aggregation stages such as $out and $merge refused by the read tool. Update tools have separate approval behavior.
• Redis: selected databases and key allow/deny patterns, incremental scans and bounded reads. A read can still require approval because returning a value may disclose sensitive information.
• SSH: saved runbooks with typed parameters and controlled command construction, host-key verification, and no interactive PTY or agent forwarding. Arbitrary ssh_exec requires separate policy enablement and is disabled by default.
• HTTP: permitted base URLs and outbound destination restrictions, with explicit treatment of private networks and blocked cloud-metadata destinations. Network validation reduces the opportunity to turn an API tool into an unrestricted internal-network client.

These controls complement the resource's own authorization. A dedicated SQL account, scoped cloud role, constrained SSH identity and narrow API token remain valuable even when the gateway is correctly configured. Connector-specific behavior and limits are described in the integration guides.

Mask results before they enter model context

Keeping a connection password out of a prompt is only half the problem. Tool results may contain tokens in log messages, credentials in URLs, personal data in documents or sensitive database columns.

GateRook applies masking centrally before results reach the agent and before corresponding sensitive values are stored in the audit trail. Its masking system covers configured secret values and recognized encodings, credential patterns, selected fields and optional personal-data patterns. This gives different connectors a shared output policy instead of requiring every integration to implement an independent redactor.

Development masking settings: credential masking is active, while email, phone, card and IBAN patterns are optional here. Explicit field rules can mask values regardless of what their text looks like.

Production defaults enable personal-data patterns that development and staging do not enable by default. Explicit field rules are useful when a value needs protection even though it resembles an ordinary name or number—for example, customers.birth_date or a sensitive MongoDB field.

Masking is defence in depth, not a guarantee of complete data-loss prevention. It cannot recognize every sensitive fact, every transformation or every possible encoding. Prefer narrow queries, projections, source-side views and minimal account permissions; then use masking as another boundary. Data that is legitimately returned to the AI client is still subject to that client's and model provider's data handling.

Bound the work, not just the permissions

An allowed read can still be expensive. A looping assistant can issue hundreds of queries; an unrestricted log search can return an enormous response; an expensive operation can occupy a connection long enough to affect other work.

GateRook combines environment, connection, endpoint and tool limits so that tighter applicable limits win. Depending on the connector, controls include rows or documents, log lines, response bytes, execution deadlines, call rates and concurrency. Resource isolation and circuit breakers also help prevent repeated failures from consuming all available capacity.

The demo endpoint shown above displays a development policy of 120 calls per minute per token and 512 KB per result. Those are configuration values from this example, not universal promises. Production defaults are stricter, and individual tools can impose smaller budgets. Truncated results are identified as truncated so an agent can distinguish a bounded answer from a complete dataset.

A read-result row limit is not a limit on the number of rows a write may change. Review the actual SQL predicate or MongoDB filter; UPDATE without a restrictive condition and update_many can affect substantially more data than a read cap suggests.

Production separation also has structural enforcement: PROD connections require PROD endpoints, and PROD endpoints use PROD connections. Production defaults deny SQL DDL, apply smaller SQL budgets, and do not allow production endpoints to be published through the built-in public tunnel feature.

Existing MCP servers can use the same controls

GateRook is not limited to built-in database and infrastructure tools. It can connect to external MCP servers over supported remote transports or launch a configured local server. Setup accepts server URLs, supported client configuration snippets and registry discovery, so existing tools can be brought into the same workflow.

The security benefit goes beyond putting another address in front of a server. GateRook stores reviewed tool definitions, exposes namespaced tools, and checks whether definitions have changed before execution. A changed definition requires review; any read-only attestation is tied to the reviewed definition and version. This reduces the chance that a tool quietly gains new advertised semantics after the operator first trusted it. A definition hash detects changes to the advertised definition; it cannot detect a server changing its implementation while advertising the same definition.

A third-party readOnlyHint remains a statement made by that server. Registry presence is a discovery aid, not proof of trust. GateRook can constrain the exposed tool and arguments, but it cannot prove that a remote implementation behaves honestly or observe every internal side effect. Review the server, restrict its upstream credentials and avoid automatically trusting newly discovered tools. See External MCP servers in GateRook 0.7.0 (opens in a new tab).

Local subprocess and extension controls add another layer: supported platforms can sandbox local MCP processes, and connector plugins run in separate hosts with bounded resources and scoped secret capabilities. Isolation differs by platform and connector; there is no blanket claim that every external process is fully sandboxed on every operating system.

Audit explains what happened, and why

A useful audit record should connect intention to effect. GateRook's Activity view links the client, endpoint, connection, tool arguments, policy decision, approval history, execution status and timing. Result metadata can include size, digest and masking count; the event shown above retains the result summary and hash rather than its full body.

Filters let you narrow investigation by endpoint, connection, tool or decision. Trace identifiers help correlate related work, exports support further analysis, and Insights summarizes usage. Setup changes have their own history, so an operator can investigate both an action and the configuration around it.

The audit implementation uses append-only constraints and integrity mechanisms, including a hash chain and authenticated state. Execution requires successful recording of its receipt. The appropriate term is tamper-evident: these mechanisms help detect alteration; they do not make a local machine or its administrator incapable of tampering. The versioned architecture (opens in a new tab) documents those boundaries.

One application for the whole workflow

The same model extends across a broad set of systems:

The desktop UI connects the operational pieces: Overview for current access and health, Connections for resource setup, Endpoints for exposure and modes, Policies for common constraints, Approvals for pending decisions, and Activity and Insights for evidence. Playground lets you inspect a tool through the same enforcement pipeline before relying on an assistant to use it.

AI-app setup supports common clients including Codex, Claude Desktop and Cursor, with configuration review and preservation of unrelated entries. GateRook can also hold and renew supported external-server OAuth credentials. Its local-first design means service access runs from your machine and can use the network access you already have, including your VPN.

When a remote client is needed, managed Cloudflared or ngrok access uses a separate public listener for selected MCP/OAuth routes, not the administration API. This is an explicit exposure choice with restrictions, including the prohibition on publishing PROD endpoints. Encrypted full backups and validation on restore help recover configuration; restored access grants and pending approvals are invalidated rather than silently reviving old authority.

These features make consistent security easier to maintain. You can inspect one permission model, manage or replace a connection's credential centrally, with source rotation where supported, reuse a connection across appropriately scoped endpoints, and troubleshoot calls without assembling evidence from several unrelated tools.

A practical configuration for safer daily work

1. Start with one task and one endpoint. Add only the connections and tools that task needs. Keep development and production separate.
2. Use narrow upstream accounts. Select only required databases, schemas, collections, keys, namespaces or API scopes. Prefer read-only credentials for investigation.
3. Make ordinary reads automatic where appropriate. Put sensitive reads and changes in Approval; leave unused tools Off.
4. Set realistic budgets. Bound rows, response bytes, time and call rate, and inspect truncation rather than assuming a partial result is complete.
5. Review the prepared action. Check the environment, target, statement or arguments and expected scope. An agent's explanation is context, not proof.
6. Inspect the resulting evidence. Verify the resource outcome when needed and use Activity to understand denials, approvals and failures. Do not blindly retry an uncertain write.
7. Review change over time. Reassess new MCP definitions, credentials, endpoint membership and temporary exceptions as the workflow evolves.

For a hands-on starting point, use the getting-started guide and the integration catalog.

Where the protection stops

GateRook limits the authority available to an agent and makes consequential actions reviewable. It does not eliminate prompt injection, prove arbitrary tool output safe, guarantee that a human approves wisely, or repair excessive permissions in an upstream service. The MCP security guidance (opens in a new tab) likewise treats authorization, local execution and proxy behavior as separate security concerns.

The desktop product has one local operator; it should not be mistaken for enterprise multi-user RBAC. Code running with the same operating-system account remains inside the local trust boundary. Native unlock is not hardware-backed proof of human presence for every later action. Bypass deliberately removes the review step. Third-party servers and connectors still need evaluation, and masking needs a policy appropriate to the data.

Within those boundaries, GateRook offers a concrete improvement over a collection of direct, independently configured MCP connections: smaller grants of access, protected credential handling, exact-action review, bounded and masked results, and an audit trail that connects a request to what actually executed. The AI assistant remains useful, while the operator retains a visible, enforceable role in deciding what it may do.