The script does:

var res = bridge.getGlobalAppServiceProxy().readSelectedProperties(["MY_SECRET_PROPERTY"]);
if (!res || res.status !== 200 || !res.data || !res.data["MY_SECRET_PROPERTY"]) {
    bridge.logError("failed to read MY_SECRET_PROPERTY");
}

Running it from the portal returns:

{
  "response": {
    "logList": [
      { "level": "error", "message": "failed to read MY_SECRET_PROPERTY" },
      { "level": "error", "message": "skipped POST: bearer token unavailable" }
    ],
    "callStats": { "globalApp": { "READ_SELECTED_PROPERTIES": 1 } },
    "callCounts": { "total": 4, "api": 2 },
    "status": 200
  },
  "duration": 17
}

So the call is made and succeeds — READ_SELECTED_PROPERTIES: 1, status 200, no exception — but the requested key is absent from data. It is silently filtered rather than reported.

A non-secret property in the same app is read successfully by the same proxy on every run. The Secret flag is the only difference between the two. Support confirmed this behavior is expected, and I see no Sys-prefixed read method for properties in the docs — only SysCreateProperty* / SysUpdateProperty*.

The suggested workaround was to keep the secret in our server environment and read it from there, but Cloud Code runs on brainCloud's infrastructure — a .ccjs script has no access to our environment variables or secrets manager. Global Properties appears to be the only config store Cloud Code can read, so flagging one Secret makes it unreachable by the layer that needs it.

Questions

1. Is there any supported way to read a Secret Global Property from Cloud Code?
2. If not: what is the recommended pattern for a secret that Cloud Code itself consumes, rather than one our backend consumes? Unchecking Secret would expose the token to any authenticated client via GlobalApp.ReadProperties(), which we can't accept in production.

Thank you.