Yeah, so I'm Jake. I'm one of the three co-founders and the CEO over at AuthZed. It's just kind of like, you know, why you should listen to me, why I have maybe interesting things to say. I'm also the co-creator of SpiceDB, which is our open source implementation of relationship-based access control. So I'm super happy that the last presenter talked about relationships so much, because that's all we do. And I'm also the former co-founder, co-creator of a product called Quay, which was the first private Docker registry.
10 years ago, almost to the day, I was in this exact same spot talking about Quay and all of the amazing things that we were doing for Quay. But if you think about what a private Docker registry is, it's just a public registry with authorization added to it. So I've been doing authorization professionally for a very long time. When we think about, you know, like, what is the goal with a private Docker registry, it's to prevent people from getting access to things that they shouldn't. So all of our feature requests, all of our product roadmap, everything was all authorization.
I didn't think about it that way at the time, but, you know, this is what I've been doing for quite a long time. So I, 10 years ago, standing in this spot, believed that authorization has to be built into the product in order to create a delightful experience. So the best products in the world are sort of defined by their authorization model. And so I was like, if you want to build the best product, you have to take full control over your authorization. You have to do very specific things.
It's very unique to each domain, how you deal with the sharing and the delegation and those relationships that we're talking about. Those are all very unique to each product.
So, you know, these are maybe some things that I thought to myself or I said to myself or some other people, right? Like, oh, our domain is special.
So, you know, we have to build it ourself. That was wrong.
You know, it can't be clearly expressed in a delegated way. It's too nuanced. It's too fine grained, right? It has to just be 50,000 if statements that I sprinkle all through my product that say things like, oh, if user is admin, allow this. If user is reader, allow this, right? So these were things that I believed. And then the last thing was that you just can't separate it out from your business logic. So it was like, you know, again, to build a delightful product, which is, I hope, what everybody aspires to do.
Nobody wants to push something over the wall and have their users hate them for it. So to build a delightful product, we had to actually go and write this code by hand and build it into a product. So these are all things that I believed and I think what a lot of people believed for a very long time.
And today, I want to challenge that notion. So first, I want to walk through just a few examples of products that are defined by their authorization. I'm calling these the greatest hits of authorization. Originally, this was a 10-minute talk. It may still end up being a 10-minute talk. So there aren't very many greatest hits on my album here. I could go on and on about products that are defined by their authorization, but here's a couple. So the first one is a safe deposit box. I think everybody can probably understand how a safe deposit box works. You show up at the bank.
Before you get there, somebody opened the vault, which has all of the safe deposit boxes in it. You have a key, and then the manager of the bank also has a key, and you both have to turn your keys in order to open the box. What is a safe deposit box without authorization? It's a spot on a counter. It's nothing. This defines the product of a safe deposit box. What you're buying is the security that's provided by this authorization model. This is an interesting one because it's done in multiple layers. When you peel back the onion, there's authorization for who's allowed to open the vault.
There's authorization for who's allowed to hold a key. There's authorization around who's allowed to identify themselves, to get access to the vault, to hold the key, to turn the key. There's a huge amount of trust that's built into all of these mechanisms about how we get access to a safe deposit box. The presenter before me talked a lot about relationships.
These are, in fact, all relationships. The next one I want to talk about is Google Docs. I feel like Google Docs really defined the way I think about the ideal authorization experience, and I think it's changed the way a lot of us think about how good authorization looks. Before Google Docs came around, we were sharing things in a business context by emailing them to each other and calling them version 1, 1.2, 1.3, final, don't edit, final, final, final 2. It was horrible.
Google Docs came and said, why don't we just share the actual artifact directly with the people who need to consume it, and we'll give them access in a way that defines that relationship about how they should be interfacing with this artifact, with this asset. There's things like someone can be a viewer only. Someone can be a commenter. Someone can be an editor. Someone can be an owner of a Google Doc, which gives them rights to delegate authorization.
This defined the way I think delightful authorization should look and should feel, and I think since Google Docs has come out, I've heard a lot of people tell me, because I work in the authorization domain, they're saying that people are demanding this style of authorization for the rest of the corporate world. This has become the new paradigm. People want to just be able to share things with each other. They don't want to have to get added to an active directory group and have that interpreted by some code somewhere to give them access to things.
That's a very difficult way to reason about these things, but if I can just open it up and type in my coworker's name and click share, that's a wonderful experience. And I think it really defined the way we think about work, and you've seen this get adopted by things that didn't have this model since then, right? Like SharePoint and things like that have adopted this easy sharing model and made it easy to sort of delegate off and to give access to things. One thing that I find really cool about Google Docs is it seems conceptually very easy, right?
It's just like, oh, it kind of defined this modern share dialogue and you open it up and you click share, but when you really start to dig into it, which one of my co-founders and I did on a video, we just opened up Google Docs and we're like, we're going to figure this thing out, right? What are all the nuances here? And it has a lot of flexibility and a lot of power, right? You can delegate things to teams, you can put things in folders, you can put folders in other folders, you can actually have deny lists, right?
You can say this person should otherwise have access to this, but they specifically don't. You can delegate things, you can give access to service accounts, you can go into your Google admin and create a service account, and you can share a Google Doc with a service account, which I think is going to be a really important paradigm moving into the new agentic world. So this kind of really defined for me what good authorization looks like.
The last one I want to talk about is GitHub, because it's a really interesting mix of that sort of Google Doc style sharing, but then there's also a lot of really fine-grained things you can do in GitHub. I think probably everybody in the room is really familiar with GitHub and how it works, but the authorization model looks like the tip of the iceberg for the authorization model for GitHub is that, like, oh, there's repositories and I can share them with people. I'm super familiar with the permissions model for GitHub because we literally copied it in Quay.
We were like, all right, how will people want to share repositories of Docker images? Well, they already share repositories of source code probably the same way. So we just went and we created, like, reader-writer admin in Quay and we said, that's it, right? But when you actually start to, like, look a little bit below the surface, there is a ton of complexity in the GitHub permission model.
So you can do things like branch protection, you can do things like share at the organizational level, or you can share at a specific repository level, or you can organize people into teams and teams of teams. It's got all of the same complexity of, like, Google Docs, but it's packaged up in a way that it looks very simple at the surface.
So, yeah, I think everybody here probably can understand these three models, right? Can these three models resonate with people in the room?
So, yeah, those are my greatest hits. I could go on and on. There's a lot of products that sort of fit the bill. But at the end of the day, I find these products interesting because they can all be very cleanly expressed in relationships, right? So we've talked a lot about relationships in the talk before mine. But when we express things as relationships, we're defining those delegations and those relationships. I like to say it's between people and people or people and data, data and other data. Now I have to say the word agent a lot.
It's between agents and people, agents and agents, agents and data, right? So all of these things can be expressed as relationships. The way we conceptualize relationships at AuthZ and in our open source SpaceDB is as a directed graph. So in the computer science sense, right, you've got a relationship. You've got one thing that points to something else, and it says, all right, Jake is a reader. That is a relationship, right? So all of these things can be expressed as relationships. The safe deposit box example is pretty interesting because it actually requires two relationships to exist.
So there's an intersection there, right? I have to have both keys. I have to have the manager key and the individual key. The Google Docs one, very clear, easy to understand as relationships. So the user can be an editor of a doc. The folder is a parent of a doc. A folder can be a parent of another folder. And then on GitHub, you have like a team can own a repo, an organization can own a repo, a repo can be nested under an organization, and then, you know, you have users can be members of teams.
So we call this idea of using relationships to do authorization, we call it Reback, relationship-based access control. You've probably heard all the other backs, right?
Pback, ABack, RBack. I am particularly excited about Reback because it is a superset of a lot of those other things.
So, like, anything that you can do with Reback or RBack can be pretty cleanly expressed in Reback. ABack is a little bit trickier, and we've had to go and make some extensions to the concepts of Reback to make attribute-based things possible and, like, policy-based things possible. And we have some policy-based authorization experts in the audience here today. All right. So this is just our DSL for how we define relationships and, you know, what relationships can possibly exist.
So in our DSL, we, you know, this is just what Google Docs, like, at the, you know, the tip of the iceberg layer looks like expressed in our language. So at the top, we actually have to define that there's a user. A lot of systems assume a lot of things about users. We assume nothing. So we're an infrastructure product. We make no assumptions, basically, about anything, right? So we define that there's a user. You could totally imagine an agent would be another thing up here. Then we have a folder, and then we say, like, who is allowed to do things to folders, right?
What relationship can we have with the folder? And then similarly, what relationships can individuals have with documents? And then based on those relationships, how do we make access control decisions? And this is, in my opinion, a very natural and very clean and very concise way to reason about and to express these permissions models versus some things that I've used in the past.
You know, an earlier version of this deck had AWS IAM as kind of a counter example. You basically have to have a PhD to be able to reason about AWS IAM. There's a full simulator that's like a product line at AWS to be able to understand their IAM products. So I find this much easier to digest and much easier to reason about.
So yeah, given this basic structure, we can go and we can build up a graph. A really interesting thing about this example in particular is you can see that a parent for a document can be a folder, but then a folder can also have a parent that is another folder. And so in that way, we can very cleanly express these recursive relationships where I can get access to a document by being, you know, an editor on any level of the hierarchy, and that sort of self-referential chain is just very easy and very natural to express.
So I just think of the whole world in relationships, and that's how we do authorization. So, you know, a lot of time, a lot of people think, like, again, when we started, my model is special, my model is different, my model is unique. Your model likely isn't as unique as you think, and it's probably quite easily expressed using Reback. I just have, you know, the big logo soup there just to show the variety of different companies that are using our solution to express their permissions model using Reback.
And, you know, there's banks, there's AI companies that, you know, it's all across the board, people are able to do this and able to kind of get out of the business of maintaining all of this really, really terrible logic and really terrible authorization code. So, you know, you can do it too.
And so, like, we've been able to distill all of these sort of old authorization models into this concept of relationships, but it's also really well-suited and really well set up for, like, the next 10 years of apps, which I think we can all acknowledge are probably going to be AI until there's the next AI winter or whatever coming along. So, you know, it also works really well for non-human users as well, right? So we have to extend this concept where we're establishing relationships and where we're defining these models.
And, like, there are potentially things where we would never want an agent to be allowed to do, right? Like, I don't know, I don't want an agent to be able to delegate my power of attorney, right? So we could just, like, totally elide that from the permissions model. But we've got, like, all new things that we're talking about here, but they all boil down to basically the same concepts. I'm a big believer in the fact that we really want deterministic authorization in these apps, though.
Like, I don't think we want AI in the loop of making authorization decisions. So, you know, when people ask, like, Jake, what's your big vision? Where do you see this all going?
I'm like, I think what we want is we want deterministic authorization in the loop for all of these interactions. And then I think that that will actually help us do more with AI. If we feel good and we feel that the authorization is solid and we can rely on it, then we'll actually be able to delegate more to AI and let AI do more. So I think, like, a strong authorization framework is kind of one of the keys.
But yeah, I guess the other thing that's different in this world of AI, I tend to think of AI, like, agents as kind of just, like, little humans. Anytime you would reach for a human might be a good use case for AI. Anytime you would not reach for a human would be, like, not a good use case for AI. So I've heard a lot of people be like, oh, well, we're going to put AI in the loop. And I'm like, well, we have, like, badge scanners at the front door for a reason. They're not, like, checking our credentials against, like, a list.
We've managed to make these things deterministic and very fast and very easy to reason about. So in the new world, we're going to have principles that aren't just humans. What does that mean? One of our customers is actually ChatGPT. They're using us for enterprise authorization. Sorry. Enterprise ChatGPT connectors, which is where OpenAI connects, makes a trust relationship with your organization and gives access to their models, to the data that you have in things like Google Drive and, you know, the like, SharePoint, Salesforce, right? For OpenAI, right, there's this new scale challenge.
They've got an incredible number of users, an incredible amount of information that they're managing. Using our system, they're currently gating access to 37 billion documents. And what they're doing is it's similar to that trust chain, right?
Like, when the model is acting on behalf of somebody, is the person that it's acting on behalf of allowed to access the data that they brought over, right? So they're respecting those upstream permissions models. And all of the permissions models from all of those things they're connecting to are expressed cleanly using Reback, and they're able to gate access to that data based on that. One of the really popular examples is, like, you know, who should have access to the Q4 quarterlies or, like, the spreadsheet that has everybody's salaries.
Like, when you bring that over, you don't want to just make it accessible to the world. You want it accessible to only the people who should have been able to access it in the upstream system. So they're doing that with us. Pretty excited about that. And then the last thing that I want to sort of leave with is this concept of sharing in Google Docs, I think is a really, really incredibly powerful primitive for working with agents and working with AI in general. How many of you have tried Open Claw? Anybody? Yeah. A few hands. We're all brave. I tried it, too. I wrote about my experience.
But Open Claw seems to start from this idea that you're just going to give it the keys to the kingdom and then kind of cross your fingers and hope that everything works out. That's terrifying.
So what I, you know, the way I want to work with it and the way I did my experiment was starting from zero and building our way up to the amount of access that it needs to do its job. And I like that idea. I like that primitive. And I think that that's something that we should really lean pretty heavily on.
So, you know, we're all familiar with how to share things with fellow humans. But in the future, if we want to share things, like if we want to delegate some task off to an agent, we can give it just the access that it needs to do that very specific task, to do its mandate, so to speak. And so I like that. And I think it's very scalable and it's very easy to reason about. And we can start, it can even come up in like agent-to-agent scenarios, right?
Like if an agent has to spin up a sub-agent and it needs to give it access to some memory that it's created or some session context, it can just share that context with the sub-agent that it just spawned for a very short amount of time and say, okay, you have this access to this very specific thing, right? Like in the concert booking example from earlier, it could say, like, I'm booking a hotel and it has to coincide with the flight. Here's some information about what the flight booking agent generated, some artifacts that it's generated.
I'm sharing it with you, hotel booking agent, because it will help you get your job done better. So I really like that paradigm of just everything is sharing all the time. And we should start from zero and we should build our way up to just the minimal amount of data and just the minimal amount of access that these agents should have.
And, you know, it is a little self-serving because our infrastructure is super well positioned to be able to support these kind of use cases. Yeah. So that's it. That's all I had.
So, you know, stop building your own custom authorization. I had to say something spicy, right? It's not super well solved. The people in the standards bodies are doing amazing work, the kind of work that I just, you know, it's not my cup of tea. I like to build things with, like, nice defined boundaries and control my own destiny and things.
But, you know, I encourage you to go out and try SpiceDB. It's fully open source, Apache 2, very liberal license. We're not going to, like, try to come after you or, you know, anything like that. We also have AuthZ dedicated, which is, like, the single tenant way to run these things. So we run everything, but it's all isolated to you.
It's all, you know, very, very isolated. And, yeah, you can reach me on LinkedIn. I don't tweet that much.
So, you know, I do have a Twitter, but I think I put, like, one tweet about a burrito one time on there or something. So LinkedIn would be the way to get ahold of me.
And, yeah, we have a booth just up from here. So come say hi if any of this sounds interesting. That's a nice advice. Thank you very much, Jake. Just on time.
