{"slug": "how-i-manage-mcp-access-approvals-and-tool-history-with-gaterook", "title": "How I manage MCP access, approvals, and tool history with GateRook", "summary": "A developer has built GateRook, an open-source desktop MCP gateway that sits between AI coding clients like Claude, Codex, and Cursor and backend systems such as databases, SSH log servers, APIs, and cloud services. The tool lets users define per-endpoint scopes and approval rules for tool calls, and records an execution history of every routed call — including denied and failed ones — with arguments, environment, policy decision, and outcome. The developer frames the design around three requirements: defined scope, control over changes, and a reviewable history.", "body_md": "I use AI coding tools such as Claude, Codex, and Cursor, and I want them to work with the systems behind my applications: databases, server logs, APIs, and cloud services.\n\nMCP makes those connections useful. But once several servers and environments are involved, I need to answer a few practical questions:\n\nThose questions are the reason I am building **GateRook**, an open-source desktop MCP gateway.\n\nI am the author of the project. In this article, I want to explain the access model, walk through a database-and-logs workflow, and describe the boundaries of the approach.\n\nA database connection is useful on its own. Add an SSH log server, a cloud integration, a few external MCP servers, and separate development and production environments, and there are more decisions to keep track of.\n\nEach integration may have its own credentials, tool names, permission model, approval behavior, and logs. Using several AI clients adds another place to configure and review those choices.\n\nThe difficult part is understanding the combined access you have granted.\n\nA request such as “investigate this failed job” might lead to several calls: discovering a schema, reading records, searching logs, inspecting infrastructure, and proposing a change. The natural-language request does not specify every step in advance.\n\nA chat transcript can explain what the assistant thinks it did. I also want an execution history that shows the tools it actually called, their arguments, the target environment, and the decisions made along the way.\n\nFor me, useful AI access needs three things together: **a defined scope, control over changes, and a reviewable history.**\n\nGateRook runs as a desktop application between the AI client and the connected services.\n\nYou add connections in GateRook, choose which connections and tools an endpoint exposes, and connect the AI client to that endpoint. The gateway handles authentication, evaluates the applicable rules, and records the calls passing through it.\n\nAn endpoint can provide one entry point for several resources. You can also keep separate endpoints for different purposes: for example, development work and production investigation.\n\nThat distinction matters. “One place to connect” should not mean “every client gets access to everything.”\n\nA small setup might look like this:\n\n| Resource | Access for an investigation | \n|---|---|\n| Development database | Read queries; changes require approval | \n| Selected application log files over SSH | List, read, and search within configured limits | \n| Production database | A separately scoped endpoint with stricter permissions | \n| External MCP tools | Only the reviewed tools needed for the task | \n\nGateRook includes built-in connectors for databases, logs, SSH, APIs, and cloud services. It can also connect external MCP servers, so existing integrations can participate in the same access model.\n\n*The Overview groups connections by endpoint and shows which AI applications are connected.*\n\nOne of the main things I wanted was a place to inspect **all tool calls routed through GateRook**, including calls that were denied or failed.\n\nThe Activity view brings together the AI client, endpoint, connection, environment, tool, arguments, policy decision, duration, and outcome information. You can filter the history to investigate a particular client, connection, tool, or time period.\n\nThis is useful for ordinary debugging as well as access control.\n\nIf the assistant produces an unexpected answer, the history helps you check whether it queried the wrong environment, searched too narrow a time range, encountered a policy denial, or received an error. If it proposes a change, you can inspect the calls that led up to that proposal.\n\n*Activity shows calls across connections and clients, including successful calls, policy denials, and errors.*\n\nRecording denied attempts matters too. A rejected operation is part of the explanation of what happened.\n\nThe scope here is specific: GateRook records activity that passes through its gateway. An agent's separate terminal commands or direct connections are outside that history. Stored payloads also have masking and size limits; a useful audit trail does not require retaining every byte of sensitive output.\n\nGateRook requires review for changes by default.\n\nWhen a call needs approval, the application presents the prepared action and its target. For a database update, that means being able to inspect the SQL, the connection and environment, the reason approval is required, and available impact information.\n\nConsider this illustrative development-database change:\n\n```\nUPDATE users\nSET email = 'new-address@example.com'\nWHERE id = 42;\n```\n\nBefore approving it, I want to check the target database, the table, the condition, and the value being written. A generic “the assistant wants to use a tool” prompt would leave too much of that review implicit.\n\nThe approval is tied to the prepared action stored by the gateway. After approval, GateRook executes that stored payload, with the applicable checks, instead of asking the model to reconstruct the command.\n\nYou can approve or deny the request. An unanswered request expires; waiting does not turn into permission.\n\n*A pending SQL request shown in the AI client. “Approve in GateRook” opens the app’s review screen; the action remains unexecuted until you approve it there.*\n\nApproval behavior is configurable. GateRook has explicit per-tool Bypass settings, and temporary bypass is available for specific tools and connections in development and staging. Bypass skips the human approval step while retaining applicable policy limits.\n\nThat makes the chosen mode part of the access decision. For a workflow where I want to review every change, I keep those tools in approval mode.\n\nTo search logs or query a database, the model needs access to an allowed operation. It does not need the underlying authentication material in the conversation.\n\nWith GateRook, connection credentials are configured on the gateway side. The model works with connection names and permitted tool arguments; GateRook handles authentication to the selected service.\n\nThat means I do not need to paste database passwords, API keys, or SSH private keys into a prompt. Stored secrets are encrypted, and the application can also reference supported external secret stores.\n\nThere is an important distinction between **connection credentials** and **the data a tool returns**. A database row or log line can itself contain sensitive information. Credential isolation therefore works alongside access restrictions, masking rules, and bounded results.\n\nThe claim is that GateRook keeps the configured infrastructure credentials out of the model's tool arguments. It is not a guarantee that every possible secret in arbitrary source data will be detected, or that a separate agent with broad access to the same computer cannot reach files through another route.\n\nThe SSH log connector is a concrete example of this approach.\n\nYou configure SSH authentication in GateRook and explicitly select the remote files the connection may access. The AI can then use structured tools such as:\n\n`ssh_logs_list` to discover the selected files.`ssh_logs_read` to read a bounded portion of a file.`ssh_logs_search` to search by text, level, and event time.\nFor example, after configuring a connection named `server-logs` and selecting `app.log`, a search could use these arguments:\n\n```\n{\n  \"connection\": \"server-logs\",\n  \"file\": \"app.log\",\n  \"query\": \"timeout\",\n  \"matchMode\": \"literal\",\n  \"levels\": [\"ERROR\", \"WARN\"],\n  \"from\": \"-1h\",\n  \"to\": \"now\",\n  \"maxLines\": 50\n}\n```\n\nThe request identifies the connection, file, filters, and desired output size. It contains no SSH private key.\n\nGateRook builds the bounded commands used to read the selected files. The AI cannot supply an arbitrary shell command through these dedicated log tools.\n\n*An SSH log search in Activity, with the client, connection, timing, and structured arguments available for inspection.*\n\nThe result still needs to be interpreted carefully. Time filters depend on timestamps in the records, and size or time limits can produce partial results. A bounded search returning no matches is not proof that an event never happened.\n\nThe [SSH log connector guide](https://github.com/msrv-ai/gaterook/blob/main/docs/ssh-log-files.md) explains file selection, timestamp parsing, limits, and continuation.\n\nA gateway is more useful if it can work with integrations you already have.\n\nGateRook supports external MCP servers alongside its built-in connectors. You choose which tools are exposed through an endpoint and manage their access modes there.\n\nConnections and tools can be enabled or disabled as the task changes. Tools switched off are not exposed or callable through that endpoint. This gives me a central place to narrow access when an investigation finishes or a resource is no longer needed.\n\nCompatible clients receive tool-list change notifications. Client discovery and caching behavior still vary, so the gateway's enforced permissions and what a client currently displays are separate concerns.\n\nExternal MCP servers also remain software you must trust appropriately. GateRook requires review of external tool definitions and does not treat an upstream `readOnlyHint` as proof that an operation is harmless.\n\nHere is an example workflow using those pieces together. It is an illustration of the setup, not a benchmark or an incident report.\n\nSuppose a background job is failing and you want the assistant to compare its database state with its application logs.\n\nThis connects the investigation, the proposed action, and the execution record. It also gives the person reviewing the work a place to make a decision outside the assistant's explanation.\n\nThe same application includes connection health, environment-aware policies, execution and output limits, a Playground for trying tool calls, and Insights derived from the audit history.\n\nHTTP APIs can be added through OpenAPI import, with the server, authentication, and selected operations reviewed before they become tools.\n\nThe [architecture document](https://github.com/msrv-ai/gaterook/blob/main/docs/ARCHITECTURE.md) describes the call flow, credential handling, approval model, and implementation boundaries in more detail.\n\nGateRook is still in development. Its current scope is a desktop application for one local user.\n\nThere are practical tradeoffs to work through. A central gateway becomes an additional component to configure and trust. Approval prompts need enough detail to support a real decision without making routine work exhausting. Audit history needs enough context to explain events while respecting sensitive data and retention limits.\n\nI want the access model to stay understandable as the number of connections grows. At any point, I should be able to see what an AI client can reach, review a consequential action, and trace what actually happened.\n\nIf you use several MCP servers, I would be interested in how you handle that today. Which operations do you review manually, and what information do you need in a tool-call history to investigate a problem?\n\nGateRook is available under the Apache 2.0 license.", "url": "https://wpnews.pro/news/how-i-manage-mcp-access-approvals-and-tool-history-with-gaterook", "canonical_source": "https://dev.to/w4p/how-i-manage-mcp-access-approvals-and-tool-history-with-gaterook-4i8n", "published_at": "2026-11-01 22:16:08+00:00", "updated_at": "2026-11-01 22:21:51.031649+00:00", "lang": "en", "topics": ["ai-agents", "agent-protocols", "ai-tools", "developer-tools", "ai-safety"], "entities": ["GateRook", "Claude", "Codex", "Cursor", "MCP"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/how-i-manage-mcp-access-approvals-and-tool-history-with-gaterook", "markdown": "https://wpnews.pro/news/how-i-manage-mcp-access-approvals-and-tool-history-with-gaterook.md", "text": "https://wpnews.pro/news/how-i-manage-mcp-access-approvals-and-tool-history-with-gaterook.txt", "jsonld": "https://wpnews.pro/news/how-i-manage-mcp-access-approvals-and-tool-history-with-gaterook.jsonld"}}