Navigating Authorization Challenges in FinTech with Jimmy Zelinskie and Pierre-Alexandre Lacerte – KubeCon Europe 2025

This is Textron tv. Hey everybody. Welcome back to CubeCon Plus Cloud Native Con 2025.

We're back here in London for the Europe edition of this show. We're here with Jimmy Zelensky, who's chief product officer for au Z. There a startup focused on authorization.

And we have Pierre Lizer, who's, uh, works at one of the, uh, banking financial services firm called Upgrade, correct FinTech. Yep. And they're a customer of Jimmy's.

Guys, welcome to the show. Thank You. Thanks for having us.

Thank You. Have a unique approach to this whole problem because you're kind of using graph technologies and, uh, I think Google created some sort of white paper that you guys are essentially using as a foundational document. But walk us through what you guys built a little bit and how it's a different approach.

'cause this authorization thing has been a pain in the butt for longer than anybody can remember. Absolutely. Yeah.

So, uh, my story really starts with building play, which was one of the first private docker registries. And when you think about it, the only thing that makes a private docker registry different from like a regular docker registry where anyone can pull any container down, is literally authorization. The core differentiator of that product was authorization.

And so throughout the lifecycle of building that product, we hit lots of different hurdles, and those hurdles were all related to authorization. And fundamentally, there were certain features that we just could not ship as a business because we, it wasn't, the juice wasn't worth the squeeze for refactoring custom code we had written around authorization. And, uh, we, we just didn't ship those features.

And, uh, ultimately one day Google publishes this paper called the Zanzibar paper as 2019, and we read this paper and said, this is actually how you're supposed to solve these problems. This would've solved all the problems we had building clay. Um, so we basically took a look around, said, why is no one else doing it this way?

And left our jobs at Red Hat to found off z. And at the core of that is some graph technologies or how is, what is exactly in that Zanzibar? Yeah, Ocean.

So the approach in the Zanzibar paper is basically this idea of relationship based access control, which is not how most people are doing things today. Um, the idea is essentially that you can save sets of relationships inside of a database and then query that later to determine who has access. So an example of that would be, Jimmy is a part of this team, this team has access to this resource, and then if I can find that chain from Jimmy through the team to that resource, that means Jimmy has access to that resource transitively through those relationships.

So that's the fundamental concept behind everything. And authorization is kind of core to the whole FinTech motion. So how did you wind up finding these guys?

Because there's a lot of people talking about authorization solutions for decades, and so, and these guys are hanging out in Brooklyn, so how did you find 'em? Yeah, Yeah. Um, so I guess like, um, initially upgrade, well, yeah, we're a FinTech, so we offer personal loans accounts, but, uh, eventually we started developing more advanced products where we, we had to kind of change the foundation of our authorization, uh, model.

Uh, and then usually when those situations happen, you're, you're kind of like, okay, should I build something? Should I purchase something? And is there something in the open source world that answers our need?

Um, so we started looking at, uh, a few solutions actually, and then also the, the landscape, like what is GitHub doing? What is a Carta Airbnb doing? So there was a podcast I think done by, um, I think Okta anyway, a few years ago.

And they talk about like a lot of in-house built solutions and a lot of those solutions were kind of hedging into the direction of Zzi Bar or a Zzi Bar ash approach. So we kind of discovered, uh, SPICE db. Um, and then, yeah, that was kind of it.

We reached out and then started experimenting and we built a few prototypes, which eventually led to a, okay, let, let's go with Spice DB and not build, uh, in house. So you Weren't really reinventing a wheel, but you decided it would be better for somebody else to build a wheel, Kind of. Yep, that's it.

That's it. And, and our need, I mean, our, our team, uh, like we have somewhat, uh, I mean 400 engineers, you know, so we're, we're kind of not that small, but at the same time, we cannot allocate like 200 engineers on authorization, you know, so, so the idea was to leverage something that, uh, that's proven, uh, and also easy for our developers to onboard to, you know, so the concept of a graph, the concept of schemas, how do you roll this out to production? Um, and then, yeah, so that was kind of the idea.

You know, you hear two terms co-mingled all the time, but they mean different things. You know, there's authentication and then there's authorization. Do people get that or are they kind of still co-mingling and at it?

'cause sometimes I'll talk to people and they're like, yeah, we have active directory. And I'm like, eh, not quite the same thing. Yeah, This is definitely still something that even the most senior engineers slip up because it's really easy to abbreviate both these terms with just off and then it's completely vague conversation you're having.

Um, to the degree where we basically decide not to use those terms at all. We try to avoid saying authentication and authorization and instead we say identity and permissions, because even non-technical folks can understand the difference between those two, proving your identity to someone and then asking about what you're allowed to access. Right.

And I would imagine security plays into this for you guys as part of that core issue. But it seems like a lot of times when we do give people permissions and authentication, we don't really look at beyond what is it they're supposed to have access to. So then the, you know, the bad guys come in and start escalating privileges.

So is this kind of at the front end of the whole, let's be smarter about security and zero trust because we've got a good authorization model? Yeah, Absolutely. Yeah.

Now you guys are here at the show, I'm assuming you have a cloud native base? That's correct. That's alright.

