Google Drive is unvalidated at the last hop

[davidmckayv]

Raised from the pre-release validation pass. Nothing has ever come back from Google Drive. Everything OpenBot owns on that path is verified; the hop from OpenBot to Google has never run.

This is not a defect report. It is a gap in evidence, filed so the release notes do not claim more than has been tested.

What is verified

A Bot calls the tool, and the whole chain up to Google works and is on the trail:

{
  "bot": "risk-analyst",   "tool": "search_files",
  "server": "google-drive", "effect": "read",
  "actor":     "AqarPaoMdN0KXTpLJaObzBNey7KDNaJE",
  "reachedAs": "AqarPaoMdN0KXTpLJaObzBNey7KDNaJE",
  "decision": { "mode": "enforce", "rule": "true", "allowed": true, "carriedOut": true },
  "failure": "You have not connected your Google Drive account. Connect it in Settings and ask again."
}

• the Bot authenticates its callback
• the grant is checked
• the boundary is evaluated
• mcp.call_failed is written
• a per-person credential is resolved, and reachedAs equals the asking user, which is the whole point of the design
• effect: read is the read/write classification
• the refusal names a cause somebody can act on

The surfaces are right too: /admin/plugins/google-drive enables, shows the exact redirect URI built from OPENBOT_PUBLIC_URL, lists the four read tools, and /settings/connected-accounts/google-drive refuses with "Google Drive has no OAuth client registered yet. An administrator has to add one first."

What is not verified

• a real consent flow completing
• a real search_files / list_recent_files call returning real files
• returned filenames checked against the audit row, so the answer is known to have come from Google rather than from the model

Why it stopped there

Registering the OAuth client needs a Google Cloud account, and per docs/plugins/google-drive.md it is more than pasting a secret:

• enrolment in the Developer Preview Program, which the doc calls "the step with the least evidence that it is missing" — without it everything else can be correct and still return The caller does not have permission
• both drive.googleapis.com and drivemcp.googleapis.com enabled; the connector talks to the second
• consent screen carrying drive.readonly, with each person listed as a test user while the app is in Testing
• a Web application client whose redirect URI matches character for character

The GOOGLE_OAUTH_* values in .env are a sign-in client and cannot serve: different callback path, and none of the above. Sign-in itself is separately verified and works.

The browser route is not a substitute. Google refuses sign-in from headless browsers, and a Bot holding somebody's Google session in its own profile is exactly the second copy of their access that this connector exists to avoid.

To close this

1. Register the client per the doc.
2. /admin/plugins/google-drive → paste the client, Refresh tools.
3. /settings/connected-accounts/google-drive → Connect, complete consent.
4. Ask a Bot to search Drive.
5. Check the returned filenames against the mcp.call_succeeded row, and confirm a second person asking the same question gets their own answer.

Step 5 is the one that matters. A list of files in the transcript is not evidence on its own.

Until then

Release notes should not say Drive works. What can be said is that the connector is wired, governed, per-person and audited up to the vendor call, and that the vendor call is untested.

[davidmckayv]

Diagnosed. The blocker is Google's preview allowlist, not this repository.

Went into the Cloud Console for the project this deployment's client belongs to (openbot-auth) and found the setup is further along than assumed, and failing at a place no code change reaches.

The setup is already correct

The OAuth client OpenBot local development already carries the plugin callback:

http://localhost:3001/api/auth/callback/google      ← sign-in
http://localhost:3010/api/auth/callback/google
http://localhost:3001/api/plugins/oauth/callback    ← the Drive plugin

Both APIs are enabled:

API	Requests	Errors
Google Drive API	17	0%
Drive MCP API	6	100%

So drive.googleapis.com works. drivemcp.googleapis.com — the one the connector actually talks to — does not.

The failure, exactly

Drive MCP API → Metrics, filtered to this same credential:

• Traffic by response code: 403
• Errors by API method: 100%, on google.apps.drive.mcp.v1.DriveMcpService.ListFiles and google.apps.drive.mcp.v1.DriveMcpService.SearchFiles

Those are precisely the two methods behind list_recent_files and search_files. Every call this project has ever made to them has 403'd, and the service is listed as Enabled.

Why

Enabling the API is not the same as being allowed to call it. drivemcp.googleapis.com is part of the Google Workspace Developer Preview Program, and a project that is not enrolled can have every other step correct and still be refused. Independent diagnoses of this exact symptom agree: the block sits at the *mcp.googleapis.com service layer, and nothing changed client-side fixes it until the project is allowlisted.

Which is what docs/plugins/google-drive.md already warns, and it was right:

It refuses with The caller does not have permission, which says nothing about enrolment. Do this first; it is the step with the least evidence that it is missing.

The doc is accurate. This is now measured rather than predicted.

What closes it

Enrol the project at https://developers.google.com/workspace/preview, then re-run the check. No re-authentication is needed afterwards; existing tokens keep working.

