The Infra Pod - Security is moving to the frontend?! Chat with David at Arcjet

Episode Date: August 5, 2024

Ian and Tim sat down with David (founder of Arcjet and Console.dev), where David is building a new company that's bringing security to the frontend stack, so developers can provide security from day one and at the edge. Come listen to how this trend is starting and what is David believing that would happen for security in the future!

Welcome to our yet another Infra podcast. It's Tim from EssenceBC and let's go. It's Ian Livingston, open sneak turn to a platform. And today we're joined by David Mitten, formerly of Console. I guess you still run Console, but currently off building this thing called ArcJet. David, how are you? Tell us a little about yourself. Yeah, still writing Console, console.dev weekly newsletter for developers been doing that for four years now just playing with dev tools all day every day and then

about a year ago started artjet which is a tool to help developers secure their applications in production so i think bot protection rate limiting attack detection data sanitization just helping developers build more secure apps. What is it, after playing with developer tools for four years, you're like, I'm going to go try and secure apps and try to build something new. What got you down the road? Where did the idea for ArcGIS come from?

What was your why now? What got you off of doing what you were doing, successful newsletter, to decide, I'm going to go build another startup? This isn't your first, so you've been down this road before. Like, what's the rationality? So alongside building OnSol writing console, I'd also been spending time just doing hacking challenges,

bug bounties, just learning about how insecure software is. And as I got more into that, I was getting more into the tooling that is used in hacking. And just the mindset of hackers is so different. Developers, you want to build something, whereas security people want to break something. And at some point, those converge. But the tooling is just not there to help developers with security. Typically, you push your code to production, and then you start thinking about

security. That's way too late. And then you have to throw something in front of your application that's already deployed. It's at the network. You can't test it locally. You have no connection between what's going on in production and your code. And I just thought there was a better way for developers to be thinking about security and building that into their products from the beginning i'm curious you know like traditionally the traditional nonsense that i heard and this is true you know 10 years ago as developers don't care i'm not even 10 might be 20 years ago certainly still heard it off from 10 years ago and five years ago so like the traditional idea is like developers don't give a shit about security like why build a security tool for developers like what's the thought process like How do you cross that chasm?

How do you think about building a tool that you market to developers for developers to integrate in their apps instead of traditional security market, which is like developers build stuff and then a bunch of security tools are bought to try and monitor the things that developers build, but they're in completely separate worlds. What's the thought process here? I think it comes

down to the incentives. Developers are pressed to deliver features. And so security tends to be something that they do later. Commonly, that leads to adding security at the network. You turn on a WAF and it usually breaks your app. And so that's when developers start to care because things get broken or they get broken into and then developers are caring either way. And so I think it's less about developers just not that they don't care. It's just they don't have the tooling.

They're in that different mindset. And it's just something that they think is someone else's job. And I think the way to try and solve that is to bring developers into the security process and help them build things that have security by default. And really, so

they don't actually have to think about it. That's how DevOps is one, that's how the platforms is one. You don't have to think about scaling, you just push your code to Bacel or Netlify or wherever it is, and it just all happens. Maybe you have to pay for that if you're not careful about how fast it's scaling. But the kind of scaling challenges, they've been solved in a way. As things get bigger, you obviously have to do a lot more. But I think getting security to that position where it's really there by default, and then as things become more sophisticated and complicated, then you can get into the details and figure out how to actually solve specific things. But really, it's that common layer, that common foundation that just doesn't

exist in the same way that it should do. So web application firewalls are not new. Akamai has one, Cloudflare has a built-in, Vercel has launched a feature. Can you help us in the audience understand what's the difference between the traditional web application firewalls at the network or load-balanced layer and what you're doing with ArcChat? What's the delta? Give us the black and white, if you will. So I'm still going back and forth

as to whether we should even talk about WAF just because it has the connotations of decades of products that have existed and in some ways have been successful and in other ways they haven't. Arcjet has a WAF, but it is way behind the scenes. It's not something that we put front and center of what we're building.

