upvote
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.

reply
Good question. To clarify: the app still has its own internal auth logic — we're not bypassing that.

The encrypted lane handles connection isolation (who can reach the app), while the app still handles identity (who the user is).

For agent-to-app communication specifically, the pattern we use: 1. Agent passes a short-lived token in the request payload (not URL) 2. App validates the token against its local auth store 3. The encrypted lane ensures no one else can intercept/replay that token

Let me clarify. I am not suggesting disabling authentication inside the app. I am suggesting a solution is to layer the network isolation + application auth. The secure application layer channel just removes the OAuth redirect dance for machine-to-machine flows.

For human access, you'd still need SSO. But once the human is authenticated, the services authenticate to one another (machine-to-machine) also at the application layer (not layers 3/4).

Does that make sense for your use case, or are you looking for something that works with human SSO flows too?

reply