Authentication, Authorization, And The Future Of AI Security With Alex Salazar

Alex Salazar: “When you think about authentication and authorisation, the other thing that we're thinking about is the way we thought and talked about authentication authorisation in web and cloud world, all of it was about front door access. How does a user or another machine come into your service? So, all the vendors, the vendors that I was a member of, all optimised on the login screen or the SSO flow in. Well, in agent world, that problem is easy piece. Now the problem is, how does the agent itself interact with authenticated and authorised services? Those interactions are happening on the other end of the agent stack. It's not at the front door, it's at the back door. So, authentication authorisation is really different, and the services that matter, the really valuable ones, it has to be on behalf of the end-user.”

[INTRODUCTION]

[0:00:57] Guy Podjarny: You are listening to The Secure Developer, where we speak to industry leaders and experts about the past, present, and future of DevSecOps and AI security. We aim to help you bring developers and security together to build secure applications while moving fast and having fun.

This podcast is brought to you by Snyk. Snyk's developer security platform helps to build secure applications without slowing down. Snyk makes it easy to find and fix vulnerabilities in code, open source dependencies, containers, and infrastructure as code, all while providing actionable security insights in administration capabilities. To learn more, visit snyk.io/tsd.

[EPISODE]

[0:01:37] Danny Allan: Hello, and welcome to another episode of The Secure Developer, where we talk about designing and shipping secure software without sacrificing velocity or innovation. My name is Danny Allan. I'm the CTO at Snyk Security, and I'm joined today by a very special guest, Alex Salazar, who comes to us from Arcade. Alex, welcome to the show. How are you?

[0:01:55] Alex Salazar: I'm doing well. Thank you for having me.

[0:01:59] Danny Allan: Yes, I'm excited, Alex. Now, I know you are the founder and CEO of Arcade, and you have a pretty interesting background, and we're going to get into AI, but maybe if you can just introduce yourself for the audience, I think that'd be a great place to start.

[0:02:13] Alex Salazar: Yes, perfect. So, prior to Arcade, I did a brief stint in venture capital where I really realised I was really still a founder and not a VC. I was mostly focused on AI infrastructure and security infrastructure. Then prior to my stint in VC, I had a great firm called Neotribe. I was at Okta. And at Okta, I was the head of product for their developer products, as well as product strategy, and then eventually, I was the general manager of new product introductions, in particular, their security access gateway for on-prem systems.

Prior to that, I was the founder-CEO of a company called Stormpath, which was an authentication service for developers that Okta acquired to accelerate its developer-based business. Stormpath, for those who may not have ever experienced it. It looks and smells very similar to Auth0.

[0:03:04] Danny Allan: So, obviously, an extensive background in the software space and building software. But I actually have to ask a question because I looked at your LinkedIn before you joined. I think you and I crossed paths for one month at IBM. I was at IBM in 2007, and I looked at your profile there, and you were on the sales side? How did that happen?

[0:03:21] Alex Salazar: Oh, my gosh. Wow. What a throwback. So, it's a very funny story. I'm unfortunately old enough to have been in college during the dot-com crash. So, as I was getting ready to graduate.

[0:03:32] Danny Allan: So was I.

[0:03:33] Alex Salazar: The world ended. It's crazy to think about it now, but software developers had a very hard time getting a job. I had friends waiting tables and things like that. So, I got very aggressive in my job search, trying to get a software development job. I was crashing on campus interviews that I was not invited to. And I did it a lot, like 40 times. It worked; no one ever said no. But after a number of rejections from people like Microsoft and IBM, because they just didn't have slots to hire me, I got a phone call one day, on the same day from Microsoft and IBM offering me a sales job. I was very offended because I was an engineer. I was top of my class, computers I did, and then IBM showed me sales compensation, and then I was less offended, and I had to make the rent, so I took the job, and I loved it. So, I spent four and a half years at IBM, and it was wonderful. It was actually more valuable than my Stanford MBA.

[0:04:34] Danny Allan: Well, there is nothing but goodness that comes out of that. I think too many engineers get stuck in writing code, and they actually don't see the business side and the value side of the equation. So, having that experience is hugely valuable. I actually was an SE way back in my career, and not only have I've written code, product management kind of the full spectrum, but talking to customers and being in front of them every day, there's no better MBA, as you put it, than understanding the business side of this.

