The 2026 State of AI and Identity: How AI is Reshaping Security, Architecture, and Enterprise Trust

Dayna Rothman — 03:09–51:15

Alright, let's go ahead and get started. Good morning everyone, or afternoon, and welcome. Thanks for spending the next hour with us. Today's webinar is on FusionAuth's brand new research, the 2026 State of AI and Identity Report — how AI adoption is reshaping identity infrastructure, security posture, and enterprise trust. So if you're here for that webinar, you are in the right spot.

A little bit about me. I am the Chief Marketing Officer here at FusionAuth. I've been in cybersecurity for almost ten years and was previously CMO at OneLogin and Censys. So I've been around the identity world for a while.

Just a quick bit of housekeeping before we dive in: this session is being recorded, so if you have to drop, you'll get the replay and the slides afterwards. Put your questions in the Q&A box and we will try to get to them at the end.

First, a quick word on FusionAuth — I'm not going to spend too much time here, we're going to get into the data. We are a customer identity platform built for teams that want control: authentication, authorization, and identity infrastructure you can deploy anywhere — cloud, self-hosted, on-prem, hybrid. And critically, for today's topic, we work with all identities: human users, machines, and AI agents. That's really why we ran this study. We live in this problem every day, and we wanted to see the real numbers on how organizations are actually handling identity in the age of AI.

So what are we going to cover during this webinar? We have a lot of data to get into. We'll start with an introduction and why identity infrastructure is under pressure in the first place. Then we'll walk through the core findings — how AI has reached operational saturation — and we'll also go through what we call the confidence reality gap. We'll go through why governance alone isn't enough and why your deployment architecture turns out to be one of the biggest predictors of risk. Then we'll take a look at where the pressure is the highest: role, industry, company size, and even geography. And we'll close with a practical AI and identity checklist.

Everything you'll see today comes from more than 300 qualified technology and security leaders that we surveyed. We screened every respondent for direct, hands-on involvement in AI identity and security decisions. These are not bystanders offering opinions — these are actual CTOs, CISOs, and VPs who are making these calls in real time. We asked them about the full picture: AI adoption, actual security incidents, how they're governing their policies, how they manage the lifecycle of AI agent and nonhuman identities, and, of course, their identity architecture. So when you see a number come up today, that's the signal from the people closest to the problem — not an analyst projection or vendor spin. We wanted to make sure we were talking to some of the top people doing this work.

So, four takeaways. If you only take four things away from today, take these.

Number one: AI has reached operational saturation, but identity has not. 79% of organizations we surveyed are running AI-powered features in production, meaning a lot of these folks are running them in customer-facing applications already, and yet 88% say their AI deployment is already ahead of their identity and security readiness. The product has shipped; the controls have not. They are over their skis.

Number two — and this is the one that surprised us the most — the confidence reality gap is real and it's inverted. The more confident an organization is in their AI security, the more likely it is to have had a confirmed incident. We'll dig into some reasons why in the coming slides.

Number three: governance is necessary, but it is not sufficient. Comprehensive policies and formal processes are sitting right next to high incident rates in these companies. Policy defines intent, but it does not enforce it.

Number four: your deployment model is a first-order security variable. So obviously being an identity company, we ask a lot of questions about how their identity is being deployed. We found that multi-tenant SaaS identity environments reported confirmed incidents at actually twice the rate of self-hosted ones. So architecture isn't a back-end detail when it comes to AI — it's actually part of your risk model.

Let's start at the beginning. Why is identity under this type of pressure at all? Our first section: identity wasn't originally built for this. For decades, identity answered one basic question: can a user log in? That assumption — that model — was based on a human at a keyboard with a password. And AI has really broken through every one of these assumptions. AI agents can make API calls. Models reach into customer data. And the controls and policies that are supposed to govern access, isolation, and auditability simply have not caught up at the pace that companies are adopting AI. The ground is really shifting under identity, and this isn't a niche problem.