And the real difference is that the WAF sits inside your code, what we're doing. The way it actually works, it doesn't. It runs elsewhere, and so it's not interfering with your code. But the way you configure ArcGIS is in your code. It's an SDK. You install it. NPM install ArcGIS.

You get it up and integrated into your application. The key there is that developers have access to the rules. They can control what is happening on each route that's configured, but then you can also see the security signals. So maybe you don't want to apply a bot detection rule because you know a user is signed in and they're paying on your enterprise plan

and so you trust them and so you don't. You want to just really lower the level of security just because you already have inherent trust there if it's an anonymous user then you can apply completely different rules the way the WAFs work today is they sit on the network they have a generic view of the traffic coming through they can apply generic rules which work in some senses like a disputed denial of service attack. That's a great example where you want something on the network blocking traffic. But how do you distinguish between a DDoS attack and your largest customer just making loads of API requests? Maybe they're coming from all over the world, so you can't just filter it by IP

address. You need to have this additional context. It's that context that's key. And you get that by being in the application layer the same way that you know who the user is through that session. You can bring that into the security side of things as well. I mean, one of the things you said that really piqued my interest, I mean, a lot of ways it piqued my interest,

but the number one thing that you said that piqued my interest was, we're in your app, but we're not. Can you elaborate on what you mean by that? Right. So the challenge that WAFs have had in the past, and in particular, this RASP category, Runtime Application Security,

has come and gone in many ways. And the challenge there was that developers were integrating something into their code that would often integrate so tightly that it would just break everything. And as soon as you install a new component, when something breaks, that component is going to get blamed. And the first thing that you do is just remove it.

And so one of the things that we do with our WAF component is it runs behind the scenes on our systems. We have the SDK that you install into your application, sits at the middleware layer, and intercepts every request that comes through. We then use that SDK to pass the request into a WebAssembly component that's running entirely in your environment

and we can do a degree of analysis there but you can't do everything in WebAssembly there's no shared state so every request is separate and so we have an API which we run very close to your application that does real-time analysis and that's where we do things like tracking state tracking rate limits, tracking clients across requests and then the final stage of that is that the request goes through a background process.

So the first request comes in, we return a decision within 20 milliseconds and the application continues running. But behind the scenes, we're analyzing that request and deciding whether we think it's suspicious. And that's where the WAF sits. And over a period of a number of requests, we'll build up a picture of this client so that once it goes over a threshold, we'll then return a different decision. And at that point, we might say, well, this client is now suspicious because although the zero days are the sexy attacks that everyone talks about, they're very rare and you usually protect against them with different mechanisms. Actually, most attacks come about by someone probing your application multiple

times, trying to find different endpoints, testing for SQL injection, all those things. And you want to detect that and then block them from making further requests. And that's where our WAF comes in. So I'm just curious, because looking at your background, whatever you worked on, you started with

servers, right? And then you went to DevT tools as almost like a newsletter. Now you're going all the way up to stack here. Why do you want to focus on really the front-end side of the world, giving your vantage point of running a big dev tool newsletter? You're seeing a bunch of dev tools. You see a bunch of products, right? What have you seen? Why do you think security needs to be brought

to almost like the full stack or front-end centered engineers? What's the paradigm shift you're seeing that prompted you to jump down to this deep rabbit hole here? It's the rise of the developer platforms like Vercel and Netlify where you just push code. And perhaps a little slightly different, the likes of Netlify where you just push code. And perhaps a little slightly different, the likes of Fly.io where you almost push code, but you do get access to more of the underlying primitives.

And there's others, there's Render, there's Railway, there's all sorts of platforms that do things in slightly different ways. But the common theme across them all is that developers are in control. The problem is that every security tool is built for a security person and they're important. They have to be involved at some point. But when code starts, when you're

