• In the age of AI, identity is king—it drives the system (and with it, security itself).
• As metrics expand at AI scale, it’s time to rethink SaaS IAM risk and utility.
• With a new understanding of identity solutions, repatriating IAM is worth the risk.

I need to make a confession. A few years ago, I was firmly in the “buy, do not build” camp for Identity and Access Management (IAM). I was the architect for a private SaaS vendor solution that met all requirements and even addressed data sovereignty concerns. SaaS IAM delivered the results– with fewer servers to patch, fewer midnight alerts, and easier access for customer understanding and success.

Since then, my perspective has shifted. Of course, SaaS vendors didn’t suddenly get worse. But as AI transforms the identity ecosystem, we need an approach better suited to its continued evolution. 

In the current security landscape, identity is not a passive login screen. It’s the control hub for every action in the enterprise: data access, raising privileges, API permissions, machine-to-machine trust, session risk, and, increasingly, the governance of semi-autonomous AI. In 2026, identity drives the system.

It’s time to repatriate an IAM built for the moment

With identity now in the driver’s seat, it’s time to repatriate IAM with an awareness of the risks and a willingness to address them. I know “repatriation” can sound like giving up, but IAM repatriation is not a step backward. This is not a call to "kill the cloud," turn off SaaS, or pull everything back into the data center. Instead, it’s a call for clarity about the risks that happen when your identity control plane is both mission-critical and externally rate-limited. Ultimately, repatriation is a move toward resilience, agility, cost predictability, and security at AI scale.

Repatriation is not an all-or-nothing plan

While it might sound like a step backward, IAM repatriation has potential to:

• Bring authorization decisioning (policy evaluation) closer to workloads
• Own token services, signing keys, and high-assurance session controls
• Reclaim identity telemetry (auth logs and signals) as first-class security data
• Manage machine identities and service accounts with the same rigor as human access

Within a repatriation approach, there is still a place for SaaS, leveraging it in places like user lifecycle workflows, while moving parts that must be deterministic, scalable, and always available to your repatriated Identity system. This flexible approach is ideal because fraud networks work best when the reach of SaaS services can be combined to better evaluate signals. 

Risk-free repatriation requires understanding AI

To fully grasp the value of repatriation, you must understand the game-changing impact of AI. AI adds a whole new class of actors to the environment:

• Agentic assistants that take actions on behalf of users with AI-driven automation running 24/7
• Bots that call the APIs at machine speed, processing each request as fast as the machine can handle
• Copilots embedded across tools, each needing scoped permissions
• Retrieval and orchestration layers that access data domains every time a prompt is used

AI multiplies identities and explodes authorization events

Traditional IAM models were built on a series of assumptions:

• A predictable number of employees and contractors
• A bounded number of apps
• Login peaks around business hours
• Reasonable ratios of users to auth requests
• Static policies

AI upends those assumptions with:

• More non-human than human identities
• High-frequency token exchanges
• Burst traffic driven by automation
• Authorization checks inside every agent workflow, not just at login
• Dynamic policies

Even if the AI agent is just another service account, the rate and fan-out of access checks multiplies. A single user prompt can start dozens or even hundreds of backend calls. When the AI agent does that across teams, the IAM system ceases to be a directory and becomes a high‑throughput transaction platform. 

How to respond when AI tips the scale

This reality complicates scalability. Many SaaS IAM discussions focus on availability, noting vendor outages that are real and painful. But those outages can’t compare to the scalability needs created by this new age of identity.

When IAM is SaaS hosted, you inherit the constraints. Those constraints are often fine, until…

1) Rate limits become security limits

At AI scale, IAM must be able to keep high-volume operations running without compromising security. But, in practice, rate limits push people into choices like:

• Caching drives to last longer than they should
• Skipping real-time risk checks during bursts
• Making exceptions for trusted workloads, often allowing them to drift into over-privilege
• Delaying revocation propagation when it matters most

When identity bottlenecks, engineering teams route around it, acting as humans do under pressure

2) AI renders cost models nonlinear

Many SaaS IAM vendors charge enterprises by:

• Monthly active users
• Premium feature tiers
• Connection counts
• Event volume or log ingestion
• API calls/token operations (directly or indirectly)

AI workloads upset the events side of the equation—issuance, self-checks, policy checks, step‑up challenges, device posture, anomaly detection, and logging. Even if the initial unit cost seems small, the total can become a bloated line item prompting everyone to look for ways to bypass costs. Unfortunately, a bypass like turning off controls weakens the whole system.

When authorization is essential, latency becomes an existential crisis

In order to resolve the latency challenge, we must consider:

• Fine-grained authorization (ABAC/ReBAC)
• Just-in-time privilege
• Continuous session evaluation
• Real-time data access decisions

Authorization affects application performance, with service-to-service calls routed through a SaaS decision point adding delay. If developers avoid these calls because of a slow SaaS decision point, the system loses enforcement. Neither lost performance nor lost enforcement is acceptable.

Multi-tenant realities mean noisy neighbors and shared fate

Even the best SaaS vendors operate multi-tenant platforms with shared risk. In these platforms, global incidents affect customers regularly, while platform-wide policy changes, deprecations, or behavior shifts affect everyone unequally. As for regional dependencies and cross-zone propagation delays, those are outside of your control.

The model has to work this way, but when IAM is the control plane, “shared fate” is a much bigger deal than “fate” was when the SaaS tool was only for expense reporting.

What do you want first–good news or bad?

This entire blog may feel like “the bad news.” But even in an uncertain identity landscape characterized by rapid evolution and new risks, there’s reason for hope. That hope requires revisiting what we think we know. Hang tight for “the good news,” with actionable suggestions coming in Part 2 of this two-part series. In that blog, we’ll explore vendor risk and give you some informed suggestions on the very best sequence for repatriating IAM while reducing risk.