There’s also a related issue: many services use per-project API tokens. When agents need access to multiple projects, you have to pass several tokens at once. Which often leads to confusion and erratic behavior, including severe hallucinations.
- The application code is exactly the same in prod and preview environments. The only thing that changes is the OAuth provider configuration (endpoints, secrets, etc.), not the auth flow itself.
- The mock lets you specify a user ID / username directly on the sign-in screen, without real credentials or email verification. That makes it usable both for humans testing previews and for agents or automated test suites.
- It also lets us simulate third-party identity providers (Google, etc.) without actually integrating with them in previews. Dealing with things like captchas or provider-side enforcement in ephemeral environments is another source of friction we wanted to avoid.
It’s not real auth, but it keeps previews fully functional and avoids special-casing large parts of the app just to make OAuth work with dynamic URLs.
This sounds like an interesting approach. I’m not fully sure I understand one thing though.
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.
> Wouldn't the client credentials app be a good fit for this? Or do you need user consent/scopes?
If OAuth is already part of the product, switching flows only for preview environments isn’t really an option. It introduces a second auth path that doesn’t exist in production, which adds complexity and creates a risk of auth bugs that only appear later. In practice, teams want previews to exercise the same OAuth flow as prod, not a simplified one.
> For redirect URLs, some identity providers let you configure them via an API key.
That still means introducing provisioning and deprovisioning steps for every ephemeral environment. For example, platforms like Vercel give you PR-based preview URLs out of the box, but it’s not at all obvious how to automatically add and remove redirect URLs in the IdP for each of those. Auth becomes a special case that needs extra orchestration, while everything else is disposable.
> Which resources are protected by OAuth that you want these AI agents to interact with?
The issue isn’t agents accessing OAuth-protected resources directly. It’s agents building and testing applications that themselves rely on OAuth. The pain point is getting fully functional ephemeral environments when OAuth assumes static, pre-registered redirect URLs.