You've lived through some revolutions. I always say one of the big architectural revolutions that happened is we went from physical systems. I started my career in a mainframe, but we went from physical systems to virtual systems. We're going through another massive revolution right now with AI, and you're at the forefront of that. Talk to me about your involvement at the beginning of AI. When I say the beginning of AI, I'm really thinking generative, like the chat AI. Where do you foresee this going in the future?

[0:05:29] Alex Salazar: Yes. I love how you put it in terms of revolution because that's actually how we came to the insight. So when, I mean, way back when, I was in business school at the time and I wrote a paper, like my unofficial thesis for a venture firm that paid me for it on what was going to happen in cloud computing. Or people weren't even calling cloud at the time, it was SaaS. I'd made this very bold statement to them that someone was going to – a big company that had deep pockets is going to roll out compute and storage as a service. When that happened, there was going to be an explosion of middleware, databases, and server security systems. Then, while I was still in school, EC2 and S3 suddenly became what we now know to be EC2 and S3.

I was very surprised as a bookseller, I didn't think it was going to be that. When it happened, I was like, “Oh, shit, this is real. This is the new platform. I've got to put my money where my mouth is. I'm going to go start a middleware company,” in particular, an authentication middleware company. And that worked out quite well.

When I was sitting in Venture, I joined Venture in 2020. And OpenAI was already out, but nobody really talked about it very much. It wasn't a terribly exciting company. There's a lot AI happening. I don't know if people would have called it Generative AI yet; I forget, but there was a lot happening. But man, all of it was on the training side. I just wasn't seeing production services, production systems. I wasn't seeing a platform. So, we were investing mainly at the application tier because that's where the action was at the time. But when GPT 3.5 came out, and then immediately after ChatGPT came out in November of what? 2020? 2022? It hit me like a lightning bolt. I was like, “This is a new platform, and there's going to be an explosion of middleware.”

Sure enough, immediately after, everything we were seeing from that point on was something being built on top of GPT 3.5, and then eventually, Claude and all the successors. Then, similarly, we started to see demand for middleware, and people were custom-building way too many things, and that's when I decided to leave and start something. Interestingly enough, I started, initially, Arcade started as an agent itself. We were going to do site reliability agent that could see an alert and diagnose it and do remediations. We got it working, but it was incredibly difficult, and the way we got it working was by solving this authorisation and authentication and tool calling layer. Once we step back and realise what we built, we were like, “Oh, shit, everyone needs this. This should be the company instead.”

[0:08:06] Danny Allan: That's really, what you're describing as a Gen Two of AI, if I'm reading this correctly, because kind of Gen One was chatbots. If you're stuck there, you're not really understanding what this revolution is about, which is leveraging intelligence to drive pipelines, and in that case, maybe whatever solving performance issues or whatever it happens to be. But that's the real revolution, the Gen Two. Do you agree with that?

[0:08:29] Alex Salazar: Yes, I do it, but the way I phrase it is, chatbots were really cool, but it was hard to get ROI out of them. I like to reduce all software to workflow automation. From Netflix to Facebook to Workday to everything's workflow automation under the hood. And the problem with chatbots is they're not workflow automation. In order for it to do workflow automation, it has to talk to something, it has to interact with the outside world. That’s still an unsolved problem until we released.

[0:09:05] Danny Allan: So, there's obviously security or potential security issues with this. I'm interested in those, obviously. The Secure Developer, we talk a lot about security and how it impacts. A couple that come immediately to mind. One is obviously the authentication authorisation. I always say the perimeter of AI is really identity, which is a real challenge. There is also hallucinations. How do you know what's happening is actually what you needed to happen? Let's start on the identity side because it sounds like that's where you're very well grounded and focused on. How do you manage authentication authorisation in a world where things are doing something on behalf of someone else?

[0:09:41] Alex Salazar: Yes, it's a great question. So, I think first the premise, software development in the new agentic world is radically different than software development in a web cloud world. Or what I'll say a deterministic versus non-deterministic software development. So, a fundamental premise that you have to go in with is that you cannot trust a large language model. You can't give it credentials, and you can't trust it to make the right decision, and you don't want to over-permission it because it might do a bunch of bad stuff. It's like an intern, right? You want to be very careful with what it does. It's not because it's malicious; it's just super smart in a way.

