S13 E10: Decoupling Authorization: Scalable Policy-as-Code for Enterprise Apps with Alex Olivier, Co-Founder & CPTO of Cerbos の全文書き起こし

01:58.987 [SPEAKER_02]: In fact, his dad awarded him an old Linux box, from which he built a Harry Potter website. 01:59.487 --> 02:08.672 [SPEAKER_02]: Five years after he deployed said website, his site was getting 3 million visitors a month, and gained him success and access to red carpet events and interviews with the cast. 02:09.592 --> 02:14.578 [SPEAKER_02]: Instead of computer science, and eventually went to work for Microsoft before getting into the start-up world. 02:15.218 --> 02:22.026 [SPEAKER_02]: But outside of tech, he's a dad to a two-year-old daughter, so he doesn't have much free time, but when he does, he enjoys cycling and skiing. 02:24.355 --> 02:30.460 [SPEAKER_02]: In several prior companies, Alex built and built and rebuilt solutions around applications, permissions. 02:31.140 --> 02:35.884 [SPEAKER_02]: Each time he did so, he found himself annoyed that he had to create this type of solution again. 02:36.665 --> 02:41.929 [SPEAKER_02]: He and his co-founders decided to set out and create a company around an authorization management platform. 02:44.531 --> 02:46.853 [SPEAKER_02]: This is the creation story of Serbos. 02:51.918 --> 03:02.587 [SPEAKER_00]: At heart, I'm a software developer, and three various roles I've been building software various infrastructure skills, and I've worked through a number of different companies, and I found myself having to solve this one particular problem over and over again. 03:03.128 --> 03:12.876 [SPEAKER_00]: And that problem was how we built our platform up to serve enterprise customers that had different roles and groups and permissions that needed different access models to our platform at the time. 03:13.496 --> 03:30.283 [SPEAKER_00]: The first place I'd have to do this was when I was at Comptable Cupid in the UK, they did e-commerce analytics, personalization, that kind of thing and we had customers ranging from Emirates Airlines and Staples in the US and companies down in Australia and they all have obviously different organizational structures in different ways they needed to 03:30.823 --> 03:43.486 [SPEAKER_00]: provision access to our system at the time to round out the solution across the organization because you don't want someone in the U.S. accessing data or artifacts or campaigns about someone in Europe if they can pick different cost sentence. 03:43.886 --> 03:58.129 [SPEAKER_00]: But then another business might align themselves around departments rather than location in it that that matrix gets hard and end up having to solve that problem a couple of times and I went on to another company after that in the supply chain space and ended up solving that problem again and did it three 04:01.391 --> 04:06.234 [SPEAKER_00]: And it always bugged me, like every time we did it, I got annoyed about how long we spent trying to solve this problem. 04:06.695 --> 04:12.079 [SPEAKER_00]: And there wasn't really anything off the shelf designed for that application permissions type management. 04:12.119 --> 04:23.247 [SPEAKER_00]: There was always kind of low level infrastructure type things, because it was very to the policy engines that kind of things like utilities and search, but there really wasn't a product level sort of SaaS permissions and type product at the time. 04:24.027 --> 04:50.247 [SPEAKER_00]: So, ended up banging on this problem a bit more and ended up joining it together with my other two co-founders, one who was the CTO of that first company keep it I worked at, and the other one who was one of my techniques, and so the three of us have worked together for over 10 years at this point, and we finally decided, this is a big enough problem, because we've had to not only solve ourselves, but we're up here in the industry, and now network, we've saw this becoming ultimately a blocker to enterprise adoption of any product you're building, and we've got a lot to do with it, and we've got a lot to do with it, and we've got a lot to do with it, and we've got a lot to do with it, and we've got a lot to do with it, and we've got a lot to do with it, and we've got a lot to do with it, and we've got a lot to do with it, and we've got a lot to do with it, 04:50.467 --> 05:13.093 [SPEAKER_00]: And this was the COVID-2020 times we managed to get a race and funding off the back of it and build out the first kind of prototype and kick a few ideas around and actually released our first capability of our product as an open source project which the core of service today is a service policy decision point is a patch 2 license project that you can grab off GitHub we know there are thousands of deployments out there in a given weeks company's using server today and 05:13.713 --> 05:29.088 [SPEAKER_00]: Really, it's allowing you to roll out capabilities you'd need inside a product to give a way of managing, versioning, auditing, testing, and then also meeting your regulatory requirements around policy and access control inside of an S Suite over your applications and the Croucher Architecture. 05:29.268 --> 05:32.591 [SPEAKER_00]: It's also new, it's like solving a pain we had from previous lives, and turning into a company. 05:34.857 --> 05:39.384 [SPEAKER_02]: Let's dive into the MVP for Cervos, so that first version of the product you built. 05:39.744 --> 05:45.853 [SPEAKER_02]: I don't know how many times you had built it before and then it turned into a product, but I'm curious about that first time you built it as a product. 05:46.213 --> 05:48.637 [SPEAKER_02]: I want to take the build and what sort of tools we're using to bring it to life. 05:51.057 --> 06:03.520 [SPEAKER_00]: The very first kind of early ideas of this, when we looked at how we wanted to build up the company, we always knew that really the biggest blocker and the biggest hurdle we had to pass in order to get adopted was going to be out of the technical rigour. 06:03.940 --> 06:06.421 [SPEAKER_00]: This is something that's going to be deeply wired into

