Most of the conversations about AI and security are about smarter attacks and smarter defences. Less attention goes to the layer underneath: the identity system that decides who can see customer data and what they can do with it. As companies put AI assistants in front of customers and let agents act on users’ behalf, that layer is being asked to make far more decisions, far faster.
FusionAuth’s State of AI and Identity Report, a survey of more than 200 US technology and security leaders, found that 88% say AI deployment is outpacing their identity and security infrastructure. We spoke to Bell about non-human identities, why the most confident teams reported the most incidents, and why FusionAuth keeps AI out of access decisions.
How is AI changing what organisations need from their identity infrastructure?
I think AI turns identity into the control plane for people and for the software agents that touch your systems and your customers’ data. Those agents ask for access on someone’s behalf over and over, much faster than any person would, and the identity layer has to make the right call every time.
In our survey, 93% say AI is already pushing them to rethink how they handle identity. Asked for their top three criteria in an identity platform, 72% included non-human identity at scale and 57% included deployment flexibility. That second number tells me people want more say over where identity runs, now that AI features reach into customer data. The companies that sort this out early will move faster with AI, because they won’t have to rip out identity halfway through a rollout.
As AI agents start logging in, buying and accessing accounts on behalf of users, how should companies verify and authorise them?
I’d start with the human. An agent acting for me should have its own identity, separate from mine, and all the authority it holds should trace back to the person who granted it. Verifying an agent means it signs in with its own credentials, so you know which software is calling and which person it’s acting for. The pattern I worry about is an agent borrowing a user’s password or session, because then nobody can tell the person from the software, and you can’t pull the agent’s access without locking the person out.
Then the question is what the agent is allowed to do. In ticketing, checking which seats are free, buying two and handing one to a friend are three different permissions. So, the authority should be scoped to the task, limited in time and easy to revoke. For anything consequential, like spending money, the agent should come back to the person to approve it, at least for now.
Deterministic rules outside the model should decide whether the agent can act. Models are probabilistic and built to finish the task they’re given, so you can’t rely on one to police its own permissions.
Does AI make identity data more valuable, more vulnerable, or both?
Both, and the value is the reason the vulnerability matters. For AI to do anything useful for a customer, it has to know who that customer is and what they’ve agreed to. That knowledge sits in the identity layer, so the account and the consent record behind it get more valuable as companies put AI in front of customers.
The same data gets more attractive to attackers, and AI lowers the cost of going after it. Credential stuffing gets cheaper to run at scale, and synthetic identities are getting convincing enough that a single check at sign-up tells you less than it used to. In our survey, 65% of organisations had a confirmed AI identity-related security incident in the past 12 months, and almost nine in ten had either a confirmed incident or a near miss.
What did the report show that surprised you most?
The teams most confident in their AI identity infrastructure were the most likely to have had a confirmed incident. I expected the opposite. Among respondents who said they were extremely confident, 84% had a confirmed AI identity-related incident in the past year, against 65% across the whole survey.
That doesn’t mean confidence causes incidents. I think confidence tracks how fast a team is moving more than how well protected it is. The most confident teams tend to be deploying AI broadly, and every new agent or integration adds access that somebody has to scope. Mature security teams are also better at finding incidents, so some less confident respondents may simply have looked less closely. I’d judge a team’s readiness on what it can show you, like which agents can reach which data and how fast it can cut one off.
Your report found that 85% of tech leaders have been asked to prove tenant isolation. What’s driving that?
My hypothesis is that it changed when AI features started reading customer records. Once that happens, one of the first things a buyer asks is whether their data is kept apart from every other customer’s, and whether you can prove it. 85% said they’d faced demands from customers, partners or regulators to demonstrate tenant isolation at least occasionally, with 56% facing it frequently. How a company answers that question is affecting whether its deals close. And 58% said the CISO or security team owns identity for AI agents, so responsibility sits with the people who sign off on risk.
Many companies are rushing to plug customer data into AI tools. What risks do you see from the identity side?
The biggest risk is treating retrieval as authorisation. A retrieval setup like RAG pulls whatever looks relevant, and unless you build the check in, nothing asks whether the user may see it. An assistant wired into customer records can summarise one customer’s account for someone else. The permission check has to happen before data reaches the model, against the identity of whoever is asking.
Third-party AI tools add a scoping problem. If a tool connects through one broad credential, nobody can see what it touched or switch off just that tool. And 80% of the leaders we surveyed report shadow AI. My read is that those employees mostly want to show they can use AI at work, and bans push them underground. I’d give them an approved route where every tool is registered separately and gets only the access it needs.
Then there’s consent. Someone who shared their details to manage an order may not expect them in an AI tool. Consent should be tied to a purpose and easy to withdraw, as GDPR expects, and the identity system is where it gets recorded.
How is FusionAuth using AI in its own product, and where are you deliberately holding back?
We deliberately keep AI out of the decision about who gets access to what, which is what we mean by “AI can assist. Identity decides.” Our risk-based MFA scores 10 risk signals with deterministic, rules-based logic that runs inside the customer’s own deployment. If a customer is asked why a login was flagged, they need a reason they can point to, and rules give them one.
Our engineers use AI to help write and test code, and we use it for research and analysis. In the product, most of our AI investment goes into helping customers govern the agents they’re starting to deploy, rather than putting generative AI on the login screen.
Is your argument against shared identity platforms a reaction against the big cloud providers?
Partly. My concern is specifically the shared multi-tenant model, where your customer data sits in the same system as every other company’s. SaaS is very good at getting a login live quickly, and for plenty of companies that’s the right place to start. The constraints show up later, when a customer or a regulator asks you to show how their data is kept separate.
Among the organisations we surveyed, 83% of those on multi-tenant SaaS identity had a confirmed AI identity-related incident in the past 12 months, against 38% of those who self-host. The survey can’t prove the architecture causes that gap, but if I ran a consumer brand, I’d want it explained before deciding where my customer relationships live.
Where will customer identity be in three years? Does the login survive?
The login survives, but I think most people will barely notice it. Passkeys are a big part of that, and I expect people to take a fast, phishing-resistant login for granted, the way they do HTTPS.
The harder problem is authorisation: deciding, in the moment, what each person or agent can do. Consumers will spend less time approving individual clicks and more time giving an agent a job with limits attached: reorder my usual groceries if the total stays under a set amount, and check with me before going over it.
What’s one thing most companies get wrong about customer identity today?
They still treat it as a login box: something you pick once, wire up and stop thinking about. Today the identity layer is where you recognise a customer, hold their consent and decide what they and their agents can do. If it goes down, people can’t sign in to buy anything.
Because it gets filed as a commodity, whoever needs a login working this quarter often makes the decision. Then the product team wants an AI agent to act for a customer, and the platform you picked back then decides what’s possible. My advice is to treat identity the way you’d treat payments or your core database, as infrastructure the business depends on, and to choose it with the next five years in mind.
Bell’s argument is that AI hasn’t made identity less important; it has made every access decision count for more. As agents start acting for customers, the organisations that move fastest are likely to be the ones that gave each agent its own identity, scoped what it can do, and kept the final call on access in rules they can explain.
