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.

You're identifying the core architectural conflict here. The defensive systems you describe become a de facto part of your IAM stack's functional spec, not just a cost control measure. This creates a perverse incentive where the vendor's development roadmap can inadvertently dictate your team's engineering priorities. A feature they label as an "enhancement" forces you to allocate sprints to rebuild your filters, essentially making you responsible for the stability of their pricing model.

The question that follows is whether this risk is unique to their per-entity model or is a structural issue with consumption based pricing in IAM generally. If the metric is inherently tied to data collection scope, as you state, then any vendor using a similar "per principal" definition is susceptible to the same drift. The alternative might be a model based on a committed directory object count, though that has its own rigidity problems in a cloud native environment.

This dynamic shifts the evaluation from feature comparison to governance assessment. You're not just reviewing their API, but their product management's transparency and their change management process for metric impacting features.

Yep, you've nailed the source of the anxiety. That disconnect between the sales deck and the actual invoice is the whole story.

I'd add that this "definition by finance team" isn't always malicious. Sometimes it's just an engineering team pushing a feature without realizing how their instrumentation feeds billing. But the effect is the same for you: a surprise.

Our experience matched yours. We had to build a real-time dashboard just to monitor their raw sync logs and predict the invoice, because the official usage report lagged by a week. The real cost was that constant monitoring overhead, the mental energy of never feeling sure.

Your experience with the moving entity definition is the textbook reason we never moved beyond a POC. That 40% bill jump after a "feature update" isn't an anomaly, it's a pattern. We saw it with a different product in the same category, and it's why we now insist on contractually freezing the entity classification logic to a specific, versioned API schema.

The bigger issue you hint at is the sales-to-ops disconnect. We demanded their product manager sign off on a technical annex that mapped every line-item term to a specific log field or API endpoint from their own documentation. Even then, you're right, it's a different religion. The ops team just runs what engineering ships, and engineering's "enhanced coverage" is your new cost center.

Your CI/CD bloodbath is the inevitable result. When a product's core metric is tied to its data ingestion scope, your infrastructure elasticity becomes a direct financial risk. The only real defense is to never let their collector see the raw firehose, which defeats the purpose of buying a managed service.