You can really see the scale here. The identity and access management market is projected to hit $42.6 billion by 2030. And within that, machine identity alone is headed towards $21.4 billion in 2026 — massive, and a huge uptick from where it's been. Here's another striking number: nonhuman identities now outnumber human identities by 144 to one. That's up 44% in a single year. For every human in your directory, there are 140-plus service accounts, agents, tokens, workloads, and now AI agents in your system. 90% of incident response investigations right now trace back to identity loopholes, and many of them have to do with AI. The takeaway is simple: AI adoption and innovation are outpacing the governance and the systems that organizations have in place, and that gap is exactly what we are going to measure.

So how far has AI actually gotten inside these organizations? Maybe further than you think. AI has reached operational saturation. To be precise again about who we surveyed: we did not survey AI-curious companies kicking tires. AI is already live in these organizations — in employee workflows and customer-facing experiences. What hasn't arrived yet is the control layer, and AI is really starting to surface all of the different cracks in the system.

Let's take a look at how deep the adoption actually goes. 67% of respondents have approved AI tools in wide use across departments internally. The vast majority — 80% — have AI-powered features live in production today, and a little bit higher, 93%, if you're talking about in pilot. This was actually higher than I thought. I know companies are using a lot of AI internally, but I wasn't as prepared for the higher numbers around it being live in production products. And not surprisingly, 86% of people are personally using AI tools in their daily work — that was kind of to be expected. But moving fast has consequences, and you can see this in the later parts of the data.

88% of all respondents said that their AI deployment was already ahead of their identity and security infrastructure — that's a pretty massive number. And 88% of the total population already had a confirmed or near-miss AI-identity-related security incident in the past twelve months. I wasn't asking just about regular security incidents; this was specifically around AI and identity, and 88% said that they had experienced an incident or a near miss. So clearly, here's the tension: AI is already operational, but the policies, control layer, and technologies are not. There's a big gap that drives the rest of this report. Everything else we'll look at is really a symptom of this one imbalance.

As usage grows, so does your attack surface. Watch what happens when AI moves from pilot in a couple of teams within the company to something used broadly across the business. Every risk indicator rises with it. Confirmed incidents, shadow AI, and planned investment all climb up together.

At the bottom of this chart, we look at companies where AI adoption is widespread across multiple departments and they also have significant investment — these companies are actively investing in AI. 88% of this cohort show shadow AI, meaning unauthorized or unmanaged use of AI models, workflows, or chatbots within their organization, which is causing a massive increase in the attack surface. 74% of that group report a confirmed AI-related identity security breach. Let that sit for a second: three out of four organizations at the frontier of AI adoption have already had a confirmed security incident related to the interplay between identity and AI.

As you move up from there and look at adoption that is only really in engineering and IT — a little bit more limited — you also see less investment and slightly less shadow AI and fewer breaches, still a significant amount. And finally, you have companies where AI adoption is supposedly just being piloted. These organizations are investing less and have a lower number of breaches — only 9% confirmed a breach. However, shadow AI is still there, with 27% reporting it exists in their organization. Not surprising that companies not investing in AI or not actively putting in place any sort of programs do have a lot of shadow AI.

As our respondents themselves point out, 86% already use AI as part of their daily tasks. If you don't have a policy in place, your employees are most likely using it anyway. The inflection point isn't using AI — it's using AI broadly enough so that agents and copilot tools start touching internal systems and customer data at scale. That's when the risk really compounds.

There's a specific combination that is most dangerous of all — we call this the saturation threshold: the cohort running AI in production in their product and using it widely across the workforce. This group has the highest exposure in the entire study. But here's the counterintuitive part: this is not a group of laggards. These organizations look mature. They are confident. 96% reported that they are very or extremely confident in their AI security posture. They formalize their processes — 71% say they have a process in place for AI — and they're investing. Saturation creates exposure even when organizations believe that they're ready. Deployment velocity is generating identity complexity faster than controls can actually contain it. 90% of this group report shadow AI and 79% had a confirmed AI and identity-related security incident. Looking mature and being protected are clearly not the same thing, and this is really the essence of our findings.

Before we get deeper into the confidence level versus security incidents, I also wanted to touch on what our survey respondents had to say about hiring. The hiring landscape around AI is something we are definitely talking about right now across a variety of organizations, between employees and between leaders. 64% of our respondents reported they were hiring for AI talent. These are companies that are building up their teams, seeking folks they can potentially train up or who have experience building out AI systems. Only 22% said that they were training existing teams — I thought that would be higher. I know that we internally at FusionAuth do a lot with training our internal teams on how to leverage AI within each department.