your co-base. 06:06.461 --> 06:20.444 [SPEAKER_00]: So being every part of the application that is ever checking with a similar do-sum action, needs to interact with this system because we ultimately externalise all the logic around who can do what's on the what context and when and why to an external service that's running alongside your system alongside 06:21.424 --> 06:38.499 [SPEAKER_00]: So we had to be solid from a performance, from an integration perspective, from an observability perspective, and we need to ultimately make developers and architects happy before we could even dream of going and talking to the business side or the security side or the CSO side of the house. 06:39.199 --> 06:48.427 [SPEAKER_00]: So the way we did it was started with that open source core, and as I mentioned there are other policy engines out there, the most famous being open policy agent, if anyone has been digging around. 06:49.007 --> 06:53.952 [SPEAKER_00]: The CNCF speaker system and the community user as well, and we looked around that's the right idea. 06:54.492 --> 07:01.238 [SPEAKER_00]: You have this external thing where you just throw a request at saying, can this user or can this identity do this action on this particular resource with this context? 07:01.818 --> 07:06.980 [SPEAKER_00]: It then evaluates and then what comes back is the decision and allow our denying news. 07:07.561 --> 07:15.864 [SPEAKER_00]: The tools at the time out there, they have policy frameworks and languages, they have policy agencies and language called Lake Rigo, which is they have not derived. 07:16.425 --> 07:23.708 [SPEAKER_00]: I mean, it says, right model, but this is way too complicated if we ever wanted to get this into the hands of like product or security or business out of things. 07:24.388 --> 07:30.734 [SPEAKER_00]: So actually the first dozen or so releases of the server's open source project, we actually used to use OPN beneath what we put on top of it. 07:31.194 --> 07:38.461 [SPEAKER_00]: Well, we at the time, we're convinced that there's going to be our differentiator, which is a much simpler manifest, driven way of defining policy. 07:39.021 --> 07:46.728 [SPEAKER_00]: So we actually did a load of internal translations to take what is now the server's policy format, which is just YAML and cell common expression language to define your conditions. 07:47.429 --> 07:51.833 [SPEAKER_00]: I don't want to need to convert that down to underlying policy that was executed by your beer engine. 07:52.274 --> 08:01.644 [SPEAKER_00]: And that allowed us to very iterate very quickly around what are the fundamentals that you need in this policy definition format to meet those business requirements or numerical questions. 08:02.384 --> 08:30.653 [SPEAKER_00]: So we landed on this idea of like resource policies because it also makes every source as the thing that someone is trying to interact with You need to find positions around it and then basically layering on top of it a few other concepts to make it easier to build repeatable It's a logic and repeatable conditions that may be applied to do a different context and that got us to something that was Reciable testable version on any open source project thankfully took off pretty quickly and we got some large enterprises adopting it within the first six to 12 months of running the company 08:33.155 --> 08:37.240 [SPEAKER_02]: So you've got that MVP, you've got the traction, the open source version's growing. 08:37.420 --> 08:39.923 [SPEAKER_02]: How did you progress and mature it from that point? 08:39.963 --> 08:42.326 [SPEAKER_02]: I'm curious about breaking that into a roadmap. 08:42.366 --> 08:44.328 [SPEAKER_02]: How do you put together your robot? 08:44.388 --> 08:45.470 [SPEAKER_02]: How do you go about deciding that? 08:45.530 --> 08:49.114 [SPEAKER_02]: Okay, this is the next most important thing to build or to address with service. 08:50.489 --> 09:00.262 [SPEAKER_00]: Yeah, thankfully, if you don't know what's out there building dev tools, developers particularly have very strong opinions, and they, they, a lot of the time are happy to tell you them in various different contexts. 09:00.803 --> 09:03.486 [SPEAKER_00]: So we, from the early days, we had things like their community slack channel. 09:03.907 --> 09:04.908 [SPEAKER_00]: We got a lot of early... 09:05.629 --> 09:07.670 [SPEAKER_00]: feedback of this works by here the Nali bits. 09:07.750 --> 09:17.577 [SPEAKER_00]: Here the things that if I want to take this an operationalize it inside of a company I have to go and build or how to go and not take or how to go and plug in these six other systems to get it to actually work it at at the scale of it. 09:17.677 --> 09:21.099 [SPEAKER_00]: So me, because at the end of the product side of things, that was a gold mine. 09:21.499 --> 09:39.492 [SPEAKER_00]: because we saw real world deployments in the C250, what you have 100 types of type companies running our core engine, but they'd have the bill rules extra infrastructure around it, and MOOCs are then pattern matching, it's like, okay, there's a problem around here, around how do you distribute policies if you've got hundreds of thousands of these things running across your arctic? 09:40.413 --> 09:45.458 [SPEAKER_00]: Well, how do you then get back a single pane of glass or will the order until the decisions from a person? 09:45.498 --> 09:55.388 [SPEAKER_00]: How do you make sure that when a policy changes out, you don't have to set up your whole custom CI pipeline that does a whole barrier tests that may or may not be related to the policy itself. 09:55.468 --> 09:57.550 [SPEAKER_00]: Okay, there's an interesting thing about CICD in here. 09:58.250 --> 10:21.989 [SPEAKER_00]: And really, the roadmap came out of those early, it's a feedback we have in the users of the extra work, the extra things they had to go and build to actually use our core engine across their system, which is why we