building a new application, it's the developer picking the framework, developer picking the stack they want to use. They're building a prototype and they just push it to production and you get all these apps then that sprawl across all these different platforms. And if you're on AWS or you're on GCP, there's a load of security tooling there. And if you're a developer, you've got to try and figure out how it works and find all the tools and get them installed and working. But if you're on Vercel or Netlify, there are no modern tools that are native to these platforms that work wherever they are.

Whether they're on these platforms or running locally or in staging. This is the challenge with existing tools is they typically only get deployed to production and they're managed by a small elite group of security people and not the broader set of developers. And so I think this trend is the rise of developers being in control more,

picking the tools that they want to use, the platforms that they want to use, and then those getting adopted. But security is lagging behind. And I think that's what I am trying to bring from what I've seen through the tools that console is understanding what makes a good dev tool, how do developers adopt things, and bringing that into security where it's been lacking for a long time. And that's super interesting. Like the Vercel, Fly.io, like I think we all have heard of these platforms and maybe not everybody actually fully realizes how much production these platforms are collectively running. It sounds like there's not just explosion of small apps or prototype or

just even your marketing static, right? We often hear like Vercel has been used for static stuff, but obviously these things are changing quickly. Flyo is actually pretty broad. I guess the question is, what is the type of production applications you're seeing these platforms are starting to emerge? And what kind of attacks people should be thinking about? Because if you're just a full-stack engineer, I don't think security is the first thing ever. I'm writing my little Express app, and oh, wow, how do I do security? I don't think most people really feel like even half of their brain

or even a big part of their brain think about that. But it sounds like with ArcJect, the simplicity of installing you, you're trying to get people to use you as early as possible, is my guess. What kind of attacks they should be aware of that you're seeing the most common in these platforms today? Right, so developers have to understand who is responsible for what.

You've got a full spectrum of shared responsibility. Essentially, you're always going to be responsible for your code. And then the question is, well, what else do you need to take care of? You've got Vercel at one end where they handle almost everything for you. You just push your code and they'll deal with the runtime and making sure that's up to date for the latest Node.js vulnerabilities.

They deal with the containers that's running inside and whether it's inside serverless functions and what's the connectivity to your network. So they're dealing with a lot there. And then on the other side, you've got something like EC2 or a VM you buy from Digital Ocean, where you're responsible for almost everything up to where the data center is. You're not responsible for the security of the data center, but anything prior to that. And so the goal with what we're doing with ArtJet is to try and help developers take a bit more responsibility.

And the way that I see that developing is very similar to how DevOps has become something that developers are responsible for. But you still have SRE teams. They're the elite specialists who are building tools to help developers deploy. They come in and they advise developers on how to use the platform or how to deal with certain scaling issues related to running production applications. And I think we will see the same with security. The idea of DevSecOps hasn't really worked out. And so I don't think it's the same kind of thing. But I think it's more that developers will take care of a lot of the security,

but there'll still be a very important function for the security team, the specialists to make sure the foundations are there and the tooling is there to help developers build secure applications. But it won't be the case that everything is done by the security team and they have to try and force developers to do things, which is the challenge that you have today. How much of the traditional security stack do you think the sort of like security as a library or npm installable thing as an example gets eaten? How far down the road do you think this travels? For example, today, a lot of what you're doing is intercepting HTTP calls in the framework layer. But that's just where we are today.

Where does this go and where do you think this broader change occurs? I think about this as the next step for something like Cloudflare. And it's a Cloudflare-sized opportunity. The past was you would buy a firewall, you'd rack it in a data center. Very few people do that now to protect their applications.

This is what's actually happening behind the scenes, but most people are not dealing with that. Then the way that you do things today is you throw a network-level security platform in front of your application, something like Cloudflare or Fastly or Akamai or someone who has a large global network. I think the role of those platforms in the ArtJet vision diminishes to providing generic network level security for large volumetric attacks where you do need a huge network, someone like Amazon, someone like Cloudflare who can absorb the large DDoS attacks