Looking at the lower numbers: 4.4% are planning on hiring but haven't made any big moves yet. 3.4% are reducing headcount because of AI — they've specifically cut some headcount, trying to gain efficiencies, which we've heard about a lot. But the overwhelming majority of our respondents are either hiring or training. And then we see 3.4% hiring fewer junior workers, trying to potentially supplement some of that workforce with AI. So we did see some reduction in our survey audience, but not as much as we perhaps anticipated.

And not surprisingly based on our data, we saw a difference in security posture. 86% of organizations that are aggressively hiring for AI talent have had a confirmed breach, compared to only 33% of those focused on training their existing teams — that's a 2x difference. 87% of the hiring-for-AI group say that AI is significantly outpacing their infrastructure, versus only 33% of the training group. The read here is nuanced: it's not that hiring is bad. The hiring-for-AI cohort is moving so fast that deployment velocity is really outrunning what they have in place. The training cohort is adopting a little more deliberately, catching more problems before they escalate, thinking through some of those decisions versus bringing on a massive cohort of folks just focused on AI.

That brings us to the next finding, and this one we are calling the confidence reality gap. This next section is the most counterintuitive finding in the survey. Typically, when you ask about confidence, you would expect to see less shadow AI and fewer breaches, because a confident organization seemingly has their stuff together. But in this data, that is not how things tracked — we actually saw the opposite. When you look at this gradient, the organizations that told us they were extremely confident in their AI security had the highest confirmed incident rate, around 88%. Very confident organizations were still very high at 64%, and then it drops steadily as confidence drops. The folks that are not so confident have far fewer confirmed incidents, and that was really, really interesting.

To be clear, we're not saying confidence causes incidents at all, but confidence is clearly not measuring what people think it's measuring. If your sense of security goes up while your incident rate goes up, your confidence is tracking something other than the actual problem. So what is it actually tracking? The organizations at the very top of the confidence scale share a profile: they're deploying AI broadly, they have comprehensive policies they think they've put in place, they formalize what they think are lifecycle processes, and they're investing heavily. By every conventional measure, they're doing the things a mature organization should do — but they're still getting breached at these very high rates.

What do we think is actually happening? We think that in these cases, confidence is tracking deployment velocity and governance activity, but not actual protection. The faster you move, the more artifacts you produce — the more policies you have written down, the more you've sent them out to your employees. Maybe you feel a little more confident, but all the while your attack surface is quietly growing because you're introducing these new technologies. And there isn't one single cause here; there are factors we haven't anticipated.

If you're thinking this must track by company size or something similar, that isn't the case. We didn't really see large trends in the data showing that more confident and more breached organizations were smaller and therefore had fewer resources. So what's driving the gap? Here are the reinforcing causes we saw in the data.

Number one: aggressive deployment simply creates more exposure. More identities, more integrations, more permissions, more paths to misuse. All the AI in production that you can't properly track is expanding the attack surface.

Number two: governance artifacts are creating a sense of false comfort and false control. Policies and certifications are essential, but a document doesn't enforce runtime access decisions. This is also so new for so many organizations that we don't know if the governance policies being created are the right ones — are they working, or are they just artifacts sitting out there?

Number three: better detection surfaces more incidents. Some of these mature organizations aren't necessarily less safe — they're better at seeing what less mature organizations miss. That has something to do with size potentially, but it's that more mature organizations have more resources for detecting these breaches.

And number four: identity risk is still genuinely poorly understood. We're managing autonomous agents at massive scale with mental models built for human users, service accounts, and traditional APIs. Many of these models are still incomplete, and the identity landscape and vendors are still catching up and trying to build new things.

That last point is really the crux: an AI agent isn't a user and isn't quite a service account. It's really something new. So how do our policies catch up to that? And if policy isn't the answer, what are the questions you should be asking? The real question isn't necessarily "do we have a policy?" It's really looking deeper at that layer.