So, when you think about authentication and authorisation, the other thing that we're thinking about is the way we thought and talked about authentication authorisation in web and cloud world; all of it was about front-door access. How does a user or another machine come into your service? All the vendors, the vendors that I was a member of, all optimised on the login screen or the SSO flow-in.

Well, in the agent world, that problem is easy piece. Now, the problem is, how does the agent itself interact with authenticated and authorised services? Those interactions are happening on the other end of the agent stack. It's not at the front door; it's at the back door, and so authentication authorisation is really different, and the services that matter, the really valuable ones, it has to be on behalf of the end user. It can't be as the agent, and an agent sending an email as itself bot at Arcade isn't terribly valuable, but an agent that can send an email as Alex at Arcade, that's where the value is, because it preserves a bunch of authorisation, and it's also me, so it can really automate me in a way that makes sense.

But that's really hard because the protocols like OAuth, they never envisioned this kind of flow. An agent is not a web app. It might have a web tier for presentation, but it itself is a different system that's beneath the web tier. That's just never been designed before. So, it's very hard for developers to get this stuff working.

[0:12:05] Danny Allan: I have so many questions that come out of that. The first is how do you audit? If the agent is doing something on the behalf of the person that's coming in, does that need to be made known to the third-party service? How do you audit that? Is it the person doing it? Is it the agent doing it to the agent? Do it specifically with an approval from the user? How do you audit that in a GDPR, CCPA, like all of the regulations that we face today. How do you want that world?

[0:12:31] Alex Salazar: Yes, that's probably a podcast on to itself. But I'll give you the really simple answer which is it is a great question to ask, and this is one of the things that OAuth lends to us. If you could figure out how to get OAuth working in an agent, which we did, that's one of the big pieces of IP in the product. With OAuth, there is this disambiguation between who the user is and what the service is. So, that's why when you go integrate two different web apps, you can see the Google screen that says, “Hey, do you want to give Snyk access to this information?” That's disambiguating. The service is registered with Google. All the traffic and all of the actions that service takes are going to be logged as that service on behalf of this user, and the user has to very explicitly grant that access to that service before anything can happen.

So, this is auditable, this is traceable, and it is revocable and manageable. That's really powerful. Within your application, then, it just comes down to business decisions, right? You should be logging it. How do you log what a large language model is doing? Well, thankfully, there are a lot of services out there. LangSmith is a great example from LangChain. But in addition, how you ultimately get the user to be a human in the loop that's really user experience decision that every developer has to go through of like, what am I going to have secondary approval for? Versus, what am I going to allow it to just happen based on a user prompt or some other input?

[0:14:05] Danny Allan: How long do you think we – well, maybe you think forever we'll need a human in the loop. But do you think that within five years, these agents are going to be truly autonomous, truly agentic to use that term? Or do you think, that's not going to happen. Someone has to give it approval explicitly before it goes and does something?

[0:14:24] Alex Salazar: I mean, look, I think it's a gradient. Is an agent ever going to go initiate a wire transfer fully autonomously?

[0:14:30] Danny Allan: Hopefully not.

[0:14:32] Alex Salazar: I would say our mission is to make that a possibility. It's not today, but do I trust a fully autonomous agent to go into my inbox and categorise my inbox? Yes. So, I think it's really a function of value compared to risk. I would say for low-risk operations, autonomy is available today.

[0:14:59] Danny Allan: Right. So, you might have an agent go in and categorise your inbox, but you probably wouldn't have an agent go through your inbox and automatically respond to the people that emailed you and start off a conversation that you're not involved in.

[0:15:08] Alex Salazar: Correct. Now, what it could do is it could autonomously write the drafts for me, and then leave them there in the draft and then have a flow where I go in and approve them all. Like, that's perfectly possible, but that's where the human loop is really critical today in agent flows. Whether it's a chatbot or whether it's like a background service bot or calling ambient agents. Either way, I'm still a big believer in the human loop. But that's not really a statement on AI. The same is true with humans, right? At Snyk, how many people can be fully autonomous in the decisions they can make in the organisation? It depends. The intern can't make a unilateral decision on architecture. They have to have an interaction with somebody else in the organisation for that decision. Agents are the same way.