that you see just as part of the internet weather. And the future of application security is having much more context in your code, but not interfering with your code close enough, like that the middleware layer, but not so close that it starts breaking things. And that's the ArtJet opportunity and is why we're building out a load of primitives. We've got rate limiting, bot protection,

email validation, and we've got attack detection, the WAF product, which we call Shield. We're in the process of building a data sanitization product to detect person information. And there's a range of other primitives that we're planning on building. The goal with each of those is that they're not thought of as security, but they're thought of as helping developers solve a particular problem, which is how I think developers think about security, is that they're not in the market for a security product. They're in the market to try and solve a problem.

They might be getting spam signups. They might be seeing too much traffic on their API. They need set quotas, or they've got bots scraping their site. These are all developer problems, but they have a security angle. And that's what we're trying to do with these primitives. So I think you already alluded to, you want to have more context, because that enables you to protect way more than just your traditional security products. So maybe talk about how does ArcJect roughly works?

Because NPM installing, you're getting into directly, I saw you have validation on your signup forms, you have bot detection. It seems like you do quite an array of different sort of surface protection. Do you have like a fundamental difference when you have how Arcject even fundamentally works? Do you have to weigh more client-side

security detection, for example, or is the client purely just sort of like a hook-in? Is there like a paradigm shift from how you implement security even? Not just get the context, but probably even like protect them at the edge much better and easier. And there's probably some kind of trade-offs here. So I'm just curious how you see actually even building a security product this way. The component I think is the coolest is the WebAssembly part of the product.

The SDK itself is really a lightweight shim and the goal is to make it feel native for the developer in whichever language they're using. We're starting with JavaScript. And to then provide hooks into the frameworks and the appropriate parts of the runtime and the language that they're using. But the goal there is to push the request into this WebAssembly module. We write it in Rust,

we compile it to WebAssembly. We think that's the best language because it doesn't have a garbage collector. And it allows us to run this security bit where we're putting a lot of our effort in multiple environments. We use it with the Node.js runtime, with the Edge runtime in JavaScript. It works with Deno and with Bun. But it will also work with Python. You can call it directly from Python in PHP and Ruby. All of the different language stacks and ecosystems

have a way to run WebAssembly code server-side. And so the SDK takes the request, all the headers, the body, and any context that you pass it, like details about who the user is, the authenticated session, and it pushes it into the WebAssembly module. And the great thing about that is we can run it entirely in your environment. We don't need to send anything into a cloud service. And it's sandboxed. You can have a look at the SDK. You can see the bindings, you can see exactly what we're pushing into the WebAssembly binary

and what's being pulled out so you can have trust and transparency there. And then we return the result back to you in the SDK so you can deal with the signals. Where the challenging bit comes is where you need to have shared state. And we're starting with very constrained environments. Something like Vercel, everything's run as a serverless function, and they start cold, they spin up, and then you have this undetermined period where the function is running. And at some point it will be recycled and you lose all the state. And so there's nothing

in memory. This is in contrast to a long running server in a typical Node.js application or a Go server or a Python server where you spin up the server and it runs until you tear it down or it crashes or something like that. And so you can have this shared environment. And this is important for security tools because you need to track clients across multiple requests. You need to counter rate limit or you need to build up a picture of that client to decide whether it's suspicious or not to build up a picture of that client to decide whether it's suspicious or not. And in a serverless environment, you can't guarantee that if you're counting up to 10 for a rate limit, by the time you get to five, the environment

recycles and it resets to zero. And so that's where our API component comes in. And we run this really, really close to the user's application in the same AWS zone, same region, so that we can send a synchronous request to our API to take a decision to track the rate limit across multiple requests and to return a response back into the SDK. And so we do as much as we possibly can inside that WebAssembly component. It adapts depending on where you're running, and we can analyze more depending on whether you have a long-running server process or not. But ultimately, the API is there as a fallback to allow us to do these stateful requests and analyze what's going on. That sends the headers, but it doesn't ever send the body.

