| We have a real setup that treats this challenge as a network isolation problem instead of an auth problem. Have you considered that approach? Meaning: instead of trying to authenticate to the preview app, make the preview app only reachable via an encrypted application-layer channel. The "authentication" becomes having the encryption key to that channel. For AI agents, this could simplify things: Agent generates an encryption key when spinning up preview
Preview app runs in isolated network (e.g., behind a customized Envoy proxy doing application-layer encryption without PKI/TLS)
Agent communicates with preview over the secure channel
No OAuth redirect URLs needed at all The pattern we've been using is basically "encrypted lanes" between services - each preview gets its own lane(s), fully ephemeral. When the preview dies, the lane disappears. Main downside is this doesn't help if you need humans to access the previews with their SSO credentials. But for agent-to-preview-app workflows, it's been cleaner than fighting OAuth's assumptions. Curious if you've explored this direction or if there are constraints that make network isolation insufficient? |
Are you suggesting to completely disable authentication inside the app and rely only on the encrypted channel? If yes, that’s not always an option — many apps have logic that depends on an authentication context, even in preview environments.
If not, how do you translate network-level authentication into app-level authentication? In other words, how does the app know who the caller is, beyond the fact that they can reach it over an encrypted lane?
The idea of treating this as a network isolation problem makes sense, but I’m trying to understand how it works when the app itself still expects a real auth context.