So what is your stack look like? Uh, so we're on Amazon, uh, a a KS, so, uh, foundation, uh, so we, I I would say we leverage a lot of Amazon services. Um, and on top of that we use, I mean TO and a bunch of CNCF projects, uh, across the board.

So for us, finding something that was cloud native, Kubernetes native was very important. Um, yeah. Now are you on AWS as well?

We are, we actually have a cloud product to run space to be managed for folks. And in that, uh, in that environment, we support both GCP and AWS with Azure on the land. So when you're looking for solutions, are you looking for things that are run natively on AWS 'cause?

Um, no. I would, I would say this was not a factor per se. We cared about something that could run on Kubernetes at scale, because this was also another concern with, um, I mean, we're onboarding more and more customers and more products, you know, so we wanted to be sure that we could find something that would scale over time.

Um, and then, yeah, so I think the main factor for us was having something that was cloud native and not something we had to configure on, on the side or on a AC two, our bare metal machine, you know, so leveraging Kubernetes as a foundation, You cannot walk down this show without somebody leaping out to tell you about their great new AI thing. True. Yeah.

Ken, we apply AI to authorization and what might that look like? Yeah, I, I think, um, the real kind of question is actually applying authorization to AI and not vice versa, right? Because, um, in the past we had folks collecting all this data up and they didn't, and data warehousing tools, right?

And then we hired people, we called data scientists. And those data scientists were people looking at all this data you had in your data warehouse. And there really aren't any permissions on any of this data once you copy it outta the original source and put it inside your data warehouse.

And the only reason why we didn't have a huge problem at that point in time is 'cause we were only hiring a couple folks, the data scientists to access that data and query that data, and we could just have them be privileged and say, it's okay, as long as it's just the data scientists, they'll be careful or they'll use tools to redact things. But now with ai, we don't have that same advantage of it just being like a couple folks, if you train a model or, uh, have tons of embeddings around your personal private data, now anyone querying that LLM has access to all that data at your business. So we really need to rethink how we're doing the permission system there and have these scalable permissions models so that when you're bringing this data in from an external service, you can also bring in the permissions model and have something flexible enough to understand various permission models, but also scale to the amount of data you're using to actually train, um, and, and power the, uh, vector databases for LLMs.

Mm-hmm. Yeah. I don't know if you're thinking about this, but I'd love to get your input.

At some point I will have AI agents as a consumer. Yep. You'll have AI agents that will do various things on my behalf, and they, we will communicate, but how will you know what my AI agent is authorized to do?

And does that increase exponentially the number of end users you're kind of trying to support if I have? Mm-hmm. I don't know if we all have 10 AI agents each, it gets a little crazy.

Agreed. Um, I think at the moment, um, in our, in our lab, we're exploring different patterns leveraging, uh, SPICE DB where, uh, we have a lot of internal documentation. And the idea is to ingest, um, those documents and tag them on, on SPICE db and then leveraging some, um, tools in the Gen AI space to query, uh, some of this data.

But the idea is to be sure that everything as a, as a user, you are authorized to see something, right? And we wanna be sure that this is, um, this is properly represented. So if you use, um, a user interface or a Slack bot, um, or a backend product flow, I mean the, the same concept should, should, should be there, right?

So we wanna be sure that you have access to specific documents, and we wanna be sure that it's restricted properly and refreshed, uh, quickly if you lose access, for example. So, so that's why we're looking at, uh, spicy pea at the moment for, for this flow, uh, at both ingestion time and at runtime when we query the data. So somebody logs in and they go to access something and they're not authorized, what happens after that beyond the fact that you say, no, do I get a report?

Does somebody like circle back on all of this? What is the, the, the workflow from there? Or do I just ignore it and it's just noise in the system?

Yeah, I, I think this one completely depends on your use case. And this is kind of why we brand ourselves as, uh, infrastructure for authorization. Because folks are gonna build different behaviors for the different use cases they have, um, for the authorization tooling.

They're trying to, to, um, create the, the experience they're trying to create. So for some of our customers, um, a single request being denied means I need to email the CEO tomorrow, right? Like, we need to start ringing alarm bells and something needs to go off.

And those customers are typically consuming, um, one of our enterprise functionality, which is audit logging, um, where we can stream audit logs of all kind of the request and response context to a sim if you're using one of those, um, um, basically to trigger security events. Yep. Um, but uh, then there are tons of other users where 99% of their requests are actually gonna be denied, right?

And only very few are gonna actually be, uh, approved. Um, and in those scenarios, really it's up to the end user to create the experience, oh, sorry, the, um, the end developer to create the experience for their users, the one that they expect based on the domain. One of the things I've also seen is that, um, I don't wanna say we've been sloppy about this, but you know, we're okay with setting things up, give people initial authorization access, um, and then they change the job function, they change the role, or they go away, and yet they're still authorized to access all kinds of stuff because nobody actually, you know, off boarded them from a particular thing.

Can we get better about that? Because I feel like, you know, it's the, the business side says to it, grant this, and then they never call back and say decommission that. Yeah, Absolutely.

