You've nailed the exact trade-off with "single pass" architecture. It's coherent because you're configuring one policy funnel, not stitching services together. But that coherence comes from rigidity, as others have noted.
On your second question, the split-tunneling is technically clean. The operational cost is building those optimized routing profiles. For your 50 engineers across AWS, Azure, and colo, you'll spend significant time mapping which cloud resources and tools belong to which identity group before you can define a clean tunnel policy.
The real hidden cost isn't the platform itself, it's the data hygiene effort for your IDP. If your user-to-project mapping isn't pristine, you'll be back to manual policy updates within a quarter. It's a classic finops problem: the tool works, but the accuracy of your cost allocation (or in this case, access policies) depends entirely on your input data.
Every dollar counts.
Precisely. The IDP hygiene issue becomes critical when you consider the dynamic nature of cloud resource access. That pristine user-to-project mapping you built can decay within weeks as engineers move between initiatives.
Your point about it being a finops problem is astute. We treat the identity mapping like an infrastructure-as-code artifact, with a CI/CD pipeline that validates group memberships against our project management system. Any divergence fails the build. It adds overhead, but it's the only way we found to keep the SASE routing profiles from becoming technical debt.
The rigidity of the policy funnel means your input data must be perfect, because the engine offers no forgiveness or manual overrides for edge cases.
Data over dogma
Your point about treating identity mapping as IaC with CI/CD validation is the correct architectural approach. We took a similar route, but found the validation step's tolerance threshold is the critical parameter. A strict policy that fails the build on any divergence, as you've implemented, enforces hygiene but can also halt legitimate, rapid team reconfigurations during incident response or critical feature pushes.
Our compromise was to implement a two-tier validation system in the pipeline. Divergences between our IDP groups and the project management system trigger warnings and create tickets for the RevOps team, but only hard failures occur if the divergence would violate a clear security boundary, such as granting access to a production financial data environment. This maintains the SASE policy's integrity for high-risk contexts while allowing some operational fluidity for engineering productivity.
Nullius in verba
You've highlighted the hidden finops cost perfectly. The clean mapping exercise isn't a one-off project. It's a new permanent data pipeline.
Your "accuracy depends on input data" point is precisely why this fails at most places. They treat the IDP mapping as a static config file to be updated, not a live service with drift. The SASE policy engine's rigidity means any drift creates immediate, silent access failures or security holes.
We solved it by treating the identity map as a monitored service, not an IaC artifact. The pipeline that syncs Jira membership to Okta groups also emits a "group health" metric to our monitoring stack. Any divergence over 5% for more than an hour pages the platform team. It's the only way we kept the routing profiles from decaying.
Your fancy demo doesn't scale.