If you're confident in your AI security posture, that confidence deserves some scrutiny — not because your governance is wrong, and it definitely matters, but because governance and runtime enforcement are two different things and with AI they start to diverge really fast. So it's not "do we have a policy?" — it's four harder questions you can start asking yourselves. Can we scope what each agent can access? Can we see what an agent is doing? Can we prove what it had access to after the fact — do we have audit logs? And can we revoke access before a near miss becomes something worse? Do we have the ability to revoke that least-privileged access for those AI agents? If the honest answer to any of these is "not really" or "we haven't thought through all of them yet," a written policy won't save you. You really need the mechanics behind that written policy to make it work.

So a written policy is one thing, but architecture is another, and that is exactly where we're going to look next. Governance is necessary but not sufficient. Policies define intent, but processes define operating rhythm. Both matter, but neither one on its own enforces least privilege, isolates data, or revokes access in real time. For that, you need the platform underneath to actually be able to do these things.

So we asked our respondents about six lifecycle processes for managing AI agents and nonhuman identities. We got together with a group of leaders to determine these, and also did a lot of research with subject matter experts and analysts to come up with six AI lifecycle processes that organizations should have formalized. Everything from provisioning AI agents to monitoring their behavior, scoping permissions, rotating credentials, revoking access, and auditing what they did.

Here's the pattern: organizations are strongest at the front door — provisioning and monitoring — which isn't quite surprising because we are investing in AI and we've figured out maybe how to let them in. But we're weakest at the two things that really matter most after an agent starts acting autonomously in your system: revocation and auditing. These are the two processes least formalized across our respondent group. We're very good at letting AI agents in, but much worse at proving what they did and shutting them down. We are building that front door faster than the accountability layer behind it, and that's causing a lot of issues.

There's another important point: even the organizations with all six processes formalized still report high incident rates. Looking at this readiness chart, those that claim to be well prepared have the most confirmed incidents by far and the most shadow AI. Perhaps maturity enables better detection, but we're having a huge issue when it comes to prevention.

AI identity is now also a security problem. For years, AI and identity in many ways lived in engineering and product. AI particularly was an innovation story — something that folks put machine learning into their software products and were really able to sell as an intelligence layer — but that's not what it is anymore. Today, AI means much more than that, and the responsibility for AI agent identity has come to sit in security. At least, this is how our respondents answered. We asked who is responsible for making decisions around AI and identity security: 88% of our respondents say the CISO and security teams have that ownership, with engineering leadership and platform teams sharing pieces of it. In some organizations, engineering still kind of owns those decisions, but it's become very much a coalition buying and coalition kind of buying ownership process.

This is a real market signal: AI identity has moved from innovation enablement within the product into risk governance. And this matters because it's still fundamentally a developer and architecture problem, even as security now owns the risk. It very much needs to be collaborative. Another reason detection may have ramped up in more mature organizations is that if the onus is now on the security team, they've got the process in place to really detect these types of breaches. The practical implication for identity vendors and teams is that you have to speak both languages at once — developer control and security governance — and the ones that will struggle are the ones that can only speak one language.

That dual nature points straight into another interesting architectural finding: your architecture is your attack surface. I will underline this twice. Your deployment model — how and where your identity infrastructure runs — is not a back-end preference or an IT convenience. In the world of AI, it becomes part of your risk model, and the data really bears this out. We split respondents by their identity deployment model: multi-tenant SaaS identity versus those using self-hosted, single-tenant SaaS, or on-prem deployments. The outcomes diverged sharply. We found that multi-tenant SaaS environments reported confirmed incidents at more than twice the rate of self-hosted ones — 83% of those on multi-tenant SaaS were reporting incidents. They also report far more shadow AI at 91%, more investment urgency at 84%, and they were more confident, with 94% saying they were very or extremely confident in their AI security posture.

Aside from the pace of deployment, is there an architectural reason behind this? The answer is yes. It really comes down to blast radius. In a shared multi-tenant environment, a single compromised token or misconfigured policy doesn't stay contained — it can cascade across every AI workflow connected to that identity layer. A self-hosted or single-tenant isolated deployment gives you a fundamentally smaller blast radius when something goes wrong.