ended up producing our first commercial product, which we could have settled up, which is ultimately a control plane, it's an administration layer for all these different decision engines that are running across your stack. 10:22.549 --> 10:25.851 [SPEAKER_00]: And really, I think that that is the benefit of us. 10:26.852 --> 10:37.157 [SPEAKER_00]: Or anyone really starting with an open-court over-sourced project, an open-court model, essentially, because you get that adoption early, from people that are willing to put in the effort and the time to build up the other bits of the stack. 10:37.617 --> 10:39.598 [SPEAKER_00]: And that really starts building up a Regal Room map. 10:39.658 --> 10:51.445 [SPEAKER_00]: So, we had about two years of just the core engine out there, just gathering feedback, hearing what the real world deployment story is where, and then we started building up and tropelling, and then that became our first actual paid product. 10:51.905 --> 11:01.898 [SPEAKER_00]: ultimately and built the business around that and we've just kept repeating that motion and tackling the next problem that we are searing that we hear the most from all uses that with up to the product in its current state. 11:04.000 --> 11:10.809 [SPEAKER_02]: Okay here I hear you saying we tell me about how you built your team and what you look for in those people to indicate that they're the winning horses to join you. 11:12.684 --> 11:39.298 [SPEAKER_00]: We are a COVID-era company, we are a video remote, registered in the UK as a U.K. business, but we decided early on we're not going to have an office and that overhead that expense out the time ever was working from home anyway, and so we hide globally so that opens up obviously the group and we also took the view of because we're about we're not going to be all there to like hand hold people and all people as much and easily as if we're all sitting enough us together. 11:40.078 --> 11:59.405 [SPEAKER_00]: So, we made a decision early on that we were only going to go and hire predominantly senior roles and we were very heavy on the development side of things, so that we didn't hire any marketing or whatever or anything else set up with those sales until much later on we really focused on their developer, engineer and designer. 11:59.725 --> 12:03.247 [SPEAKER_00]: In the early days, and we also made a decision to make sure that 12:03.967 --> 12:23.384 [SPEAKER_00]: kind of intentionally, where we can, that they are very distributed, because that will then force the documentation, the coordination and the asynchronous of the company, one of the first highs we made, bulk loss that we're here in the in-Europe, was actually one of engineers who was in New Zealand at the time, we can't get more drastic a time difference, so that really fostered. 12:24.145 --> 12:36.816 [SPEAKER_00]: The way we built and scaled up the company, in terms of the culture of how we document things, how we share things, how we do a sync