What this changes about the release

It sharpens the note rather than softening it. The connector is wired, governed, per-person and audited up to the vendor call — verified. The vendor call cannot succeed for this project yet, and the reason is on Google's side and is now evidenced rather than suspected.

Release notes should still not claim Drive works. They can accurately say the connector is complete and blocked on Workspace Developer Preview enrolment.

[davidmckayv]

Correction: I got the previous comment wrong. The preview gate does not apply.

I diagnosed a blocker this connector does not have. Correcting it rather than leaving it to be believed.

The catalogue does not use drivemcp.googleapis.com. It uses the generally-available REST API:

host: "https://www.googleapis.com",
path: "/drive/v3",
transport: "google-drive-rest",

drivemcp.googleapis.com appears in this repository only inside comments explaining why it is not used. There is no live reference to it anywhere in server/src or app/src.

And google-drive-rest.ts says exactly why, in its own words:

Google publishes a hosted MCP server for Drive, drivemcp.googleapis.com, and pointing the catalogue at it was the original design… It is gated behind the Google Workspace Developer Preview Program, and refuses an unenrolled project with The caller does not have permission — a statement about the project, not the credential, so every check available locally says the setup is correct. It is.

The REST API underneath has been generally available since 2015. So this trades "no code" for "no dependency on a preview", which for a connector people rely on is the better side of the trade.

That decision landed in #97, tonight. It is the same trap I fell into, already found and already designed around.

So what were the 403s?

Historical. Those 6 Drive MCP calls predate #97, from when the catalogue still pointed at the preview host. The metrics window is 30 days, so they are still on the chart. They say nothing about the current code.

The row that matters is the other one:

API	Requests	Errors
Google Drive API (what the connector uses)	17	0%
Drive MCP API (no longer used)	6	100%

What is actually left

Not an enrolment. Not a Google-side application. Just:

1. Register the OAuth client at /admin/plugins/google-drive — the client already exists and already carries http://localhost:3001/api/plugins/oauth/callback
2. Confirm the consent screen carries https://www.googleapis.com/auth/drive.readonly
3. Connect an account and ask a Bot

Which is a much smaller thing than the previous comment claimed, and possible tonight.

Ignore the enrolment advice above. It described the design this connector deliberately moved away from.

[davidmckayv]

Closed by validation. Drive works, and it is proven with files.

A Bot searched a real Google Drive and returned real filenames:

Exact filenames returned:
OpenBot PRD: Knowledge, Cloud, and Per-User Access
OpenBot PRD: Knowledge, Cloud, and Per-User Access
OpenBot PRD: Knowledge, Cloud, and Per-User Access

Cross-checked against the same tool called directly, which returned the same files with their doc ids, docs.google.com links and modified times. The audit row:

{
  "bot": "risk-analyst", "tool": "search_files",
  "server": "google-drive", "effect": "read",
  "actor":     "AqarPaoMdN0KXTpLJaObzBNey7KDNaJE",
  "reachedAs": "AqarPaoMdN0KXTpLJaObzBNey7KDNaJE",
  "decision": { "mode": "enforce", "rule": "true", "allowed": true, "carriedOut": true }
}

reachedAs equal to actor is the whole per-person thesis, recorded: the tool was reached as the person asking, not as a service account. effect: read is the read/write classification.

So every step named in the original issue is now done: consent completed, a real call returned real files, and the filenames were checked against the trail rather than taken from the transcript.

What finishing it turned up

Two defects, neither of them Drive's, both now fixed:

• A granted MCP tool returns nothing to a Bot and leaves no audit row #135 / Record a Bot callback that could not prove which Bot it was #136 — a Bot whose callback could not be authenticated was refused with no audit row at all. It returned nothing to its own model, and the model said "no files were returned": a false negative delivered as an answer, with every place you would check agreeing nothing had happened. Now recorded as mcp.callback_refused, and read correctly by Admin rather than falling through to "Allowed".
• Stop treating a service that answers as a service that is current #137 — the drift that caused it. start.sh skipped any service that was already answering, so a secret it had just minted reached neither the Bot container nor the server.

The second was found because of the first: after #136 landed, the same failure took seconds to diagnose instead of an hour.

For the release notes

Drive can be described as working. It is a governed, per-person, audited connector reaching the vendor as the person asking, and that has been driven end to end rather than reasoned about.

Two things worth carrying into the notes as setup facts rather than caveats:

• The connector uses the GA REST API, not drivemcp.googleapis.com. No Developer Preview enrolment is required. (My earlier comment claiming otherwise was wrong and is corrected above.)
• An administrator still has to register an OAuth client whose authorised redirect URIs include <OPENBOT_PUBLIC_URL>/api/plugins/oauth/callback, and each person connects their own account. docs/plugins/google-drive.md is accurate on both.