You can see that here in the data as well. In the AI world, look, something eventually is going to go wrong. Interestingly, self-hosted organizations actually report more near misses — fewer breaches but more near misses — meaning they are catching things before they escalate, likely because of tighter isolation and more hands-on monitoring. Only 26% of these respondents believe that their AI is significantly outpacing infrastructure. This cohort is running at a much more deliberate pace, which is to be expected for folks keeping their deployment in-house or vendor-hosted in a single tenant.

And perhaps this is a reason why we're also seeing a wave of reinvestment. AI is forcing an identity architecture reset — and this isn't a normal budget reset. We saw 93% of respondents say that AI is already a trigger for reevaluating their identity infrastructure, and 91% expect their identity investment to increase over the next twelve to eighteen months. When 90-plus percent of a market is reevaluating the same control layer at the same time for the same reason, it's not incremental. That's a market-wide architecture reset driven by machine identity at scale, deployment flexibility, the need for fine-grained authorization, and AI risk.

When we asked what organizations are looking for as they evaluate identity for AI readiness: 72% said support for nonhuman identities — you want your identity platform to support your agents and other AI workloads. 57% said deployment flexibility, meaning they are seeing gaps in their current deployment — these are folks on multi-tenant SaaS looking for something different. 54% said fine-grained authorization — they need a platform that can treat AI as a first-class identity with fine-grained control over what someone or something is accessing. And even 32% said they now need tenant isolation for data separation.

So the identity layer is being rebuilt, and it's happening now. And it's not just security teams driving it. When we look at something like tenant isolation and data separation, customers are now in the room as well. Here's where this stops being purely a security story and becomes a revenue story. AI features can reach across your customer data, your partner data. It's not just regulators asking the hard questions about isolation — it's your customers, and your answers really can determine whether deals close.

This was also a somewhat surprising finding for us. 85% of all respondents have faced demands to demonstrate tenant isolation at least occasionally, and more than half face it frequently — a higher number than we thought. Tenant isolation has moved from a back-end implementation detail to something of a commercial requirement, part of the proof a customer needs before they'll trust you with sensitive data. 56% are frequently required to demonstrate tenant isolation, 29% occasionally, and only 11% expect it in the future. Architecture and being able to prove that data can't cross between systems has become revenue-critical. And these findings hold broadly — not just in regulated industries or areas like the EU. We saw this across the population.

But we wanted to take a look at where the pressure is the highest. The top-line findings do hold across the board, but when we cut the data by role, industry, company size, and geography, the intensity shifts in ways worth pointing out, because they tell you where this is all headed.

We talked about role a little bit, but we saw different answers based on a persona-level look at the data. The same risk looks completely different depending on where you sit in the organization. Security leaders — CISOs especially — report the highest confirmed incident rates in the respondent group. Engineering and platform leaders report more near misses: same underlying risks, two different vantage points, two different pieces of ownership. Security historically is in control of incident detection and response. CTOs and technology teams are more in the mix on the infrastructure, perhaps catching things before they actually happen. Security tends to see it as an incident response problem; engineering sees it as an architectural control problem. And here's the thing: they're both right. The solution needs to satisfy both, which is exactly why the buying committee for this has gotten way more complex.

Let's look at how this impacts different industries. You might assume that the most heavily regulated industries would be the safest. The data said otherwise, particularly in areas like financial services. When financial services respondents answered, they showed high policy maturity, high process maturity, and heavy customer and regulatory pressure — and yet it also has one of the highest confirmed incident rates in our sample. Surprising to us, as financial services can be a little more conservative with their technology usage, but that doesn't seem to be the case. Financial services organizations are being pushed to have AI internally as well as within their product. 86% of our data cut had a confirmed incident. 74% said AI is outpacing infrastructure, even though 80% have a formalized process. And 80% of financial services respondents also have frequent tenant isolation demands from their customers.

The lesson for regulated industries is that the AI identity challenge isn't a lack of awareness. It's that traditional governance frameworks are being outpaced by autonomous access patterns these regulations were never designed for. A CISO who can satisfy a SOC 2 auditor can still have a misconfigured AI agent quietly accumulating permissions nobody meant to grant. Passing the audit is not the same as controlling the agents.