work, how we report back, we are extremely meeting lights, we don't have a daily stand-up because the time's over to now it. 12:37.317 --> 12:41.721 [SPEAKER_00]: So we build that as the culture and ask influence to how we hire as well and find people that fit that. 12:42.361 --> 12:52.690 [SPEAKER_00]: Okay, that model and a lot of it came from our networks, people we work previously, but we will say, broaden some of the great team members who just saw the project and reached out and wanted to get involved more. 12:53.070 --> 12:53.471 [SPEAKER_00]: So is it? 12:54.171 --> 13:03.379 [SPEAKER_00]: Make sure of deliberate culture setting and then hiring based upon the skills that we needed and the people that was fit the culture that we were built the company around. 13:07.279 --> 13:09.240 [SPEAKER_02]: Let's move into scale, right? 13:09.260 --> 13:13.263 [SPEAKER_02]: I'm curious about how you approached scale from the beginning. 13:13.343 --> 13:18.527 [SPEAKER_02]: I thought about scale even when you're building MVP and moving into progressing and maturing it. 13:18.807 --> 13:25.352 [SPEAKER_02]: But I think what's interesting is has there been to have there been any interesting areas where you've had to fight scale as you've grown? 13:26.803 --> 13:29.324 [SPEAKER_00]: Scales, there's many ways to kind of look at it. 13:29.504 --> 13:37.127 [SPEAKER_00]: And if you look at it purely from the technology perspective, so my background and my co-founders background are quite a lot of engineers that work with us now. 13:37.647 --> 13:53.853 [SPEAKER_00]: We've all come from companies or backgrounds where we've had to face the scale challenge head-on because we're building systems that were in the critical path of every request of, say like an analytics product or a supply chain system or a basic data processing pipeline. 13:56.074 --> 14:05.657 [SPEAKER_00]: All right, for whose companies we're doing about 60 billion requests a day through our system, so I personally made every mistake possible when it comes to scale and adventure consistency and edge compute and all those sort of things. 14:06.437 --> 14:20.402 [SPEAKER_00]: And unlike something like authentication, which you just do once, and then you get a token that's valid for say 30 minutes, authorization, which is where we really play, where it's being done on every single request, many times within the scope of a single request in most cases. 14:21.222 --> 14:28.467 [SPEAKER_00]: and needs to hold up and needs to hit the middle second of my daily sub-millisecond kind of time frame of evaluation or else this is because did in the water concept. 14:28.587 --> 14:34.411 [SPEAKER_00]: So we had a lot of that background, we had a lot of that learnings that we built even into the MVP release. 14:34.551 --> 14:37.873 [SPEAKER_00]: The engine was fast, it had to be, that was just a non-negotiable, but also... 14:39.314 --> 14:45.561 [SPEAKER_00]: one of the challenges of scale really is actually

