Liveness detection answers a question that passwords, device signals, and behavioral analytics cannot settle on their own: is a real human being actually behind this session? This webinar examines how presentation attacks, injected camera feeds, and deepfakes undermine identity verification, why analyzing pixels alone is a weak foundation, and where a liveness check provides enough additional trust to justify the friction. You will also see how that decision changes across onboarding, account recovery, promotional abuse, high-value transactions, and agent-driven workflows.
.png)
.png)
Hi, folks. Thanks for joining us today. I'm Dan Moore, Senior Director of CIAM Strategy and Identity Standards at FusionAuth, and I wanted to welcome Cameron D'Ambrosi to the stage. He's been in the identity space for over a decade, and he is currently Head of Strategic Partnerships, North American EU for FaceTek. We're going to talk about liveness detection and how that can help secure your customer's identity.
Quick bit of housekeeping: if you have questions, please use the questions tab. This is going to be an interactive session, so we welcome any queries you have for us. Cameron, thanks for joining us.
It's my pleasure. This is a fun little bit of role reversal — I'm kind of used to sitting in the moderator catbird seat. So, excited to be joining as a subject matter expert and, obviously, deeply excited to chat about identity, liveness, and the intersectionality of all these different threads that I think are bubbling to the fore here with the rise of agentic identity, and all the happenings in identity and access management and customer identity and access management. So let's dive into it.
Yeah, let's do. Well, first, let's kind of set the stage. Some of our audience may or may not know what this is, but can you give us a simple definition of liveness detection, what it is, and why does it matter for identity verification?
Sure. Liveness detection is extremely complex and extremely simple at the same time, but I often like to describe it as: do you know who the physical person is behind that user session? Both — is it a physical person at a terminal, and then is the face that they are presenting actually their real-life face, or are they wearing a mask? Are they holding up a cardboard cutout? Or increasingly, are they using some form of injection attack to compromise that camera signal path, take that over, and then insert a deepfake face? So whether it's Dan's face, my mom's face, anybody's face on the Internet — understanding, can I trust those pixels that I'm seeing in that camera input so we can determine: real human being, right here, right now? And then critically, who is that person, so we can either authenticate them or perform an identity verification session.
And when you talk about cardboard cutout, you mean someone actually printing out a high-fidelity picture of my face or your face and then holding it up to the camera? Is that a common attack vector, or is it much more software-based at this point?
I would say much more software-based at this point. FaceTek has been around for over a decade. And when Kevin and Josh, our cofounders, started the company, the threat vectors were really, you know, Mission Impossible-style latex masks — or, again, for really low-quality liveness, just printing out a face and holding it up to the camera, or simply holding up your smartphone to a high-resolution screen was good enough. There wasn't any attempt to actually understand where these pixels were coming from, where this image was coming from. It was like, hey, it looks like a face, it is a face, and therefore this is a real person.
Sure. On that same vein, what's the difference between a presentation attack — which is one of the things you just kind of mentioned — and an injection attack, and which one is more difficult to defend?
Great question. Different attacks can take different shapes, and obviously a well-executed presentation attack and a well-executed injection attack can both be extremely difficult to detect. But I think in some ways it's really a question of which signals are we paying attention to and how do we risk-score those appropriately.
I often analogize fraud defenses or thinking about identity as holes in a pile of Swiss cheese lining up. You often hear this analogy in aviation accidents or aerospace accidents where you have all these different layers of safety, and what it takes for an incident to occur is all those holes in the Swiss cheese to line up just right. In liveness, I think about how we can add as many layers of that Swiss cheese as possible so that the odds of all those holes lining up and the ball bearing dropping through are exceedingly low. Detecting injection versus presentation attacks is really about signals fusion — understanding what is the risk of this device, what do I know about the session, and do all of these data points make sense.
From a presentation attack perspective, we use a 3D depth mapping of the face as our key liveness signal. The FaceTek Zoom 3D proprietary methodology has you pull the camera away from your face and bring it back towards you. That's where we're capturing the depth of your jaw, the under-chin jowl — obviously not on GLP-1, so I still have some work to do here. But that is really one of the primary mechanisms for detecting if you presented a 2D cutout.
On the injection attack side, it's really about protecting that device, looking at that signal path, leveraging the robust on-device SDK that we deploy to really look at: is this a trusted device? Has it been jailbroken or rootkitted? And what do we see from all those on-device sensors, and do they line up with the signal coming out of that camera?
What many deepfake detection platforms are doing, I refer to as pixel peeping — just looking at the image itself and saying, can we detect the signature of pixels that have been manipulated by a deepfake? That is exceedingly difficult to do, and the false positive rate is exceedingly high. We're obviously doing some of those analytics as well, but the heavy lift is being done on that on-device SDK, really looking at: can we trust what is coming off of that camera signal path internally in the device? That's where a lot of the heavy lifting is being done because, you know, pixels can be manipulated in a number of different ways. Someone might be using one of those smoothing filters that makes their skin look nice. I've seen people do makeup or hair manipulation just to look nice on camera, and obviously all of that is being done with similar technology to face replacement — and it may throw false positives.
Gotcha. So the reason you all focus on the device side — even though you do some of that pixel peeping, as you say — is that it's just more deterministic and it's a better foundation to build a liveness check on. Is that a fair statement?
Exactly. And we really, really strongly believe that both your FAR and your FRR — apologies for going into full jargon speak, false accept rate and false reject rate — are both critically important. If we are going to be in a high-trust position with our partner platforms, we need to make sure that we are keeping the bad guys out. But just as importantly, we need to make sure that we are letting the good traffic in, because we deeply understand that fraud teams increasingly in today's era are not just beholden to those fraud metrics — they're working very closely with growth teams to make sure we can keep that hockey stick moving up and to the right in terms of welcoming good users in.
I hate to overly generalize, but for most platforms, fraud is not truly an existential threat. What is an existential threat is a crippling amount of false rejects. I often joke — and you can tell I'm an absolute hoot at parties — I like to tell people: I will stop your fraud problem across any platform tomorrow. I can guarantee a 100% reduction in your fraud rate. And do you know how I would do that? I would reject every transaction. I would kick every customer out of the flow. The proverbial monkey's paw wish coming to life: oh, you wanted to get rid of fraud? Congratulations — you also have no customers.
That reminds me of the old proverb that the only secure computer is one that's off a network and unplugged — super useful, but it's secure. So similar kind of thing. Makes sense.
Yeah. That's actually a really interesting viewpoint, because you're kind of walking this tension between false positives and false negatives. You want to stop as many of the bad guys as possible while letting as many of the good guys in as you can. How do you frame that conversation? Because it feels like that's fundamental across all security, but are there any special ways you frame it in the context of liveness checks?
That's a great question. Just like all facets of your identity stack, understanding which tools you have to deploy and where and when to bring them to bear is critically important. That's why in my time at Liminal, developing our market intelligence platform, we really liked to anchor on use case as the core driver of understanding how we're going to tackle a problem.
At FaceTek, we service platforms of all kinds. We power iFood, the Brazilian food delivery service, protecting the platform from fake couriers — couriers who are impersonating a trusted and onboarded employee of the company and trying to rob you while pretending to be a delivery person. And we also secure platforms where maybe there isn't an existential trust and safety risk — it's merely enabling a platform to deduplicate users for a coupon or promotional offer. Obviously you want to configure where you trigger that liveness check and how aggressively you push folks into it based on those risks.
If I'm a trust-and-safety-focused platform like our partner at Match Group, they're sending every single new Tinder and Hinge account in the US through a Face Check 3D liveness check because they want to make absolutely sure there are no fakers on the platform — nobody who created an account with a deepfake who doesn't actually exist, or nobody creating an account claiming, hey, I'm Ben Affleck, come meet me on Tinder. Paradoxically, you have platforms where they may be much more willing to accept a fake Ben Affleck and let him have, say, two free coupons. But the third time they come in for a coupon, you prompt them to scan their face and say: you've gotten two bites at the apple, but if you want three or more, we're going to push you into a liveness check and deduplicate you with a one-to-N biometric against our list of known customers.
So it really comes down to: what are you trying to achieve as a platform, and what are the pros and cons of layering in some of that incremental friction? I'm not an absolutist when it comes to liveness. I will fully acknowledge that there is an inherent level of friction that comes with pushing someone to a liveness check that doesn't exist with other signals. It's really about deeply understanding your use case — where are those moments of highest risk to your platform, what are your objectives in deploying liveness, and are you truly trying to keep 100% of threat actors out and accepting the associated decline in pass rate, or are you playing with those sliders a little bit and adjusting risk on an as-needed basis?
That's a fantastic answer. One of the things I've run into — and I know other folks have too — is that because these things are probabilistic, they give you those levers. And lots of times customers are coming to companies like FaceTek saying, I don't necessarily know what the right number is. So how do you think about helping them? Because they know their business a lot better than you do, but you know the technology and the risks and that friction better than they do. Is it a consultative approach? Do you have stats from people in similar industries or situations? How do you help people pick the right number? And I understand it's also probably not a point-in-time decision — it's a, let's set one number, experiment, and see how things go. What's your process around that?
Great question. Obviously every customer is special and unique, but I think you really start from understanding what are those existential threats — what is the absolute worst-case scenario that we don't want to happen — and making sure we can cut that out. Then conversely, what are the opposite types of customers, the ones we absolutely want to make sure we are not inconveniencing? We play with those risk criteria and really tailor the stack and when and where we bring liveness in as a challenge to those exact needs.
And to some degree that sounds like a platitude, but I do think that looking at a granular level at where you are seeing drop-off in your stack, what those percentages look like, and then critically identifying what are those known fraud breaches that have happened — those confirmed attacks and those losses — and understanding where we can be most impactful in minimizing the false accept rate while keeping that false reject rate down as low as possible.
From that perspective, understanding what your metrics are actually telling you is another key signal. It may come as a surprise to some folks, but if somebody drops off out of a liveness check session, that's kind of an incomplete signal. We don't necessarily know conclusively: was this a fraudster who simply ran into the brick wall three times and couldn't get through, or was this a good customer who was actually inconvenienced? So from the FaceTek side, we only have a partial picture. Our most successful customers are really looking holistically at all of the data points they can leverage to understand what is noise and what is signal.
And actually, somewhat surprisingly — although I think it makes sense the more you think about it — support calls and customer service tickets are a really critical data point in understanding where you have real drop-offs and real customer friction versus where it's actually a signal that the platform is working as intended. We have a Brazilian neobank customer that recently came to us with what they thought was a surge in false reject rate. They said, we've noticed this spike in drop-off on customer authentication sessions, and we're concerned that too many good customers are dropping out. We took some time to walk through their help desk and support call metrics to really tie, at a granular account-based level: for these accounts that we knew were trying to log in and hit three rejected liveness detection sessions, did they end up opening a support ticket, or did they never come back in any way, shape, or form?
It turns out almost all of the people who had hit three failed liveness checks were not coming back to support channels. Now, could those be 100% legitimate customers who really wanted to get into their bank account, hit a liveness fail three times, and then simply decided, I don't want to transact today? That's certainly a possibility. But from our perspective, that's a pretty good indicator that those were actually account takeover attempts that were rebuffed — as opposed to a good customer, because a frustrated legitimate account holder is very likely going to complain to somebody. They're going to say, I cannot get past this authentication mechanism, please help me get into my account. If you don't see those kinds of tickets and support calls coming out the back end, that's a great leading indicator that what looks to be false reject is actually the system working exactly as designed.
I love it, because that was going to be my next question — what are those other signals that customers have that FaceTek doesn't have? And I would just say to anybody listening: that is a great reason not to shut down real-life customer support, because it gives you this other high-fidelity metric that you can track — real people. Fraudsters, to your point, are not likely to open support tickets. Not every legitimate customer will either, but the overarching trend is definitely going to go the other way.
I do want to ask: we've kind of talked about liveness as the root of trust, and I was wondering if you could talk about why you describe liveness in that way. What makes it so good for that kind of solution?
Yeah. One way of thinking about it is: if you have a platform and you have never actually done a liveness check on one of your users, what do you really have in terms of signals of humanity? You have verified a data pattern — and data patterns are infinitely reproducible by attackers. That's certainly not to say that a set of probabilistic signals, again when sufficiently overlapped like those proverbial slices of Swiss cheese, can't reach a very high level of certainty as to the humanity of a user. But it is not a certainty. You don't know for a fact that there is a real human face, a real human being behind that account, and liveness brings you that certainty.
So it really depends on how you are treating those levels of assumption that you've built from probabilistic signals. And when you have a critical risk inflection point in a user session, do you want to step up to a more authoritative source of ground truth?
I think that can be really powerful particularly in the account recovery motion. When people start thinking about liveness, they often think, well, if I'm going to go down the liveness path, I need to be running liveness at all times — every authentication needs to be liveness, every touch point, every transaction should get a liveness check. And that's not where we can be best deployed. I think: can you, at an opportune time at account opening, throw a liveness check in to establish that baseline, and then fall back on those more probabilistic signals? The customer is behaving as expected, doing normal customer things. Their risk profile is in line with an expected customer. There's no need to step up to that added friction — I recognize this device, I recognize the IP address, maybe we have some geolocation signals, some behavioral signals that they're buying things they've normally bought and shipping to places they've normally shipped.
But then you have a deviation. A geolocation outside the normal — maybe this person is on vacation, maybe it's an account takeover attempt. They're looking to reset their password on a non-trusted device we've never seen before. If we have built our customer relationship on that ground level of trust of knowing what Dan Moore's face looks like, then when we have one of these high-risk moments, we can step up and say: prove to me that you're the same person who opened this account — with a biometric level of certainty. And then we can, at a very high degree of trust, push through that password reset, rebind a passkey to a new device, or ship a high-value product to a new address without additional risk or friction, because we've reached back to that proven point of liveness.
So in many ways, I think of it as a very strong foundation for your house. Just because you build a strong foundation doesn't mean your house is going to get hit by a hurricane or stressed by an earthquake every single day. But if and when you have that five-sigma black swan event, it's nice to know that we've built our house on a foundation of concrete and not a foundation of sand.
Right. That's great. And just a reminder, anyone listening on the webinar, please pop your questions in the question area.
That kind of leads to my next question, which is: there's a spectrum. You just talked about how liveness is really good at critical points in the authentication or user lifecycle. But how do you think product and security teams should think about structuring this identity verification funnel? There's definitely liveness, which is kind of on the far end in terms of certainty but also expense and friction, as we've talked about, versus lighter-weight checks like email one-time password. How do you counsel people to think about that cost-benefit?
Great question. In many ways your key number — and product managers in the audience, their ears will immediately perk up — is you start from the lifetime value of the customer. If we bring a good customer in, what's that expected revenue across their average lifecycle? Then work backwards from that point in terms of what budget do we have to play with to check each one of these identities, and where can liveness fit into that equation?
Depending on the database check you're running, paradoxically, a full liveness check can actually be a lot cheaper than some of those database calls, because data can be quite expensive — especially depending on the jurisdiction and the source. Obviously, the more authoritative the source and the closer to that government root, the more expensive it can be.
How we are typically seeing leading platforms structure this is what we call a waterfall approach, which can be fully dynamic in nature. We talked about some of those trust signals used to risk-score a transaction for an existing customer — we can bring all of those similar signals to bear in our onboarding waterfall and dynamically decide on the fly which challenges to present in which order. The sliders we play with again are: what is the budget we have to play with pursuant to that lifetime value of the customer, and what do all of our previous onboarding experiences tell us about what level of friction this type of customer is willing to accept, where are those drop-off pain points, and in what order does presenting them modify user behavior.
If we ask somebody to present their selfie for a liveness check right off the bat, that can be off-putting. Oftentimes you want to bring folks deeper into the flow to establish some skin in the game. Historically, the deeper you get into an onboarding flow and the closer to completing a transaction, people feel like, well, I've come this far, I don't want to drop off. Playing with those sliders and understanding how to optimize that total budget of friction and raw dollars to spend on checks — and ordering those in a way that maximizes each of those key performance criteria — is really the exercise.
That said, even within a specific type of business, depending on which geography a user is coming from, that might radically change how and where you deploy these different signals. For a customer in a more privacy-conscious market like Germany, asking for personally identifiable information right off the top might scare them off, whereas maybe a more passive check like a phone number or email OTP to weed out high-frequency fraudsters right away is a better approach. There are so many technologies and risk signals that we can bring to bear — it really is an overflowing cornucopia, which can be overwhelming. But really understanding how your customers are feeling when they come into this flow, and how you maximize bringing those folks through while minimally inconveniencing them, is really the name of the game.
Yeah. And I realize I'm asking you general-purpose questions, whereas if anybody on this webinar wanted to come talk to you, you would do a lot more listening initially than talking — because you'd want to discover what they know about those flows and those pain points and the type of customer they have. We don't have an example customer to use right now, so I appreciate you acknowledging both the general sense and giving people actionable things in terms of trying to understand their flows themselves.
Actually, I did have a question about specific customer use cases. You talked about the food delivery service and neobanks, but promo abuse on AI platforms is something you mentioned in our prep calls, and it seems like an underappreciated threat. How significant is the revenue bleeding from these burner accounts exploiting free token usage, and what does a biometric check that helps block this look like in practice?
Yeah, great question. Ring-fencing some of these fraud pain points can be quite difficult because it's a Rumsfeldian unknown unknown for many of these platforms. If you have not been focused on rooting out promo abuse, it can be pretty tough to tell as a product manager what percentage —
Real quick — can you define promo abuse? I kind of brought it up without explaining it.
Sure. Raise your hand if you have ever been presented with a coupon for a product or platform you already use, and it's only eligible for new customers — and maybe you realized, I have that second email address, I have my FusionAuth work email address that I can put in here and place another order and get that 15% off even though it was only technically for new customers. I think most platforms are fully aware of this kind of nudge, nudge, wink, wink. And if they wanted to, using some pretty simple first-pass data cuts, they could cut some of these attacks outright — have I seen this shipping address before? But companies are loath to do that for a number of reasons. One, even with the coupon, they're probably still turning some ancillary revenue from the transaction. But also, hey — people move. The guy who just took over my apartment after signing a new lease would be pretty disappointed to be ineligible for becoming a new customer of your platform because someone who lived there six months ago shipped their first Goldbelly pastrami package to that address.
So promo abuse is one of those classic double-edged sword problems where you really need to be careful to make sure you're not scaring away a good customer. I think where this risk calculus goes a bit pear-shaped is for some of these pre-revenue platforms — exactly this use case we talked about with AI, where I am losing a significant amount of real dollars from compute and token costs for these new accounts, and I may be keen to root some of those out because I'm not making real revenue off any of my customers.
Biometric liveness is a perfect use case for this, and you can pick and choose exactly how deep you want to go. We can do a first pass which is just: I need to see a real human face behind this session to cut out programmatic headless bots that are spinning up accounts for a human to later aggregate when they run out of tokens. My bot just sends me a new login tied to a new email address that was created completely programmatically, and I just switch accounts and keep slurping free tokens.
Or, if you really want to get granular, you can run liveness and — with the FaceTek platform — actually save the 3D encrypted face vector of every user that onboards and store those derived vectors completely on your own server as our customer. FaceTek never sees your customer biometrics. We never see raw images, we never see those stored vectors. But you can store those in your secure cloud storage as a FaceTek customer. And then every time a new customer comes in, you can check: this new customer who claims they're unique — have I ever seen this face before across any previous onboarding session? And flag the exact account they opened previously.
The beauty of the extensibility of these checks is that we are not telling you what to do with that signal — we are just giving you the signal. So as a platform you could choose to say, you already have an account, we do not wish to let you create a new one. You could nudge them in a friendly way and say, hey Dan, we know it's you — did you make a mistake and try to log in under a new email address? Get creative with it and say, here's the email for your previously created account, do you want to log in with this one?
Or you could say, we know our platform is so great and you really enjoy using it that you've created multiple accounts — if you sign up for a new paid tier, we'll offer you a 20% loyalty discount because you love the product so much. You can get as creative or as aggressive with it as you want. We feel really strongly: let's give you the maximum amount of those signals to play with.
We can add and remove pieces of Swiss cheese, we can layer in probabilistic or deterministic checks as we see fit — again based on: what are your specific needs? Is stopping all fraudulent new accounts the main criteria, or is it, we'll let you have three free accounts, but once you get to five, that's the inflection point where token burn starts to impact our bottom line? Full extensibility there. It's really about that lifetime value of the customer and what a new customer drop-off costs you in terms of projected revenue. You can almost dial in to mathematical certainty what that asymptote is — what's that sweet spot on the graph.
Sure. Yeah. And I think AI — because it has this direct usage-to-cost ratio — is almost in a special category. Because SaaS companies have, in some ways, AI is similar to ecommerce in that fraud or promo abuse has direct bottom-line costs, as opposed to SaaS, where one more account on your software has a marginal cost of delivery of essentially zero — that's a different kind of calculus.
As platforms move towards agentic AI systems where these agents are doing more and more, how do you distinguish between a legitimate automated workflow and a fraudulent one? And where does liveness play in terms of solving that problem?
Yeah, another fantastic question. I think platforms, if you do not have a strategy in place for how you want to assess the risk of agentic workflows — do we want to encourage those workflows, and if and when we do, how do we want to ring-fence and constrain the risks associated with them — those are the key questions everyone should be asking themselves. Only when you have those goals locked in can you decide which tools from your identity toolkit you want to bring to bear.
From an agentic workflow perspective, I really see liveness as playing a critical, almost speed-bump-style role in these flows. Obviously, people are deploying agentic tools and workflows to minimize human touch points — I am sending my AI agent to do this task because I don't want to do it as a human being. However, when we reach those critical risk inflection points in these workflows — when the agent is, I don't know, trying to deploy a bunch of code to prod, or check out with a $15,000 fifteen-leg around-the-world trip in first class, or pick your crazy high-risk use case — can we pause and say: all of this is great, we salute you for having an agent get this far, we just want to check in and confirm that the human being directing you consented to this, and put a human seal of approval on this transaction.
I think one of the big dangling question marks around agentic workflows in general — especially when a transaction goes pear-shaped — is how do we adjudicate who is left holding the bag? And I can really see liveness checks playing a critical role in that. So let's say you have an agentic commerce workflow that's about to execute, using tokenized payment credentials to purchase a ticket — can we hit a quick liveness check? Hey Dan, this ticket is about to get purchased, your agent is about to do X, Y, and Z, here's the budget, here's when it's happening. Hit a quick liveness check. Now, from a card issuer perspective, a payment rails perspective, a merchant perspective, an AI agent provider perspective — everybody can know to a certainty there was a real human being who consented to this, and we have a timestamped, cryptographically signed piece of evidence sitting on a server. If and when somebody has questions, here is an authoritative proof that Dan Moore — and not just Dan Moore's login, not just Dan Moore's saved password that, by the way, an agent could have access to — there was a real human being who said yes, I consent, and presented their face. And we can prove that to a very high degree of certainty.
Now it's up to platforms to decide when and where and how to deploy those speed bumps. That all ties back to the previous conversations we've had: what are our expected fraud losses, what's the lifetime value of our customer, and what are we looking to get out of these agentic transactions? Are we willing to eat some incremental fraud losses to become a leader in the agentic commerce space, or are we looking to have absolutely zero fraud and question marks because we think that's a key indicator of future adoption of our agentic workflows? It really depends on what type of business you are. We mentioned Amazon earlier — they're kind of the poster child for eating fraud losses and sacrificing those on the altar of friction, not inconveniencing good customers. Amazon is very willing to let a few additional basis points of fraud slide to make sure that at two in the morning, when I'm trying to buy $500 worth of tchotchkes I don't need, I don't hit a login screen and think better of it.
But if I'm deploying agentic coding tools and I want a speed bump before an intern can push code to prod, maybe maximal friction there really is a good thing. And we don't mind if somebody is ten minutes delayed pushing that new repository because they were struggling with how to complete a liveness check.
Yeah. I love this, because I've been thinking about agentic security for a while, and this whole concept of human-in-the-loop is really important. It feels like liveness checks are yet another solution with some unique characteristics because they are so tied to that human identity — both at the moment they happen and, as you mentioned in your previous answers, back to maybe that first implementation or first recognition of that user.
You did kind of start out by saying — and this maybe is not as closely related to liveness checks, but you said you need to think about whether you want to encourage agentic workflows. I just want to come back to your opinion on that. Not even thinking about liveness checks or anything else, but what does encouraging agentic workflows — or conversely discouraging them — actually look like for you?
Yeah. With the speed that AI agents are being deployed and developed, putting guardrails up on your platform is becoming increasingly difficult. By show of hands in the audience: who has asked a question of one of their Claude agents, had it bounce off a robots.txt and say basically I can't access that page — and then you fire up the Claude browser agent to basically pretend to be a human user and have Claude use its robot hand to move your mouse to scrape that information in a way that the site's owners did not really intend?
I think those guardrails are the first ways in which platforms are going to be encouraging or discouraging agentic workflows. My personal perspective is you are going to really struggle to keep agents off of your site because of these workarounds. So if you want folks to use your site with agents in the way that you like, build those tools. Build an MCP server. Surface those agentic touch points that you can surveil and watch in a programmatic fashion, and you can build those human-in-the-loop touch points. You can build those liveness speed bumps in as you see fit as a platform. Because the assumption of, well, I put three deadbolts on my front door, so there's no way bots and agents are getting in — they're coming in the window. They're bringing out a band saw and cutting through the side of your house. They're doing everything they possibly can.
From that perspective, I really strongly believe in a carrots-over-sticks approach, because similar to the fraud world, the AI and agentic platforms are on the front foot when it comes to building tools that make any website or any service accessible to AI agents. You're really going to struggle to keep them out. So paradoxically — let's open the front door, but have that front door lead into a cage.
Or at least the path we want you to take. Not necessarily a cage, but, like, you go through the kitchen, you don't go through the living room. Yeah, makes sense.
I do want to be conscious of time. We're coming up on it. So I'd just like to leave the last word for you, Cameron. Our audience is mostly technical folks — developers, CTOs, VPs of Engineering, engineering managers — less from the identity side, which is why we love to bring in identity experts like you. If you had to give one piece of advice around liveness checks for that audience, what would it be?
Great question. I would love folks to think about us as one very powerful tool among many in your digital identity stack. Don't be discouraged by the potential for friction to impact your user flows. Really reframe that conversation and think about friction as a feature and not a bug, and identify those high-value touch points where the right level of friction can make or break your risk posture and your customer experience.
User friction is always thought of as a negative, and it doesn't necessarily have to be. I think users appreciate knowing that you are taking platform security very seriously. I think users appreciate knowing that their account credentials, their payment information, their identity information, and their data in your platform is being secured, and that teams are working hard internally to protect against all kinds of fraud and risk threats. So don't shy away from using friction where appropriate, but deploy that friction in ways that are rowing towards those critical goals: what is the lifetime value of my customer, and what is the true cost of the fraud I'm experiencing?
When it comes to identity, I do think we can have our cake and eat it too. I don't think we need to be sacrificing user experience or accepting unchecked fraud losses on the altar of revenue growth. I really think we can find that sweet spot on the graph — maximize revenue, reduce those fraud losses — and do so in a privacy-preserving and biometric-records-preserving way. The FaceTek solution can be deployed fully self-hosted. You can comply with all relevant data and biometric localization requirements. Don't get scared off by the use of biometrics, or by terms like a 3D biometric face map. We can comply however you need to comply with relevant regulations.
That's great. And just again, what I took away from what you just said is: friction is a feature, and you need to know how to use it wisely. And identity liveness is a very powerful way to deploy that at the right point in time, as you talked about many times throughout this conversation. Cameron, thank you so much for joining us. Really appreciate it. And if anyone wants to learn more about FaceTek, it's facetech.com.
Facetech.com, and my email address is cameron@facetech.com. No sketchy email format mysteries on our end. Would love to hear from anybody. If you couldn't tell, I love talking about digital identity — always glad to chew the fat, whether it's about biometric liveness or any other facet of the space. I hosted the Liminal podcast for a number of years, so I'm on record as being a big identity nerd. Please reach out — we'd love to hear from you.
Great. Alright. Thank you so much. Thanks everyone for watching — now or in the future. Bye.
