Read-only OAuth is one boundary. Your agent still needs others.

By Xplormity Collective

A coding agent asks for Search Console data. You approve a read-only Google scope. Can it change your website? The answer depends on which tool it uses next.

Read-only OAuth limits the Google operations authorized by that grant. It does not turn the entire agent session into a read-only environment. An agent that can also edit files, run a shell or send messages still has those capabilities.

We maintain SearchDock, an open-source Search Console client. This walkthrough examines its public implementation, rather than reporting a live experiment. The examples below are synthetic, use reserved example domains and contain no credentials or real search data. No authenticated commands were executed for this article.

Separate four questions before connecting an agent

1. What can the OAuth grant authorize at the remote service?
2. Which operations does this particular adapter implement?
3. What other tools can the host agent invoke?
4. Where can returned data and local credentials end up?

These questions describe different boundaries. Checking one does not settle the others.

1. Inspect the scope and the implementation

In src/auth.js, SearchDock requests exactly:

https://www.googleapis.com/auth/webmasters.readonly

The consent flow uses a loopback callback bound to 127.0.0.1, an S256 PKCE challenge and a random state value. The callback validates state. Initial login requires an offline refresh token and the exact expected scope. Token exchange rejects a different scope when Google supplies a scope in the response.

Those are observations about this source revision, not a security certification or a claim that every installed version behaves identically. Review the release you actually install.

Then inspect src/providers/google.js. Its implemented operations list properties, read analytics, read sitemaps and inspect Google's indexed version of a supplied URL. A report combines these operations. There is no request-indexing operation in this adapter.

An important detail: an HTTP POST is not necessarily a write to the underlying resource. Search analytics queries and indexed-URL inspections use POST requests in this implementation. Judge an operation by its endpoint and semantics, rather than its HTTP verb alone.

2. Tool annotations describe intent; handlers implement behavior

src/mcp.js registers five tools:

Each registration includes readOnlyHint: true, destructiveHint: false, idempotentHint: true and openWorldHint: true. These annotations communicate intended behavior to clients. They are not the mechanism that enforces Google's OAuth grant, and they do not constrain unrelated tools in the host.

Trace the handlers through selectedContext into the provider. That gives a more useful review than trusting a label alone. The MCP handlers use an already-connected profile; they do not start consent or change account settings. Local CLI setup is a separate path: selecting a site writes a local profile, and logging out deletes its local file.

3. A selected property is a default, not a sandbox

SearchDock lets a user select a property for convenient later requests. selectSite checks that the exact property appears in the properties returned by Google before saving it.

However, the MCP tools also accept an explicit site, and selectedContext prefers that value over the saved default. Saving sc-domain:example.com therefore does not create an application-level rule that every future request must use that property. Google's authorization still applies, but the saved selection is not an additional per-agent allowlist.

If your workflow requires one-property access, enforce that restriction in a reviewed wrapper or host configuration. Confirm the restriction works for explicit tool arguments too. Merely telling an agent which property to use is a workflow instruction, not a new access-control boundary.

This distinction is useful beyond analytics tools: a remembered workspace, project or account often provides convenience without narrowing the credential's underlying access.

4. Use an inspection plan with explicit limits

Here is a synthetic tool-input example, not a captured request or an execution result:

{
  "site": "sc-domain:example.com",
  "start": "2026-09-01",
  "end": "2026-09-30",
  "urls": ["https://example.com/guide"]
}

This illustrates the shape of searchdock_report input. It does not demonstrate that any account can access that example property.

A practical request to an agent could be:

Read the selected property's finalized metrics for the specified month. Inspect only the one supplied URL. Summarize observations and uncertainty. Do not modify files, publish anything or request indexing. Ask before using any other tool.

The last sentences describe intended workflow policy. Whether they are enforceable depends on the host's permissions. Prefer actually limiting tools when that is available, rather than relying on instructions alone.

Interpret the output narrowly. SearchDock's default reporting window ends three days before today in Pacific Time. Exact dates can be supplied. Search Console returns top rows and omits some anonymized query data; absent rows do not establish absent demand. An indexed-URL inspection describes Google's indexed version, not a live-page test. A report's issue list covers returned sitemap information and the URLs explicitly inspected, not every indexing exclusion for a site.

5. Read-only data can still be private

A query report can expose customer interests, business performance and unpublished page paths. Reading it successfully does not make it suitable for a public screenshot or an external model provider.

The repository's privacy documentation says the release has no SearchDock backend or telemetry endpoint. It also states that agents and MCP clients may handle returned data under their own settings. A local tool cannot establish the privacy behavior of every host that consumes its output.

Before sharing a result, remove property identifiers and sensitive queries, check the receiving service's data handling and use synthetic examples for public teaching. Do not include OAuth client files, profile files, sign-in URLs or tokens in screenshots, prompts or issue reports.

6. Local permissions are not encryption

src/storage.js writes profiles as local JSON. Unix file modes and Windows directory ACLs restrict access, but SearchDock does not encrypt that JSON or place it in a dedicated credential vault. That matters when choosing a machine, reviewing backups or granting another process access to the same account.

The documented logout command deletes a local profile. Revoking the grant at Google is a separate step through Google Account permissions. Deleting one file does not prove that every backup or copied credential has disappeared.

A review checklist you can reuse

• Match the installed release to the code you reviewed.
• Identify the exact OAuth scope and the implemented remote operations.
• Trace tool handlers, including optional arguments that override defaults.
• Review the host's shell, filesystem and publishing permissions separately.
• Decide where credentials, reports, logs and model inputs may be stored.
• Distinguish saved defaults from enforced allowlists.
• Separate local logout from provider-side revocation.

For this source review, the useful conclusion is specific: SearchDock's Google grant and exposed MCP operations are read-only, while local setup, host capabilities and downstream data handling remain separate concerns. That is a clearer basis for a workflow decision than treating the entire agent as safe because one integration says read-only.

Source snapshot

Reviewed public revision 28b39813308ae834e606c9290a1e68b35e788ceb, 2026-11-14. Links below are pinned so later changes do not silently alter the evidence.

• README
• OAuth implementation
• MCP tools
• Context and selection
• Google adapter
• Storage and privacy documentation

Disclosure: Xplormity Collective maintains SearchDock. This article was prepared with AI assistance and checked against the cited source. It is a source walkthrough, not an executed demo or an independent security audit.