[0:15:55] Danny Allan: Yes, I tend to agree. I always – the example I give is that we've had autopilot in airplanes since 1912, and we only started flying a few years before that. And we still have pilots in the cockpit. Even though autopilot has existed for a long time, we still require a human in the loop. I think the role will change over time, obviously, of developer in the experience, but you'll still want a human to approve many of those transactions.

Actually, that raises an interesting point. Do you think developers are going to go away? You just talked about agentic, and actually you showed me before this podcast an agent sending an email on behalf of someone else. Do you think that developers are going to disappear and just manage and oversee, or do you think we're going to automatically create the code for the next world of software?

[0:16:37] Alex Salazar: Yes. I mean, as a developer and as someone representing a whole team of exceptional developers, I actually think there couldn't be a better time to be a developer. Life just got so much easier, and the grind work has just been severely minimised. We use Cursor everywhere in the organisation, and Cursor can handle the grind work for us, right? But that frees the whole team up to go work on the stuff that's high value, that requires thinking, that's net new, right? That a large language model's never seen before. So, I think just developers are just getting more for less work. But this is kind of where I sometimes chafe at the idea that agents are going to take all of our jobs.

The history of automation in humanity shows that like humans just up-level what they can do, and I think software developers are just going to up-level in the same way that like frameworks took away a bunch of work. Prior to the Spring framework in Java, developers were grinding out all this stuff that didn't matter, and then Spring came out, and it's like no one tested anymore. That's how I think it'll play out.

[0:17:51] Danny Allan: Yes, I definitely agree with that all the things that you don't want to do, the documentation, the grind work, takes it all away and allows you to focus on the higher-level issues. Back to the risk on the authentication authorisation. Is there a risk, then if the agent holds the credentials? Do you foresee the robot taking over the world using those credentials to do something that it shouldn't do? Is there risk involved in the model where the agent owns the credentials or delegated credentials for the individual?

[0:18:20] Alex Salazar: Well, that's a great question. So, this is actually something we spend a lot of time on in our design of our product, is really how do we help an agent take secure actions while also enforcing behind the scenes, least privileged access without a developer even having to know what any of these words mean. So, I'll give you a really good example. Let's say you're building an agent and you're using Arcade to access Google Drive, so the agent can put in and find files and do tool-based rack. When that agent gets its scopes and claims, its permissions from Google through Arcade, Google, you may have registered your agent with Google and you may have been granted this very large set of scopes and claims, that's what you registered for, but Arcade isn't going to give all of that to the in the moment.

We're going to give the agent the smallest scope token humanly possible for the request they just tried to make. That's important because you don't want the agent hallucinating and accidentally deleting fire. If that wasn't the user request. Obviously, we have all kinds of behind-the-scenes workflows to do mismatch resolution and up level the token we needed. But that's one way to resolve it. The other way is the agent itself never actually holds any tokens. It never holds any credentials. All it can really do is ask the service at Arcade to perform actions on its behalf. So, the agent can only ever do what a developer has made available to the agent as tools from Arcade.

[0:19:55] Danny Allan: That makes a ton of sense, and it reduces the risk of them having autonomy to go do something on their own outside of the transactional workflow that exists. How do you handle hallucinations? Or maybe I should ask, are hallucinations an actual thing? It was obviously at the beginning, and it still sometimes happens. Hallucinations for those listening who you'd have to be living under a rock not to know where they are, but when the LLM makes a bad decision at that. But how do you handle that?

[0:20:26] Alex Salazar: Yes, it's a great question. So, look, hallucinations will always be a problem. We can mathematically prove to you that they will always be a problem, right? Large language models are themselves probabilistic systems, right? So, they're not deterministic, like traditional, if-else checks in software. There's always going to be a chance where it gets it wrong. That is the nature of the product, the nature of a model. You always have to account for hallucinations.

With us, one of the things that we've made available as part of our product is we have this concept of a retrieval tool error. And so, as a developer, if you're using one of our pre-built tools, it's already custom-built. So, let's say you're using one of our Slack tools and you want your agent to go Slack on your behalf, and it guesses the wrong user ID to go send a message to. Instead of Danny Allan, it's Danny Allen with an E, and it errors. Our retrieval tool errors would then pull the actual user list from Slack and in the error message, send that as additional context so that the large language model can now retry with more information. As a result, the error rates drop significantly, and you keep looping as much as the developer chooses to until it gets it right, so the user never sees an error. They just see higher latency. That's incredibly powerful when you make that work.

