Document Application Integration credential access

[carlospolop]

Summary

• document the exact-permission integrations.authConfigs.get credential-disclosure path and its Critical classification
• document the exact-permission integrations.integrations.invoke stored-credential workflow path and its conditional High classification
• explain Gmail, Drive, Workspace, and HTTP connector scope boundaries without claiming arbitrary-user or domain-wide access
• add known-resource, source/Terraform/log, Cloud Asset, and read-only IAM fallbacks for principals without list permissions
• make explicit that GCPPEASS only checks IAM and never retrieves an auth profile or invokes a workflow

Live validation

Both paths were independently tested on 2026-09-08 in the authorized disposable gcp-labs-ly3gvnn7 project.

For integrations.authConfigs.get, a custom role contained only that permission. Before binding, profile GET and LIST returned 403. After binding, GET returned 200 with the exact synthetic bearer token while LIST remained 403, and project testIamPermissions returned only the get permission from the candidate set.

For integrations.integrations.invoke, project testIamPermissions returned only the invoke permission from the candidate set. Integration list/version GET, Secret Manager access, direct connector action execution, service-account actAs, and token minting remained denied. The principal still invoked a deliberately published workflow; a controlled endpoint confirmed that its synthetic API key was attached without logging or returning the key.

No real Workspace credential or data was used. Every created auth profile, connection, integration, IAM binding, custom role, service account, secret, Cloud Run resource, image, source artifact, service-agent grant, and temporary API enable was removed. A final audit found zero test resources and both APIs disabled.