understanding when your system isn't actually performing properly so understanding where the trope points are. 14:45.821 --> 14:49.525 [SPEAKER_00]: So we invested very early on into soft rock solid telemetry. 14:49.785 --> 14:57.733 [SPEAKER_00]: So open telemetry tracing, community metrics, all that kind of a cloud native observability stack or whatever it's been branded as these days. 14:58.154 --> 14:59.175 [SPEAKER_00]: That was baiting from day one. 14:59.695 --> 15:07.478 [SPEAKER_00]: So, not only can we say we're a bit of a scale, we could also fall back and like we've done this previously, and we're not hiding how this isn't before me. 15:07.498 --> 15:15.622 [SPEAKER_00]: We publish all the observability metrics, because ultimately, this is running inside of your environment, in your infrastructure, in your VPC, in your air gap data center, like some of our customers. 15:16.242 --> 15:17.883 [SPEAKER_00]: So we need to be rock solid in terms of, 15:18.603 --> 15:45.308 [SPEAKER_00]: scale from technology perspective to make sure that the system is behaving and you also know what it needs to make some attention and then as we scout the business to go alongside the technology we've been very focused on making sure we're hiring and scaling out the company sensibly because we are still all venture back to kind of business and there is always that runway that everyone needs to think about until some point so we've been very careful to 15:46.728 --> 15:52.474 [SPEAKER_00]: how and when and where in higher we've had some routine we've had some misflies in terms of our hiring. 15:53.454 --> 15:54.355 [SPEAKER_00]: What roles were hiring? 15:54.836 --> 16:04.044 [SPEAKER_00]: Originally for example we were going off developers so we actually built out like a different functionality and that made sense the time that those kind of teams involved as our customers and our professors have evolved. 16:05.285 --> 16:28.263 [SPEAKER_00]: Scaling, I think, is different at different parts of our journey through building our own company, and it's affected in our build of technology, how we build our processes, how we build our teams, how we go to market, and being very deliberate and conscious, because, like the technology perspective, I've made a lot of news and stakes, and not to do it previously, so I had that pull-up on and draw-up on, and then in this new AI era scale, there's another different ballgame I think. 16:29.344 --> 16:37.431 [SPEAKER_00]: Many of us are still trying to wrap our heads round, but this means in terms of how you scale the business when we have models that can do all sorts of crazy stuff from on our behalf. 16:38.913 --> 16:43.157 [SPEAKER_02]: Okay, so as you step on the balcony, you look across all that you've built with service. 16:43.357 --> 16:44.278 [SPEAKER_02]: What do you most proud of? 16:45.905 --> 17:05.811 [SPEAKER_00]: I think, even to this day, I'm most proud of the fact we've managed build this very involved, very vocal core user base that show up, they create issues, they raise threads get up, are nice like community and what they guys buy now, where we find like someone else has written a blog or someone has written some a reddit thread about. 17:06.191 --> 17:24.632 [SPEAKER_00]: how they solve some big security floor or some security model challenge they're having by using servos and the fact that even if we maybe didn't build a whole commercial thing the core engine is out there and it's being used and people will talk about it is something I'll to be proud of ultimately and I am to end the rest of our team are as well as I'll be seeing it and 17:25.392 --> 17:26.713 [SPEAKER_00]: I think, well, there's early decisions. 17:26.933 --> 17:27.633 [SPEAKER_00]: It was a gamble. 17:27.653 --> 17:28.854 [SPEAKER_00]: There was a risk. 17:28.894 --> 17:33.195 [SPEAKER_00]: We had some inclination how things might go, but it still was a gamble, and it still was a risk. 17:33.315 --> 17:48.902 [SPEAKER_00]: And a lot of those decisions have paid off, and having that group of users that are using us, our systems day in day out, and it gives you that feedback is the most valuable thing I can have as someone on the product side of things, but also just having, also being network or people evangelizing about. 17:49.222 --> 18:03.635 [SPEAKER_00]: I'm not very serious, but this idea of how to do permissions properly and how to do permissions at scale and how to do security in a way that ticks all the boxes when it comes to making sure you cover your bases from compliance and regulatory needs, and that kind of foundation is what. 18:04.416 --> 18:12.379 [SPEAKER_00]: this whole rethink of, let's say, the architectures and the patterns and the screen models that need to be in place to probably do agents across an ecosystem. 18:13.119 --> 18:22.283 [SPEAKER_00]: Require it, that is what kind of, so it drives me every day when I'm talking to users or getting issues of feedback and using that to drive kind of the roadmap and keep building companies up a bit. 18:23.903 --> 18:25.004 [SPEAKER_02]: Let's flip the script a little bit. 18:25.044 --> 18:28.845 [SPEAKER_02]: Tell me about a mistake you made and how you and your team responded to it. 18:30.553 --> 18:35.759 [SPEAKER_00]: I think one of the felt values and the bit of the culture points that we set very on with how we're kind of really companies. 18:36.520 --> 18:42.987 [SPEAKER_00]: We will try things, we will test things, we will not precious about code because it doesn't work or throw away and we will try something else. 18:43.628 --> 18:51.717 [SPEAKER_00]: And quite early on we were looking at how do we go and support and how do we go and build out different ways of using our system in each grain to 18:52.337 --> 19:02.184 [SPEAKER_00]: There's many different ways or places or architectural points where you want to do authorization properly and one of it Internal kind of debates we had is do we focus on