Another place where hallucinations come in, or more generally, let's call it accuracy, the inverse of hallucination, is how do you know an agent tool is working, right? How do you know that your agent in its large language model is properly selecting the right tools for the right use cases and the right parameters for those tools? Today, people call it a vibe check. They visually check the outputs manually to see if they're comfortable with it, but that's not how software is built everywhere else in the world. So, we also come with what we call our LLM tool eval suite. So, we make it very easy for a developer who's not a machine learning engineer to create these evaluations to see how a large language models perform on accuracy on the tools they've built so that they know how much it's hallucinating based on the inputs.

[0:22:48] Danny Allan: That makes a ton of sense. We do the same thing. We will iterate through – we use AI within our platform, if you will, to generate fixes or do assessment, and we'll iterate multiple times through it, and you'll find each time it goes through it drastically reduces the risk that it gets it wrong. And I suppose, depending on what your task is, so if your task is, that a broken bone, you're a medical physician and it's looking at an image, you probably want to run it through multiple times to make sure that you're not getting a mistake on what the problem is versus you showed me a demo, send an email, probably you don't need to iterate quite so many times on that type of task. I saw on the keynote –

[0:23:26] Alex Salazar: I’ll add one more thing. This is where the power of agentic tools themselves are really important. One of the patterns we've seen historically is that teams are trying to get determinism. They're trying to squeeze hallucinations out by fine-tuned training or bigger models, or a lot more retry logic, when in reality, in many cases, you can just achieve better goals by taking work off of the large language model and offloading it through a deterministic, agentic tool that the large language model is calling.

I'll give you a really simple example. If you were to ask DoorDash, “Hey, order me a pizza for Tuesday.” Do you really want DoorDash reasoning its way through every step in that chain? Or do you want the developer to write a tool that says, “Order food,” and it says, “What's the food? What's the date? And what's the address?” And all I want us to do is say, “Oh, I want to use the order food tool, hear the inputs, and then the code executes.” Hallucinations are a big reason why tools are so powerful.

[0:24:34] Danny Allan: Yes, I sometimes think, and I group it all under AI, but I sometimes think we go all the way to fine-tuned models when you could be using RAG, when you could be using just a simple, I'll say simple algorithm. You're using APIs to do a direct call as opposed to wasting, frankly, the compute cycles to solve what is relatively simple, like relatively simple examples from a code base.

[0:25:00] Alex Salazar: I think the reason is that this field is so new, tool calling wasn't even a reality for most use cases up until a few months ago. God forbid there was any kind of authentication or authorisation involved. It wasn't an option until we released. I don't blame most teams for the path they took. They had very, very few options.

[0:25:20] Danny Allan: What is the impact of these LLMs and AI and agentic models on APIs? Because in the past, if you wanted to do something in a third-party system, you went and you found the API and read up the spec and what was the inputs. That was the only way to do it. Is it possible that APIs themselves will change over the next few years as we have LLMs interacting with them and integrating with them as opposed to actual humans coding to the API?

[0:25:48] Alex Salazar: Yes, it's a really great question. I'm very surprised other people are seeing this issue because it's something we spent a lot of time on. An agent will never understand an API. There are ultimately next-token predictors on natural language. An API is not natural language, right? Unless it's a highly super well-documented API, like a Gmail API, like Goodluck, right? So, I think APIs were designed for a different thing. I think APIs should stay there, and by getting a large language model is a reason through APIs. The hallucination rates are going to go through the roof.

But APIs are required though. So, the APIs is every organisation needs to make sure that anything that they want to do, they need to be exposing via API, right? If you have very little coverage of APIs in your enterprise, you're going to be hamstrung on what your agent can do. But the agent needs its own interface layer, and that's what an agentic tool is. Now, an agentic tool might wrap APIs anywhere.

I'll give you a great example. Gmail has a send or a draft email API, very nice API. But if you want to do a reply and maintain threading, that is not one API call. That is multiple API calls and a fair bit of logic on the developer side to repack the threads with the new information. All of that gets packed into a tool, right? An order food tool is not one API call to DoorDash. It's probably like 10, right? The developer has to go to find the workflows.