That's always kept in your environment. And so we can also provide some privacy guarantees to ensure that we're not sending sensitive data as part of the form post, for instance. That can all be processed inside the WebAssembly. And then the SDK returns that back to you as the developer. You can see the decision that we've made. You can see all the reasoning behind it, the metadata. And then that's where you can customize the logic of your application. You could flag a new signup or human review

because it's come through a Tor node or you could automatically just allow someone through because there's no security signals at all. That's part of the response context as well as the request context that we get. So it's interesting because I've heard you describe this as RAS

or I've heard you say this as a WAF. Like, what is it? Is it a new category? Like, how do you think about this? And do you think this is just one of many tools that will in this sense sort of... It's similar to shift left, but it's not exactly shift left.

So I'm curious to understand. It's developer native security is probably a better way to frame it. It is actually security for the developer. The developer integrates into their app that actually runs the application. It's closer to runtime security than anything else. So help us understand, how do you categorically think about your position in the market? And then also, how does this market evolve over time? Are there more ArcGIS

that look similar? What are the other parts of security spend that this type of stuff could eat? I hope it's not in RASP because that category has kind of disappeared. And the challenges of the WAF category are there's a lot of incumbents who have very legacy solutions. And as soon as you start talking about WAF, people create this image in their mind,

which we don't necessarily want to be associated with. But the challenge of creating a new category is everyone's always going to try and think about the existing categories that you fit into. And then we have the second problem of we're building multiple primitives and they all have their own potential categories that they could be in. The Shield product is obviously a WAF. That's what it's doing behind the scenes. And so it fits into that. Rate limiting is a different type of product altogether. And bot detection is another one. You could probably put them all into their own Gartner magic quadrant,

and they would have different categories. So I suppose the question is, what's the category of the underlying platform? What is ArcGIS fitting in rather than ArcGIS rate limiting? And I don't think there is a good categorization at the moment. There's developer native security, cloud native security. I don't know whether those are categories and whether people are buying the whole thing. That's what we want them to do.

But the way in is with a single product that they need something for. They need a rate limit or they need bot protection. And that's how AWS started. They had one or two primitives. You start with one and then the next one that you need you think, oh well does AWS provide that? It's on the same bill, same permissions, we've already got our account set up and that's what we want to do with ArcJet. As we start with three or four you bring us in for one of those and then as your security needs

expand you think of us first and and we will be ahead, hopefully, of your needs building out the primitives over time. So I'm curious, we've seen a big shift. I remember talking to even Gaius Sneak back in the day. The way he marketed security to developers was so different than security companies marketing generally to security people, right? Given you're going to market security to even further audience than most security products do at all. I don't think we've seen that many security product really going out for like full

stack or front end, but there's really just a few. And they usually revolves around NPM, right? You're not in that camp, right? You're directly selling security directly to those folks. Is there any sort of like learnings or challenges around like learning how to like even market security to these folks? Have you found any sort of like interesting ways or ways you have to learn how to market effectively to this kind of people? Just curious what kind of thoughts you have here when it comes to talking about security to these folks, because they may or may not,

they probably know about the attacks, but my guess is they may not know the severity or they know when they should do this. There's probably some level of uncertain, how much do I need this? How have you found yourself able to convince them? What is the right way to talk about security to those folks? So far, we've seen two types of use cases. The first is someone who

just wants a sense of security. They don't have a particular problem they're solving. It's kind of the insurance model. You want to put something in place because you know it's going to be a problem at some point, and you want to have a general foundation of security. You're implementing insurance against potential mistakes you might make or potential vulnerabilities you're not aware of. And so that's what something like ArcGIS Shield, the WAF component, does.

