This is a bug I reported to Google via Google's Vulnerability Rewards Program on Aug 23, 2019.

Below is an intact reproduction of the report sent to Google (I formatted several parts so they are better looking here, I could only send plain text to Google, and I censored some parts):

Steps to reproduce

1. Open a new tab in Chrome and open https://productexperts.withgoogle.com.
2. Click the "sign in" button in the upper right corner and sign in with any Google Account.
3. After signing in, open the developer tools in that tab and open the Network tab of the developer tools (click the XHR button in order to show only XHR requests which will make the third step easier).
4. Navigate to the following URL: https://productexperts.withgoogle.com/profile
5. Now find in the requests list a request to https://content-alkalibento-pa.googleapis.com/batch[...] (be careful! before the requests to https://content-alkalibento-pa[...] there is one request to https://content-alkalicore-pa[...], which is a different URL)
6. Click on one of those requests to open it and go to the "request payload" section in the Headers tab, which will look like this:

--batch123456789012345678
Content-Type: application/http
Content-Transfer-Encoding: binary
Content-ID: <batchbatch123456789012345678+gapiRequest@googleapis.com>

GET /v1/user/language?key=thisisarandomstring
X-JavaScript-User-Agent: google-api-javascript-client/1.1.0
X-Requested-With: XMLHttpRequest
X-Goog-Encode-Response-If-Executable: base64
Authorization: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
X-ClientDetails: appVersion=5.0%20(X11%3B%20CrOS%20x86_64%2012239.67.1)%20AppleWebKit%2F537.36%20(KHTML%2C%20like%20Gecko)%20Chrome%2F76.0.3809.102%20Safari%2F537.36&platform=Linux%20x86_64&userAgent=Mozilla%2F5.0%20(X11%3B%20CrOS%20x86_64%2012239.67.1)%20AppleWebKit%2F537.36%20(KHTML%2C%20like%20Gecko)%20Chrome%2F76.0.3809.102%20Safari%2F537.36

--batch123456789012345678--

7. Copy the authorization token which is sent in the request (in the sample I provided in step 4 it is marked with XXXXX[...]XXXXX).
8. In a terminal, run the following command (assuming curl is installed), replacing XXXXX[...]XXXXX with the authorization token we got in the previous step:

curl https://alkalibento-pa.googleapis.com/v1/whitelist -H "Content-Type: application/json" -H "Authorization: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"

9. You'll get a list of users in the whitelist specifying whether they have registered in Bento or not.
10. Copy one of the emails which are set as "NOT_REGISTERED", and run the following command, replacing YYYYYY with the email address of the user you want to remove from the whitelist and XXXXX[...]XXXXX with the authorization token:

curl -X DELETE https://alkalibento-pa.googleapis.com/v1/whitelist/YYYYYY -H "Content-Type: application/json" -H "Authorization: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"

11. Now run again the command of step 6, and check that the email chosen in step 8 is indeed removed from the whitelist.

I don't know what is the use of the whitelist, but from the information it gives and the context of the application, I'm supposing this whitelist is used to allow people to register in or access the Bento platform.

Browser/OS: Chrome OS 76.0.3809.102

Attack Scenario

To exploit this vulnerability the only requisite for the attacker is to have a Google Account in order to authenticate themselves. Thus, following the steps outlined above any Google user could view a list with the emails of all the Google Product Experts who are using or are invited to use Bento, and also manipulate the whitelist removing users from it. This means all emails of a part of the Google Product Experts ([REDACTED]) are exposed to the public in general.

Also, although I haven't tested it, it may be possible to remove the access to Bento to someone who is already registered.