Secure Web Proxy next-hop routing: source.matchServiceAccount() does not match Compute Engine VM

I'm investigating a source-identity policy matching issue with Google Cloud Secure Web Proxy in NEXT_HOP_ROUTING_MODE.

Configuration

• Compute Engine VM with a dedicated, enabled service account

• Private VPC, no external VM IP

• Next-hop Secure Web Proxy with gateway security policy

• TLS destination: fhir.epic.com:443

• Source VM service account verified through Compute Engine configuration

• No TLS inspection or application data involved

Diagnostic policy rules

Priority 70: DENY
source.matchServiceAccount('PROBE_SA')

Priority 80: DENY
host() == 'fhir.epic.com'

Priority 90: DENY
source.matchServiceAccount('PROBE_SA')
&& host() == 'fhir.epic.com'

Observed results

• The VM's TCP connections reach Secure Web Proxy.

• VPC firewall logs confirm the diagnostic connections were permitted.

• SWP logs correctly identify fhir.epic.com from TLS SNI.

• The hostname-only DENY rule matches.

• The service-account-only DENY rule does not match.

• The combined service-account and hostname rule does not match.

• The service account exists, is enabled, and is correctly attached to the VM.

• SWP transaction logs do not expose a clientServiceAccount value.

Questions

1. Are there additional prerequisites for source.matchServiceAccount() in next-hop Secure Web Proxy mode?

2. What can prevent SWP from attributing traffic to a correctly attached Compute Engine service account?

3. Is there a supported way to diagnose source-identity attribution without weakening the security policy?

4. Can empty VM OAuth access scopes affect this attribution?

This is an isolated staging environment. We have preserved correlated firewall and SWP evidence and can provide sanitized diagnostic details if needed.

We need to retain service-account-based authorization rather than using a hostname-only ALLOW rule.