It's analyzing your requests, and it's helping detect potential attacks for things like cross-site scripting and SQL injection and remote code execution type vulnerabilities that come up every so often, but are not a particular pain point today. You're just trying to protect against something. The other group of users that we've seen is that they are experiencing a very particular pain point right now and they need a solution to it. And it's something like bots are stealing their AI inference. That's a more modern one that we're seeing with newer applications where you might

have a public endpoint because you're providing a chatbot on your docs and through prompt injection you can get that bot to do things that it's not designed to do. And so you're stealing someone else's inference. There's a project called GPT-4-3-4 on GitHub that has a big script that binds all of these places which have insecure APIs. And it will automate that process of going to run AI inference for free using someone else's AI credits. Or it might be that their API is being attacked, or they're getting a lot of traffic, and they want to implement rate limiting.

And that's a common thing that developers understand and know. And so they're looking for a very specific solution. And so this is how we're trying to reach developers by providing a much more native approach to solving some of these problems, the pain points. They're not thinking about security as such, not in that second case, but they're thinking about a pain point. And I think that's how you market and reach developers with security tools is you're not selling them on the security benefits. That's what you would do if you were approaching a security team or a CISO, but you're selling them on the security benefits. That's what you would do if you were approaching a security team or a CISO,

but you're selling them on the development pain points that they're facing. Because building a rate limiter is a pain, and then you have to figure out how to set up Redis, and you have to manage that. Or if you're building bot detection, you have to buy a product and integrate that. And if you're trying to do email validation,

you've got to figure out, well, is the email syntax valid? And then is there a disposable email address? And how do i get a list of those services uh is the sign up coming through a proxy or a tour node or through a cloud relay and how do i associate that and really that's not something that developers should be having to build they should just bring in the primitive into their application and so it's this insurance on the one hand you know you need something but you don't have a pain right now and then on the other hand you you know you need something, but you don't have a pain right now. And then on the other hand,

you've got a real pain that you're trying to solve, but it's not a typical security problem that developers are thinking about. One of the things you've come back to a couple of times in our conversations is the idea of context. Like you should have more context, you should have more context. I'm curious, as more, I hate this word,

but I'm going to say it anyways, as AI eats more of the stack. You see things like browser-based, where you have browser-based going to websites and there's no human there. There's a vision model behind it or some model behind it that's driving it. Where does the intersection between this deep context and the rise of LLMs, where does this come together? Does it come together and do you see that context is key

to actually securing the internet moving forward? Like if I have an app securing against these sort of different vectors? Because this is new. The fact that we can have, you know, a company like Browsbase, right, and solve fundamental problems where people are trying to do things

that we couldn't do before, like web scraping. Web scraping is almost impossible. Right now it's almost a solved problem. Like where does that fit into your mental model for ArcGIS and security, app-level security, broadly speaking? Right, so this is a question around identity, really, is who is accessing your application. And we're not solving that problem right now where we will inherit whatever identity you give us, whether it's something that's come through a social provider, you provided the login

details and you're logging in through GitHub or whatever and that's how you're authenticating into the application or maybe it's an API key and you're using that for access to the API that you want to set rate limits on. I think the question is how do you identify users and then that becomes part of the context and you use that identity to then decide, well, they're on this pricing plan, so they get access to these features. Or they're coming from this country, and so we have to deal with these privacy regulations. That's kind of the context that we're thinking about at the moment. I think the challenge with identifying an automated agent like a scraping tool is just how well they can mimic the human. And we're seeing more of these tools starting to appear that can supposedly detect whether it is a human or not,

kind of blocking AI from scraping your site and building into the models. But it is a really difficult problem, and there is no solution that is 100% accurate for bot detection. It's definitely an arms race. You can see how the mechanisms for detecting whether it's a real browser or not are trying to keep up with the techniques that people are using to evade them. And it's just it's a cat and mouse game. It's very, very difficult. Awesome. Well, I want to jump into our signature place, which is the Spicy Futures. Spicy Futures.

