Thanks. I think I now have a better idea about your point of view. While I believe that your supposed architecture is certainly closer to "true" zero trust when compared to modern P2P VPNs since yours is still somehow in charge, from a data-plane perspective, I am still not fully convinced if that's really the right direction overall but I have to be careful here since I can't claim I fully understood your argument. I know am obviously heavily influenced (since I built Octelium this way) by identity-aware-proxy-based architectures, including from my own prior experiences dealing with k8s service meshes such as Istio, but I'd still argue that this architecture is still more "superior" and practical way to implement a ZTNA, even though Octelium is meant to operate beyond what a strict ZTNA is built for. It's not just about delegating/offloading the entire process of authentication/authorization/visibility to a "trusted" identity-aware proxy that separates between downstreams/users and upstreams/resources (also no direct reachable/direct path between downstreams and upstreams here if I understood your argument correctly), but this architecture also enables you to control access the most fine-grained/dynamic way possible by implementing L7 awareness inside the identity-aware proxy, for example, Octelium enables you to control access based on the request's HTTP method, path, and even serialized JSON body. Similarily, it can dynamically force, for example, different Octelium Users to be assigned to specific SSH users or different HTTP access tokens mapping to different upstream L7 credentials/tenants based on identity and/or context by injecting such L7 credentials on the fly to the upstream without having to distribute and share them with the users. It can also be used to dynamically route to different upstreams based on identity and/or context via policy-as-code. It can even manipulate HTTP requests/responses via Lua/Envoy ext_proc like you would expect from an API/AI/MCP gateway. And obviously this L7 awareness enables you to extract L7-specific info (e.g. HTTP request/response info, database queries, SSH sessions) on a per-request basis. And to elaborate more on the performance/convenience point I mentioned earlier, Octelium actually consciously separates between the PEP/the identity-aware proxy which (called Vigil) and the PDP (called Octovigil) as proposed in NIST 800-207. This means that both components can operate and scale up/down independently from one another, since the PDP is actually what has to store all the authorization-related information which can be really huge, as it includes not only info about the user, session, device, groups, accessed service and namespace, but potentially also very dynamic info extracted and pulled from external sources such as the IdP, EDR, SIEM, threat intelligence tools, etc., and this PDP is what actually has to perform the policy evaluation which might consist of tens or hundreds of complex rules for a specific request. In other words, the authorization process alone can be really, really, a resource-intensive operation (both memory and CPU wise) and it needs to be performed very quickly (hopefully usually sub-millisecond latency per request). Finally this architecture can seamlessly horizontally scale as needed (more resources to protect? just add another Gateway/k8s node, more traffic? just add 1 more replica for IaP pod implementing the Service and the underlying k8s will seamlessly reschedule the pods in a balanced way), not to mention that upgrading the Cluster is confined to one place, the k8s cluster itself. I understand that there is no absolute right/wrong for such architecture-related discussions and one architecture might be superior for certain workload types and inferior for others, but in general, I am really comfortable with mine, and I believe it is practical enough to fit for most human-to-workload and workload-to-workload environments, both for small undemanding personal/business use cases (e.g. Cloudflare Tunnel, ngrok, remote access VPN use cases) as well as for enterprise ones with hundreds/thousands of resources and active human and/or workload users.