We also wanted to look at company size — how are different-sized companies absorbing this AI risk? Looking at the differences between large enterprise organizations, mid-market, and smaller startups: in this data cut, we saw that smaller and growth-stage organizations are running especially hot in all areas. They have the highest confirmed incident rates early in their lifecycle: we're seeing 83% have confirmed incidents and 96% shadow AI. They're building AI into their products and workflows before they have the enterprise-grade identity infrastructure you might normally associate with this level of complexity. Their investment is high and so is their risk.

AI identity risk is no longer something only the largest enterprises are worried about. These growth organizations are absorbing these complexities years earlier than they used to, because they're agile, they're AI-forward, and they often have less governance in place to begin with. It's a lot easier to get AI models in place and agree on which AI platforms employees should use in a much smaller company than a large one.

The companies that are north of 5,000,000 are investing less. They're a lot more conservative in how they're investing, and they're seeing less breach and shadow AI activity. These are slower-moving organizations with more red tape. They also likely have a bit more sophistication in their ability to detect some of these things.

We also want to look at geography. We call this the Silicon Valley effect: when we cut the data by geography, regardless of company size or anything else, the Pacific Region runs hotter in almost every single metric. They are more SaaS-centric, more likely to say AI is outpacing infrastructure, and show more confirmed incidents, more shadow AI, and much higher planned investment. The way we read this is that the Pacific Region — largely Silicon Valley — is running about twelve to eighteen months ahead of the rest of the market in feeling this pressure. Not overly surprising to me as someone who's been working in Silicon Valley for well over a decade. But it's important to call out because these folks are previewing what the broader market is most likely going to start feeling. If you're not in this cohort yet, treat this as an early warning — you do have a little bit of runway that the front runners didn't have.

So what do we all do about this? Here's the encouraging part. The organizations in this data with better outcomes — lower confirmed incidents, more near misses caught early, stronger isolation — share a set of characteristics, and those characteristics aren't only policies or headcount. They're architectural. It's how they're approaching the problem and being more deliberate in how they're thinking about AI, which means these are things you can actually evaluate and build towards.

We've turned some of those characteristics into something you can use: the AI identity evaluation checklist — ten questions to ask either your identity vendor, including us, or to ask yourselves if you have some of this stuff in place.

I won't read all ten, but let me pull a few. Can you deploy across SaaS, single tenant, self-hosted, hybrid, or on-prem, and change later as your needs evolve? As we saw in the data, respondents relying only on multi-tenant SaaS — where they don't have the opportunity to migrate — are starting to see complexity that is tough to remedy. With single-tenant SaaS, self-hosted, or on-prem hybrid, you do have more control over your attack surface and over your data.

Can AI agents and nonhuman actors be treated as first-class identities? Can their access be scoped with fine-grained authorization — meaning, are you able to pull back permissions for AI agents in workflows in real time with context? Can you prove tenant isolation when AI features touch customer data? As you saw with our respondents, organizations are being asked this question more and more, particularly in regulated industries, but they're being asked this across the board. Can every AI-initiated action be traced back to the agent, the system, the human authority, the data, the action taken? And can credentials be scoped, rotated, expired, and revoked automatically? Can your agents revoke or enforce permissions in real time?

Notice that these map directly to the weak spots we saw in the data: auditability, revocation, and fine-grained control — the lifecycle processes our respondents were weakest in. Both you and your vendor should be able to start answering these questions clearly. If not, really consider ensuring your roadmap covers off on these things internally as you think about your identity strategy as it pertains to AI.

So let me bring this all together — here's where we land. The AI identity challenge is no longer theoretical. Organizations are already deploying AI — we see it in our data and I'm sure you're seeing it too. They're already seeing incidents, already fielding customer demands, and already reevaluating their infrastructure because of it.

The core lesson from the data: confidence, policy, and process maturity are not enough on their own. In fact, the organizations that look the most mature often carry the highest exposure because they are moving the fastest. The next era of identity will be defined by architecture, deployment flexibility, isolation, machine identity, FGA, real-time enforcement, and auditability. To put it simply: AI can assist, but identity must decide.

If you want to go deeper into this report, we will send it out to you after this webinar, or you can go to our website at FusionAuth.io to get a copy. We'll also obviously send you this recording. I think that's about all the time we have. Thank you so much for spending time with us. Watch your inbox for the report and the recording, and I hope everybody has a great week. Take care, everyone.