google-drive has four grants pointing at tools the connector no longer advertises:
google-drive/copy_filegoogle-drive/create_filegoogle-drive/download_file_contentgoogle-drive/get_file_permissions
They are inert only because the REST adapter does not advertise them. listForAgent joins
plugin_grants to mcp_tools, so a grant naming a tool that is not in the tool list offers nothing
to a model.
That is a property of the transport, not of the grant. Google's Drive MCP server advertises all eight
names, and the adapter deliberately uses the same names character for character so grants survive a
transport swap. So setting transport: "mcp" back on the catalogue entry — one field, done when the
Developer Preview opens — silently re-enables create_file and copy_file on a connector whose whole
description says read-only.
Two things stop it being exploitable today, and neither is the grant table: the requested scope is
drive.readonly, so Google refuses a write; and both names are in the entry's writeTools, so the
policy engine sees them as writes. That is the belt-and-braces working as intended. But the grant row
is the thing an administrator reads to answer "what may this Bot do", and it currently says something
that is only false by accident.
Suggested fix
Have refreshTools delete grants for tools that are no longer advertised, in the same transaction
that replaces the tool list. A tool a connector has stopped offering is a tool nothing should hold,
and the tool list is already replaced wholesale rather than merged for the same reason.
Worth deciding deliberately rather than defaulting: pruning means a vendor briefly mis-reporting its
tool list would drop grants an administrator then has to make again. The alternative is to surface
them — show a granted tool the connector does not advertise, and say so — which keeps the
administrator's decision and makes the discrepancy visible.
Found in review of #97, where the grants were left rather than pruned silently.
google-drivehas four grants pointing at tools the connector no longer advertises:google-drive/copy_filegoogle-drive/create_filegoogle-drive/download_file_contentgoogle-drive/get_file_permissionsThey are inert only because the REST adapter does not advertise them.
listForAgentjoinsplugin_grantstomcp_tools, so a grant naming a tool that is not in the tool list offers nothingto a model.
That is a property of the transport, not of the grant. Google's Drive MCP server advertises all eight
names, and the adapter deliberately uses the same names character for character so grants survive a
transport swap. So setting
transport: "mcp"back on the catalogue entry — one field, done when theDeveloper Preview opens — silently re-enables
create_fileandcopy_fileon a connector whose wholedescription says read-only.
Two things stop it being exploitable today, and neither is the grant table: the requested scope is
drive.readonly, so Google refuses a write; and both names are in the entry'swriteTools, so thepolicy engine sees them as writes. That is the belt-and-braces working as intended. But the grant row
is the thing an administrator reads to answer "what may this Bot do", and it currently says something
that is only false by accident.
Suggested fix
Have
refreshToolsdelete grants for tools that are no longer advertised, in the same transactionthat replaces the tool list. A tool a connector has stopped offering is a tool nothing should hold,
and the tool list is already replaced wholesale rather than merged for the same reason.
Worth deciding deliberately rather than defaulting: pruning means a vendor briefly mis-reporting its
tool list would drop grants an administrator then has to make again. The alternative is to surface
them — show a granted tool the connector does not advertise, and say so — which keeps the
administrator's decision and makes the discrepancy visible.
Found in review of #97, where the grants were left rather than pruned silently.