AI Agents Are Leaking Your Secrets. Here's the Fix | Amber Britton, Doppler

Now when it comes to security uh you may think that your biggest security risk is a clever attacker but in most cases it's your own API keys sitting in some Slack message or a forenb file. We have all done it and actually we continue to do that. And now when we start using AI agents to write code, deploy code, clean the code, they make things even worse because every agent needs credentials and then they multiply, they hallucinate it, they will leave it somewhere, they will save it some. Sometimes they will warn you but they are also kind of becoming part of the problem which also means that the attack attack surface or to be able to track is also getting bigger and bigger and by the time you notice a leak the damage is already done. Now Doppler is here to give teams one secure place to manage every secret and today we have with us Amber Britain CEO of Doppler to break it down for us. First of all, Amber, it's great to have you on the show. >> Thank you so much. I'm really excited to be here. >> Same here. And this is uh to be honest with you, this is not problem specific to the security team. It is actually everybody's problem because credential they are part of what we do today. Before we talk about what do you folks do, what problem you're trying to solve. I want to understand the problem area that it comes to or if possible or if you are interested uh tell a bit about the company itself talk about your own background because this is the first time I'm talking to Doppler and since this is a serious problem so I also want our audience to know who we are talking to today. >> Yeah. Yeah. Well, as you said I'm I'm Amber. I'm the CEO of Doppler. Uh my background is uh for over 10 years I've been in startups. I've been at Doppler for several of those years, but my background is all in product management and in marketing. And so product growth kind of became my sweet spot. Um, which is how I came to Doppler and over a few years of our growth and uh things that I was doing here that led to me kind of taking over the the CEO role. >> Awesome. Thank you. Can you now talk about u Doppler? What they are doing? How old is the company? uh did they start with solving this problem or they started solving other problem but as the industry market is evolving because of AI they are focusing on credential security talk about the evolution of the company >> yeah so Doppler is about 8 years old um and we've always done this we've always been focused on solving secrets management for developers and uh to that end to what you said kind of before on you know secrets isn't just a like company problem it's All developers have this problem. It's why we always and as far as I I plan to always have a free entry point for students learning how to code. I'd rather you code with a secrets manager and learn how to do that at the beginning than than later. Um and developers have a lot of hobby projects. There's people with side projects. And so we always want you to have a free place um to be able to store and and manage your secrets. Um and then when you become a you know startup gets funded, you start taking off and getting a bigger team. There's different features and different uh you [clears throat] know sets of problems that you'll have to solve that we want to be there to do. But we've always been a secrets management platform. Um we've always been a cloud-based secrets management platform. That's that's shifted recently. We now have an on-prem version as we've moved up market. Um but the basic problem we solve is that the to your point every team every person but but focusing on teams has credentials somewhere. You've got them in ENV files. They might be in Slack threads or emails or you know this tool or that tool and not everyone has a single place to manage them. And when you don't want to encounter that problem is when you're having the worst day of your life in the event of some sort of a breach. uh that's when you don't want to have to figure out where did this credential come from where how do I rotate it who all has access where is it going to break having a place to let you fully manage the kind of this control plane that sits on top of wherever you're storing them storing them is part one but then having a way to manage the life cycle of that secret for everyone that's supposed to have access makes that potential disaster much easier to deal with and much less of a headache and probably one that doesn't happen in in the first place. Um, and and I think to another thing you said earlier, we typically are focused on the developer experience and selling into our, you know, being a product that developers use, but lately agents are starting to outnumber individual developers and that's that's definitely changing the game a little bit in how secrets are used. But we pride ourselves in being kind of the security tool that engineers actually love to use. We all need uh credentials, secrets uh and sometimes managing it does uh become challenge. Most cases it becomes a big mess and sometimes organizations teams they look for solutions and sometime market is overwhelmed with solution. We always you know wet one solution other solution but this is something you know sometime it become sticky once you have moved a secret somewhere you don't want to keep moving it you know around because it becomes once again fragmented mess. uh can you talk about the importance of teams that why they should have dedicated platform for managing secrets versus a whole fragmentation? >> Yeah, I think um you know when you think about a solution like us, you think that the problem is I don't have a place to put secrets and that's not necessarily the problem to solve. The problem is that people have a all my secrets are everywhere problem which is what we call a secret sprawl. Um, so somebody's onboarding on the team and they're slacking like, "Hey, can I get this key for this or this key for that?" And so you're giving those via Slack or email. And then you've got config drift between staging and production cuz things are changing or maybe someone manually accidentally committed a secret and that gets pushed and then revoked but it's still in a fork somewhere. And without like that that central place that everything is coming from, that problem just gets worse and worse. I no one actually sets out to like we want to do secrets management badly in our team. Um that's not anyone's goal. It's something that happens over time. um it just this problem just starts to sprawl and all of a sudden there's some incident or event or security issue that really sheds light on it in a way you don't want there to be light shed on a problem like that. Um so it's about solving it before it gets there. But most organizations have this problem in some way and they come to us when it's like we're spending too much time and energy trying to solve this and that's taking away from our core competency of whatever product we serve. One one of our customers Ada um said in a case study to us they said for about themselves we are not a secrets management company we are an AI customer service company and they had started to become a secrets management company because they were spending so much time trying to solve this problem right so that that's a big reason why it's better to have a dedicated solution for this so you don't have to become and continue to be the expert in this other thing >> as you rightly mentioned and we have done it ourselves somebody an employee quickly needs something you will share the key secret credentials on Slack or whatever messages and now it is there now you cannot revoke that message it is out there uh talk a bit about how does Docker actually work how are no keys shared managed who I mean who has access to it also revoking a key can also break a lot of services as well you cannot just turn it off so can you just if possible talk a bit about the inner workings so when developers security teams they look at it, they're like, you know what, that does make sense. >> Yeah. I I think that kind of goes into what makes us different and makes us unique is our approach is very much centered around the developer experience and how they work. There's a lot of security tools that are meant to be used by developers but aren't built for them. They're built for some security executive who wants a dashboard and then to use it is cumbersome. And engineers are an efficient group of folks and they are going to find a way around it if it is painful and difficult to use. So we pride ourselves very much on the developer experience and that extends all the way to even our pricing is very clear and easy to understand. You don't need some complex calculator. Um so the but the way it works is especially I'm going to talk about more about like when it's set up and working properly. Um you you can import all of your secrets into Doppler. So we will write to wherever you want to read from. But at first you can set up all the syncs. We have integrations with all the providers you would expect. You can set up all of your syncs to populate secrets from wherever you have right into Doppler. You can import ENV files. Um and then you can, you know, there's lots of granular roles and permissions, but we follow like a project uh environment config structure very similar to, you know, how GitHub uh mirrors their repo structure. So it's very familiar to developers from day one. Usually, you're going to set up your projects um in terms of like different applications or different services. Every company does it different. Some can have hundreds and hundreds of projects. But you'll set those up. You'll set your syncs up. And then you'll bring your team in. And you can have really granular roles and permissions per team. You can have groups. You can also integrate with, you know, different providers to just like autoimp import whatever users you want and assign them access to the secrets that they need. Um most people aren't going to be in the Doppler UI every day. maybe like your manager of your team is your leader of your team to configure access or make sure things are rotated. Um, but the end user is going to likely download our CLI, maybe our VS Code extension, um, connect their accounts, you know, make sure that they're all connected to GitHub, and they're going to inject secrets at runtime. Um, so that they are working on whatever they're working on. They're building out your product and they're just injecting secrets as they need them without ever needing to see the secret. for those that need to see it. You can definitely do a lot of pretty much everything through our CLI, but you can also go into the pro product. You can create service accounts for agents use cases um configured with OIDC. You can set up a change request workflow so that any addition, deletion, change to a secret, that whole diff is visible and logged for compliance reasons. You can take all of our audit logs which track every who read a secret, what IP they read it from, um like what device it was on. All of that is in our logs for compliance reasons. You can port all of that to whatever provider you like. Um which is really good for your security teams to have in the event that you need any of that. Um but for the day-to-day developer, you just get to work how you want to work and you're injecting those secrets as you need them. And then for your team lead, for your security lead, for your head of engineering, you're able to make sure that secrets are regularly rotated, that stale configs are removed or uh you know provisioned. If you need to share a secret with someone else who might not have access, we have uh Doppler share built into the product, which is basically a free tool that we offer anyway outside of our product to share any piece of data securely. Um but we have a Slack integration for that and you can that is built into the product itself. So if you go to share a secret, it's not just in Slack. You have to have access to that link and it auto expires and there's some other criteria around that. Um and that's that's overall that's the gist. Um that singular place to use secrets as you need them, but then to also fully understand who has access to these immediately provision, immediately deprovision and rotate everything someone touched when you deprovision. Make sure the right people have access at the right time. Um and then everything is logged for compliance reasons. And how is your approach uh different from your competitors because this secret management is you know even whe AWS big cloud providers also offer it and then there are specific player they one password I mean there are so many players in this space how is your approach different and as you also mentioned it's more focused on understanding not only developers painoint but also how clever developers are that you know they want to find the easiest solutions easiest way to solve a solution and sometime it can lead to some compromises. So talk about your approach and how is it different from others. >> Yeah, it really is that developer experience that it from the moment you like interact with our marketing it goes all the way from that beginning, right? We I don't ever want someone to read uh uh one of our landing pages on our marketing site and be like I have no idea what that I just read. Like we don't want it to be fluffy and verbose for no reason. We want to speak to developers, use the terminology that they use, be in the places that they uh operate in, that they want to discover tools in. Um, and once you sign up for the product, that's really evident right away. Um, the so that that is a really important concept. And there are lots of competitors out there, agentic use cases, like I feel like everyone's trying to vibe code a new solution to another software every day. There's a cost to that uh to to maintaining those for sure. And so we I am the first one to tell you if that competitor is better for you. I'm not going to try to force someone to use Doppler if it's not a good fit for them and they wouldn't be happy here. In terms of AWS Secrets Manager, we have a lot of companies that come to us and they're like, "Oh, I'm using AWS Secrets Manager or GCP Secrets Manager." I don't consider them competitors. We integrate with them. Some people have done a lot of work to set those up and uh want their security team wants them to be, you know, using the way that was set up and that's fine. we can connect with AWS Secrets Manager because you're likely not a single cloud company. You're likely multicloud and you want to be able to use secrets in local development. So you can integrate with AWS Secrets Manager, pull all those secrets into Doppler. That uh AWS instance now becomes a read replica. We'll keep that up to date. But Doppler becomes the place that you update and change and like manage your secrets day-to-day and your team uh that has access to those secrets along with all of the other places that you have secrets. Uh that wouldn't be possible with AWS. And some of the other tools that are out there that are competitors to us are just not built for the individual developer. They're not built for their workflows and they're not as flexible to their workflows or they're really expensive to maintain. But if you've got if your organization has the money to spend and wants to have a you know more complex product that has a dedicated team that they hire to just maintain that piece of software like by all means if that's a better solution for you go for it. We pride ourselves on being a tool that you don't need to have that for. You get to invest that money and staffing back into your own company and feel really confident in our approach handling that for you. And like I said, it extends to our pricing even being per seat like human seat. We don't charge for machine identities. Um so if you have 50 developers, you need 50 seats, right? You don't uh and you may not even need all 50, but typically if they need to ingest secrets, they need a seat and you can spin up all the agentic use cases you want. We don't charge for machine identities. >> Excellent. Thank you. And since uh that's a perfect segue that as I mean you also mentioned that companies are wipe coding and everybody's coding there are pros and cons for that but it has also changed the whole secret management because of the rise of EI agents agent unlike humans you know agents can just be all over the place. Uh how has the kind of rise of AI agency impacted your market your space your approach to secretress management? Yeah, it's definitely been an interesting point of conversation here at Doofler since uh it was really start first starting to pick up. Um machine identities are outnumbering humans in a crazy uh a crazy amount. Um I think it was like 42 to1 and then 82 to1. I'm sure it's higher now. Um and I was reading something the other day. I think it was something from Gartner that predicted by 2028, so that's what a year and a half from now. um that AI agent like abuse attacks or breaches as a result of abuse were going to be about one quarter of all breaches. And that's pretty frightening. Um because agents essentially are just breaking them they're breaking some of the assumptions that we made about secrets. Um one of those being provisioning is humanpaced. You used to have to like open a god forbid Jira ticket to get access to a service account or get a service account created. But now a developer can spin up like a hundred agents in an afternoon and that the agentic use cases there's a lot of pressure from on top at at organizations to like use AI more and be more productive and it's that is happening faster than security teams are governing access and understanding what's happening there. So making sure that you're doing that in a secure way is really important. [clears throat] Um because the other thing that breaks is like scoping. We used to think that you could scope permissions by reading the code and who needs access to what part of it, right? And that doesn't work for agents because the agent decides what it needs at runtime. And so what results is people giving agents really really broad access so that it doesn't get blocked and can do its job. But now that's even if you're prompting it to like please don't do this thing, it has access to do that thing and eventually it's going to go do that. Um, so being able to know what's happening there and when something is happening and who what user that's attributed to, like that's really really important. Um, that is definitely changing the game. Um, and then now there's like another place that you didn't initially think about where there's a new like potential leak or attack vector because you can't unprompt a secret. You can't you can't remove that from a prompt uh with an agent. So once it's in their context window, it's in there forever and it's going to be in those logs and you can't get rid of that. So knowing how to not give it that access directly, not to not to give it um a direct credential is really important or give it much more scoped like just in time type of access so that it doesn't have this long-standing access. Those things become more and more important now >> beyond you know of course we talked about the whole evolution of AI and how developers are working. What are some other trends that you are seeing in cyber security security space that you think that teams who are managing secrets credentials they should be aware of? >> Um yeah I think one [clears throat] it it happens here at Doppler 2 is actually just happening before I jumped on here. Um, everybody, every product has an MCP server now. And when we vet software to bring into an organization, you're typically have, you know, you typically have some sort of security process, security review for that vendor. And it's but it's based on your general, you know, original use of that vendor. Now that all of these vendors have MCP servers, there's this um there's this push to connect them and get access to them and how it would help you be faster or whatever. and that isn't being treated any differently. You've got the first initial review done on the vendor, you've been using it for a while. What's the deal with the MCP server? So, those are growing. Um, that usage is growing, but we should be treating those like new integrations because they are now being connected to systems and giving access to different systems that didn't happen before and that now makes them a potential bigger risk. So my like this happens now and there's not review processes specifically to MCP servers at all companies other than that initial vendor one and it happens here at Doppler when someone will ask for you know us to allow an installation of an MCP server. My default is a lot of questions or no because I want to make sure we understand what we're about to do here and is there a potential risk that we need to be aware of and I don't think that's being talked about enough at orgs and that's going to start to be a lot more locked down and scrutinized. Um, and I think the other one is just about uh machine identities being getting more mature that whole process. If you think about like password management, um, I don't think we're not seeing so many instances of hackers or attackers like breaking the door down anymore and getting in. They're now just like logging in with valid credentials that they found uh, that still work and kind of just walking through the unop unlocked front door. And human identity has had a decade of investment and lots of regulation around that. Lots of security compliance. We're going to start to see the same thing around machine identity for sure cuz we machine identities were just like I guess you just put them in a in a storage solution in some sort of a vault and call it a day. Um and we're not thinking about the long-term effects there. So I think we're going to start to see a lot of regulation. And how different is you know when you look at machine identity versus actually agents get their own identities and permissions uh just like people do because uh that I mean in most cases people are organizations are treating agents as employees. >> Yeah they uh they definitely need to have watch over them. You need to be monitoring logs and understanding what it can do and what it's able to access and what can it give access to itself. that that was something that recently came out I think in one of the breaches where the agent asked another agent and convinced it to give it access right so that's going to happen more and more if you're not tracking exactly what's happening if you're not on top of what those agents are doing looking setting up alerting and having um policies around making sure it can't do that you're at least reviewing what's happening there um you have to give it the same rigor that you would with human seats with those on your team where you're going to be monitoring what they're doing and what's happening There you you have to have that same rigor around machines >> depending on who you talk to. Some organizations some teams take it very very seriously the whole secrets management some teams are like nah it is okay we are not uh if there's a team organizations who is like you know what we need to get really serious about it before it becomes a big problem. What is your advice? Of course they can sign [laughter] up with Doppler. But what is your their advice to because this is also not just a solutions technical problem. It also goes back to the whole culture problem because that's how you share things right sharing on Slack or putting something in the file. So it is also more of like a process and culture problem as well. What advice would you have for the team or the organizations that this is how you should get started? Um I think one you have a lot of evidence that you can use. So secrets Doppler is definitely an early adopter. Secrets management was a was a product that people knew there was a problem they wanted to solve but there were other problems that were more top of mind to solve. And now you can point to so many breaches that are the result of a leaked secret uh that gave someone backdoor access to something they shouldn't. And a solve for that is rotating those secrets. But it's impossible to do if you don't know where they all are and can't easily do that. Some organizations rotation can take years, you know, just to track all the instances down and make sure it's provisioned right. Can be a crazy labor of love. Um, so you can point to a lot of those breaches and want to make sure that doesn't happen to you. Um, so you want to make sure your stuff is locked down. And you don't have you, every industry is affected by this. If you build software, you need to be concerned about this. If you have an engineering team, you have secrets. And you should also be concerned about your vendors. Do your vendors have a secrets management solution? Because that could give them the key to something that affects your data. And so, you want to make sure that they're using some sort of solution and h can respond quickly in the event there is an issue and that they're regularly rotating secrets. But internally, I think you can use a lot of the uh breach results that have happened as some proof points of why you should do it because you don't want to be in the news. Um and then there's a huge developer productivity time savings. Uh we have lots of case studies from our customers around that specifically the amount of time it took to onboard new engineers, offboard engineers, the amount of time they were spending tracking down credentials. Like we have teams that have quantified that and were able to just drop that to nothing, which was way more time they're spending on their current product made their team much more efficient and productive. That's another huge win that you can add to that. Um, but it's it's kind of like uh sometimes it's like insurance, right? You're the biggest payoff is not having a breach as a result of a secret and that may you may never see the direct, you know, monetary value of that, but you'll because you'll never have a breach. Um, but so there's also the developer productivity case you can make and get started is just like play around with some of the solutions that are out there and find one that works for your team and your workflow. There's also possibility that you not possibility in most cases it may be possibility that some of your customers client they also operate in heavily regulated industries or compliance industry. How how do you meet those requirements? >> Historically we didn't if you were in like a really heavy regulated in uh industry you didn't want any you didn't want secrets to live outside of your infrastructure. So you typically wanted a self-hosted solution. And so historically we just didn't go after those uh those industries. Um, we've recently, you know, just had a barrage of requests from folks in those industries wanting to use Doppler, loving what we do, but needing a self-hosted version. Um, so we did create that um back in June and now we are able to work with those more regulated industries who have uh that requirement and we are here to handhold them kind of through the process um and we can we can meet their needs. Now >> remember thank you so much for joining us and uh sharing these insight with us. It was of course since is we are everybody's moving towards AI AI agendas. So this is becoming a serious problem and Doppler is solving this problem. Thank you so much and folks who are watching please if you want to learn more about Doppler and how they can solve your secrets management problem. Please go check.com and once again thank you so much and I look forward to chat with you again. >> Thank you so much. It was great to be here.