Leadership and security in the age of AI are running into an older, unsolved problem: most organizations don't know who actually owns identity. The CISO holds part of it, the product org holds another part, fraud holds a third, and none of their KPIs point in the same direction. Eve Maler, author of Mastering Digital Identity and founder of Venn Factory, joins FusionAuth's Dan Moore to work through that structural failure and what it means now that AI agents are calling APIs at runtime with privilege requirements nobody anticipated. The conversation covers the real difference between intent and authorization, what FusionAuth's AI readiness data shows about organizations that move fast, and why the OAuth scope model that served the API economy is a poor fit for agents that need contextual, purpose-specific access.
.png)
.png)
Hi, folks. Thanks for joining us today with another conversation with an expert in identity. We have Eve Maler with us today — she's an author, founder, and president of Venn Factory, and whose latest book is called Mastering Digital Identity. Eve, thank you so much for joining us today.
It is a great pleasure. Thanks, Dan.
We have a lot to dig into, so I want to jump right in. The first thing I want to talk about is really the conundrum of the spectrum between tech and product innovation and security leaders. In an organization, you have these two kinds of areas. Can you talk a little bit about what you've seen around that?
For years, I was observing — working on the vendor side, working with a lot of enterprise customers — that it's really hard to know who's the owner of identity. And sometimes there isn't really a clear owner. Oftentimes it's the CISO. CISOs, I would say in the modern era, over the last couple of years, have gotten a lot more sensitized to the importance of identity to the security conversation. But when we're talking CIAM, and you are mister CIAM, it is absolutely acknowledged that it's a product function.
I make the case in my book that identity should be treated as a product in every way, shape, and form, even if you're talking like workforce identity. But for customer identity and access management, you'll often find product leaders actually owning that function. And the challenge is that if security does own it or own parts of it, if product owns some parts of it, maybe you're in a financial services organization where fraud owns parts of it — and I've seen that and lived that — it's really quite confusing how you satisfy all the requirements in an environment where no one leader has KPIs, and they may even be entirely disjoint from each other.
So that's what I'm starting to think of as the frenemies conundrum, because we know how powerful identity as a set of technologies and concepts is, but it doesn't have a chance of addressing any of those cool things it can do if people don't get on board.
So what's a good way for people to kind of align those KPIs across different situations? What have you seen work — and what have you seen not work, more importantly?
What doesn't work, I think, is treating identity as mere infrastructure. It'll often be owned by IT, owned by a CIO somewhere in there. And it's a natural thing because it tends to be a shared service. Even in product, it might be a carve-out among the different lines of business as a kind of shared set of things. So the first thing, if you think of identity itself as a product that is enterprise-facing, is to actually take on board everything that being a product means. So it turns stakeholder conversations — and I feel so bored every time I say the word "stakeholder," it's terrible.
You're a real grown-up when you use the word "stakeholder," Eve. Go ahead.
When I started showing this four-set Venn diagram that became kind of the heart of this book, I was talking about stakeholder management, but you can go to a lot of leadership conferences about stakeholder management and still won't solve the problem, because identity is kind of this many-splendored thing. And so if you start thinking of each of those constituencies as customers — and even the different users, even if they're not end users — like with workforce identity, I talk about user access reviews, and an approver or a manager is really a different kind of user, a different persona, from a worker who just wants to get their job done.
So part of it is really taking the product metaphor quite seriously and understanding what product-market fit looks like. And only then can you start to generate some metrics that are truly meaningful for having no compromises across all of those different functions. And metrics and KPIs are a sore subject, I find, in identity writ large. Even in CIAM — if you're looking at what percentage of people are succeeding in authentication, does that actually tell you anything useful? I think we need to grasp for smarter, more compound metrics.
So when you said it's a sore point — it's because it's kind of like a vanity metric? That's maybe the wrong term, but it's like to me it's only surface level. The easy metrics are the ones that don't matter as much. Is that what you're saying?
Yeah. I was interviewing a series of really mature identity leaders to gather information for the book. They're great folks, and they're working with people who are telling them what to measure. And it might look like the metric I just mentioned, which is not a favorite of mine because it's not revealing — it's more of a sort of input metric versus an outcome metric. And metric design is subtle and hard. It's hard to find the right ones that really get you the outcomes you're seeking, and to not have too many of them.
The metrics you want to deliver to the board — and I think all this stuff should be board relevant — are going to be different from the metrics you're tracking day to day in some kind of dashboard that practitioners and leaders look at more often. I think there's work that can be done to come up with more meaningful metrics. And when it comes to CIAM, there are a few that I essayed in the last chapter of the book to whet people's appetite about what's possible.
Do you want to highlight one of those for us? And can you take a step back and give us the thirty-second to one-minute pitch of the book in general, and then talk about the CIAM metrics you mentioned?
The full title of the book is Mastering Digital Identity: From Risk to Revenue, and people may be able to see it on the screen. I'm required to show it whenever I'm on video. The trick is, I wrote a book about identity not for identity practitioners or leaders really, but for enterprise CEOs. That was my target persona — thinking about the book as a product, if you will. CEOs are looking to have market dominance, and they're worried about any personal liability they may face. They need to answer to the board in a very direct way.
So the book is trying to make the possibilities of identity and the risks of identity — in the security conversation, but also in what I'd call UX vulnerabilities — real to that CEO, so they understand they may not be appointing a chief identity officer. I don't actually really agree with that line of thinking until you get clarity around what they're supposed to do. But they need to empower somebody, maybe at a skip level, who is responsible for strategy and backlog and prioritization and connection to the corporate strategy. I think all that is possible, but it takes a pretty sophisticated CEO to get to that place, and I'm there to help them understand those things.
Cool. That's the underlying kind of premise of the book, which I agree with — though of course I would, given the industry and where I've spent my time. But to tie back into the previous discussion, what were the deeper metrics you feel like, especially for our audience who's customer identity and access management aware, they should be thinking about or considering or digging into?
One of the things I know you're very sensitized to is that security is kind of a baseline, but experience and upsell and cross-sell and loyalty — and I have this framework of the four P's in the book, of which one, usually the least respected, is people: what people actually want out of these connected technologies. One of the things a security-aligned identity leader often won't look at is time on task.
UX leaders understand about counting clicks. There are a number of input metrics that exist in the UX world, in the digital product design world. But number of clicks doesn't quite get at it either. I really like time on task for every end user, because once you combine that with something like year-over-year fraud, you've got a very interesting compound picture of whether you've chosen a no-compromises design for your different journeys and how you've instrumented the back end. And you can even look at, if it's applicable to the business, something like cart abandonment.
Once you start to understand these things — metrics are best when they're derivatives or compound in some fashion — and you start to combine them, it can get quite powerful. You had a big passkey deployment: well, what suffered? Did your business suffer? Did your security suffer? You can start to get a sense from just those things in a CIAM context.
That's great. Well, I think it is 2026, so I can't have a webinar or discussion without talking about AI — so I'm sorry. AI is reality in some ways. I bet you have opinions or thoughts on this. One of the issues I personally struggle with when I talk about AI in general, and about identity in the AI space, is what's real and what's transient. What's a trend worth jumping on, and what is a fad?
I kind of made up my own personal hype cycle in Mastering Digital Identity. It started with a talk title somebody gave me — "Trends and Transients" — and I think those are two great categories, but I realized the stuff I came up with also had in it tropes and transparence. So that's my little framework for trend assessment.
One of the things I've observed go through the transient phase and into the trend phase is this question of intent. We're starting to get interesting clarity among the smarty-pants in the identity field around understanding intent versus authorization. You can get finer and finer grained authorization, but intent is about what the privacy world would call purpose of use: what are you going to do with the access you're given? And that's a really hard thing to solve with agents that are parsing your natural language — they're quite easy to confuse on that score. It looks nothing like an authorization problem exactly.
Last year was all about agentic. 2025 was agentic — that was the word. I looked it up, and I think people started Googling for things like "agentic AI" and "AI agent" around November 2024. And I sort of think that 2026 is the year of intent. It's gone from not being a visible problem — because we didn't even understand the problem space yet — to starting to enter the consciousness of enough people that I would say it's become a trend. In the meantime, all kinds of other things have become tropes.
Right. What's an example of a trope? And then I'd love to dig in more to this intent idea.
A trope — here's how I define it. It's like you want to give an eye roll when you hear it, or make air quotes. Like, for a long time, I couldn't say "digital transformation" without going like this. Maybe "stakeholder" got a little bit of that too.
I'm not going to make you pick one — I don't want to get you in trouble. But that's a great definition. If it's something that has become cliché, is that a fair statement?
The whole — in fact, the same way I think about decentralized identity: we started having this use case very early on. In fact, before we had decentralized identity, we had user-centric identity. You'll remember. And the use case was, "I want to prove that I'm old enough to drink when I walk into a bar without showing my age." My feeling about that was the entire use case became a trope. It was like the use case is old enough to drink by now.
So I would say a trope in the AI world — the analog to that — is going and booking your airfare through AI. Not that it's not useful, but you have to dig to get to the usefulness beyond the eye rolls.
Right. That makes sense. So you mentioned this contrast of intent versus authorization. I wondered if you could talk about how you determine intent at scale, and then what do you do when you determine it?
It's really tricky and quite nascent. I'm starting to see a few solutions that are scratching at the surface of battling meaning injection. The example I was just using — betraying my Star Trek: The Next Generation history — is "Shaka, when the walls fell," which was a people that only spoke in analogies and cultural allusions. You can parse all the words but you don't really know what it means. And if you're using analogies to describe something, people have been playing with Claude Fable 5 of late, and you can easily get it to overrun its guardrails just by using clever analogies for how to break into a system.
That's the kind of thing that is very hard to instrument without going into potentially neuroscience, and definitely into the ontological world. My roots are in SGML, which was the predecessor to XML, and that field is still full of data scientists who really care about instrumenting and objectifying ontologies, reifying them. I think we're going to have to go there.
So it's a much deeper problem. Authorization was bad enough — authorization is ten times harder than authentication, and we've now started tackling those issues. I'm so excited because authorization and delegation is my happy place. But this intent challenge is getting into the semantics in a very deep way. I look forward to making it tractable, because right now it's a little scary.
So where is that discussion happening — for someone who stumbles on this in three or six months? Is it in the standards bodies? Is it in the backrooms at identity conferences? Given your point that identity spans a bunch of different disciplines, is there a particular discipline spending more time thinking about it? I'm sure fraud divisions think about intent quite a lot.
From the practical sense, the folks doing fraud mitigation in all its various guises have been using AI for a long time — predictive AI, old-fashioned AI — and have been using more and better tools as we go. So that's a great locus for it.
The conversations I'm finding today are really all over the place, at every chance we get — whether it's an in-person conference like Identiverse, or whether it's in Signal or Slack. People are hungry to advance the state of the art quickly. I'm seeing some proposals for specs, but when someone proposes a spec that's cleverly using transaction tokens and the OAuth stack and says it's intent-based access control, my first assumption is that they've defined intent down to become much finer-grained contextual authorization. And it's okay to solve that problem. We need better solutions in that area. Getting to a place of zero standing privilege, where we're comfortable adding back privilege at a moment of need — that would be awesome, and it will help us pay down the debt we've been collecting for maybe decades.
But the intent problem is just a different plane entirely. I think it's going to be quite exciting what happens by, say, the end of 2026. I look forward to it.
Awesome. I do want to move on to another AI-based topic — the idea that I think you've referred to as the Dunning-Kruger of AI readiness. Do you want to talk about what Dunning-Kruger is, for people who may not know? I've heard it before, I had to look it up. And then can you talk about what that means in terms of AI readiness?
Dunning-Kruger is the phenomenon where one feels very confident in abilities one does not actually have. There are whole cooking shows where it would be no fun if people didn't have Dunning-Kruger — they're so confident they can make the dish and they're terrible at it, and it's funny to watch.
But when it comes to AI readiness, we're finding unwarranted confidence all over the place. And you folks at FusionAuth have put out a report that I think is important for people to see — it puts some data behind that.
Yeah. At the end of the day, what we found — and we'll put a link in, we don't need to dig into the charts or graphs — is that the more people used AI, the more incidents they had. People who weren't using AI didn't think they had incidents. So the more you use AI, the more breaches you had. What does that mean from a practitioner perspective, in your opinion?
There's a tension. Cautious, risk-averse organizations are going to want to go slow — not use new tools, and grow their business at linear speed as a necessity. And then there are organizations that are hungry to 10x their business, they're going to be a little more loose and maybe have that unwarranted confidence, and they're going to experience more breaches and more incidents. They might consider it the cost of doing business, but we don't even know the extent of how bad these could be. We haven't fully lived through just how bad it really could be yet.
As a risk-averse organization, you kind of want to let up on the brakes a little, just to compete. That's the challenge. Everybody's sort of hurtling forward at some speed, and that's presenting problems for those of us who are trying to at least add security to the mix and add fraud reduction to the mix.
Is this an AI-specific problem, or is this something that happened with other technologies too — mobile, APIs, back decades ago, the Internet itself? Or is it just bigger because AI is bigger and making some people move faster than others?
The element that makes this different in kind — "quantity has a quality all its own," as they say — is this: I was there when the API economy started, and everybody did have to participate. But everybody was almost equally motivated to create a mobile app, create APIs, expose them. Maybe a lot more API keys were used than we'd like, but it still felt linear. Least privilege was still a concept. The fact that OAuth has scopes is evidence there was some sensitivity to least privilege.
I've been calling AI agents "most privileged engines," because you don't know until runtime what they need to do — and they don't know until runtime what they're going to want to do. Are you going to want to let them? That depends on your risk tolerance. It's the marriage of AI agents being LLM-driven human mimicry — okay, that was fine enough with chatbots — with the API economy. We let them go make calls, and that's what enables that kind of privilege explosion. That's where the intent problem comes in, as well as the authorization problem. I think that part is different in kind.
One of the things I've thought about is that people have a desire to over-permission their agents because the more permissions you open, the more useful they are. But the other half, in my opinion, is that the API economy doesn't have the kind of granularity of permissions needed. I use this example all the time: I can't say "agent, you get access to this portion of my Gmail." I can say you can read Gmail, but I can't say you get it for this time period and for these senders, because Google hasn't built that into their scopes. Do you have any intuition on how to solve that other than asking Google to fix it? Is there a proxy in the middle, any kind of technical approach?
It's an application-by-application problem, and that's what makes authorization ten times harder than authentication. With authentication, pretty early on we agreed on some semantics that everybody cared about flinging across the Internet in SAML assertions. But the semantics for each application are owned by those application owners. That's why it comes down to the product developers and app developers for each of these connected products — and socializing the ability to tweak access. It's hard to implement, and it's going to be different everywhere. I use Notion all the time, and Notion has been relatively clever in adding more granularity. But Notion's grain will still be completely different from, say, Canva's grain. It's just the nature of the problem.
I think AuthZEN started a nice, interesting conversation about this a couple of years ago. I was part of the initial work, leveraging not just policy-based access but also needing to send descriptors around of what the grain is. RAR — Rich Authorization Requests — was a great entrant into that landscape. It's the kind of thing that starts to let us describe our own application semantics sufficiently, and then bubble up standardization where it's appropriate for an industry that decides it's no longer differentiating to expose that feature.
Well, if it comes back, we'll splice it in. I'd like to move on to our fourth and probably last topic, because we want to be respectful of everyone's time. What's your stance on responsible innovation? Some of the frontier labs are charging ahead, and others are saying, "Woah — this is going to have impacts not just on technology but on society at large, employment, and other things." Do you have thoughts on that?
I'm a heavy user of Anthropic products, and I've appreciated quite a few elements of their approach to the grain question — finding happy medium places where you ask for something and can ensconce it as a kind of policy or setting. In terms of the development of AI itself and model development, we're all feeling our way. Obviously there's huge business in this — to the point where you can't even conceive of as many zeros as there are.
A couple of years ago I started rereading Dune. I'm still in the process, and Dune has some cautionary things to say about machines that think like humans, shall we say. I have that essential caution in my nature because we don't know the implications. There are Oppenheimer references that could be made.
At the same time, I'm seeing a flowering of innovation at every level. The model makers are fueling innovation among individual people who are coming up with the next things that are going to be the new hotness. Going back to my science fiction roots — I think it was Theodore Sturgeon who said "90% of everything is crap," in response to someone who said 90% of science fiction is crap. People are going to come up with ideas that maybe aren't good. But people are also going to come up with good ideas, and we're going to have more ideas. I'm actually quite excited about the innovation landscape among those who are finding new ways to leverage AI. We don't even know what the next few unicorns will be, but it's going to happen rapidly.
Very thoughtful response. And in some ways this gets back to our original talking point — the product leaders versus the security leaders and the common tension between them. Here we're talking about frontier labs being more cautious, while at the same time — literally the Butlerian Jihad is the thing that's mentioned in Dune — the thinking machines, which I really appreciate that reference. And so much has been enabled at the same time. I have seen nontechnical people in my life build things I wouldn't have had time to do myself. I don't need to remember the intricacies of the GitHub API — I can just say, write the script to do this. Is this different in kind, or is this just an accelerant?
Those are great examples from your own life, and I have them in mine as well. Let me give one example. I'm a cochair — one of three cochairs — of the Death and the Digital Estate group, DADE. Dean Saxe is our fearless leader. He created a skill — a Claude skill — to help people do digital estate planning. This is one of the most difficult things to do in life, one of the things people are most incentivized not to do. We're also facing technological challenges in the CIAM world around things like legacy contacts and identity relationships. This skill helps people broach the topic with someone who's not going to be judgmental, to collect the necessary information in a privacy-preserving way, and to even get to the point of — it's like backup and recovery for your life and your digital life. I'm so excited about what's possible around even depressing topics.
So is it different in kind? I think it is, because it's akin to being able to leapfrog — like nations that never had landline phones and went straight to mobile telephony. We had a lot of POTS infrastructure we had to live with for a long time. But there are people now who are able to be productive, get their ideas out there, generate new thoughts and content and solutions and products and patents. I've talked to so many people who have just put in a patent application with Claude's help. We don't know which of those will be productive, but this is a leapfrog for most of those people. And it's certainly a leapfrog in productivity for people who could do it the old-fashioned way but can now do more. I really do see that as a real leapfrog — different in kind through quantity.
Totally. The analogy I've heard is it's horses versus cars — it's not a faster horse, it's an automobile, and it's only getting faster. Well, I think we're wrapping up. Can you mention your book again, please?
Yes. Mastering Digital Identity: From Risk to Revenue — appealing to the CEO, but I hope I'll find among all the identity and security practitioners and leaders champions who find something in it that's truthful and could help them accelerate their programs and strategies. And maybe you'll find it worth handing to someone you know who really needs to read it.
As an identity practitioner, I'm reading it. And what's been helpful to me is the framing of what CEOs actually care about. As someone who's down in the depths of SAML and OIDC and signing of tokens and all that fun stuff, you don't necessarily understand what your CEO is thinking about and the broad concerns they have. Your book does a great job of connecting the two — you're speaking to the CEO, but someone who knows the details of identity can learn to use the language to speak to the CEO and get things they consider to be important done.
Cool. Any last final thoughts about identity in general? For people who don't know — you were one of the authors of the SAML spec, if I get that right.
That's correct, and I was the first chair of the group as well. When they were looking for somebody who wouldn't be on one side or the other of a particular fence, I came up as the person who could bridge that fence.
Awesome. From that perspective, do you have one last bit of advice you'd give to anybody around the identity space?
Within the book, I mention the four P's framework, and I talk about people. And there's a reason I'm a big fan of CIAM as well — precisely because we know we're not the boss of our users, we can't make them do things. And that means identity jobs-to-be-done are different for different people.
If you take away anything, it's to remember that the person you're talking to might see single sign-on as a security measure that allows you to propagate strong authentication throughout multiple systems. They might see single sign-on as the primary reason to join together a bunch of brands and give people a great experience no matter what brand they came in through. The realization that single sign-on literally means different things to different people — it symbolizes everything I tried to put into the book: that everybody's going to get something out of it, and it might not have been the same thing that you came to the table with. And that's a powerful realization.
I love it. Great. Alright — thank you, Eve. Really appreciate your time, and thank you everyone for watching and listening.