one point towards you stack do we go broad? 19:02.244 --> 19:07.148 [SPEAKER_00]: Do we go and contract out load of cancels and demos and extensions and things on top of it? 19:08.569 --> 19:23.461 [SPEAKER_00]: And we definitely made some mistakes around it, and we probably went too broad to quickly with some of the integrations in SDKs and such, where we, you know, what we can see now from our data is as really, probably one or two major architecture and tech stacks of it into so we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we 19:23.621 --> 19:38.098 [SPEAKER_00]: Also, we break wasted a lot of time, building out demos and extensions and plugins and SDKs and things, for our things that never been looked at again, and it's one of those scenarios where we even inside the team, there's a bit of a disagreement and commit, type mentality, and that was definitely one of those where we probably 19:38.979 --> 19:40.440 [SPEAKER_00]: Shouldn't have done it, but we did. 19:40.580 --> 19:41.220 [SPEAKER_00]: We learned something. 19:41.860 --> 19:49.064 [SPEAKER_00]: We ended up throwing away a lot of work and just keep iterating and keep building that way, which, getting much easier these days. 19:49.124 --> 20:02.529 [SPEAKER_00]: And I think the main way as a team, we think about it is like, anyone in the company can call an idea, anyone can go and test an idea, anyone going to build a prototype or demo or put together a go-to-market documentation plan or anything like that. 20:03.090 --> 20:06.071 [SPEAKER_00]: Yes, we have titles, but it doesn't define really 20:08.773 --> 20:17.784 [SPEAKER_00]: And it's the times where we've tried to be maybe more narrow and in our lanes where we've been worst as a business is best when we all are really actually collaborating in. 20:18.144 --> 20:27.135 [SPEAKER_00]: So we'd lean into that much more and that's definitely brought some of our best ideas and press capabilities in terms of how the products evolved and we need to lean into that more. 20:30.197 --> 20:31.558 [SPEAKER_02]: Okay, Alex, let's move forward. 20:31.618 --> 20:32.359 [SPEAKER_02]: This will be fun. 20:32.399 --> 20:34.421 [SPEAKER_02]: What does the future look like for Cerbrose? 20:34.481 --> 20:43.310 [SPEAKER_02]: Given where the industry is going or the change in AI and taking over the world and all those things, what does the future look like or the company to product in the team? 20:44.878 --> 20:50.906 [SPEAKER_00]: I look at this not just really surplus, but if I look at the industry as a whole, but industry at what's happening on the security side of things. 20:51.767 --> 20:53.590 [SPEAKER_00]: There's more code being generated never before. 20:54.331 --> 21:02.582 [SPEAKER_00]: More systems and more prototypes and more PCs and more things going to be an option with more users and more autonomous users and the genetic users and agents being out there and trying to access signal systems. 21:03.503 --> 21:07.206 [SPEAKER_00]: At some point, these things need to be controlled, and these things need identities. 21:07.567 --> 21:22.021 [SPEAKER_00]: So what's really been happening over the last year, 80 months now maybe, is we, collectively, as kind of security industry, or at least a software kind of industry, are starting to get bitten by maybe some of our past decisions. 21:22.662 --> 21:31.351 [SPEAKER_00]: and I think the best kind of example of this is if you have that say a number of systems in your business there's one that does like accounting, there's one that does HR, there's one that's finance, etc. 21:32.031 --> 21:43.523 [SPEAKER_00]: and if you have maybe some an intern coming aboard and you get in some tasks to do and it's to go and filter through some data in the CRM and pull out some bunch of beauty and go and pull some data into a spreadsheet and do a report. 21:44.083 --> 21:44.844 [SPEAKER_00]: You give that to an intern. 21:44.864 --> 21:47.725 [SPEAKER_00]: They're probably going to go this is about customers and CRM data. 21:47.745 --> 21:50.447 [SPEAKER_00]: They're from never going to go look at the HR system. 21:51.047 --> 21:54.008 [SPEAKER_00]: Even if I can log into it or I'm not going to touch the finance system. 21:54.449 --> 21:55.809 [SPEAKER_00]: Even in my account, it gives access to it. 21:56.530 --> 22:00.552 [SPEAKER_00]: And that model has now broken under agent. 22:00.612 --> 22:03.874 [SPEAKER_00]: This kind of security and trust model just has broken. 22:03.914 --> 22:06.275 [SPEAKER_00]: Because now if you give that same task that you might go into a human, 22:06.695 --> 22:27.395 [SPEAKER_00]: to an agent and as all these tools in all this access is going to go and pull on every single lever and every single push it open every door and push every button that can to go the cheese I go and if it figures out you can go and find something in the nature system or we're sure for our inside of the finite system, it will go and look in that and pull every hit every API endpoint and pull every button through every data export and data to do that of et cetera in order to achieve its goal. 22:27.955 --> 22:37.664 [SPEAKER_00]: And so the way I look at what's going on with sort of agents and that whole space is these like interns or that morals and ploys with that morals They will just do whatever they can to achieve their goal. 22:38.164 --> 22:45.371 [SPEAKER_00]: And one that's fundamentally exposing is the security models that have been placed to date are not fine-grained enough with a fact that 22:46.171 --> 22:50.215 [SPEAKER_00]: A human isn't looking at a system just because they probably think they shouldn't. 22:50.936 --> 22:52.818 [SPEAKER_00]: It doesn't work in this

