Here's how it could work.

In devproxyrc.json, you activate the new plugin and specify the path to the file that defines scopes for the different CSOM actions:

{
  "$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v0.25.0/rc.schema.json",
  "plugins": [
    {
      "name": "MinimalSharePointCSOMPermissionsPlugin",
      "enabled": true,
      "pluginPath": "~appFolder/plugins/dev-proxy-plugins.dll",
      "configSection": "minimalSharePointCSOMPermissionsPlugin"
    }
  ],
  "urlsToWatch": [
    "https://*.sharepoint.com/*"
  ],
  "minimalSharePointCSOMPermissionsPlugin": {
    "$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v0.25.0/minimalsharepointcsompermissionsplugin.schema.json",
    "permissionsFile": "csom.json"
  },
  "logLevel": "information",
  "newVersionNotification": "stable",
  "showSkipMessages": true,
  "record": true
}

In the csom.json file, which we ship with Dev Proxy, we define the list of actions and the supported scopes:

{
  "$schema": "schema.json",
  "types": {
    // for readability to map CSOM type GUIDs to human-readable names
    "268004ae-ef6b-4e9b-8425-127220d84719": "Microsoft.SharePoint.SPTenant"
  },
  "actions": {
    "268004ae-ef6b-4e9b-8425-127220d84719.RemoveDeletedSite": {
      "delegated": [
        // all permissions that can be used to perform this operation
        // sorted ascending by privilege level, least privileged first
        "AllSites.FullControl"
      ],
      "application": [
        "Sites.FullControl.All"
      ]
    }
  }
}

We include these mappings in a separate files, so that users are not blocked in case they need actions that we haven't documented yet.

At runtime, this plugin intercepts requests to /_vti_bin/client.svc/ProcessQuery and parses the body to get the list of actions, and the necessary permissions to perform them.

The complexity of the implementation is twofold:

1. Properly parsing CSOM request bodies to get the operations
2. Mapping the SharePoint permissions supported by each operation

nice idea 👍
Unfortunately I don't have anything creative to add. I really like the idea in the csom.json to add the types node which allows to define GUID to something more meaningful to humans.
Maybe if we already define that "268004ae-ef6b-4e9b-8425-127220d84719": "Microsoft.SharePoint.SPTenant" then in the actions node we define scopes as "Microsoft.SharePoint.SPTenant.RemoveDeletedSite": { ... instead of "268004ae-ef6b-4e9b-8425-127220d84719.RemoveDeletedSite": {.... So also here drop the GUID. What do you think?

We could do absolutely do that @Adam-it. That's a nice suggestion that'll make it all a bit more readable with fewer look up, especially as the file grows.

Here's a POC of how detecting permissions from CSOM requests could work: https://github.com/waldekmastykarz/dotnet-parse-csom