So, I would say that agents consume tools, consumed tools might consume APIs to do their job, or they might not might be like a math function or data processing tool, but APIs need to exist. If you want an agent to have a tool that can interact with another third-party service.

[0:27:53] Danny Allan: Yes, I believe that we'll need APIs in their current existence for a long time. I mean, developers are going to continue to call them, but I also think they're going to see an evolution of APIs that are exposed for a different purpose. The same way, I suppose in some ways it's like search engine optimisation. It used to be that you put metadata in the fields, and almost that's a waste now because it just scrapes up all the content and turns it into what's discovered. It's interesting to me because I think that natural language processing an AI interaction, an agentic interaction with systems, will change the nature of APIs into something that's yet to be determined. I don't know.

[0:28:30] Alex Salazar: Well, I mean, I think the evolution of what you're describing, we fully agree with. I think, maybe it's arose by another name, that evolution is an agentic tool. It's an abstraction on top of the API because an API is ultimately a crud operation, right? But agents don't think that; large language models don't think that way, right? And so, there's an abstraction above that, which is an encapsulation of an action, that can be described in natural language. That is how large language models interact with the world. So, that semantic layer on top, that logical abstraction, that is what people are calling a tool. It's still an API in a way. It's just operating a little bit differently.

[0:29:17] Danny Allan: Yes. Well, certainly exciting to see this evolution. We've gone from obviously machine learning to Generative AI to agentic AI. I saw Jensen in his keynote at CES said the next is physical AI. What do you think is next beyond agentic AI? Do you think it's physical AI? Do you think there's something different? Where do you see all of this going?

[0:29:40] Alex Salazar: You asked great questions, by the way. I like to disambiguate the word AI. I think it's become overloaded by the press and by a lot of the vendors. So, I want to separate what the innovation right now really is. The innovation right now is not AI, right? AI is a lot of things, right? A real innovation is large language models. I mean, if you look at everything everybody's building, everything everybody's talking about, you unpack it, it's large language models. I mean, whether they're really big or they're really small or they fight, it's large language models. And almost all of them are transformer-based.

So, it's hard to predict what the next major AI innovation is going to be. I'm not smart enough to tell you that either, but I can tell you that large language models are continuing to evolve, and I can comment on the impact they'll have. What we are seeing is an explosion of capabilities with more built-in reasoning like R1 and O1. We are seeing a very silent rise of small language models, source movements. You go into hugging face, and I think there's like 3,000 forks of Llama. With really good fine-tuning, you can get a very small model to be very fast and very accurate at like one thing.

Ask it about Taylor Swift, it has no idea. Ask a Linux model that only knows Linux about Linux, and it would give you the right answer in time. So, I think that's going to really have a huge impact on what's going to happen in the future because as accuracy goes up, as more system-level functionalities made available to developers like Arcade, like LangGraph, like other things, and as the cost of running these things drops like a stone, we're going to see an explosion of more interesting use cases.

Now, how many of them are physical? I don't know. But if I watch my kids interact with AI, my kids think Google is a voice because they have a Google Home in their room, and they interact with it like voice-based. They're blown away when I show them a search tool I have to type into with a mouse. They're like, “Why?” So, I think the intersection of large language models on the physical world, I think there's going to be a lot happening at the voice level.

[0:32:12] Danny Allan: Yes. I do believe that we're going to enter into a world where the models become verticalised, to use that term, specialised in specific areas. I think I was in Azure the other day, and there was like 1,800 different models in there. So, part of it will be, which model do I want to use for this specific thing? And you may not even need to know that. Maybe it's just something that a model determines what the best model is for this particular thing. Now, latency plays in at some point, but the systems are so fast now that it will abstract even the decision as to which model to use for a particular challenge or problem.

[0:32:46] Alex Salazar: I mean, this is the vision that some people are putting out around agents of agents, like multi-agent systems. Some people at the very forefront are like, “Hey, there's going to be already a pre-built with agent, all up, that handles a very, very narrow task, and they can be used as a building block for your bigger agent.” Too early to tell how that'll play out, but I think it's in line with your hypothesis.

