They can easily build and view their own versions of the gmail stack, but they would not be able to generate auth tokens to decode the private data of accounts they did not have passwords for.

I was more thinking of deploying trojan-code into the production service (as a trivial example, allow a special password to access any account): it can't be practical to vet every production service change through too many people.

You seem to suggest that you are using an encryption key based on the password or oauth token on login, which is great to hear, which stops the simpler forms of trojans like the example above. That makes it much more involved to achieve the same (and login from new computer reports make it harder too), especially undetected (because it has to happen over a short period) but not impossible (thinking of cases like just making a new API endpoint or perusing an existing one to store actual content in an often unlooked at log file/service).