I think the real end solution to all that is centralization, right? If there's only one system of record, it's really easy to make sure you've just removed that person from the sys the one single system of record, right? So I think, uh, space DB is actually kind of unique in the idea that, um, we say like, you should centralize all the authorization data into one place, uh, rather than have it be federated and living all over the place across your whole business because you get this type, uh, type of advantage.

Not only can you be sure that when you remove someone, you've removed them everywhere, but the security model itself can be tested and understood when it's all in one place versus scattered across all of your different applications. It means you'd probably have to pay security auditors to go through the custom source code you've written in every single service at your whole business, right? And all that just adds up to be an insane amount of complexity when if you had just put it in a single place, made sure it runs reliably, make sure it scales, then all those problems just go away.

So if you do that, how do you handle in a certain level, if I'm a cyber criminal, I'm like, good, now I know where everything is, it's in one spot. So how do you secure, right. That particular thing.

Right. Um, well I think like our reality is a little different where we have different systems, but we build some automation in place. So when, when someone leaves the company or when someone changes teams, um, we do have automation that would propagate the changes across like the applications you have access to, uh, down to the, the SPICE DB instance.

So we have this kind of sync infrastructure that makes sure that this is replicated within a few seconds, you know? Um, so I guess that's kind of the first foundation of it. Um, yeah, I don't, I don't really know like what else I could add to that.

Do I gotta put, do I gotta put a firewall in front of your database to secure that particular thing? Yeah, I mean we, we do offer, um, basically once again as an enterprise feature, because a lot of the open source folks, they're, they're not necessarily gonna care about kind of like the organization level security. We actually offer the ability for, uh, access control of accessing SPICE db.

So that lets you kind of attenuate API keys talking to SPICE db. So you can say these resource, like these services, they actually only need to be able to read data at a SPICE db. They should never be able to write data to SPICE db, right?

And this service can only write maybe these types of objects into Spice Beef 'cause this service owns those types of objects. So that way there is this central place where all this is located, but there's no kind of like God mode access to that central service to start kind of mucking with that data and doing privilege escalations. All right.

What do you know now that you wish you knew before you met them? Oh God. Uh, I think, well, a typical answer is, I mean, the field changes very quickly and now like with everything AI coming up and kind of merging internal tools with documents and rag applications and all of that space, I think it's, um, it's been a, like a challenge to stay up to date.

Um, but I think like things I would've, I mean, yeah, retrospectively I think we did like look at the landscape, look at different solutions, open the conversation, uh, up with, uh, with different vendors. So I think I would not change that part. Uh, obviously I probably have decided to go with spicy B sooner, but, uh, but yeah, I mean we had to do our homework and, and learn, uh, and then, yeah, I think it's kind of been through this, so as long as we stay up to date on the latest trends, you know, and, and you talked about the CM anomaly detection that, so that's another factor where, you know, you wanna be sure that you have, um, snappy, uh, detection when something is, some patterns are emerging in your systems.

Um, but yeah, I think like overall probably have, yeah, should have gone with Spicy Bee suitor instead of doing like a few months of prototyping and looking at all the trade offs and, you know, Well I think it's great because I think a lot of customers should go out there and, um, consider all the options and do their homework and do their research, because I think they're gonna arrive at a similar answer, which is probably SPICE db. Um, if there's like one takeaway from kind of us building this business, it's that folks shouldn't be building their own authorization. Whether the tool is SPICE DB that they end up choosing, or another one like developers, they, they, they wouldn't dream of building their own database when they're building their applications.

But authorization systems, they've been studied and researched and written about in computer science since the exact same time. Yet every developer thinks they can write custom code for each app implementing custom logic for a thing they don't have no background in, right? Mm-hmm.

And I think this is kind of just like preposterous and the, the more and more people do their homework, they'll realize how preposterous that is and they'll pick solutions up off the shelf. So how do you get them to kind come to that realization? Because I'm sure when you go engage an IT organization for the first time, um, you know, every engineer thinks they can build something better than the vendor.

And usually there's some C-level execs sitting up the top who's the CIO say be that as it may. Yeah. We have other things to do.

Um, how, you know, what level of maturity do you see in customers and how do you kinda get 'em to, to that core realization? Yeah, What what's actually interesting is a lot of these, these users, um, they've already built it themselves maybe three or four times and they've realized the fifth time it's not gonna be any better, right? So they've stumbled and if, if the organization itself hasn't done that, a senior engineer or a senior architect has had that experience, and so you kind of look towards the more senior leadership in the engineering org and say like, do you really wanna try to solve this?

Again, I know you don't have the background for this. And they know they don't have the background for this, and that's often when they just go looking in, in the first place. So I try to advocate at conferences and things just to like have that bubble up back to them and have them remember, oh yeah, the next time we get a product requirement where we're gonna have to totally rewrite this, there's actually a landscape now of tools I can go out and, um, do, do my research on to evaluate to actually solve this problem for the long term.

All right. Hey folks, somebody once said if you go out and bang your head against the wall and expect a different result, you might be insane. I think that applies here.

Hope Gentlemen, thanks for coming by. Thanks so much. And we'll be back in a minute.

This is tech tv.