Tell us, David, what is your take on the Spicy Future here? Give us your spicy hot take here, and we'll go from there. I've got two ideas. When you mentioned this, I thought of two different things. One related to security and one related to something completely different. The security hot take is something I've been messing around with recently and securing our own infrastructure, which is around environment variables and secrets. Ian and I have discussed secrets for a while and the challenge there.

And as soon as you spin up new infrastructure and you deploy something to AWS and then you put it on Vercel and then you've got more than two developers in your team, you start having to think about where all these secrets live. And one of the most common things that I've come across when doing hacking challenges is being able to get lateral movement when you get into a container or a server and all of the secrets are in the environment. They're there in plain text and it's very easy to download them and get access. You can then connect to a database, you can access an internal service just because everything is there in plain text

in an environment variable. And it's a very specific hot take, but I think the idea of storing secrets in environment variables is a terrible idea and no one should be doing it, but everyone does it because it's part of this idea of a 12-factor application, which is a common pattern

for how you build modern applications. And you put all your configuration into environment variables. And it's a great way to configure, but it's not a great way to store secrets because you can't audit them. You have no idea where they are. And they are just plain text strings

sitting there in the environment, ready to be taken out through a remote code execution vulnerability, someone getting access to the container, a rogue developer who's on your team, a script that you just npm install and it runs a post-install script and then scrapes your environment

and pulls all the environment variables out. I think that's just a terrible way of doing secrets management. That was spicy. I love it. That's deeply spicy. I'm it. That's deeply spicy. I'm curious. I've been thinking a lot about agents specifically, which is, you know, autonomous agency idea that Datadog or ArcGIS

or insert any company will come along and just modify your code base and that code gets deployed in production. And, you know, you went in the loop. It just, you like installed the Datadog thing, and it's just like, oh, your entire code base is instrumented, and you install the segment thing,

and oh, here's a stack trace you found on some JavaScript page, and here's the fix, right? Or the sneak agent does similar work. I'm curious, building off your secrets, spicy take, secrets is a problem for agents. It's a problem of identity. How do we access these things? Where do you think tools like

ArcGIS fit into solving the secrets problem? Where do you think tools like ArcGIS fit into solving that broader, how do we actually enable autonomous workflows? On one side today, you're very much like sitting at the front end. You're dealing with a lot of introspecting traffic coming in and out. But broadly speaking, the patterns and layers of security we need to enable actually Gentoo workflows, the guardrails we need to have in place, they don't exist today.

There's never been this idea that there's some third party thing that's going to go there and turn the knobs on my app or turn the knobs on my thing. And you can even imagine this role where it's not specific to the SDLC, where you have Datadog or these different agents. It could be I have a Shopify agent and it's going to go into my, you know, my vending app or something and it's going to modify and do things on behalf of me. And it doesn't even matter.

I'm curious how you've thought about sort of the future of identity, how it intersects with what you're doing, and how it intersects with sort of this rise of agents that will come into the B2B landscape. Right, so the correct way to do secrets is to load them at runtime, where the server starts up and you make a request to, let's say, AWS Secrets Manager or Doppler or a hash call fault, and it verifies who's making the call and verifies you've got the correct permissions and then it gives you the secret and it sits in memory. That's a separate question about how easy it is to reach into memory and steal the secrets there,

but it's a lot harder than it's just sitting in plain text in the environment. And then giving that to whatever's running for a period of time. And the challenge we have today is that you've got to create the method for access to the secrets, and then they're typically long-lived. You have an API key that lives forever, it never expires,

and it sits somewhere for a very long time, and then you have a breach, and you have to figure out how to rotate it. And the way that this is trying to be solved at the moment is through OIDC, where you get a very short-lived credential based on a pre-existing trust relationship. And it gives you very specific permissions that last for a very short period of time. And the only tool that I use today that actually does that is when I have GitHub connecting to AWS, because we do our deploys through GitHub Actions

