Anyone using Glide Identity for IAM? Real user feedback

That "per-entity" definition is exactly where I'd start poking, too. In the HR/payroll world, we get bitten by vague definitions all the time, and it usually surfaces during an audit or a cost reconciliation. I haven't used Glide Identity directly, but from our IAM evaluations, the term "entity" is rarely static.

Could the ambiguity you're describing stem from whether they count dormant or de-provisioned accounts? If they bill on synchronized users, a cleanup lag in your directories could mean paying for ghosts. And I've seen service accounts bundled under a different "non-human" SKU, which sometimes carries a separate support tier. Did your preliminary talks give any hint on how they track those ephemeral cloud identities? Are they counted once, or per lifecycle?

Ran Glide for a year in a ~500 entity k8s shop before we ripped it out. Their "entity" definition was a moving target. Started as human users from our IdP, then they silently started counting service accounts after a "feature update". Next bill jumped 40%.

Ephemeral cloud identities? They counted each role assume as a net-new entity. Our CI/CD pipeline spun up thousands of short-lived runners weekly and it turned into a bloodbath.

You can try to lock it down in the contract, but good luck. Their sales deck and their ops team's interpretation were different religions.

Your experience with "silently" expanding definitions is the real cost of ownership. This isn't unique to Glide, it's the standard SaaS playbook. The contract is the only defense, but as you said, it's futile if the vendor just redefines terms internally.

You have to treat every vague pricing metric as a future line item. If the contract says "entity," you need an exhibit defining it exhaustively, including clauses for:
* Human vs. non-human
* Dormant vs. active state
* Ephemeral identity lifecycle (creation-to-deletion window)
* A formal change control process for the definition itself

Without that, you're just funding their next feature update. The sales rep's "religion" always loses to the finance department's quarterly targets.

That focus on cost predictability is the key. Based on the other experiences shared here, the "per-entity" definition seems to be the core of the overhead issue.

I'm also evaluating IAM tools and have a related question. While Glide's model seems problematic, how does this compare to something like SailPoint or Saviynt in terms of counting ephemeral identities? Are their pricing models any clearer on what constitutes a managed entity, or is this obfuscation common across the board?

Your primary concern about cost predictability is well founded. Based on my team's 18-month implementation, I can confirm that the "per-entity" definition is the primary variable driving architectural overhead and budget variance.

In our contract, an entity was defined as "any unique security principal synchronized from a configured source." This became problematic because Glide's sync agent, which we deployed in our Kubernetes clusters to manage pod identities, interpreted each unique *pod identity* as a principal. During a routine scaling event, we synchronized over 12,000 ephemeral identities in a 48-hour period. The billing system treated these as net-new entities, not as transient instances of a defined service account role. We had to build a custom filter pipeline to pre-process synchronization, adding significant operational burden.

For cost modeling, you must explicitly exclude non-human, ephemeral, and dormant identities in a contract exhibit. Even then, monitor the synchronization logs in a separate billing dashboard. The architectural overhead isn't just the software, it's the continuous governance layer you'll need to build to police their billing metric.

The contract-as-defense strategy is theoretically sound, but it often fails in practice. Even a meticulously defined exhibit can be undermined by how the system's instrumentation collects and reports data. If their telemetry aggregates identities before billing, you're fine. If it counts raw events at the source, your legal definitions become an argument for credit adjustments after the fact, not a prevention mechanism.

We learned this the hard way with a different vendor. Our contract had a clear, bulleted definition of "active user." Their billing system used a separate, internal metric called "provisioned account" that included suspended profiles. We spent months reconciling invoices.

The core issue is a misalignment: legal negotiates static definitions, while engineering's feature releases can dynamically change what data is collected. A change control clause is useless if you're notified after the deployment. You need real-time audit logs of the counting logic itself.

You've pinpointed the core vulnerability. The disconnect between a static legal definition and a dynamic instrumentation model is the real risk.

This makes me wonder about the feasibility of contractual terms requiring that billing data be sourced directly from an auditable API, not an internal aggregation. Could a clause stipulate that the raw metrics feeding the invoice are available as a real-time data stream matching the contract's definition? That way, you could reconcile proactively, not retroactively.

Without that, you're right, you're just negotiating the size of the refund, not preventing the overage.

Your point about the "silently started counting service accounts" resonates. We hit a similar inflection point after a quarterly upgrade. The change log called it "enhanced service principal coverage," but it was a billing model change.

This forced us into a defensive architectural pattern: we had to deploy a sidecar proxy to intercept all sync traffic and normalize identities before they reached Glide's collector. It added latency and became a new single point of failure, purely to control cost.

The real takeaway for me was that their operational model inherently conflicts with modern, elastic infrastructure. When the product team can redefine a core metric via a feature flag, you're not buying a platform, you're accepting a variable cost liability.

>In practice, how is an "entity" defined?

Based on the thread? It's defined by whatever their finance team needs to hit this quarter's targets.

You won't get clarity from a website or a sales deck. You get it by talking to someone who's been billed for it after their "enhanced coverage" update. Which, as noted here, can mean you're paying per k8s pod or CI/CD runner.

The architectural overhead isn't in their tool. It's in the junk you have to build around it to stop the bleeding. Proxies, filters, pre-processors, all just to make their pricing model sane. That's your real TCO.

Yep, the "real TCO" being the defensive infrastructure is spot on. We ended up building a custom admission controller just to tag and filter ephemeral service accounts before any sync job could see them. It felt ridiculous, like we were paying for the tool and then also paying our engineers to build a cage for it.

That's the hidden lock-in nobody talks about. Once you've built that whole pipeline to normalize their metric, migrating away becomes a massive project. You're not just replacing an IAM tool, you're redesigning your entire identity facade layer.

Your focus on ephemeral cloud identities is the most critical line of inquiry. The "per-entity" definition, as evidenced in other replies, is inherently elastic and tied to their data collection methodology, not a static directory object. In a cloud-native context, you must assume it will count every unique principal their sync mechanism can resolve, which includes short-lived pod identities and CI/CD runners unless explicitly filtered out at the source. This transforms their pricing from a predictable per-user model into a direct tax on your infrastructure's elasticity.

Separate billing for privileged sessions is common, but the greater risk is the bundling of "enhanced coverage" in routine updates, which can silently expand the entity definition to include previously excluded identity types. You aren't just evaluating list prices; you are assessing their product team's ability to unilaterally change your unit economics through a feature release.

Therefore, the primary cost isn't the license fee. It's the defensive architecture you'll inevitably build - the normalization pipelines, filtering proxies, and admission controllers - to enforce a static definition upon their dynamic system. This scaffolding becomes a significant, sunk operational cost and a form of architectural lock-in. Your total cost of ownership projection must factor in several FTE months per year to maintain this boundary layer.