[0:33:08] Danny Allan: Well, if it's nothing else, it is clearly a revolution to use this term that we mentioned earlier. Well, Alex, what makes you most exciting? So, you're doing some very cool integrations at Arcade and integrating with all these systems. You're probably more on the cutting edge than almost any of our audience. What gets you most excited? What gets you out of bed in the morning?

[0:33:28] Alex Salazar: I mean, honestly, what gets me out of bed in the morning is just seeing these jaw-dropping experiences that are now suddenly available that weren't available a few weeks ago or a few months ago. The rate of change, it's the best. If I get really narrow, the thing that gets me most excited is the developer community starting to think about the art of the possible in a way that's beyond just simple chatbots, right? If so many people we talk to are like, “Oh, yes,” hits my knowledge base and gives the user regurgitated documentation in natural language, what I get excited about is those people realising that they can built so much more, that that chatbot can update their accounts and pull information and give them details or go even further and have that chatbot actually pull from the CRM and product information and potentially even try and upsell, cross-sell the user, or even further that an agent might not even need to have a chat interface. That it can be a background process that's running on its own for lower-risk operations in full autonomy, and that's how it all happened.

[0:34:40] Danny Allan: And we're totally missing the point if we limit AI or authentic AI to the only the chatbot environment, how productive do you think organisations are? I saw a recent study from UBS that said that organisations broadly, I think, they had surveyed 400 organisations, had seen a productivity increase of 11%. Whether that's true or not, I don't know. Actually, one of the organisations said they saw productivity decrease from using AI of the 400. If you project out five years, where do you think it stabilises or normalises? How much productivity are we going to get out of these agentic systems?

[0:35:16] Alex Salazar: I can only speak to what I'm seeing in my own organisation, and it's been wild. I mean, just for myself alone, my productivity is a multiple, like an integer-level multiple of what it was before. The problem is that most people don't fully appreciate what's available. So, there's an education problem. People think, “Oh, it's ChatGPT.” I think part of it is a lot more of this making its way into the organisations and beyond just chatbots. But once you get there, it's huge.

[0:35:51] Danny Allan: Yes, I have to say that AI on a daily basis has made me at least twice as productive. And that's including chatbots. I use them for creating emails or posts or content or summarising things, but also for many other things on the code side of things, of completing tasks on my behalf. But I think the biggest barrier, like you say, is education and enablement. That's a cultural change that will come with a generation, like it will come with your children and my children, but we're in this flux period right now where we have many different generations trying to figure it out. Education enablement's a big part of that.

[0:36:28] Alex Salazar: I mean, it's like what happened with clients, the switch on client-server to web, way back when. There was a category of developers who jumped in and learned all the new technologies and were relevant to web. There's a category of developer who didn't believe, who thought client-server was the right way to go, and they held on to that until the very last moment they possibly could, and they were late to the game. I think the same thing is happening, and I see it happening on a regular basis. There are category of developers that are tinkering on the side. They're playing with this stuff. They're wrapping their heads around it. They're trying to build agents, even if it's just for themselves. Those of you who are going to be in the forefront, and there's developers who are like, “Yes, but is AI real and can I really trust it?” Just a passing fad like crypto. Those people are going to have a really hard time once it's obvious that everything's being built this way.

[0:37:19] Danny Allan: Well, I do believe that the companies that have long-term sustainable growth will be those that embrace AI. Like you say, this isn't Web3 or blockchain or whatever. It is truly a revolution that is changing the entire industry. Well, Alex, it's been great to have you on and have this discussion. I get passionate about this because Snyk is also at the forefront of a lot of this AI-changed guardrails for a lot of the code generation and those types of things. But it's been great to have you on, have your perspective. And thank you everyone for joining us for another episode of The Secure Developer. We'll see you next time.

[0:37:51] Alex Salazar: Thank you very much.

[OUTRO]

[0:37:55] Guy Podjarny: Thanks for tuning in to The Secure Developer, brought to you by Snyk. We hope this episode gave you new insights and strategies to help you champion security in your organisation. If you like these conversations, please leave us a review on iTunes, Spotify, or wherever you get your podcasts and share the episode with fellow security leaders who might benefit from our discussions. We'd love to hear your recommendations for future guests, topics, or any feedback you might have to help us get better.

Please contact us by connecting with us on LinkedIn under our Snyk account or by emailing us at thesecuredev@snyk.io. That's it for now. I hope you join us for the next one.