and on every single run, it uses GitHub's OIDC infrastructure to authenticate to AWS, get a very short-lived token, and then use that to push to ECR and to get the container deployed. And after however many minutes it is, it's disappeared and you have to create a new one. But it's not easy to get that up and running, and it's quite hidden in GitHub's documentation, and it's a pain to configure on AWS's side,

and it's just really annoying to get up and running. But the way that that's working is it's giving a unique identity to that particular GitHub workflow that's running at that particular moment with specific permissions on AWS. And that's running at that particular moment with specific permissions on AWS. And that's really how we need to do it. You need very short-lived credentials that give very specific permissions to a very specific context. It's not something we've been thinking about at ArcJet, but you just mentioning it does make me think about how we could do that in the runtime and inject an identity into the

running code and provide that through our SDK. We don't have an agent. That's the great thing about WebAssembly is there's no agent required. You don't have to install anything else. Just install the SDK and that's it. There's nothing else there. And the different runtimes, whether it's Node or Bun or Python or PHP, they all provide different ways to inject things into the runtime. And that could be a very interesting way of doing things because who wants another agent? That's why Datadog has been so successful in many different ways

is because you've already got the agent installed. And so you might as well just enable the next feature that they release, but no one wants to install another agent. I think that's the challenge that we have. So I want to actually ask you about, I love your hot, spicy hot take. It's very, very specific, but I do want to allude to maybe a more categorical question. Given that you're trying to really enable

all the developers to implement security pretty much up front, if ArcJack is successful, I believe that you should be able to actually protect way more at the edge than what people have to do sort of like backwards. Do you think there is a time where we actually see security basically shift way more to the front end? And does the security roles changes? Like, do you see the security teams start to stop worrying about complete all the front-end related or even like to some degree, most of applications stack related questions

and they just do, I don't know, other things? Like, where do you see the world changes? Security probably should just do this instead. And we see the architecture of the world. I'm curious, do you have a take on that as well? Frontend, the meaning of frontend has changed quite a lot

compared to when I started 15 years ago. Frontend then meant JavaScript that ran in your browser and that was it, literally nothing else. And that was a big engineering task. It was definitely engineering, particularly in sophisticated applications. But front-end has morphed into this idea of full stack, and they're almost similar.

They're almost the same thing. And you're using front-end technologies to build server-side applications, which to me is strange because I would write code that runs on a server in Python or Go or something that is a systems language, not a browser-based language like JavaScript. But it is the most popular language aside from Java, and it's used by so many people. Frameworks like Next.js and SvelteKit and Nuxt have made it so easy to build code that runs on the server in the same language,

TypeScript or JavaScript, that you're writing code for the browser. And the challenges you've now got people who are not used to thinking about systems-level security problems writing code that is running on the server. And so I think this is where the security need is arising, and it's changed over the last 10-15 years because there are more people writing code in areas that they have moved into organically rather than coming with a lot of a lot more experience and thinking about things in a different way because writing javascript for a browser is very different from writing code that's going to sit much closer to the metal on a server

and so the security challenges change there and so this is where I think the opportunity is because in building a security tool, it's built for JavaScript. We're building a JavaScript SDK. So we can go to other languages, but we are still in the server as well. We're running WebAssembly on your server. We're looking at the incoming request

and helping you deal with the response using a language that was actually designed to be run in a browser in a front-end context. server, we're looking at the incoming request and helping you deal with the response using a language that was actually designed to be run in a browser in a front-end context. And it's this merging of all these different contexts that makes it interesting. And also there's so many different challenges to deal with. Awesome. So for anybody that likes to check out Arcject, what are the ways for people to actually check you out?

Do you have any social or suggested places to start? First place is arcjet.com. You can sign up and try the product out in just a couple of minutes. We have an example application at example.arcjet.com where you can try it. They're rate limiting. You can send a test attack to that app and see what it does.

And then you can click the nice Vercel button on there and get it deployed to your own Vercel account and see what it's doing behind the scenes.