new phase. 22:53.318 --> 23:05.110 [SPEAKER_00]: We're really now paying the price for not doing proper authentication firstly, not doing proper authorization, and then also not having the right level of audit and visibility and insights and observability in place. 23:06.351 --> 23:13.357 [SPEAKER_00]: every vendor and every software stack and every project out there now is really starting to work on this problem. 23:13.397 --> 23:15.259 [SPEAKER_00]: We need to give everything a proper identity. 23:15.859 --> 23:24.507 [SPEAKER_00]: That's from a workload to a function to a agent, as well as your humans be a partner's customer's internal users, etc. 23:25.475 --> 23:31.101 [SPEAKER_00]: And so we really sound to pay that price and what that really means going forward for someone that works in authorization spaces. 23:32.343 --> 23:33.865 [SPEAKER_00]: It now means we need to be ubiquitous. 23:33.945 --> 23:46.399 [SPEAKER_00]: You need to have an authorization check, a permissions check being done on every single step of the interaction, and the every single step of that process, not just all this persons logged in therefore they can access everything we need to do at every layer. 23:46.759 --> 23:51.546 [SPEAKER_00]: So, if there's service A, according to service B, can service A cause there would be on behalf of this upstream identity. 23:51.986 --> 23:58.235 [SPEAKER_00]: And these kind of delegation chains really is where we need to start building this muscle memory all around how we going build out. 23:58.315 --> 24:01.960 [SPEAKER_00]: And truly do there to use a horrible buzzword zero trust model. 24:02.540 --> 24:24.199 [SPEAKER_00]: I think that was a concept that predates everything around AI around really making sure you're no longer just trusting the boundary on us, no not just trusting the VPN, no not trusting the perimeter, but actually going down and moving that trust from it to down to an individual request for an individual API call in a sequence of calls in the authorizing down to that level because as the only way we're going to build resilient 24:24.659 --> 24:31.950 [SPEAKER_00]: Secure systems when we have these agents running out there trying and hitting every single ABI input to achieve the different goal. 24:32.010 --> 24:39.121 [SPEAKER_00]: And to what that means is that as a forciples as a company, we're really investing and building out much more on how we can understand. 24:39.561 --> 25:00.761 [SPEAKER_00]: Policy, how we understand behavior, how we put good governance around what your pushing model is and be able to report that in a way to product managers, security teams, auditors, CSOs, or the other way down to developers around like here's your current security posture, here's how behavior is actually occurring and then when you decide to make a policy change or a permission change, we can actually 25:01.321 --> 25:11.249 [SPEAKER_00]: Play out to you what the impact that will be across the organization and what applications and systems it touches and what that means from downstream impact Because these things aren't going to go away. 25:11.589 --> 25:29.643 [SPEAKER_00]: We'll be just needs to get much better controlling and monitoring and Pventy them from drifting off their original goal through a proper security boundary Alex Let's switch to you who influences the way that you work name a person or many persons or something you look up to and why 25:31.467 --> 25:57.745 [SPEAKER_00]: If I was to go to the most recent what's happening because of the Canadian space, I don't know if anyone has been following like Matt Pococ and what he's doing in terms of his agent skills and really how we take a lot of the best practices that are if I have been in the fundamentals of all the classical future science and software development literature, the progress of engineering and kind of those those kind of and the bodies of work and the turn them into kind of repeatable. 25:58.205 --> 26:00.348 [SPEAKER_00]: skills that we can apply to our planet and processes. 26:00.849 --> 26:03.032 [SPEAKER_00]: I think that's a that direction. 26:03.332 --> 26:04.514 [SPEAKER_00]: I think is really super interesting. 26:04.754 --> 26:07.477 [SPEAKER_00]: A lot of the things with models going to change, but there's a few people. 26:07.497 --> 26:09.840 [SPEAKER_00]: I think Matt's probably the most prolific in that space right now. 26:10.361 --> 26:13.045 [SPEAKER_00]: In terms of what's going on, how we rangle agents. 26:13.065 --> 26:14.667 [SPEAKER_00]: So how do you recommend going to look at him? 26:15.607 --> 26:35.855 [SPEAKER_00]: And also, I just look at some of the previous sort of managers and mentors I've had as one manager particularly that I think did a very good job of explaining to me when I first moved from developer to product like what my role was which is If you think of like a classic analog TV where you have that wall of static there's no signal, the job of ultimately for product 26:36.676 --> 26:54.897 [SPEAKER_00]: Manager, product Wrangler, product specialist, whatever role you may be in, is filling the blank space, it's filling the noise to make sure there's a complete picture and be able to accelerate and block teams ultimately as what someone's role is and now whether the work is being done by an engineering team or set of agents it's still the same problem we have to solve, there's a lot. 26:55.397 --> 27:16.482 [SPEAKER_00]: of both how we run a business, how you run a product team, how you run an engineering team is ultimately going back to the same fundamentals that we've always had pre the AI world and just applying this just this new context but I think ultimately the fundamentals don't change and we should always go and lean, lean on someone that's classic texts I don't think it has changed that much just yet at least. 27:19.669 --> 27:24.298 [SPEAKER_02]: Last question, so you're getting on a plane, sitting next to a young entrepreneur who's built the next big thing. 27:24.779 --> 27:25.601 [SPEAKER_02]: They're jazzed about it. 27:25.641 --> 27:28.466 [SPEAKER_02]: Can't we just show it off to the world and can we show it off to you right there in the plane? 27:29.127 --> 27:32.013 [SPEAKER_02]: What advice do you give that person having gone down this road a bit? 27:33.857 --> 27:34.898 [SPEAKER_00]: don't hide your enthusiasm. 27:34.918 --> 27:37.801 [SPEAKER_00]: If you're going to go down this road, you need to be all in. 27:38.241 --> 27:39.642 [SPEAKER_00]: Now I will say that with a caveat. 27:39.662 --> 27:41.364 [SPEAKER_00]: If you got a family, you got kids. 27:41.684 --> 27:44.166 [SPEAKER_00]: There's always going to be part of you that needs to find that balance. 27:44.226 --> 27:47.409 [SPEAKER_00]: But this is treat this like your life's work. 27:47.469 --> 27:49.251 [SPEAKER_00]: Like this is going to be the thing to do it. 27:49.271 --> 27:50.312 [SPEAKER_00]: So show that enthusiasm. 27:51.232 --> 27:54.853 [SPEAKER_00]: I hate a perfectly tuned and rehearsed elevator pitch. 27:55.013 --> 27:56.234 [SPEAKER_00]: It just feels unnatural to me. 27:56.614 --> 27:58.435 [SPEAKER_00]: Maybe that's too much Claude speaking whatever coming. 27:58.955 --> 28:05.617 [SPEAKER_00]: I had me these days or opens maybe, but be raw, be utterly infused by the problem. 28:05.977 --> 28:07.298 [SPEAKER_00]: Not necessarily the solution but the problem. 28:08.258 --> 28:12.639 [SPEAKER_00]: And ultimately that's the end of these and that's the thing that is going to go, oh okay. 28:12.999 --> 28:13.980 [SPEAKER_00]: This is really interesting. 28:14.540 --> 28:15.640 [SPEAKER_00]: Let's go and talk a bit more. 28:15.920 --> 28:17.341 [SPEAKER_00]: Yeah, don't be too rehearsed like 28:17.641 --> 28:23.065 [SPEAKER_00]: Life's too short to be worrying about whether you use the right center structure or prioritize our message. 28:23.325 --> 28:25.907 [SPEAKER_00]: Be excited about the problem and that excitement will be infectious. 28:26.047 --> 28:27.388 [SPEAKER_02]: Best fantastic advice, Alex. 28:27.428 --> 28:31.971 [SPEAKER_02]: Thank you for being on the show today and thank you for telling the creation story of Seribos. 28:32.692 --> 28:33.172 [SPEAKER_02]: Thank you very much. 28:35.594 --> 28:38.056 [SPEAKER_02]: And this concludes another chapter of Code Story. 28:46.828 --> 28:49.551 [SPEAKER_02]: code story is hosted and produced by no a lab part. 28:50.032 --> 28:54.457 [SPEAKER_02]: Be sure to subscribe on Apple podcast, Spotify, or the podcasting app at your choice. 28:55.438 --> 28:57.360 [SPEAKER_02]: And when you get a chance, leave us a review. 28:57.860 --> 28:59.923 [SPEAKER_02]: Both things help us out tremendously. 29:02.826 --> 29:03.927 [SPEAKER_02]: And thanks again for listening.